[openstack-dev] qemu guest agent support
Currently qemu guest agent is supported in libvirt driver via image metadata [1]. Is there a reason why it is not exposed via nova config variable as well ? It would be good to create virtio socket by default controlled via nova config param rather than ops folks having to set metadata explicitly for every image uploaded in the cluster. [1] - https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3585 Thanks, Meghal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?
Is any discussion on this topic scheduled during the summit ? Thanks, Meghal On Apr 9, 2014, at 9:03 AM, Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com wrote: 2014-04-07 23:11 GMT+02:00 Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com: Hi Phil, 2014-04-07 18:48 GMT+02:00 Day, Phil philip@hp.commailto:philip@hp.com: Hi Sylvain, There was a similar thread on this recently – which might be worth reviewing: http://lists.openstack.org/pipermail/openstack-dev/2014-March/031006.html Some interesting use cases were posted, and a I don’t think a conclusion was reached, which seems to suggest this might be a good case for a session in Atlanta. The funny fact is that I was already part of this discussion as owner of a bug related to it (see the original link I provided). That's only when reviewing the code by itself that I found some discrepancies and raised the question here, before committing. Personally I’m not sure that selecting more than one AZ really makes a lot of sense – they are generally objects which are few in number and large in scale, so if for example there are 3 AZs and you want to create two servers in different AZs, does it really help if you can do the sequence: - Create a server in any AZ - Find the AZ the server is in - Create a new server in any of the two remaining AZs Rather than just picking two from the list to start with ? If you envisage a system with many AZs, and thereby allow users some pretty find grained choices about where to place their instances, then I think you’ll end up with capacity management issues. If the use case is more to get some form of server isolation, then server-groups might be worth looking at, as these are dynamic and per user. I can see a case for allowing more than one set of mutually exclusive host aggregates – at the moment that’s a property implemented just for the set of aggregates that are designated as AZs, and generalizing that concept so that there can be other sets (where host overlap is allowed between sets, but not within a set) might be useful. Phil That's a good point for discussing at the Summit. I don't have yet an opinion on this, I'm just trying to stabilize things now :-) At the moment, I'm pretty close to submit a change which will fix two things : - the decisional will be the same for both adding a server to an aggregate and update metadata from an existing aggregate (there was duplicate code leading to a few differences) - when checking existing AZs for one host, we will also get the aggregates to know if the default AZ is related to an existing aggregate with the same name or just something unrelated Folks interested in the initial issue can review https://review.openstack.org/#/c/85961/ for a proposal to fix. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?
I am fine with taking the approach of user passing multiple avail. zones Az1,Az2 if he wants vm to be in (intersection of AZ1 and Az2). It will be more cleaner. But, similar approach should also be used while setting the default_scheduling_zone. Since, we will not be able to add host to multiple zones, only way to guarantee even distribution across zones when user does not pass any zone, is to allow multiple zones in default_scheduling_zone param. Thanks, Meghal On Apr 4, 2014, at 2:38 AM, Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com wrote: 2014-04-04 10:30 GMT+02:00 Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com: Hi all, 2014-04-03 18:47 GMT+02:00 Meghal Gosalia meg...@yahoo-inc.commailto:meg...@yahoo-inc.com: Hello folks, Here is the bug [1] which is currently not allowing a host to be part of two availability zones. This bug was targeted for havana. The fix in the bug was made because it was assumed that openstack does not support adding hosts to two zones by design. The assumption was based on the fact that --- if hostX is added to zoneA as well as zoneB, and if you boot a vm vmY passing zoneB in boot params, nova show vmY still returns zoneA. In my opinion, we should fix the case of nova show rather than changing aggregate api to not allow addition of hosts to multiple zones. I have added my comments in comments #7 and #9 on that bug. Thanks, Meghal [1] Bug - https://bugs.launchpad.net/nova/+bug/1196893 Thanks for the pointer, now I see why the API is preventing host to be added to a 2nd aggregated if there is a different AZ. Unfortunately, this patch missed the fact that aggregates metadata can be modified once the aggregate is created, so we should add a check when updating metadate in order to cover all corner cases. So, IMHO, it's worth providing a patch for API consistency so as we enforce the fact that a host should be in only one AZ (but possibly 2 or more aggregates) and see how we can propose to user ability to provide 2 distincts AZs when booting. Does everyone agree ? Well, I'm replying to myself. The corner case is even trickier. I missed this patch [1] which already checks that when updating an aggregate to set an AZ, its hosts are not already part of another AZ. So, indeed, the coverage is already there... except for one thing : If an operator is creating an aggregate with an AZ set to the default AZ defined in nova.conf and adds an host to this aggregate, nova availability-zone-list does show the host being part of this default AZ (normal behaviour). If we create an aggregate 'foo' without AZ, then we add the same host to that aggregate, and then we update the metadata of the aggregate to set an AZ 'foo', then the AZ check won't notice that the host is already part of an AZ and will allow the host to be part of two distinct AZs. Proof here : http://paste.openstack.org/show/75066/ I'm on that bug. -Sylvain [1] : https://review.openstack.org/#/c/36786 -Sylvain On Apr 3, 2014, at 9:05 AM, Steve Gordon sgor...@redhat.commailto:sgor...@redhat.com wrote: - Original Message - Currently host aggregates are quite general, but the only ways for an end-user to make use of them are: 1) By making the host aggregate an availability zones (where each host is only supposed to be in one availability zone) and selecting it at instance creation time. 2) By booting the instance using a flavor with appropriate metadata (which can only be set up by admin). I would like to see more flexibility available to the end-user, so I think we should either: A) Allow hosts to be part of more than one availability zone (and allow selection of multiple availability zones when booting an instance), or While changing to allow hosts to be in multiple AZs changes the concept from an operator/user point of view I do think the idea of being able to specify multiple AZs when booting an instance makes sense and would be a nice enhancement for users working with multi-AZ environments - I'm OK with this instance running in AZ1 and AZ2, but not AZ*. -Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?
Hello folks, Here is the bug [1] which is currently not allowing a host to be part of two availability zones. This bug was targeted for havana. The fix in the bug was made because it was assumed that openstack does not support adding hosts to two zones by design. The assumption was based on the fact that --- if hostX is added to zoneA as well as zoneB, and if you boot a vm vmY passing zoneB in boot params, nova show vmY still returns zoneA. In my opinion, we should fix the case of nova show rather than changing aggregate api to not allow addition of hosts to multiple zones. I have added my comments in comments #7 and #9 on that bug. Thanks, Meghal [1] Bug - https://bugs.launchpad.net/nova/+bug/1196893 On Apr 3, 2014, at 9:05 AM, Steve Gordon sgor...@redhat.commailto:sgor...@redhat.com wrote: - Original Message - Currently host aggregates are quite general, but the only ways for an end-user to make use of them are: 1) By making the host aggregate an availability zones (where each host is only supposed to be in one availability zone) and selecting it at instance creation time. 2) By booting the instance using a flavor with appropriate metadata (which can only be set up by admin). I would like to see more flexibility available to the end-user, so I think we should either: A) Allow hosts to be part of more than one availability zone (and allow selection of multiple availability zones when booting an instance), or While changing to allow hosts to be in multiple AZs changes the concept from an operator/user point of view I do think the idea of being able to specify multiple AZs when booting an instance makes sense and would be a nice enhancement for users working with multi-AZ environments - I'm OK with this instance running in AZ1 and AZ2, but not AZ*. -Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Rolling upgrades in icehouse
Hello folks, I was reading a blogpost mentioned in the newsletter here - http://redhatstackblog.redhat.com/2014/03/11/an-icehouse-sneak-peek-openstack-compute-nova/ A note about rolling upgrades is mentioned - The Compute services now allow for a level of rolling upgrade, whereby control services can be upgraded to Icehouse while they continue to interact with compute services running code from the Havana release. This allows for a more gradual approach to upgrading an OpenStack cloud, or logical designated subset thereof, than has typically been possible in the past. Where can I obtain more information about this feature? Does above imply that database is upgraded along with control service update as well? One more question - is there an initiative to make icehouse database schema work with havana based control services ? If control services were not tightly coupled with database schema, then I could move one half of control services out of rotation and update from havana to icehouse, while other half is still serving traffic. This would help us achieve zero api downtime during upgrades. Currently, upgrading first half from one release to another would update database schema and other half running old services does not work with new schema. Thanks, Meghal signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Rolling upgrades in icehouse
Thanks a lot Dan for your reply. This is definitely a good first step to move out nova-compute from the services to be upgraded atomically. Looking forward to your blog post. Best, Meghal On Mar 24, 2014, at 12:14 PM, Dan Smith d...@danplanet.com wrote: Signed PGP part Where can I obtain more information about this feature? - From the blog post that I've yet to write :D Does above imply that database is upgraded along with control service update as well? Yes, but only for the services that interact directly with the database. The services that do *not* need to be upgraded atomically with the schema are: nova-compute and nova-network. One more question - is there an initiative to make icehouse database schema work with havana based control services ? It depends on what you mean by control services. For icehouse, the incremental step that we're making is that all the controller services must be upgraded atomically with the database schema. That means api, scheduler, conductor, etc. A havana compute node is sufficiently isolated from the data schema that it will continue to work with an icehouse conductor, allowing you to upgrade compute nodes independently after the controller services are updated. This was just our first step at providing some capability for this. We hope to continue to increase the capabilities (and decrease the amount that must be done atomically) going forward. Hope that helps! - --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Use spice-html5proxy to connect to spice tls port
Hi folks, Has there been any discussion in the community for using nova-spicehtml5proxy to connect to spice tls port ? For example, if a vm is booted using qemu by enabling spice_tls mode in qemu.conf, it enables tls encryption on spice server for that vm. nova-spicehtml5proxy is based on websockify, which supports ssl wrapped sockets. It would be great, if nova-spicehtml5proxy could decide based on config param in nova.conf regarding use of normal sockets or ssl wrapped sockets to connect to spice server. This would ensure SSL encryption from spice proxy to spice server. Are there any concerns with this approach ? Thanks, Meghal signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
