Open Stack

Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +0000:
> On Sep 25, 2015, at 1:56 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> > 
> > Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +0000:
> >> On Sep 25, 2015, at 1:24 PM, Brian Rosmaita <brian.rosmaita at RACKSPACE.COM> wrote:
> >>> 
> >>> I'd like to clarify something.
> >>> 
> >>> On 9/25/15, 12:16 PM, "Mark Voelker" <mvoelker at vmware.com> wrote:
> >>> [big snip]
> >>>> Also worth pointing out here: when we talk about ³doing the same thing²
> >>>> from a DefCore perspective, we¹re essentially talking about what¹s
> >>>> exposed to the end user, not how that¹s implemented in OpenStack¹s source
> >>>> code.  So from an end user¹s perspective:
> >>>> 
> >>>> If I call nova image-create, I get an image in my cloud.  If I call the
> >>>> Glance v2 API to create an image, I also get an image in my cloud.  I
> >>>> neither see nor care that Nova is actually talking to Glance in the
> >>>> background, because if I¹m writing code that uses the OpenStack API¹s, I
> >>>> need to pick which one of those two API¹s to make my code call upon to
> >>>> put an image in my cloud.  Or, in the worst case, I have to write a bunch
> >>>> of if/else loops into my code because some clouds I want to use only
> >>>> allow one way and some allow only the other.
> >>> 
> >>> The above is a bit inaccurate.
> >>> 
> >>> The nova image-create command does give you an image in your cloud.  The
> >>> image you get, however, is a snapshot of an instance that has been
> >>> previously created in Nova.  If you don't have an instance, you cannot
> >>> create an image via that command.  There is no provision in the Compute
> >>> (Nova) API to allow you to create an image out of bits that you supply.
> >>> 
> >>> The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> >>> register them as an image which you can then use to boot instances from by
> >>> using the Compute API.  But note that if all you have available is the
> >>> Images API, you cannot create an image of one of your instances.
> >>> 
> >>>> So from that end-user perspective, the Nova image-create API indeed does
> >>>> ³do the same thing" as the Glance API.
> >>> 
> >>> They don't "do the same thing".  Even if you have full access to the
> >>> Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> >>> create an image of an instance, which is by far the largest use-case for
> >>> image creation.  You can't do it through Glance, because Glance doesn't
> >>> know anything about instances.  Nova has to know about Glance, because it
> >>> needs to fetch images for instance creation, and store images for
> >>> on-demand images of instances.
> >> 
> >> Yup, that’s fair: this was a bad example to pick (need moar coffee I guess).  Let’s use image-list instead. =)
> > 
> > From a "technical direction" perspective, I still think it's a bad
> 
> Ah.  Thanks for bringing that up, because I think this may be an area where there’s some misconception about what DefCore is set up to do today.  In it’s present form, the Board of Directors has structured DefCore to look much more at trailing indicators of market acceptance rather than future technical direction.  More on that over here. [1] 

And yet future technical direction does factor in, and I'm trying
to add a new heuristic to that aspect of consideration of tests:
Do not add tests that use proxy APIs.

If there is some compelling reason to add a capability for which
the only tests use a proxy, that's important feedback for the
contributor community and tells us we need to improve our test
coverage. If the reason to use the proxy is that no one is deploying
the proxied API publicly, that is also useful feedback, but I suspect
we will, in most cases (glance is the exception), say "Yeah, that's
not how we mean for you to run the services long-term, so don't
include that capability."

> 
> > situation for us to be relying on any proxy APIs like this. Yes,
> > they are widely deployed, but we want to be using glance for image
> > features, neutron for networking, etc. Having the nova proxy is
> > fine, but while we have DefCore using tests to enforce the presence
> > of the proxy we can't deprecate those APIs.
> 
> 
> Actually that’s not true: DefCore can totally deprecate things too, and can do so in response to the technical community deprecating things.  See my comments in this review [2].  Maybe I need to write another post about that...

Sorry, I wasn't clear. The Nova team would, I expect, view the use of
those APIs in DefCore as a reason to avoid deprecating them in the code
even if they wanted to consider them as legacy features that should be
removed. Maybe that's not true, and the Nova team would be happy to
deprecate the APIs, but I did think that part of the feedback cycle we
were establishing here was to have an indication from the outside of the
contributor base about what APIs are considered important enough to keep
alive for a long period of time.

> 
> /me envisions the title being “Who’s on First?”

Indeed.

> 
> > 
> > What do we need to do to make that change happen over the next cycle
> > or so?
> 
> There are several things that can be done:
> 
> First, if you don’t like the Criteria or the weights that the various Criteria today have, we can suggest changes to them.  The Board of Directors will ultimately have to approve that change, but we can certainly ask (I think there’s plenty of evidence that our Directors listen to the community’s concerns).  There’s actually already some early discussion about that now, though most of the energy is going into other things at the moment (because deadlines).  See post above for links.
> 
> Second, we certainly could consider changes to the Capabilities that are currently required.  That happens every six months according to a Board-approved schedule. [3]  The window is just about to close for the next Guideline, but that might be ok from the perspective of a lot of stuff is likely be advisory in the next Guideline anyway, and advisory cycles are explicitly meant to generate feedback like this.  Making changes to Guidelines is basically submitting a patch. [4]
> 
> Third, as a technical community we can make the capabilities we want score better.  So for example: we could make nova image use glance v2, or we could deprecate those API’s (per above, you do not have to wait on DefCore for that to happen), or we could send patches to the client SDK’s that OpenStack users are relying on to make those capabilities supported.

I'll just note the irony of asking "How do I provide requirements
feedback" and getting "Submit a patch" as the answer. ;-)

I'll try to find some time to figure out how the capabilities
specifications work, and learn about what each of the tests means
and how it works, and then how to submit the patch under the review
process you use. It's likely to take me a while, so if someone on
the "inside" who understands those things better wants to collaborate
more closely while I come up to speed, I'm happy to do that off-list.

Doug

> 
> [1] http://markvoelker.github.io/blog/defcore-misconceptions-1/
> [2] https://review.openstack.org/#/c/207467/4/reference/tags/assert_follows-standard-deprecation.rst
> [3] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n10
> [4] http://git.openstack.org/cgit/openstack/defcore/tree/HACKING.rst
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> > 
> > Doug
> > 
> >> 
> >> At Your Service,
> >> 
> >> Mark T. Voelker
> >> 
> >>> 
> >>> 
> >>>> At Your Service,
> >>>> 
> >>>> Mark T. Voelker
> >>> 
> >>> Glad to be of service, too,
> >>> brian
> >>> 
> >>> 
> >>> __________________________________________________________________________
> >>> 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
>