<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div><div><div>I'd like to expand on this at an upcoming meetup with some glance and cinder people. Come out of it with blueprints to focus on or create. Thoughts?</div><div><div><span class="Apple-style-span" style="font-family: Calibri, Verdana, Helvetica, Arial; font-size: medium; "><font color="#6F418E"><font size="7"><span style="font-size: 25pt; "><b>sean<br></b></span></font><b><font size="4"><span style="font-size: 13pt; ">roberts<br></span></font></b><font size="2"><span style="font-size: 10pt; "> <br></span></font><font size="1"><span style="font-size: 9pt; ">infrastructure strategy<br></span></font></font></span><span class="Apple-style-span" style="font-family: Calibri, Verdana, Helvetica, Arial; font-size: medium; "><font size="1"><span style="font-size: 4pt; "> <br></span><font color="#808080"><span style="font-size: 9pt; "><a href="applewebdata://2E35986A-DC2A-436F-BB4A-C451982006C2/seanrob@yahoo-inc.com">seanrob@yahoo-inc.com</a><br>direct 408-349-5234 mobile 925-980-4729<br></span><span style="font-size: 6pt; "> <br></span><span style="font-size: 9pt; ">701 first avenue, sunnyvale, ca, 94089-0703, us<br>phone (408) 349 3300 fax (408) 349 3301<br></span><span style="font-size: 6pt; "></span></font></font></span><span class="Apple-style-span" style="font-family: Calibri, Verdana, Helvetica, Arial; font-size: medium; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 13px;"><img src="cid:5CC2DB27-C6D2-429A-BDB9-0BDB1177E6E0" type="image/png"></span></font></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div><div>On 11/28/12 4:53 PM, "Vishvananda Ishaya" <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:</div></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div><br></div><div>On Nov 28, 2012, at 1:50 PM, Eoghan Glynn <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>> wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> </div><div> You could be right there, but in any case good to air the</div><div> discussion, and hopefully scare up a couple more view-points.</div></blockquote><div><br></div><div><br></div><div>I'm going to summarize the discussion at the summit just so it is included here.</div><div><br></div><div>There are two things you really need to be able to specify for each of the drives in your instance:</div><div><br></div><div>1) What is the source of the bits?</div><div><br></div><div> * image in glance</div><div> * volume in cinder</div><div> * snapshot in cinder</div><div> * local file</div><div> * empty</div><div> * formatted ext4</div><div><br></div><div>2) What is the destination of the volume (location and size):</div><div> </div><div> * permanent local disk</div><div> * ephemeral local disk</div><div> * remote volume</div><div><br></div><div>The confusion about boot-from-volume arises because the destination is interpreted</div><div>from the source (and sometimes the source is interpreted from the instance type)</div><div><br></div><div>Examples:</div><div> If source is a snapshot in cinder, then the destination will be a remote volume</div><div> If source is an image in glance, then the destination will be permanent local disk</div><div> If it is the second drive of an instance, then the source will be formatted ext4</div><div><br></div><div>We had a goal at the summit of making these things explicit, but this thread shows that there</div><div>is one aspect we did not consider: where does the metadata about the boot source come from?</div><div><br></div><div>We store various metadata that we currently can store in glance, such as image format. The</div><div>metadata is used in scheduling for example. It may also in the future be used to determine</div><div>different emulation modes for hardware (as in images that don't support virtio networking).</div><div>The metadata needs to come from somewhere.</div><div><br></div><div>There are three options here:</div><div><br></div><div>1) metadata is stored in glance</div><div>2) metadata is passed in at boot time</div><div>3) metadata is stored along with the bits somewhere (metadata in cinder)</div><div><br></div><div>It bears mentioning that we already support 1) you can create a metadata-only image today.</div><div>We already have limited support for 2), you can set the bdm data at boot time.</div><div><br></div><div>I think overriding metadata at boot time is valuable, so i see no need to remove that ability.</div><div><br></div><div>So the question boils down to whether we REQUIRE metadata in glance. It definitely makes</div><div>things simpler but it also makes the user experience quite painful. If I want to boot with a</div><div>source of a glance image and have a persistant volume. I have to go to cinder to create a volume</div><div>from the image, then go to glance to create a new image backing to the volume, then go</div><div>to nova to boot the new image. Yuck!</div><div><br></div><div>It also adds extra round trips to glance that wouldn't be necessary if we omit the image_id.</div><div><br></div><div>To boot a vm, we need source bits. our image_id represents both the metadata and (sometimes)</div><div>the source bits. If a user sends us sufficient metadata for us to find the source bits, I</div><div>don't think we need to require putting metadata in glance. It seems like it might be a useful</div><div>default however.</div><div><br></div><div>Vish</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>OpenStack-dev mailing list</div><div><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div><div><br></div></div></div></blockquote></span></body></html>