Open Stack

Doug Hellmann 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
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.

What do we need to do to make that change happen over the next cycle
or so?

[Rocky]
This is likely the first case DefCore will have pf deprecating a requirement ;-)  The committee wasn't thrilled with the original requirement, but really, can you have OpenStack without some way of creating an instance?  And Glance V1 had no user facing APIs, so the committee was kind of stuck.

But, going forward, what needs to happen in Dev is for Glance V2 to become *the way* to create images, and for Glance V1 to be deprecated *and removed*.  Then we've got two more cycles before we can require V2 only.  Yes, DefCore is a trailing requirement.  We have to give our user community time to migrate to versions of OpenStack that don't have the "old" capability.

But now comes the tricky part....How do you allow both V1 and V2 capabilities and still be interoperable?  This will definitely be the first test for DefCore on migration from obsolete capabilities to current capabilities.  We could use some help figuring out how to make that work.

--Rocky

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