Open Stack

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.

> 
> 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