Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

2014-05-13 Thread Sylvain Bauza 
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  > wrote:
>
>>
>>
>>
>> 2014-04-07 23:11 GMT+02:00 Sylvain Bauza > >:
>>
>> Hi Phil,
>>
>>
>>
>> 2014-04-07 18:48 GMT+02:00 Day, Phil > >:
>>
>> 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
>
>
>
> ___
> 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 ?

2014-05-13 Thread Meghal Gosalia 
Is any discussion on this topic scheduled during the summit ?

Thanks,
Meghal

On Apr 9, 2014, at 9:03 AM, Sylvain Bauza 
mailto:sylvain.ba...@gmail.com>> wrote:




2014-04-07 23:11 GMT+02:00 Sylvain Bauza 
mailto:sylvain.ba...@gmail.com>>:
Hi Phil,



2014-04-07 18:48 GMT+02:00 Day, Phil 
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/ 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

___
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-09 Thread Steve Gordon 
- 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 ?

2014-04-09 Thread Day, Phil 
> -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 ?

2014-04-09 Thread Sylvain Bauza 
2014-04-07 23:11 GMT+02:00 Sylvain Bauza :

> Hi Phil,
>
>
>
> 2014-04-07 18:48 GMT+02:00 Day, Phil :
>
>   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 ?

2014-04-09 Thread Chris Friesen 

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-09 Thread Day, Phil 
> -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 ?

2014-04-09 Thread Day, Phil 
> -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 ?

2014-04-08 Thread Chris Friesen 

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 ?

2014-04-08 Thread Steve Gordon 
- 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 ?

2014-04-08 Thread Khanh-Toan Tran 


> -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 
> > 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 ?

2014-04-08 Thread Jay Pipes 
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 
> 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 ?

2014-04-08 Thread Day, Phil 
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 
mailto: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 ?

2014-04-08 Thread Khanh-Toan Tran 
“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 
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 ?

2014-04-07 Thread Ian Wells 
On 3 April 2014 08:21, Khanh-Toan Tran 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 ?

2014-04-07 Thread Sylvain Bauza 
Hi Phil,



2014-04-07 18:48 GMT+02:00 Day, Phil :

>  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.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 Ce

Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

2014-04-07 Thread Jay Pipes 
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 ?

2014-04-07 Thread Day, Phil 
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=DHjJAgAAQBAJ&pg=PA141#v=onepage&q&f=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 ?

2014-04-04 Thread Meghal Gosalia 
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 
mailto:sylvain.ba...@gmail.com>> wrote:




2014-04-04 10:30 GMT+02:00 Sylvain Bauza 
mailto:sylvain.ba...@gmail.com>>:
Hi all,



2014-04-03 18:47 GMT+02:00 Meghal Gosalia 
mailto: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 
mailto: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

___
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-04 Thread Sylvain Bauza 
2014-04-04 10:30 GMT+02:00 Sylvain Bauza :

> Hi all,
>
>
>
> 2014-04-03 18:47 GMT+02:00 Meghal Gosalia :
>
>  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  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 ?

2014-04-04 Thread Sylvain Bauza 
Hi all,



2014-04-03 18:47 GMT+02:00 Meghal Gosalia :

>  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  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 ?

2014-04-03 Thread Meghal Gosalia 
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 
mailto: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

Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

2014-04-03 Thread Steve Gordon 
- 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 ?

2014-04-03 Thread Chris Friesen 

On 04/03/2014 09:34 AM, Murray, Paul (HP Cloud Services) wrote:

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.


I'm okay with only allowing hosts to be within a single availability 
zone, but in that case maybe we could have a per-instance way of 
matching host aggregate metadata when booting the instance--maybe a 
special form of scheduler hints?  This would be analogous to the 
existing matching of flavor metadata.


Also, while we're looking at availability zones I'd like to point out a 
bug I reported last year (https://bugs.launchpad.net/nova/+bug/1213224) 
where you can specify multiple aggregates with the same zone name. 
Since the user can only specify the zone name, this makes it 
indeterminate which aggregate is actually used.


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-03 Thread Steve Gordon 
- 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 ?

2014-04-03 Thread Murray, Paul (HP Cloud Services) 
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=DHjJAgAAQBAJ&pg=PA141#v=onepage&q&f=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 ?

2014-04-03 Thread Khanh-Toan Tran 
Dual-room link:

[1] IBM and Cisco: Together for a World Class Data Center, Page 141.
http://books.google.fr/books?id=DHjJAgAAQBAJ&pg=PA141#v=onepage&q&f=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 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
>
> > -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 ?

2014-04-03 Thread Khanh-Toan Tran 
+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

> -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 ?

2014-04-03 Thread Khanh-Toan Tran 
+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=DHjJAgAAQBAJ
<http://books.google.fr/books?id=DHjJAgAAQBAJ&pg=PA141#v=onepage&q&f=false
> &pg=PA141#v=onepage&q&f=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 ?

2014-04-03 Thread Chris Friesen 

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] [Nova] Hosts within two Availability Zones : possible or not ?

2014-04-03 Thread Sylvain Bauza 
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