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 ?
There is a good talk happening today at 2pm @ room B.206 in a Breakout session : Divide and conquer: Resource Segregation in OpenStack (I'm sorry, I can't provide the sched.org link, site seems to be down) -Sylvain Le 13/05/2014 11:12, Meghal Gosalia a écrit : 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.com mailto:sylvain.ba...@gmail.com wrote: 2014-04-07 23:11 GMT+02:00 Sylvain Bauza sylvain.ba...@gmail.com mailto:sylvain.ba...@gmail.com: Hi Phil, 2014-04-07 18:48 GMT+02:00 Day, Phil philip@hp.com mailto: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/ https://review.openstack.org/#/c/85961/ for a proposal to fix. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 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 ?
-Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 08 April 2014 14:25 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On Tue, 2014-04-08 at 10:49 +, Day, Phil wrote: On a large cloud you’re protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis Alternately, we could just have the affinity filters serve as weighting filters instead of returning NoValidHosts. That way, a request containing an affinity hint would cause the scheduler to prefer placing the new VM near (or not-near) other instances in the server group, but if no hosts exist that meet that criteria, the filter simply finds a host with the most (or fewest, in case of anti-affinity) instances that meet the affinity criteria. I agree that hint would be more consistent with weighting that filtering (constraint would be a better word for that) - but how does the user get feedback on whether the hint has been honoured or not ? In the case of anti-affinity they would need to: - Create a VM - Check the host hash value is different - if they really care delete the VM and try again ... which is pretty much the same cycle they can do without the hint (the filter/weighter just gives it a better chance of working first time a small system) I would guess that affinity is more likely to be a soft requirement that anti-affinity, in that I can see some services just not meeting their HA goals without anti-affinity but I'm struggling to think of a use case why affinity is a must for the service. ___ 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 ?
-Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: 08 April 2014 15:19 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 04/08/2014 07:25 AM, Jay Pipes wrote: On Tue, 2014-04-08 at 10:49 +, Day, Phil wrote: On a large cloud you're protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis Alternately, we could just have the affinity filters serve as weighting filters instead of returning NoValidHosts. That way, a request containing an affinity hint would cause the scheduler to prefer placing the new VM near (or not-near) other instances in the server group, but if no hosts exist that meet that criteria, the filter simply finds a host with the most (or fewest, in case of anti-affinity) instances that meet the affinity criteria. I'd be in favor of this. I've actually been playing with an internal patch to do both of these things, though in my case I was just doing it via metadata on the group and a couple hacks in the scheduler and the compute node. Basically I added a group_size metadata field and a best_effort flag to indicate whether we should error out or continue on if the policy can't be properly met. I like the idea of the user being able to say if the affinity should be treated as a filter or weight. In terms of group_size I'd want to able to impose a limit on that as an operator, not just have it in the control of the user (hence the quota idea) ___ 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 ?
On 04/09/2014 03:55 AM, Day, Phil wrote: I would guess that affinity is more likely to be a soft requirement that anti-affinity, in that I can see some services just not meeting their HA goals without anti-affinity but I'm struggling to think of a use case why affinity is a must for the service. Maybe something related to latency? Put a database server and several public-facing servers all on the same host and they can talk to each other with less latency then if they had to go over the wire to another host? Chris ___ 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 ?
2014-04-07 23:11 GMT+02:00 Sylvain Bauza sylvain.ba...@gmail.com: Hi Phil, 2014-04-07 18:48 GMT+02:00 Day, Phil 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.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?
-Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: 09 April 2014 15:37 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 04/09/2014 03:55 AM, Day, Phil wrote: I would guess that affinity is more likely to be a soft requirement that anti-affinity, in that I can see some services just not meeting their HA goals without anti-affinity but I'm struggling to think of a use case why affinity is a must for the service. Maybe something related to latency? Put a database server and several public-facing servers all on the same host and they can talk to each other with less latency then if they had to go over the wire to another host? I can see that as a high-want, but would you actually rather not start the service if you couldn't get it ? I suspect not, as there are many other factors that could affect performance. On the other hand I could imagine a case where I declare its not worth having a second VM at all if I can't get it on a separate server. Hence affinity feels more soft and anti-affinity hard in terms or requirments. ___ 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 ?
- Original Message - -Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: 09 April 2014 15:37 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 04/09/2014 03:55 AM, Day, Phil wrote: I would guess that affinity is more likely to be a soft requirement that anti-affinity, in that I can see some services just not meeting their HA goals without anti-affinity but I'm struggling to think of a use case why affinity is a must for the service. Maybe something related to latency? Put a database server and several public-facing servers all on the same host and they can talk to each other with less latency then if they had to go over the wire to another host? I can see that as a high-want, but would you actually rather not start the service if you couldn't get it ? I suspect not, as there are many other factors that could affect performance. On the other hand I could imagine a case where I declare its not worth having a second VM at all if I can't get it on a separate server. Hence affinity feels more soft and anti-affinity hard in terms or requirments. As the orchestrator if affinity is important to me and it turns out I can't place all of the VMs in the group with affinity, I would likely use the failure to place the second (or subsequent) instance as my cue to rollback and destroy the original VM(s) as well. I don't think either policy is naturally any more hard or soft - it depends on the user and their workloads - this is why I think a soft implementation of either filter should be in addition to rather than instead of the existing ones, though soft may make more sense for the defaults. Thanks, Steve ___ 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 ?
Abusive usage : If user can request anti-affinity VMs, then why doesnt he uses that? This will result in user constantly requesting all his VMs being in the same anti-affinity group. This makes scheduler choose one physical host per VM. This will quickly flood the infrastructure and mess up with the objective of admin (e.g. Consolidation that regroup VM instead of spreading, spared hosts, etc) ; at some time it will be reported back that there is no host available, which appears as a bad experience for user. De : Ian Wells [mailto:ijw.ubu...@cack.org.uk] Envoyé : mardi 8 avril 2014 01:02 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 3 April 2014 08:21, Khanh-Toan Tran khanh-toan.t...@cloudwatt.com wrote: Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. I'm sorry, could you explain what you mean here by 'abusive usage'? -- Ian. ___ 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 ?
On a large cloud you're protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis From: Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] Sent: 08 April 2014 11:32 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Abusive usage : If user can request anti-affinity VMs, then why doesn't he uses that? This will result in user constantly requesting all his VMs being in the same anti-affinity group. This makes scheduler choose one physical host per VM. This will quickly flood the infrastructure and mess up with the objective of admin (e.g. Consolidation that regroup VM instead of spreading, spared hosts, etc) ; at some time it will be reported back that there is no host available, which appears as a bad experience for user. De : Ian Wells [mailto:ijw.ubu...@cack.org.uk] Envoyé : mardi 8 avril 2014 01:02 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 3 April 2014 08:21, Khanh-Toan Tran khanh-toan.t...@cloudwatt.commailto:khanh-toan.t...@cloudwatt.com wrote: Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. I'm sorry, could you explain what you mean here by 'abusive usage'? -- Ian. ___ 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 ?
On Tue, 2014-04-08 at 10:49 +, Day, Phil wrote: On a large cloud you’re protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis Alternately, we could just have the affinity filters serve as weighting filters instead of returning NoValidHosts. That way, a request containing an affinity hint would cause the scheduler to prefer placing the new VM near (or not-near) other instances in the server group, but if no hosts exist that meet that criteria, the filter simply finds a host with the most (or fewest, in case of anti-affinity) instances that meet the affinity criteria. Best, -jay From: Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] Sent: 08 April 2014 11:32 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? “Abusive usage” : If user can request anti-affinity VMs, then why doesn’t he uses that? This will result in user constantly requesting all his VMs being in the same anti-affinity group. This makes scheduler choose one physical host per VM. This will quickly flood the infrastructure and mess up with the objective of admin (e.g. Consolidation that regroup VM instead of spreading, spared hosts, etc) ; at some time it will be reported back that there is no host available, which appears as a bad experience for user. De : Ian Wells [mailto:ijw.ubu...@cack.org.uk] Envoyé : mardi 8 avril 2014 01:02 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 3 April 2014 08:21, Khanh-Toan Tran khanh-toan.t...@cloudwatt.com wrote: Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. I'm sorry, could you explain what you mean here by 'abusive usage'? -- Ian. ___ OpenStack-dev mailing list 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 ?
-Message d'origine- De : Jay Pipes [mailto:jaypi...@gmail.com] Envoyé : mardi 8 avril 2014 15:25 À : openstack-dev@lists.openstack.org Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On Tue, 2014-04-08 at 10:49 +, Day, Phil wrote: On a large cloud you’re protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis Alternately, we could just have the affinity filters serve as weighting filters instead of returning NoValidHosts. That way, a request containing an affinity hint would cause the scheduler to prefer placing the new VM near (or not-near) other instances in the server group, but if no hosts exist that meet that criteria, the filter simply finds a host with the most (or fewest, in case of anti-affinity) instances that meet the affinity criteria. Best, -jay The filters guarantee the desired effect, while the weighers just give the preference. Thus it makes sense to have AntiAffinity as a filter. Otherwise what is it good for if users do not know if their anti-affiniti-ed VMs are hosted in different hosts. I prefer the idea of anti-affinity quota. May propose that. From: Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] Sent: 08 April 2014 11:32 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? “Abusive usage” : If user can request anti-affinity VMs, then why doesn’t he uses that? This will result in user constantly requesting all his VMs being in the same anti-affinity group. This makes scheduler choose one physical host per VM. This will quickly flood the infrastructure and mess up with the objective of admin (e.g. Consolidation that regroup VM instead of spreading, spared hosts, etc) ; at some time it will be reported back that there is no host available, which appears as a bad experience for user. De : Ian Wells [mailto:ijw.ubu...@cack.org.uk] Envoyé : mardi 8 avril 2014 01:02 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 3 April 2014 08:21, Khanh-Toan Tran khanh-toan.t...@cloudwatt.com wrote: Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. I'm sorry, could you explain what you mean here by 'abusive usage'? -- Ian. ___ OpenStack-dev mailing list 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 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 ?
- Original Message - On Tue, 2014-04-08 at 10:49 +, Day, Phil wrote: On a large cloud you’re protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis Alternately, we could just have the affinity filters serve as weighting filters instead of returning NoValidHosts. That way, a request containing an affinity hint would cause the scheduler to prefer placing the new VM near (or not-near) other instances in the server group, but if no hosts exist that meet that criteria, the filter simply finds a host with the most (or fewest, in case of anti-affinity) instances that meet the affinity criteria. Best, -jay This is often called soft affinity/anti-affinity (though admittedly typically in the context of CPU affinity), I had been independently mulling whether this would make sense as an additional policy for server groups. That said although it's a simple solution for the problem noted in this thread I don't think it's desirable to do this in as a replacement for the existing support and remove any ability to have hard affinity/anti-affinity - other. Some users actually expect/demand an error if the affinity or anti-affinity requirements of the workload can't be met, perhaps this is a case where sensible default tunables are required and the operators that want/need to provide hard affinity/anti-affinity need to explicitly enable it? -Steve ___ 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 ?
On 04/08/2014 07:25 AM, Jay Pipes wrote: On Tue, 2014-04-08 at 10:49 +, Day, Phil wrote: On a large cloud you’re protect against this to some extent if the number of servers is number of instances in the quota. However it does feel that there are a couple of things missing to really provide some better protection: - A quota value on the maximum size of a server group - A policy setting so that the ability to use service-groups can be controlled on a per project basis Alternately, we could just have the affinity filters serve as weighting filters instead of returning NoValidHosts. That way, a request containing an affinity hint would cause the scheduler to prefer placing the new VM near (or not-near) other instances in the server group, but if no hosts exist that meet that criteria, the filter simply finds a host with the most (or fewest, in case of anti-affinity) instances that meet the affinity criteria. I'd be in favor of this. I've actually been playing with an internal patch to do both of these things, though in my case I was just doing it via metadata on the group and a couple hacks in the scheduler and the compute node. Basically I added a group_size metadata field and a best_effort flag to indicate whether we should error out or continue on if the policy can't be properly met. Currently mine just falls back to the regular scheduler if it can't meet the policy, but I had been thinking about what it would take to do it like you suggest above, where we try to abide by the spirit of the policy even if we can't quite satisfy the letter of it. Chris ___ 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 ?
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. 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 From: Murray, Paul (HP Cloud Services) Sent: 03 April 2014 16:34 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Hi Sylvain, I would go with keeping AZs exclusive. It is a well-established concept even if it is up to providers to implement what it actually means in terms of isolation. Some good use cases have been presented on this topic recently, but for me they suggest we should develop a better concept rather than bend the meaning of the old one. We certainly don't have hosts in more than one AZ in HP Cloud and I think some of our users would be very surprised if we changed that. Paul. From: Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] Sent: 03 April 2014 15:53 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? +1 for AZs not sharing hosts. Because it's the only mechanism that allows us to segment the datacenter. Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. Why sacrificing this power so that users can select the types of his desired physical hosts ? The latter can be exposed using flavor metadata, which is a lot safer and more controllable than using AZs. If someone insists that we really need to let users choose the types of physical hosts, then I suggest creating a new hint, and use aggregates with it. Don't sacrifice AZ exclusivity! Btw, there is a datacenter design called dual-room [1] which I think best fit for AZs to make your cloud redundant even with one datacenter. Best regards, Toan [1] IBM and Cisco: Together for a World Class Data Center, Page 141. http://books.google.fr/books?id=DHjJAgAAQBAJpg=PA141#v=onepageqf=false De : Sylvain Bauza [mailto:sylvain.ba...@gmail.com] Envoyé : jeudi 3 avril 2014 15:52 À : OpenStack Development Mailing List (not for usage questions) Objet : [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. Your comments are welcome. Thanks, -Sylvain [1] : https://bugs.launchpad.net/nova/+bug/1277230 [2] : https://github.com/openstack/nova/blob/9d45e9cef624a4a972c24c47c7abd57a72d74432/nova/compute/api.py#L3378 ___ 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 ?
On Mon, 2014-04-07 at 16:48 +, Day, Phil wrote: 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. 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 ? Or doing this in Heat, where orchestration belongs? Best, -jay ___ 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 ?
Hi Phil, 2014-04-07 18:48 GMT+02:00 Day, Phil 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 Thanks, -Sylvain *From:* Murray, Paul (HP Cloud Services) *Sent:* 03 April 2014 16:34 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Hi Sylvain, I would go with keeping AZs exclusive. It is a well-established concept even if it is up to providers to implement what it actually means in terms of isolation. Some good use cases have been presented on this topic recently, but for me they suggest we should develop a better concept rather than bend the meaning of the old one. We certainly don't have hosts in more than one AZ in HP Cloud and I think some of our users would be very surprised if we changed that. Paul. *From:* Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.comkhanh-toan.t...@cloudwatt.com] *Sent:* 03 April 2014 15:53 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? +1 for AZs not sharing hosts. Because it's the only mechanism that allows us to segment the datacenter. Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. Why sacrificing this power so that users can select the types of his desired physical hosts ? The latter can be exposed using flavor metadata, which is a lot safer and more controllable than using AZs. If someone insists that we really need to let users choose the types of physical hosts, then I suggest creating a new hint, and use aggregates with it. Don't sacrifice AZ exclusivity! Btw, there is a datacenter design called dual-room [1] which I think best fit for AZs to make your cloud redundant even with one datacenter. Best regards, Toan [1] IBM and Cisco: Together for a World Class Data Center, Page 141. http://books.google.fr/books?id=DHjJAgAAQBAJpg=PA141#v=onepageqf=false *De :* Sylvain Bauza [mailto:sylvain.ba...@gmail.comsylvain.ba...@gmail.com] *Envoyé :* jeudi 3 avril 2014 15:52 *À :* OpenStack Development Mailing List (not for usage questions) *Objet :* [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API
Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?
On 3 April 2014 08:21, Khanh-Toan Tran khanh-toan.t...@cloudwatt.comwrote: Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. I'm sorry, could you explain what you mean here by 'abusive usage'? -- Ian. ___ 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 ?
Hi all, 2014-04-03 18:47 GMT+02:00 Meghal Gosalia 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 ? -Sylvain On Apr 3, 2014, at 9:05 AM, Steve Gordon 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.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 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
[openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?
Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. Your comments are welcome. Thanks, -Sylvain [1] : https://bugs.launchpad.net/nova/+bug/1277230 [2] : https://github.com/openstack/nova/blob/9d45e9cef624a4a972c24c47c7abd57a72d74432/nova/compute/api.py#L3378 ___ 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 ?
On 04/03/2014 07:51 AM, Sylvain Bauza wrote: Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. 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 B) Allow the instance boot scheduler hints to interact with the host aggregate metadata. Chris ___ 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 ?
+1 for AZs not sharing hosts. Because its the only mechanism that allows us to segment the datacenter. Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. Why sacrificing this power so that users can select the types of his desired physical hosts ? The latter can be exposed using flavor metadata, which is a lot safer and more controllable than using AZs. If someone insists that we really need to let users choose the types of physical hosts, then I suggest creating a new hint, and use aggregates with it. Dont sacrifice AZ exclusivity! Btw, there is a datacenter design called dual-room [1] which I think best fit for AZs to make your cloud redundant even with one datacenter. Best regards, Toan [1] IBM and Cisco: Together for a World Class Data Center, Page 141. http://books.google.fr/books?id=DHjJAgAAQBAJ http://books.google.fr/books?id=DHjJAgAAQBAJpg=PA141#v=onepageqf=false pg=PA141#v=onepageqf=false De : Sylvain Bauza [mailto:sylvain.ba...@gmail.com] Envoyé : jeudi 3 avril 2014 15:52 À : OpenStack Development Mailing List (not for usage questions) Objet : [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. Your comments are welcome. Thanks, -Sylvain [1] : https://bugs.launchpad.net/nova/+bug/1277230 [2] : https://github.com/openstack/nova/blob/9d45e9cef624a4a972c24c47c7abd57a72d 74432/nova/compute/api.py#L3378 ___ 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 ?
+1 for AZs not sharing hosts. Because its the only mechanism that allows us to segment the datacenter. Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. Why sacrificing this power so that users can select the types of his desired physical hosts ? The latter can be exposed using flavor metadata, which is a lot safer and more controllable than using AZs. If someone insists that we really need to let users choose the types of physical hosts, then I suggest creating a new hint, and use aggregates with it. Dont sacrifice AZ exclusivity! Btw, there is a datacenter design called dual-room [1] which I think best fit for AZs to make your cloud redundant even with one datacenter. Best regards, Toan -Message d'origine- De : Chris Friesen [mailto:chris.frie...@windriver.com] Envoyé : jeudi 3 avril 2014 16:51 À : openstack-dev@lists.openstack.org Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 04/03/2014 07:51 AM, Sylvain Bauza wrote: Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. 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 B) Allow the instance boot scheduler hints to interact with the host aggregate metadata. Chris ___ OpenStack-dev mailing list 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 ?
Dual-room link: [1] IBM and Cisco: Together for a World Class Data Center, Page 141. http://books.google.fr/books?id=DHjJAgAAQBAJpg=PA141#v=onepageqf=false -Message d'origine- De : Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] Envoyé : jeudi 3 avril 2014 17:22 À : OpenStack Development Mailing List (not for usage questions) Objet : RE: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? +1 for AZs not sharing hosts. Because its the only mechanism that allows us to segment the datacenter. Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. Why sacrificing this power so that users can select the types of his desired physical hosts ? The latter can be exposed using flavor metadata, which is a lot safer and more controllable than using AZs. If someone insists that we really need to let users choose the types of physical hosts, then I suggest creating a new hint, and use aggregates with it. Dont sacrifice AZ exclusivity! Btw, there is a datacenter design called dual-room [1] which I think best fit for AZs to make your cloud redundant even with one datacenter. Best regards, Toan -Message d'origine- De : Chris Friesen [mailto:chris.frie...@windriver.com] Envoyé : jeudi 3 avril 2014 16:51 À : openstack-dev@lists.openstack.org Objet : Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? On 04/03/2014 07:51 AM, Sylvain Bauza wrote: Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. 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 B) Allow the instance boot scheduler hints to interact with the host aggregate metadata. Chris ___ OpenStack-dev mailing list 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 ?
Hi Sylvain, I would go with keeping AZs exclusive. It is a well-established concept even if it is up to providers to implement what it actually means in terms of isolation. Some good use cases have been presented on this topic recently, but for me they suggest we should develop a better concept rather than bend the meaning of the old one. We certainly don't have hosts in more than one AZ in HP Cloud and I think some of our users would be very surprised if we changed that. Paul. From: Khanh-Toan Tran [mailto:khanh-toan.t...@cloudwatt.com] Sent: 03 April 2014 15:53 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? +1 for AZs not sharing hosts. Because it's the only mechanism that allows us to segment the datacenter. Otherwise we cannot provide redundancy to client except using Region which is dedicated infrastructure and networked separated and anti-affinity filter which IMO is not pragmatic as it has tendency of abusive usage. Why sacrificing this power so that users can select the types of his desired physical hosts ? The latter can be exposed using flavor metadata, which is a lot safer and more controllable than using AZs. If someone insists that we really need to let users choose the types of physical hosts, then I suggest creating a new hint, and use aggregates with it. Don't sacrifice AZ exclusivity! Btw, there is a datacenter design called dual-room [1] which I think best fit for AZs to make your cloud redundant even with one datacenter. Best regards, Toan [1] IBM and Cisco: Together for a World Class Data Center, Page 141. http://books.google.fr/books?id=DHjJAgAAQBAJpg=PA141#v=onepageqf=false De : Sylvain Bauza [mailto:sylvain.ba...@gmail.com] Envoyé : jeudi 3 avril 2014 15:52 À : OpenStack Development Mailing List (not for usage questions) Objet : [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ? Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. Your comments are welcome. Thanks, -Sylvain [1] : https://bugs.launchpad.net/nova/+bug/1277230 [2] : https://github.com/openstack/nova/blob/9d45e9cef624a4a972c24c47c7abd57a72d74432/nova/compute/api.py#L3378 ___ 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 ?
- Original Message - Hi, I'm currently trying to reproduce [1]. This bug requires to have the same host on two different aggregates, each one having an AZ. IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so IMHO this request should not be possible. That said, there are two flaws where I can identify that no validation is done : - when specifying an AZ in nova.conf, the host is overriding the existing AZ by its own - when adding an host to an aggregate without AZ defined, and afterwards update the aggregate to add an AZ So, I need direction. Either we consider it is not possible to share 2 AZs for the same host and then we need to fix the two above scenarios, or we say it's nice to have 2 AZs for the same host and then we both remove the validation check in the API and we fix the output issue reported in the original bug [1]. Current operator and ultimately user expectations as a result of the validation on aggregate creation are that a host can only be in one AZ, based on that I'd expect to see the gaps identified in those scenarios filled rather than allowing a host to be in multiple AZs. Nice work identifying them though! Thanks, Steve ___ 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 ?
- 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.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
