 Okay, let's get started. Good afternoon, everyone. Thank you for coming. I'm Sato Moria from Hitachi. Today, I'd like to talk about Ironic and the Cinder Integration. At first, I mean, I'd like to introduce myself. I'm Sato Moria, and I'm a researcher working for Hitachi, and my research topic is mainly improving open source software. Such as Linux, QEMU, OpenStack, et cetera. And yes, I'm OpenStack ATC from Juno, and my company, Hitachi is a huge conglomerate company, and so we have a wide variety of business group from IT, social infrastructure, plant engineering, and yeah, as you can imagine, we're a huge system. This is today's outline. First, I talk about background and introduce Ironic itself, and then explain standard storage support with Ironic. Let's move on to introduction. The background, our company focuses our business on enterprise system and IT systems, back in social infrastructure. In those systems, BMTL server are commonly used to satisfy their requirement. Those systems are really hard requirement for the reliability, availability, serviceability, and stability. And also it needs some performance, in particular, latency. But on the other hand, even in those kind of systems, demand for cloud is growing and growing and growing. So we'd like to use Ironic to deploy these systems in OpenStack environment. So what is Ironic? Maybe you guys know the Ironic. But I'll explain again. The Ironic is the OpenStack BMTL provisioning service. And it's like a BMTL hypervisor API. Via this API, users can manage BMTL nodes in the same way as virtual machine. This picture shows it. In the left side, there's a hypervisor and it manages virtual machine. And it also provides API, managing API to Nova. In the left side, there's Ironic. And Ironic manages BMTL nodes. And it provides management API to Nova. So users can control virtual machine and BMTL node via Nova API. This is a simple Ironic architecture. Ironic consists of six parts. Ironic API, message queue, Ironic conductor, database, drivers, and Nova Ironic driver. Ironic API is a service by which administrator and other services interact with BMTL node. And the conductor is a core component of this Ironic. And it does the bulk of work. And drivers. Ironic needs to support various hardware and deploy method. So Ironic introduces driver framework. This is an example. For power management, Ironic supports IPMI, MT, IRO, DRAC, and for deploy, Pixie, and Agen. And similar to other OpenStack projects, Ironic uses database to store bare metal information. And it also uses message queue to communicate inside Ironic project. And the last one is Ironic drive, Nova Ironic driver. It is not actually the Ironic itself, but it provides interface between Nova and Ironic. This is a BMTL node provisioning flow in the case of IPMI and Pixie. First, user request BMTL instance to Nova, and Nova does some work. And after that, Nova calls Ironic API to create a bare metal instance. After Ironic API gets the request, it sends that request to conductor. And then Ironic conductor gets image from glance and set up the network. And then after that, Ironic and the driver turn on the bare metal node and install OS image and reboot. The finally, user can use bare metal instance. As I explained, we can manage bare metal server, bare metal node, with Ironic. But unfortunately, we need some additional features to use Ironic in a business. One key feature is external storage support. Many users in enterprise area deploy database servers to bare metal node. And in that environment, external storage is commonly used for its data store. And the second key feature is network isolation. Current Ironic supports only flat network. It means all the bare metal nodes are on the same network. It's not acceptable for multi-tenant environment. These are another features I don't actually have. But these two features are really essential for us. And based on our customer's requirement, this presentation focuses on external storage support in Ironic. As you know, in OpenStack world, sender-managed external storage such as FiberChannel, iSCG, and RBD. So our goal supporting external storage in Ironic means making Ironic support sender volume. The supporting sender volume divided two cases. The one is boot from volume, and the other is boot from local hard disk with data volume. This picture shows the necessary function for each case. For boot from volume, Ironic needs to follow in functions, attaching volume to bare metal node, and install OS image to sender volume, and configure bare metal node to boot from volume. On the other hand, to boot from local hard disk with data volume, Ironic needs to attach volume to bare metal node, and install OS to local hard disk, and configure the bare metal node to boot from Pixi or local hard disk. Fortunately, sender and Ironic already support some functions. For example, the install or operating system to sender volume is always already supported by sender. And similar to that, install OS to local hard disk or boot set up the node to boot from Pixi or hard disk is already supported by Ironic. So to make Ironic support sender volume, we need following two functions, attaching volume and configure bare metal node to boot from volume. And attaching volume is common in both cases. So I set our goal is to support boot from sender volume in Ironic environment. This is a basic idea for boot from volume support. To boot an instance from volume, node, sender and Ironic need to work together. Especially, node should orchestrate them. Fortunately, OpenStack and Nova already has a framework for boot from volume, because it supports the boot from volume for VM. So why don't we use it for bare metal instance? So let's use it. This picture shows the boot from volume framework in Nova. First, user request Nova to create an instance which boot from volume. And then, Nova asks sender, hey, sender, please create a new volume from this image. And sender create an image and copies OS image from glance. After that, Nova asked hypervisor, where we connect the volume. And hypervisor answers the initiated information to connect to volume. After that, Nova asks sender to connect the volume to the initiator. And sender touches the volume to the initiator. After that, sender returns target information to Nova. It's number eight. And then, Nova passes target information to hypervisor. It's number nine. And after that, Nova boots an instance from it. The number ten depends on hypervisors. So in the case of KVM, Nova does mount the volume to the hypervisor. And they find the volume as a root disk and start the instance. This works well, only for VM. So what's the missing piece for bare metal node? Here it is. The missing piece are number five and number nine and number ten. And number five is getting initiated information from hypervisor. And number nine is put the target information to hypervisor. And number ten is configure hypervisor or bare metal node to boot from that volume. This is a detailed picture. As I explained in the previous slide, there are three missing steps. One is getting initiated information. And the second one is passing target information to Ironic. And the third one is setting up bare metal node to boot from volume. To fulfill these missing steps, Ironic should have following three functions. The first one is managing initiator and target information. And the second one is configure bare metal node. And the third one is communicate initiator and target information between Nova and Ironic. From next slide, I'll explain each topic deeply. The number one, this is managing initiator and target information. This is the main part of this enhancement, I think. To managing initiator and target information, we add a new table and attribute to Ironic database to store initiator and target information. And also add the restful API to create, read, update, delete, dot information. And of course, we enhance the conductor to go between API and the database. We already proposed spec for this function. So if you interested in detail, please look at this spec. Second one is configure bare metal node to boot from volume. In the Ironic, each deploy method is implemented in driver. For example, the pixie driver and the agent driver, the virtual media driver. So we add boot from volume driver. It configures bare metal node to boot from specified volume. And it needs to control the BIOS or firmware. And this driver, after the configuration, this driver turns on the node. Third function, this is a communicate initiator and target information between Nova and Ironic. Nova Ironic driver provides interface between Nova and Ironic. So to support communication, we add two functions into Nova Ironic driver. The one is get initiator information from Ironic API. And second one is put target information to Ironic API. The spec for this feature from HP, so if you need, if you want to know detail, please look at this. With these three features, we can boot the bare metal node from volume. So I'll explain the deployment flow. Before the deploy, we need to prepare the environment. That is administrator registers the bare metal node's initiator information to Ironic. So I don't maybe have initiator information at this point. And let's deploy. Use execute Nova boot and then Nova asks sender to create a new volume. And sender create a new volume and get image from glance and write it to the volume. And after that, Nova gets the initiator information from Ironic. The Ironic gets the initiator information from Ironic database and it returns to Nova via Ironic API. With this initiator information, Nova calls sender and asks, please attach the volume to this initiator. And after that, sender attaches the volume to that bare metal node and reply to Nova, this is the target information. And Nova passes this target information to Ironic and Ironic save it to database. And after that, Nova asks the Ironic to boot bare metal node from the volume. After Ironic gets the request, Ironic configure the bare metal node to boot from specified volume. And using target information and then Ironic turns on the bare metal node. Now users can use bare metal node which booted from sender volume. This is the current status. Now I'm proposing and discussing the spec for this feature. There are three specs for boot from volume support. The one is the managing initiator and target information in Ironic. And second one is Nova Ironic drive enhancement. This is from HPGuys. And the third one is a new driver to boot from volume. This is also from HPGuys and so it only works for each service. Also we posted patches which implement this specs bug. So if you are interested in this feature, please review and give feedback to spec and these patches. I'd like to these features implement in this release cycle. And to the next step, we are thinking of first boot support with sender back-end support in Glass. Currently the image copy to the sender volume is used by the network copy and DD. It sometimes puts a load on the network and IO. So with this feature, copy is we try to upload the image copy to storage. If you are interested in this feature, we have another session about this feature. So let's please attend it. To support boot from volume, we are trying to implement three functions. One is Enhanced Ironic to manage initiator and target information. And second one is a new driver for boot from volume support. And third one is Enhanced Nova Ironic driver to communicate initiator and target information between Nova and Ironic. And now we are discussing the spec and the patches in the community, so please review and give feedback. This is all I have today. Thank you very much. Is there any questions? This is a clarification question. You suppose you would use the hardware initiator, Ithcagi initiator in that case, right? In this talk, I only talk about the hardware initiator, but we can support the software initiator Ithcagi case. But we need some enhancement. Already? Yeah. Okay, I did some investigation. Thank you. And in the case of use of hardware initiator, you need some hardware support to configure the initiator from the network, right? So I suspect there would be a lot of compatibility problems between hardware vendors. Yes, so we develop the driver for each hardware, I think, each vendor. Okay, thank you. Hi, I have several questions from the sender. First of all, I would like to ask you to attend our meetup on Friday. We'll discuss something related to it. Sure. And what about security issues? Because if Ironic instance will access to storage network, what about multi-tenant networks? How do I handle it? So you ask me the multi-tenant network support? Yeah. I think there's another session in the next room from the Devananda or Jero or PTL. So I think you can ask them. Okay, did you try to make it working without NOVA? Because in sender we want to attach and boot Ironic instance without NOVA support. Did you try something like it? At this point I don't have the requirement that case. So I think you or other guides propose that kind of future. So I think we need to discuss by day. Thank you. Okay, any other questions? Have you thought about doing this without adding a database to the Ironic model by using instance info? Or what are the other fields that Ironic provides to hold information like this? I think we are discussing how to... Thank you very much.