<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">Le 28/07/2016 15:57, Chris Dent a
écrit :<br>
</div>
<blockquote cite="mid:alpine.OSX.2.11.1607281409540.669@seed.local"
type="cite">
<br>
I've been reviewing my notes from the mid-cycle and discussions
<br>
leading up to it and realized I have a few unresolved or open
topics
<br>
that I hope discussion here can help resolve:
<br>
<br>
# fairly straightforward things
<br>
<br>
* At what stage in the game (of the placement api) do we need to
<br>
implement oslo_policy handling and enforcement? Right now the
auth
<br>
model is simply all-admin-role-all-the-time.
<br>
<br>
</blockquote>
<br>
LGTM for Newton to keep that simple logic given that only Nova will
call out the placement API for the moment.<br>
Once we begin opening doors, then yes, oslo.policy will become a
thing.<br>
<br>
<br>
<blockquote cite="mid:alpine.OSX.2.11.1607281409540.669@seed.local"
type="cite">* There was some discussion of adding a configuration
setting (e.g.
<br>
'placement_connection') that if not None (the default) would be
<br>
used as the connection for the placement database. If None, the
<br>
API database would be used. I can't recall if we said 'yea' or
<br>
'nay' to this idea. The current code uses the api database and
its
<br>
config.
<br>
<br>
</blockquote>
<br>
I thought we agreed on that during the midcycle ?<br>
<br>
<br>
<blockquote cite="mid:alpine.OSX.2.11.1607281409540.669@seed.local"
type="cite"># less straightforward and further out things
<br>
<br>
There was some discussion that conflicted with reality a bit and I
<br>
think we need to resolve before too long, but shouldn't impact the
<br>
newton-based changes:
<br>
<br>
We bounced around two different HTTP resources for returning one
or
<br>
several resource providers in response to a launch request:
<br>
<br>
* POST /allocations
<br>
<br>
returns a representation of the one target for this launch
<br>
request, already claimed
<br>
<br>
</blockquote>
<br>
Please, why are you opening this thread now given it's ABSOLUTELY
not related to the placement API ?<br>
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.<br>
<br>
<br>
<blockquote cite="mid:alpine.OSX.2.11.1607281409540.669@seed.local"
type="cite">* GET /resource_providers
<br>
<br>
returns a list of candidate targets for a launch request,
similar
<br>
to what the existing select_destinations RPC call can do
<br>
<br>
The immediate problem here is that something else is already using
<br>
GET /resource_providers:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html#get-resource-providers">http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html#get-resource-providers</a><br>
<br>
Whatever the URI, it's not clear that GET would be correct here:
<br>
<br>
* We'll probably want to send a body so GET is not ideal.
<br>
<br>
* We could pass a reference to a persisted "request spec" as a
query
<br>
string item, thus maintaining a GET, but that seems to go
against
<br>
the grain of "give a thing the info it needs to get stuff done"
that
<br>
is elsewhere in the system.
<br>
<br>
I'd personally be pretty okay with launch-info-by-reference mode
as
<br>
it allows the placement API to be in charge of request what
version
<br>
of a launch request it wants rather than its clients needing to
know
<br>
what version the placement API might accept.
<br>
<br>
It's pretty clear that were going to need at least an interim and
<br>
maybe permanent endpoint that returns a list of candidate target
<br>
resource providers. This is because, at least initially, the
<br>
placement engine will not be able to resolve all requirements down
<br>
to the one single result and additional filtering may be required
in
<br>
the caller.
<br>
<br>
</blockquote>
<br>
So we had a discussion in Hillsboro about that with no consensus
yet, if you remember.<br>
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.<br>
<br>
<br>
<blockquote cite="mid:alpine.OSX.2.11.1607281409540.669@seed.local"
type="cite">The question is: Will that need for additional
filtering always be
<br>
present and if so do we:
<br>
<br>
* consider that a bad thing that we should strive to fix by
<br>
expanding the powers and size of the placement engine
<br>
* consider that a good thing that allows the placement engine to
be
<br>
relatively simple and keeps edge-case behaviors being handled
<br>
elsewhere
<br>
<br>
If the latter, then we'll have to consider how an allocation/claim
<br>
in a list of potential allocations can be essentially reserved,
<br>
verified, or rejected.
<br>
<br>
As an example of expanding the powers, there is the
<br>
ResourceProviderTags concept, described in:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/345138/">https://review.openstack.org/#/c/345138/</a>
<br>
<br>
This will expand the data model of resource providers and the
surface
<br>
area of the HTTP API. This may very well be entirely warranted,
but
<br>
there might be other options if we assuming that returning a list
is
<br>
"normal".
<br>
<br>
Sorry if this is unclear. I'm rather jet-lagged. Ask questions if
<br>
you have them. Thanks.
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>