On Mon, 13 Mar 2017, Chris Dent wrote:
* The scheduler report client in nova, and to a minor degree the
filter scheduler, use some of the same exceptions and ovo.objects
that placement uses, which presents a bit of blechiness with
regards to code duplication. I suppose long term we could cons
On 13 March 2017 at 15:17, Jay Pipes wrote:
> On 03/13/2017 11:13 AM, Dan Smith wrote:
>>
>> Interestingly, we just had a meeting about cells and the scheduler,
>> which had quite a bit of overlap on this topic.
>>
>>> That said, as mentioned in the previous email, the priorities for Pike
>>> (and
Hi Matt,
On Tue, Mar 14, 2017 at 5:27 PM, Matt Riedemann wrote:
> We did agree to provide an openstackclient plugin purely for CLI
> convenience. That would be in a separate repo, not part of nova or
> novaclient. I've started a blueprint [1] for tracking that work. *The
> placement osc plugin bl
On 3/13/2017 9:14 AM, Sylvain Bauza wrote:
To be honest, one of the things I think we're missing yet is a separate
client that deployers would package so that Nova and other customer
projects would use for calling the Placement API.
At the moment, we have a huge amount of code in nova.scheduler.
On 03/13/2017 11:13 AM, Dan Smith wrote:
Interestingly, we just had a meeting about cells and the scheduler,
which had quite a bit of overlap on this topic.
That said, as mentioned in the previous email, the priorities for Pike
(and likely Queens) will continue to be, in order: traits, ironic,
Interestingly, we just had a meeting about cells and the scheduler,
which had quite a bit of overlap on this topic.
> That said, as mentioned in the previous email, the priorities for Pike
> (and likely Queens) will continue to be, in order: traits, ironic,
> shared resource pools, and nested prov
On Mon, 13 Mar 2017, Sylvain Bauza wrote:
That way, we could do the necessary quirks in the client in case the
split goes bad.
I don't understand this statement. If the client is always using the
service catalog (which it should be) and the client is always only
aware of the HTTP interface (wh
Le 13/03/2017 15:17, Jay Pipes a écrit :
> On 03/13/2017 09:16 AM, Sylvain Bauza wrote:
>> Please don't.
>> Having a separate repository would mean that deployers would need to
>> implement a separate package for placement plus discussing about
>> how/when to use it.
>
> Apparently, there alread
On 03/13/2017 09:16 AM, Sylvain Bauza wrote:
Please don't.
Having a separate repository would mean that deployers would need to
implement a separate package for placement plus discussing about
how/when to use it.
Apparently, there already *are* separate packages for
openstack-nova-api-placemen
Le 13/03/2017 14:59, Jay Pipes a écrit :
> On 03/13/2017 08:41 AM, Chris Dent wrote:
>>
>> From the start we've been saying that it is probably right for the
>> placement service to have its own repository. This is aligned with
>> the long term goal of placement being useful to many services, not
On 03/13/2017 10:02 AM, Eoghan Glynn wrote:
We are close to the first milestone in Pike, right ? We also have
priorities for Placement that we discussed at the PTG and we never
discussed about how to cut placement during the PTG.
Also, we haven't discussed yet with operators about how they would
> > We are close to the first milestone in Pike, right ? We also have
> > priorities for Placement that we discussed at the PTG and we never
> > discussed about how to cut placement during the PTG.
> >
> > Also, we haven't discussed yet with operators about how they would like
> > to see Placement
On 03/13/2017 08:41 AM, Chris Dent wrote:
From the start we've been saying that it is probably right for the
placement service to have its own repository. This is aligned with
the long term goal of placement being useful to many services, not
just nova, and also helps to keep placement contained
On 03/13/2017 09:33 AM, Sylvain Bauza wrote:
>
> We are close to the first milestone in Pike, right ? We also have
> priorities for Placement that we discussed at the PTG and we never
> discussed about how to cut placement during the PTG.
>
> Also, we haven't discussed yet with operators about h
Le 13/03/2017 14:21, Sean Dague a écrit :
> On 03/13/2017 09:16 AM, Sylvain Bauza wrote:
>>
>>
>> Le 13/03/2017 13:41, Chris Dent a écrit :
>>>
>>> From the start we've been saying that it is probably right for the
>>> placement service to have its own repository. This is aligned with
>>> the lon
On 03/13/2017 09:16 AM, Sylvain Bauza wrote:
>
>
> Le 13/03/2017 13:41, Chris Dent a écrit :
>>
>> From the start we've been saying that it is probably right for the
>> placement service to have its own repository. This is aligned with
>> the long term goal of placement being useful to many servi
Le 13/03/2017 13:41, Chris Dent a écrit :
>
> From the start we've been saying that it is probably right for the
> placement service to have its own repository. This is aligned with
> the long term goal of placement being useful to many services, not
> just nova, and also helps to keep placement
From the start we've been saying that it is probably right for the
placement service to have its own repository. This is aligned with
the long term goal of placement being useful to many services, not
just nova, and also helps to keep placement contained and
comprehensible and thus maintainable
18 matches
Mail list logo