<div dir="ltr"><div><div><font size="4">Yes, but when you assign a "production" image to an ironic bare metal node. You should provide <b><span style="color:rgb(255,0,0)">ramdisk_id and kernel_id. </span></b><br>
</font></div><font size="4">Should the <b><span style="color:rgb(255,0,0)">ramdisk_id and kernel_id</span></b> be the same as deploy images (aka the first set of k+r) ?<br></font></div><font size="4">You didn't answer me if the two sets of r + k should be the same ? <br>
</font></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font face="comic sans ms, sans-serif" size="4"><b><i>Best Regards！</i></b></font></div><font face="comic sans ms, sans-serif" size="4"><b><i>Chao Yan<br>
<font>--------------<br></font></i></b></font><font face="comic sans ms, sans-serif" size="4"><b><i><font>My twitter：Andy Yan <a href="https://twitter.com/yanchao727" target="_blank">@yanchao727</a></font></i></b></font><br>
<font face="comic sans ms, sans-serif" size="4"><b><i><font>My Weibo：<a href="http://weibo.com/herewearenow" target="_blank">http://weibo.com/herewearenow</a><br>--------------</font><br></i></b></font></div></div>
<br><br><div class="gmail_quote">2014-06-04 21:27 GMT+08:00 Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Wed, 2014-06-04 at 21:18 +0800, 严超 wrote:<br>
> Thank you !<br>
><br>
> I noticed the two sets of k+r in tftp configuration of ironic.<br>
><br>
> Should the two sets be the same k+r ?<br>
</div>Deploy images are created for you by DevStack/whatever. If you do it by<br>
hand, you may use diskimage-builder. Currently they are stored in flavor<br>
metadata, will be stored in node metadata later.<br>
<br>
And than you have "production" images that are whatever you want to<br>
deploy and they are stored in Glance metadata for the instance image.<br>
<br>
TFTP configuration should be created automatically, I doubt you should<br>
change it anyway.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> The first set is defined in the ironic node definition.<br>
><br>
> How do we define the second set correctly ?<br>
><br>
> Best Regards！<br>
> Chao Yan<br>
> --------------<br>
> My twitter：Andy Yan @yanchao727<br>
> My Weibo：<a href="http://weibo.com/herewearenow" target="_blank">http://weibo.com/herewearenow</a><br>
> --------------<br>
><br>
><br>
><br>
> 2014-06-04 21:00 GMT+08:00 Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>>:<br>
> On Wed, 2014-06-04 at 20:29 +0800, 严超 wrote:<br>
> > Hi,<br>
> ><br>
> > Thank you very much for your reply !<br>
> ><br>
> > But there are still some questions for me. Now I've come to<br>
> the step<br>
> > where ironic partitions the disk as you replied.<br>
> ><br>
> > Then, how does ironic copies an image ? I know the image<br>
> comes from<br>
> > glance. But how to know image is really available when<br>
> reboot?<br>
><br>
> I don't quite understand your question, what do you mean by<br>
> "available"?<br>
> Anyway, before deploying Ironic downloads image from Glance,<br>
> caches it<br>
> and just copies to a mounted iSCSI partition (using dd or so).<br>
><br>
> ><br>
> > And, what are the differences between final kernel (ramdisk)<br>
> and<br>
> > original kernel (ramdisk) ?<br>
><br>
> We have 2 sets of kernel+ramdisk:<br>
> 1. Deploy k+r: these are used only for deploy process itself<br>
> to provide<br>
> iSCSI volume and call back to Ironic. There's ongoing effort<br>
> to create<br>
> smarted ramdisk, called Ironic Python Agent, but it's WIP.<br>
> 2. Your k+r as stated in Glance metadata for an image - they<br>
> will be<br>
> used for booting after deployment.<br>
><br>
> ><br>
> > Best Regards！<br>
> > Chao Yan<br>
> > --------------<br>
> > My twitter：Andy Yan @yanchao727<br>
> > My Weibo：<a href="http://weibo.com/herewearenow" target="_blank">http://weibo.com/herewearenow</a><br>
> > --------------<br>
> ><br>
> ><br>
> ><br>
> > 2014-06-04 19:36 GMT+08:00 Dmitry Tantsur<br>
> <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>>:<br>
> > Hi!<br>
> ><br>
> > Workflow is not entirely documented by now AFAIK.<br>
> After PXE<br>
> > boots deploy<br>
> > kernel and ramdisk, it exposes hard drive via iSCSI<br>
> and<br>
> > notifies Ironic.<br>
> > After that Ironic partitions the disk, copies an<br>
> image and<br>
> > reboots node<br>
> > with final kernel and ramdisk.<br>
> ><br>
> > On Wed, 2014-06-04 at 19:20 +0800, 严超 wrote:<br>
> > > Hi, All:<br>
> > ><br>
> > > I searched a lot about how ironic<br>
> automatically<br>
> > install image<br>
> > > on bare metal. But there seems to be no clear<br>
> workflow out<br>
> > there.<br>
> > ><br>
> > > What I know is, in traditional PXE, a bare<br>
> metal<br>
> > pull image<br>
> > > from PXE server using tftp. In tftp root, there is<br>
> a ks.conf<br>
> > which<br>
> > > tells tftp which image to kick start.<br>
> > ><br>
> > > But in ironic there is no ks.conf pointed<br>
> in tftp.<br>
> > How do bare<br>
> > > metal know which image to install ? Is there any<br>
> clear<br>
> > workflow where<br>
> > > I can read ?<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Best Regards！<br>
> > > Chao Yan<br>
> > > --------------<br>
> > > My twitter：Andy Yan @yanchao727<br>
> > > My Weibo：<a href="http://weibo.com/herewearenow" target="_blank">http://weibo.com/herewearenow</a><br>
> > > --------------<br>
> > ><br>
> ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > ><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>