Open Stack

Le 28/07/2016 15:57, Chris Dent a écrit :
>
> I've been reviewing my notes from the mid-cycle and discussions
> leading up to it and realized I have a few unresolved or open topics
> that I hope discussion here can help resolve:
>
> # fairly straightforward things
>
> * At what stage in the game (of the placement api) do we need to
>   implement oslo_policy handling and enforcement? Right now the auth
>   model is simply all-admin-role-all-the-time.
>

LGTM for Newton to keep that simple logic given that only Nova will call 
out the placement API for the moment.
Once we begin opening doors, then yes, oslo.policy will become a thing.


> * There was some discussion of adding a configuration setting (e.g.
>   'placement_connection') that if not None (the default) would be
>   used as the connection for the placement database. If None, the
>   API database would be used. I can't recall if we said 'yea' or
>   'nay' to this idea. The current code uses the api database and its
>   config.
>

I thought we agreed on that during the midcycle ?


> # less straightforward and further out things
>
> There was some discussion that conflicted with reality a bit and I
> think we need to resolve before too long, but shouldn't impact the
> newton-based changes:
>
> We bounced around two different HTTP resources for returning one or
> several resource providers in response to a launch request:
>
> * POST /allocations
>
>   returns a representation of the one target for this launch
>   request, already claimed
>

Please, why are you opening this thread now given it's ABSOLUTELY not 
related to the placement API ?
That confuses a lot of people here, and we basically had a consensus on 
the Newton target : allocations are made by the compute nodes, I don't 
see things less than straightforward here.


> * GET /resource_providers
>
>   returns a list of candidate targets for a launch request, similar
>   to what the existing select_destinations RPC call can do
>
> The immediate problem here is that something else is already using
> GET /resource_providers:
>
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html#get-resource-providers
>
> Whatever the URI, it's not clear that GET would be correct here:
>
> * We'll probably want to send a body so GET is not ideal.
>
> * We could pass a reference to a persisted "request spec" as a query
>   string item, thus maintaining a GET, but that seems to go against
>   the grain of "give a thing the info it needs to get stuff done" that
>   is elsewhere in the system.
>
>   I'd personally be pretty okay with launch-info-by-reference mode as
>   it allows the placement API to be in charge of request what version
>   of a launch request it wants rather than its clients needing to know
>   what version the placement API might accept.
>
> It's pretty clear that were going to need at least an interim and
> maybe permanent endpoint that returns a list of candidate target
> resource providers. This is because, at least initially, the
> placement engine will not be able to resolve all requirements down
> to the one single result and additional filtering may be required in
> the caller.
>

So we had a discussion in Hillsboro about that with no consensus yet, if 
you remember.
I heard different opinions on how nova-scheduler would integrate with 
the placement API in Ocata, and I was concerned by this service doing an 
HTTP call to an external API. My idea was rather to integrate the new 
placement tables into the existing HostManager, so that instead of 
getting a full list of compute nodes, we would provide to the filters a 
list of resource providers matching the query.


> The question is: Will that need for additional filtering always be
> present and if so do we:
>
> * consider that a bad thing that we should strive to fix by
>   expanding the powers and size of the placement engine
> * consider that a good thing that allows the placement engine to be
>   relatively simple and keeps edge-case behaviors being handled
>   elsewhere
>
> If the latter, then we'll have to consider how an allocation/claim
> in a list of potential allocations can be essentially reserved,
> verified, or rejected.
>
> As an example of expanding the powers, there is the
> ResourceProviderTags concept, described in:
>
>     https://review.openstack.org/#/c/345138/
>
> This will expand the data model of resource providers and the surface
> area of the HTTP API. This may very well be entirely warranted, but
> there might be other options if we assuming that returning a list is
> "normal".
>
> Sorry if this is unclear. I'm rather jet-lagged. Ask questions if
> you have them. Thanks.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160728/9898dba1/attachment.html>