Open Stack

Don't like dragging up old threads, but I spoke to Navneet on IRC, and
I missed this thread first time.

The Disk_Config setting is used by XenAPI to decide when it should
resize the server's partition and filesystem, but nova currently only
does this root disks that have a single partition where the partition
is either ext3 and ext4.

As I understand it, the XenServer Windows OpenStack agent currently
always resizes the server's disk. The agent currently gets all its
information from xenstore, so that should be put into xenstore, so it
can respect that setting. That is the user can choose if they want to
expand their root disk to fill all the available disk space or not.

Of couse there are other ways of doing this partition and filesystem
expansion, such as:
http://julien.danjou.info/blog/2013/cloud-init-utils-debian

As a longer term point, I wonder if we should made all the details of
a user call to "nova server show" available via metadata and
config_drive, as the above agent could in the future start using that
as a cross hypervisor source of information?

John

On 19 June 2013 18:29, Richard Goodwin <richard.goodwin at rackspace.com> wrote:
> I think resize was based on this before, but a patch upstream moved it to
> looking at the os_distro flag. (I could be mistaken.)
>
> Richard Goodwin
> Product Manager – Cloud Servers & Cloud Images
> Ideation | Intellection | Activator | Relator | Responsibility
> Phone: (512) 788 5403 – Cell: (512) 736-7897 (Austin)
> Skype: rtgoodwin - Yahoo: richardtgoodwin
> AIM: dellovision - IRC: goody / rgoodwin
>
> From: Bob Ball <bob.ball at citrix.com>
> Reply-To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Date: Tuesday, June 18, 2013 2:05 PM
>
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Discussion around blueprint
> https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore
>
> 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 - Yahoo: richardtgoodwin
> AIM: dellovision - IRC: goody / rgoodwin
>
> From: Bob Ball <bob.ball at citrix.com>
> Reply-To: OpenStack Development Mailing List
> <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>
> 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 - Yahoo: richardtgoodwin
> AIM: dellovision - IRC: goody / rgoodwin
>
>
>
> From: Bob Ball <bob.ball at citrix.com>
> Reply-To: OpenStack Development Mailing List
> <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>
> 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
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>