Open Stack

On Fri, Feb 12, 2016, at 05:29 PM, Doug Wiegley wrote:
> 
> > On Feb 12, 2016, at 3:17 PM, Andrew Laski <andrew at lascii.com> wrote:
> > 
> > 
> > 
> > On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
> >> 
> >>> On Feb 12, 2016, at 2:15 PM, Andrew Laski <andrew at lascii.com> wrote:
> >>> 
> >>> 
> >>> 
> >>> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
> >>>> Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
> >>>> gives it one nic with an IP, right?
> >>>> 
> >>>> So how is this changing that behavior? Making it harder to use, for the
> >>>> sake of preserving a really unusual corner case (no net with neutron),
> >>>> seems a much worse user experience here.
> >>> 
> >>> I was just going off of the behavior Matt described, that it was
> >>> possible to boot with no network by leaving that out of the request. If
> >>> the behavior already differs based on what networking backend is in use
> >>> then we've put users in a bad spot, and IMO furthers my case for having
> >>> explicit parameters in the request. I'm really not seeing how "--nic
> >>> auto|none" is any harder than leaving all network related parameters off
> >>> of the boot request, and it avoids potential confusion as to what will
> >>> happen.
> >> 
> >> It hurts discoverability, and “expectedness”. If I’m new to openstack,
> >> having it default boot unusable just means the first time I use ’nova
> >> boot’, I’ll end up with a useless VM. People don’t read docs first, it
> >> should “just work” as far as that’s sane. And OpenStack has a LOT of
> >> these little annoyances for the sake of strict correctness while
> >> optimizing for an unusual or rare case.
> >> 
> >> The original stated goal of this simpler neutron api was to get back to
> >> the simpler nova boot. I’d like to see that happen.
> > 
> > I'm not suggesting that the default boot be unusable. I'm saying that
> > just like it's required to pass in a flavor and image/volume to boot an
> > instance why not require the user to specify something about the
> > network. And that network request can be as simple as specifying "auto"
> > or "none". That seems to meet all of the requirements without the
> > confusion of needing to guess what the default behavior will be when
> > it's left off because it can apparently mean different things based on
> > which backed is in use. For users that don't read the docs they'll get
> > an immediate failure response indicating that they need to specify
> > something about the network versus the current and proposed state where
> > it's not clear what will happen unless they've read the docs on
> > microversions and understand which network service is being used.
> 
> I understand what you’re saying, and we’re almost down to style here. We
> have the previous nova-net ‘nova boot’ behavior, plus I think a VM with a
> network is kinda nonsensical, so adding that hoop for the default case
> doesn’t make sense to me. I’m not sure we’ll convince each other here,
> and that’s ok, I’ve said my peace.  :-)

Me too :)

Thanks for the discussion.


> 
> Thanks,
> doug
> 
> > 
> >> 
> >> Thanks,
> >> doug
> >> 
> >>> 
> >>>> 
> >>>> Thanks,
> >>>> doug
> >>>> 
> >>>> 
> >>>>> On Feb 12, 2016, at 1:51 PM, Ed Leafe <ed at leafe.com> wrote:
> >>>>> 
> >>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>> Hash: SHA512
> >>>>> 
> >>>>> On 02/12/2016 02:41 PM, Andrew Laski wrote:
> >>>>> 
> >>>>>>> I think if the point of the experience for this API is to be
> >>>>>>> working out
> >>>>>>>> of the box. So I very much like the idea of a defaults change
> >>>>>>>> here to the thing we want to be easy. And an explicit option to
> >>>>>>>> disable it if you want to do something more complicated.
> >>>>> 
> >>>>>> I think this creates a potential for confusing behavior for users. 
> >>>>>> They're happily booting instances with no network on 2.1, as silly
> >>>>>> as that might be, and then decide "ooh I'd like to use fancy new
> >>>>>> flag foo which is available in 2.35". So they add the flag to their
> >>>>>> request and set the version to 2.35 and suddenly multiple things
> >>>>>> change about their boot process because they missed that 2.24(or
> >>>>>> whatever) changed a default behavior. If this fits within the scope
> >>>>>> of microversions then users will need to expect that, but it's
> >>>>>> something that would be likely to trip me up as a user of the API.
> >>>>> 
> >>>>> I agree - that's always been the trade-off with microversions. You
> >>>>> never get surprises, but you can't move to a new feature in 2.X
> >>>>> without also having to get everything that was also introduced in
> >>>>> 2.X-1 and before. The benefit, of course, is that the user will have
> >>>>> changed something explicitly before getting the new behavior, and at
> >>>>> least has a chance of figuring it out.
> >>>>> 
> >>>>> - -- 
> >>>>> 
> >>>>> - -- Ed Leafe
> >>>>> -----BEGIN PGP SIGNATURE-----
> >>>>> Version: GnuPG v2
> >>>>> Comment: GPGTools - https://gpgtools.org
> >>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>>>> 
> >>>>> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> >>>>> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> >>>>> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> >>>>> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> >>>>> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> >>>>> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> >>>>> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> >>>>> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> >>>>> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> >>>>> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
> >>>>> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
> >>>>> GcPgzIoclwLrVooRqOSf
> >>>>> =Dqga
> >>>>> -----END PGP SIGNATURE-----
> >>>>> 
> >>>>> __________________________________________________________________________
> >>>>> OpenStack Development Mailing List (not for usage questions)
> >>>>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev