Hi Devananda and all,<div><br></div><div>I put those discussions at <a href="https://etherpad.openstack.org/GrizzlyBareMetalCloud">https://etherpad.openstack.org/GrizzlyBareMetalCloud</a>.</div><div>Based on your comment, we docomo team start discussing the next step. We will let you know once we decide the direction for the next step.</div>
<div><br></div><div>As for "disk image builder project", DOCOMO team are OK having a "stackforge project" if there is no overlap with other projects (e.g. <a href="https://blueprints.launchpad.net/heat/+spec/prebuilding-images" target="_blank" style="font-family:arial,sans-serif;font-size:12.727272033691406px">https://blueprints.launchpad.net/heat/+spec/prebuilding-images</a>).<br>
</div><div>DOCOMO team can contribute bare-metal related ramdisk (e.g. Clear ephemeral disk, Discover BM Node).</div><div><br></div><div>Thanks,<br>Ken</div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Nov 20, 2012 at 4:08 AM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div>Hi Ken, all,</div><div><br></div><div>The HP team has several goals we are working on. At the top right now is getting all the tooling for CI in place so that we can be testing the baremetal driver properly. I am adding support to devstack now, and expect to finish in the next few days. </div>
<div><br></div><div>(There are a few other bits that need to be done to tie this into devstack-gate and jenkins.o.o which aren't related to the driver development, so I won't talk about them here.)</div><div><br>
</div>
<div>I've add some comments inline ...</div><div class="im"><div><br></div><div>On Mon, Nov 19, 2012 at 2:44 AM, Ken Igarashi <span dir="ltr"><<a href="mailto:50barca@gmail.com" target="_blank">50barca@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi, <div>
<br></div><div>Since several patches start being merged, I would like to start discussion about the new functions of bare-metal provisioning.</div>
<div><br></div><div>The followings are items as far as I understand (most of them are listed at <a href="https://etherpad.openstack.org/GrizzlyBareMetalCloud" target="_blank">https://etherpad.openstack.org/GrizzlyBareMetalCloud</a>). If someone has already started implementation of some items, or if I miss some important items, please let me know. I want to avoid duplicate works and make Bare-Metal Provisioning better.</div>
<div><br></div><div>1. Security group support (we will use <a href="https://review.openstack.org/#/c/10664/" target="_blank">https://review.openstack.org/#/c/10664/</a>)</div></blockquote><div><br></div></div><div>++ </div>
<div class="im"><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p>2. One nova compute supports multiple CPU archs (x86, arm, tilera,…), power managers(IPMI, PDU,…) and capabilities</p>
</blockquote></div><div><br>This is slightly important for us, but not in the short term. In the long term, we would also like to see nova-compute understand multiple hypervisors so that baremetal can co-exist with kvm/xen/etc.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p>3. Snapshot for a bare-metal instance</p>
<p>4. Access for Nova-Volume (cinder) </p><p>- without using nova-compute iSCSI proxy.</p><p>- use iSCSI CHAP?</p>
<p>5. Clear ephemeral disk after an instance termination (e.g. fill with zero)</p></blockquote></div><div>This should be fairly a straight-forward change, with two steps:</div><div> a. build a "wipe-ramdisk" based on the current "deploy-ramdisk" but with different init scripts<br>
</div><div> b. plug this into the driver, eg. within destroy()</div><div><br></div><div>We can do this. We are also adding a hardware-discovery ramdisk, so that one does not need to know all hw info in advance.</div><div class="im">
<div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p>6. Improve an image deployment</p><p>- not use iSCSI (get an AMI directory from Glance without using "PXE bare-metal provisioning helper server")</p></blockquote></div><div>This is very important for us, and we have had several internal discussions on how to do it at scale. The general direction here is to embed a bittorrent client into the deploy ramdisk, and provide the partition layout via cloud meta-data service. This will probably be a fair bit of work; we will do this, too.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p>7. <font color="#000000" face="Arial, sans-serif"><span style="font-size:11.818181991577148px;line-height:16px">Fault-tolerance of bare-metal nova-compute and database - <a href="https://blueprints.launchpad.net/nova/+spec/bare-metal-fault-tolerance" target="_blank">https://blueprints.launchpad.net/nova/+spec/bare-metal-fault-tolerance</a></span></font></p>
<p>8. More CPU archs (arm) support</p><p><br></p><p>Others<br></p><p>- Use VNC instead of using SOL (Serial over LAN)</p><p>- Support a bare-metal node with one NIC (we need at least two NICs today).</p></blockquote><div>
</div></div><div>Actually, what we need is for baremetal to support N nic, where N > 0, and understand limitations of a physical network. Unfortunately, we won't be able to rely on SDN to solve some of the network issues for us, so we need a way to inform nova-network // quantum of the physical topology (how many NIC, what each MAC is, what networks each interface is on, what VLAN are available or required on which interfaces, and so on). I believe Robert Collins sent a large email about this last week, and it may be good for us to have a longer discussion about this topic.</div>
<div><br></div><div><br></div><div>Regards,</div><div>Devananda</div></div></div>
<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></blockquote></div><br></div></div></div></div>