On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote: > On 09/07/2016 07:34 PM, Andrew Laski wrote: > > > > > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > >> 3) core functionality should IMO require as few API calls as possible, > >> to as few components as possible, while keeping REST data models etc. > >> intact, [1][2] > > > > I agree that it should require as few API calls as possible but maybe we > > disagree about what core functionality is. Or to put it another way, > > what is core functionality depends on your perspective. > > > > I subscribe to the plumbing and porcelain approach > > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > > and believe that Nova should be part of the plumbing. So while I fully > > agree with a small number of API calls to do simple tasks I don't > > believe that orchestrating network setups is core functionality in Nova > > but is core to OpenStack. > > Personally, I think that the role of Nova is to give you a functional > compute unit. If you can't talk to that over the network, that doesn't > seem very functional to me. For complicated setups it's fine that you > need to do complicated things, but "I would like a working server with > network" doesn't feel like it's a complicated ask from the user.
I'd really like to agree here, however it seems that it is actually a somewhat complicated ask from the user due to the diverse network setups used in practice. But I was responding to the idea of booting an instance with a floating-ip which to me goes beyond setting up a simple default network for an instance. And I think therein lies the problem, there seems to be some disagreement as to what a simple default network setup should be. > > And more importantly, if there isn't some firm line there, the ability > to do that between clouds is going to be somewhat limited, because > exactly how you need to configure each cloud's neutron manually to work > with their physical network setup is going to be different. > > You end up with the shade situation now, which isn't a great user > experience. > > I do get the concern about Nova scope creep into orchestration. However > it's not like "orchestration" has a bright line anywhere. And I think > that basic working networking for requested computes isn't something we > should require another service for. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > 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