<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 25/09/2015 00:13, James Penick a
écrit :<br>
</div>
<blockquote
cite="mid:CAMomh-7vS=Xd_7HbcL5jQsdhMh1H9re62h2vg68j8xsJc9=QmA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
</span>
At risk of getting too offtopic I think there's an
alternate solution to doing this in Nova or on the client
side. I think we're missing some sort of OpenStack API
and service that can handle this. Nova is a low level
infrastructure API and service, it is not designed to
handle these orchestrations. I haven't checked in on Heat
in a while but perhaps this is a role that it could fill.<br>
<br>
I think that too many people consider Nova to be *the*
OpenStack API when considering
instances/volumes/networking/images and that's not
something I would like to see continue. Or at the very
least I would like to see a split between the
orchestration/proxy pieces and the "manage my
VM/container/baremetal" bits</blockquote>
<div><br>
</div>
<div>(new thread)</div>
<div> You've hit on one of my biggest issues right now: As
far as many deployers and consumers are concerned (and
definitely what I tell my users within Yahoo): The value
of an OpenStack value-stream (compute, network, storage)
is to provide a single consistent API for abstracting and
managing those infrastructure resources. </div>
<div><br>
</div>
<div> Take networking: I can manage Firewalls, switches, IP
selection, SDN, etc through Neutron. But for compute, If I
want VM I go through Nova, for Baremetal I can -mostly- go
through Nova, and for containers I would talk to Magnum or
use something like the nova docker driver.</div>
<div><br>
</div>
<div> This means that, by default, Nova -is- the closest
thing to a top level abstraction layer for compute. But if
that is explicitly against Nova's charter, and Nova isn't
going to be the top level abstraction for all things
Compute, then something else needs to fill that space.
When that happens, all things common to compute
provisioning should come out of Nova and move into that
new API. Availability zones, Quota, etc.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
There is an old story that I would like to see where a nova boot
could have some affinity with volumes and networks. That means that
Neutron and Cinder could provide some resources to the nova
scheduler (or nova could call the projects) so that we could use
either filters (for hard limits) or weighers (for soft limits) in
order to say "eh, Nova, please create me an instance with that
flavor and that image close to this volume or this network".<br>
<br>
That said, we still have lots of work to do in Nova to help those
projects giving resources and we agreed to first work on the
scheduler interfaces (for providing resources and for getting a
destination) before working on cross-project resources. That's still
an on-going work but we hope to land the new interfaces by Mitaka.<br>
<br>
Not sure if we could have some discussion at Tokyo between Cinder,
Neutron and Nova about how to provide resources to the nova
scheduler given we haven't yet finished the interface reworking, but
we could at least get feedback from the Neutron and Cinder teams
about what kind of resources they'd like to provide so that an user
could ask for.<br>
<br>
Thoughts on that ?<br>
-Sylvain<br>
<br>
<blockquote
cite="mid:CAMomh-7vS=Xd_7HbcL5jQsdhMh1H9re62h2vg68j8xsJc9=QmA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>-James</div>
</div>
</div>
</div>
<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>