<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 28/09/2015 11:23, Duncan Thomas a
écrit :<br>
</div>
<blockquote
cite="mid:CAOyZ2aFw+omfP-ptLz6Ch0PExV6L+=uANU7XBNbNYqm1JFQjYA@mail.gmail.com"
type="cite">
<p dir="ltr">The trouble with putting more intelligence in the
clients is that there are more clients than just the one we
provide, and the more smarts we require in the clients, the more
divergence of functionality we're likely to see. Also, bugs and
slowly percolating bug fixes. </p>
</blockquote>
<br>
That's why I consider the layer of orchestration in the client just
being as identical as what we have in Nova, not more than that. If
we require more than just a volume creation when asking to boot from
a volume with source=image, then I agree with you, it has nothing to
do in the client, but rather in Heat.<br>
<br>
The same goes with networks. What is done with Nova for managing
CRUD operations can be done in python clients, but that's the limit.<br>
<br>
About the maintenance burden, I also consider that patching clients
is far more easier than patching an API unless I missed something.<br>
<br>
-Sylvain<br>
<br>
<br>
<blockquote
cite="mid:CAOyZ2aFw+omfP-ptLz6Ch0PExV6L+=uANU7XBNbNYqm1JFQjYA@mail.gmail.com"
type="cite">
<div class="gmail_quote">On 28 Sep 2015 11:27, "Sylvain Bauza"
<<a moz-do-not-send="true" href="mailto:sbauza@redhat.com">sbauza@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Le 25/09/2015 16:12, Andrew Laski a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/24/15 at 03:13pm, James Penick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
At risk of getting too offtopic I think there's an
alternate solution to<br>
doing this in Nova or on the client side. I think we're
missing some sort<br>
of OpenStack API and service that can handle this. Nova
is a low level<br>
infrastructure API and service, it is not designed to
handle these<br>
orchestrations. I haven't checked in on Heat in a while
but perhaps this<br>
is a role that it could fill.<br>
<br>
I think that too many people consider Nova to be *the*
OpenStack API when<br>
considering instances/volumes/networking/images and
that's not something I<br>
would like to see continue. Or at the very least I
would like to see a<br>
split between the orchestration/proxy pieces and the
"manage my<br>
VM/container/baremetal" bits<br>
</blockquote>
<br>
<br>
(new thread)<br>
You've hit on one of my biggest issues right now: As far
as many deployers<br>
and consumers are concerned (and definitely what I tell my
users within<br>
Yahoo): The value of an OpenStack value-stream (compute,
network, storage)<br>
is to provide a single consistent API for abstracting and
managing those<br>
infrastructure resources.<br>
<br>
Take networking: I can manage Firewalls, switches, IP
selection, SDN, etc<br>
through Neutron. But for compute, If I want VM I go
through Nova, for<br>
Baremetal I can -mostly- go through Nova, and for
containers I would talk<br>
to Magnum or use something like the nova docker driver.<br>
<br>
This means that, by default, Nova -is- the closest thing
to a top level<br>
abstraction layer for compute. But if that is explicitly
against Nova's<br>
charter, and Nova isn't going to be the top level
abstraction for all<br>
things Compute, then something else needs to fill that
space. When that<br>
happens, all things common to compute provisioning should
come out of Nova<br>
and move into that new API. Availability zones, Quota,
etc.<br>
</blockquote>
<br>
I do think Nova is the top level abstraction layer for
compute. My issue is when Nova is asked to manage other
resources. There's no API call to tell Cinder "create a
volume and attach it to this instance, and create that
instance if it doesn't exist." And I'm not sure why the
reverse isn't true.<br>
<br>
I want Nova to be the absolute best API for managing compute
resources. It's when someone is managing compute and
volumes and networks together that I don't feel that Nova is
the best place for that. Most importantly right now it
seems that not everyone is on the same page on this and I
think it would be beneficial to come together and figure out
what sort of workloads the Nova API is intending to provide.<br>
</blockquote>
<br>
I totally agree with you on those points :<br>
- nova API should be only supporting CRUD operations for
compute VMs and should no longer manage neither volumes nor
networks IMHO, because it creates more problems than it
resolves<br>
- given the above, nova API could possibly accept resources
from networks or volumes but only for placement decisions
related to instances.<br>
<br>
Tho, I can also understand that operators sometimes just want
a single tool for creating this kind of relationship between a
volume and an instance (and not provide a YAML file), but
IMHO, it doesn't perhaps need a top-level API, just a python
client able to do some very simple orchestration between
services, something like openstack-client.<br>
<br>
I don't really see a uber-value for getting a proxy API
calling Nova or Neutron. IMHO, that should still be done by
clients, not services.<br>
<br>
-Sylvain<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-James<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
__________________________________________________________________________
<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________
<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</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>