[openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
Bob Ball
bob.ball at citrix.com
Tue Jun 18 19:05:19 UTC 2013
That's fair enough. There might be a further use case where the user wants to understand how this flag will impact them on a resize? Not sure if we check it on resize, but it might make sense to check it in future.
Thinking about it a little more, I'm not sure how the general case would work. I'll definitely look into the protected properties, but it may be a little while before I can look at that myself.
One thing to note is that it looks like auto_disk_config is XenAPI specific, so we can add it to xenstore without much problem.
Bob
________________________________
From: Richard Goodwin [richard.goodwin at RACKSPACE.COM]
Sent: 18 June 2013 18:42
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
Bob,
If the user is cognizant of the extension, they may want to do post-build activities based on the value. I think that's the use for this particular case.
As for exposing them in a more general fashion, I agree with both of your points: there can be use to expose them, and also reasons to keep certain ones private. So, I think that whatever method we used would need to allow for that. Glance is solving for exposing image metadata ("protected properties"), but I don't believe anything equivalent exists for this case.
Richard Goodwin
Product Manager – Cloud Servers & Cloud Images
Ideation | Intellection | Activator | Relator | Responsibility
Phone: (512) 788 5403 – Cell: (512) 736-7897 (Austin)
Skype: rtgoodwin<file:///callto/::rtgoodwin> - Yahoo: richardtgoodwin<file:///ymsgr/sendim%3Frichardtgoodwin>
AIM: dellovision - IRC: goody / rgoodwin
From: Bob Ball <bob.ball at citrix.com<mailto:bob.ball at citrix.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, June 18, 2013 10:25 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
I don’t have any objections to this being exposed – but the question was should we expose it, and I don’t see any benefit to the user for this particular key. Of course, as you say, a provider may want to expose many specific metadata keys. Perhaps we should look at how to do this generically rather than special-casing the disk-config key?
I suspect it would not be desirable to expose _all_ metadata keys to the guest? I’m not sure what metadata we have at the moment, but I can certainly imagine adding some metadata that would be best to stay private in the future.
Bob
From: Richard Goodwin [mailto:richard.goodwin at RACKSPACE.COM]
Sent: 18 June 2013 15:25
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
Bob,
They could do extra deduction/guessing work to infer that, but it's a valid piece of metadata from the base image, so I'm concerned why there's so much discussion about exposing it? Seems like a provider could have a reason for exposing any number of metadata bits in the Store for their implementation needs. In addition, it assumes that any scenario where there is some unpartitioned space, the intent is to partition it; but the real desire is to determine that based on the image metadata (or API parameter).
Pardon me not having a lot of history on this process in the past.
Richard Goodwin
Product Manager – Cloud Servers & Cloud Images
Ideation | Intellection | Activator | Relator | Responsibility
Phone: (512) 788 5403 – Cell: (512) 736-7897 (Austin)
Skype: rtgoodwin<file:///\\callto\::rtgoodwin> - Yahoo: richardtgoodwin<file:///\\ymsgr\sendim%3Frichardtgoodwin>
AIM: dellovision - IRC: goody / rgoodwin
From: Bob Ball <bob.ball at citrix.com<mailto:bob.ball at citrix.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, June 18, 2013 4:31 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
I’m not sure I understand why the user might want to access the disk_config value from within the guest?
This seems to be something they could infer from the partition structure – i.e. if the whole drive is partitioned then disk_config was AUTO when the instance was created.
Bob
From: Navneet Kumar [mailto:navneetk at thoughtworks.com]
Sent: 18 June 2013 04:52
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
Hi,
disk_config has been introduced by the extension 'DiskConfig'( [[http://docs.rackspace.com/openstack-extensions/compute/rax-dcf/content/rax-dcf.pdf]] ) .This extension exposes api to set and retrieve the disk_config values ( either 'MANUAL" or "AUTO' ) .As a user one wants to access the value of disk_config from inside of instance but currently there is no way to get the value of disk_config from inside of instance.
To get any metadata/userdata of the instance a config drive ( [[http://docs.openstack.org/trunk/openstack-compute/admin/content/config-drive.html]] ) can be attached to the instance during boot-up.So disk_drive information can also be included in the config drive.
Should we include this value in the config drive and xen store as well ?
--
-----------------------------
Navneet Kumar
Application Developer
Thoughtworks India
Mob: +91 9686577076
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130618/2da13ee4/attachment-0001.html>
More information about the OpenStack-dev
mailing list