On 09/28/15 at 08:50am, Monty Taylor wrote:
On 09/28/2015 07:58 AM, Sylvain Bauza wrote:
Le 28/09/2015 12:35, Duncan Thomas a écrit :
On 28 September 2015 at 12:35, Sylvain Bauza <sba...@redhat.com
<mailto:sba...@redhat.com>> wrote:
About the maintenance burden, I also consider that patching
clients is far more easier than patching an API unless I missed
something.
I think I very much disagree there - patching a central installation
is much, much easier than getting N customers to patch M different
libraries, even assuming the fix is available for any significant
subset of the M libraries, plus making sure that new customers use the
correct libraries, plus helping any customers who have some sort of
roll-your-own library do the new right thing...
Well, having N versions of clients against one single API version is
just something we manage since the beginning. I don't really see why it
suddently becomes so difficult to manage it.
I think there's a definite place for a simple API to do infrastructure
level orchestration without needing the complexities of heat - these
APIs are in nova because they're useful - there's clear operator
desire for them and a couple of operators have been quite vocal about
their desire for them not to be removed. Great, let's keep them, but
form a team of people interested in getting them right (get rid of
fixed timeouts, etc), add any missing pieces (like floating IPs for
new VMs) and generally focus on getting this piece of the puzzle
right. Breaking another small piece off nova and polishing it has been
a generally successful pattern.
I don't want to overthink what could be the right scope of that future
API but given the Heat mission statement [1] and its service name
'orchestration', I don't see why this API endpoint should land in the
Nova codebase and couldn't be rather provided by the Heat API. Oh sure,
it would perhaps require another endpoint behind the same service, but
isn't that better than having another endpoint in Nova ?
[1]
https://github.com/openstack/governance/blob/master/reference/projects.yaml#L482-L484
I remember Monty Taylor (copied) having a rant about the lack of the
perfect 'give me a VM with all its stuff sorted' API. Care to comment,
Monty?
Sounds you misunderstood me. I'm not against implementing this excellent
usecase, I just think the best place is not in Nova and should be done
elsewhere.
Specifically, I want "nova boot" to get me a VM with an IP address. I
don't want it to do fancy orchestration - I want it to not need fancy
orchestration, because needing fancy orchestration to get a VM on a
network is not a feature.
In the networking case there is a minimum of orchestration because the
time required to allocate a port is small. What has been requiring
orchestration is the creation of volumes because of the requirement of
Cinder to download an image, or be on a backend that support fast
cloning and rely on a cache hit. So the question under discussion is
when booting an instance relies on another service performing a long
running operation where is a good place to handle that.
My thinking for a while has been that we could use another API that
could manage those things. And be the central place you're looking for
to pass a simple "nova boot" with whatever options are required so you
don't have to manage the complexities of calls to
Neutron/Cinder/Nova(current API). What's become clear to me from this
thread is that people don't seem to oppose that idea, however they don't
want their users/clients to need to switch what API they're currently
using(Nova).
The right way to proceed with this idea seems to be to by evolving the
Nova API and potentially creating a split down the road. And by split I
more mean architectural within Nova, and not necessarily a split API.
What I imagine is that we follow the model of git and have a plumbing
and porcelain API and each can focus on doing the right things.
I also VERY MUCH do not want to need Heat to get a VM. I want to use
Heat to do something complex. Getting a VM is not complex. It should
not be complex. What it's complex and to the level of needing Heat,
we've failed somewhere else.
Also, people should stop deploying clouds that require people to use
floating IPs to get basic internet access. It's a misuse of the
construct.
Public Network "ext-net" -> shared / directly attachable
Per-tenant Network "private" -> private network, not shared, not routable
If the user chooses, a router can be added with gateway set to ext-net.
This way:
nova boot --network=ext-net -> vm dhcp'd on the public network
nova boot --network=private -> vm dhcp'd on the private network
nova floating-ip-attach -> vm gets a floating ip attached to
their vm from the ext-net network
All of the use cases are handled, basic things are easy (boot a vm on
the network works in one step) and for the 5% of cases where a
floating IP is actually needed (a long-lived service on a single vm
that wants to keep the IP and not just a DNS name across VM
migrations and isn't using a load-balancer) can use that.
This is, btw, the most common public cloud deployment model.
Let's stop making things harder than they need to be and serve our users.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
