[openstack-dev] [ironic workflow question]

严超 yanchao727 at gmail.com
Wed Jun 4 13:51:47 UTC 2014


Yes, but when you assign a "production" image to an ironic bare metal node.
You should provide *ramdisk_id and kernel_id. *
Should the *ramdisk_id and kernel_id* be the same as deploy images (aka the
first set of k+r) ?
You didn't answer me if the two sets of r + k should be the same ?

*Best Regards!*


*Chao Yan--------------**My twitter:Andy Yan @yanchao727
<https://twitter.com/yanchao727>*


*My Weibo:http://weibo.com/herewearenow
<http://weibo.com/herewearenow>--------------*


2014-06-04 21:27 GMT+08:00 Dmitry Tantsur <dtantsur at redhat.com>:

> On Wed, 2014-06-04 at 21:18 +0800, 严超 wrote:
> > Thank you !
> >
> > I noticed the two sets of k+r in tftp configuration of ironic.
> >
> > Should the two sets be the same k+r ?
> Deploy images are created for you by DevStack/whatever. If you do it by
> hand, you may use diskimage-builder. Currently they are stored in flavor
> metadata, will be stored in node metadata later.
>
> And than you have "production" images that are whatever you want to
> deploy and they are stored in Glance metadata for the instance image.
>
> TFTP configuration should be created automatically, I doubt you should
> change it anyway.
>
> >
> > The first set is defined in the ironic node definition.
> >
> > How do we define the second set correctly ?
> >
> > Best Regards!
> > Chao Yan
> > --------------
> > My twitter:Andy Yan @yanchao727
> > My Weibo:http://weibo.com/herewearenow
> > --------------
> >
> >
> >
> > 2014-06-04 21:00 GMT+08:00 Dmitry Tantsur <dtantsur at redhat.com>:
> >         On Wed, 2014-06-04 at 20:29 +0800, 严超 wrote:
> >         > Hi,
> >         >
> >         > Thank you very much for your reply !
> >         >
> >         > But there are still some questions for me. Now I've come to
> >         the step
> >         > where ironic partitions the disk as you replied.
> >         >
> >         > Then, how does ironic copies an image ? I know the image
> >         comes from
> >         > glance. But how to know image is really available when
> >         reboot?
> >
> >         I don't quite understand your question, what do you mean by
> >         "available"?
> >         Anyway, before deploying Ironic downloads image from Glance,
> >         caches it
> >         and just copies to a mounted iSCSI partition (using dd or so).
> >
> >         >
> >         > And, what are the differences between final kernel (ramdisk)
> >         and
> >         > original kernel (ramdisk) ?
> >
> >         We have 2 sets of kernel+ramdisk:
> >         1. Deploy k+r: these are used only for deploy process itself
> >         to provide
> >         iSCSI volume and call back to Ironic. There's ongoing effort
> >         to create
> >         smarted ramdisk, called Ironic Python Agent, but it's WIP.
> >         2. Your k+r as stated in Glance metadata for an image - they
> >         will be
> >         used for booting after deployment.
> >
> >         >
> >         > Best Regards!
> >         > Chao Yan
> >         > --------------
> >         > My twitter:Andy Yan @yanchao727
> >         > My Weibo:http://weibo.com/herewearenow
> >         > --------------
> >         >
> >         >
> >         >
> >         > 2014-06-04 19:36 GMT+08:00 Dmitry Tantsur
> >         <dtantsur at redhat.com>:
> >         >         Hi!
> >         >
> >         >         Workflow is not entirely documented by now AFAIK.
> >         After PXE
> >         >         boots deploy
> >         >         kernel and ramdisk, it exposes hard drive via iSCSI
> >         and
> >         >         notifies Ironic.
> >         >         After that Ironic partitions the disk, copies an
> >         image and
> >         >         reboots node
> >         >         with final kernel and ramdisk.
> >         >
> >         >         On Wed, 2014-06-04 at 19:20 +0800, 严超 wrote:
> >         >         > Hi, All:
> >         >         >
> >         >         >         I searched a lot about how ironic
> >         automatically
> >         >         install image
> >         >         > on bare metal. But there seems to be no clear
> >         workflow out
> >         >         there.
> >         >         >
> >         >         >         What I know is, in traditional PXE, a bare
> >         metal
> >         >         pull image
> >         >         > from PXE server using tftp. In tftp root, there is
> >         a ks.conf
> >         >         which
> >         >         > tells tftp which image to kick start.
> >         >         >
> >         >         >         But in ironic there is no ks.conf pointed
> >         in tftp.
> >         >         How do bare
> >         >         > metal know which image to install ? Is there any
> >         clear
> >         >         workflow where
> >         >         > I can read ?
> >         >         >
> >         >         >
> >         >         >
> >         >         >
> >         >         > Best Regards!
> >         >         > Chao Yan
> >         >         > --------------
> >         >         > My twitter:Andy Yan @yanchao727
> >         >         > My Weibo:http://weibo.com/herewearenow
> >         >         > --------------
> >         >         >
> >         >
> >         >         > _______________________________________________
> >         >         > OpenStack-dev mailing list
> >         >         > OpenStack-dev at lists.openstack.org
> >         >         >
> >         >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         >
> >         >
> >         >
> >         >         _______________________________________________
> >         >         OpenStack-dev mailing list
> >         >         OpenStack-dev at lists.openstack.org
> >         >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         >
> >         >
> >         > _______________________________________________
> >         > OpenStack-dev mailing list
> >         > OpenStack-dev at lists.openstack.org
> >         >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/33780a2f/attachment.html>


More information about the OpenStack-dev mailing list