Re: [openstack-dev] Glance Store Future
On 08/01/2014 10:41 PM, Jay Pipes wrote: cc'ing ML since it's an important discussion, IMO... On 07/31/2014 11:54 AM, Arnaud Legendre wrote: Hi Jay, I would be interested if you could share your point of view on this item: we want to make the glance stores a standalone library (glance.stores) which would be consumed directly by Nova and Cinder. Yes, I have been enthusiastic about this effort for a long time now :) In fact, I have been pushing a series of patches (most merged at this point) in Nova to clean up the (very) messy nova.image.glance module and standardize the image API in Nova. The messiest part of the current image API in Nova, by far, is the nova.image.glance.GlanceImageService.download() method, which you highlight below. The reason it is so messy is that the method does different things (and returns different things!) depending on how you call it and what arguments you provide. :( +1 I think it would be nice to get your pov since you worked a lot on the Nova image interface recently. To give you an example: Here https://github.com/openstack/nova/blob/master/nova/image/glance.py#L333, we would do: 1. location = get_image_location(image_id), 2. get(location) from the glance.stores library like for example rbd (https://github.com/openstack/glance/blob/master/glance/store/rbd.py#L206) Yup. Though I'd love for this code to live in olso, not glance... I think both places make sense. The reason why we decided to keep it under glance is because it's still an important piece of the project and the team is willing to maintain it, plus the team is already familiar with the code. Not sure how strong those points are but AFAIR, those two are the reason why the lib lives under glance. Here's the link to the email thread were this was discussed: http://lists.openstack.org/pipermail/openstack-dev/2013-December/022907.html Plus, I'd almost prefer to see an interface that hides the location URIs entirely and makes the discovery of those location URIs entirely encapsulated within glance.store. So, for instance, instead of getting the image location using a call to glanceclient.show(), parsing the locations collection from the v2 API response, and passing that URI to the glance.store.get() function, I'd prefer to see an interface more like this: FWIW, The API is not finished (probably not even started :D). The first step we wanted to pursue was pulling the code out of Glance and just then work on an improved, more secure and more consistent API. Your proposal looks neat, I'll propose a design session for the glance.store API. :D Thanks for your feedback, Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
Duncan Thomas On Aug 1, 2014 9:44 PM, Jay Pipes jaypi...@gmail.com wrote: Yup. Though I'd love for this code to live in olso, not glance... Why Oslo? There seems to be a general obsession with getting things into Oslo, but our (cinder team) general experiences with the end result have been highly variable, to the point where we've discussed just saying no to Oslo code since the pain is more than the gain. In this case, the glance team are the subject matter experts, the glance interfaces and internals are their core competency, I honestly can't see any value in putting the project anywhere other than glance ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
On 08/04/2014 09:09 AM, Duncan Thomas wrote: Duncan Thomas On Aug 1, 2014 9:44 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Yup. Though I'd love for this code to live in olso, not glance... Why Oslo? There seems to be a general obsession with getting things into Oslo, but our (cinder team) general experiences with the end result have been highly variable, to the point where we've discussed just saying no to Oslo code since the pain is more than the gain. In this case, the glance team are the subject matter experts, the glance interfaces and internals are their core competency, I honestly can't see any value in putting the project anywhere other than glance 2 reasons. 1) This is code that will be utilized by 1 project, and is a library, not a service endpoint. That seems to be right up the Oslo alley. 2) The mission of the Glance program has changed to being an application catalog service, not an image streaming service. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
On Aug 4, 2014, at 9:27 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/04/2014 09:09 AM, Duncan Thomas wrote: Duncan Thomas On Aug 1, 2014 9:44 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Yup. Though I'd love for this code to live in olso, not glance... Why Oslo? There seems to be a general obsession with getting things into Oslo, but our (cinder team) general experiences with the end result have been highly variable, to the point where we've discussed just saying no to Oslo code since the pain is more than the gain. In this case, the glance team are the subject matter experts, the glance interfaces and internals are their core competency, I honestly can't see any value in putting the project anywhere other than glance 2 reasons. 1) This is code that will be utilized by 1 project, and is a library, not a service endpoint. That seems to be right up the Oslo alley. 2) The mission of the Glance program has changed to being an application catalog service, not an image streaming service. Best, -jay Oslo isn’t the only program that can produce reusable libraries, though. If the Glance team is going to manage this code anyway, it makes sense to leave it in the Glance program. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
On 08/04/2014 09:46 AM, Doug Hellmann wrote: On Aug 4, 2014, at 9:27 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/04/2014 09:09 AM, Duncan Thomas wrote: Duncan Thomas On Aug 1, 2014 9:44 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Yup. Though I'd love for this code to live in olso, not glance... Why Oslo? There seems to be a general obsession with getting things into Oslo, but our (cinder team) general experiences with the end result have been highly variable, to the point where we've discussed just saying no to Oslo code since the pain is more than the gain. In this case, the glance team are the subject matter experts, the glance interfaces and internals are their core competency, I honestly can't see any value in putting the project anywhere other than glance 2 reasons. 1) This is code that will be utilized by 1 project, and is a library, not a service endpoint. That seems to be right up the Oslo alley. 2) The mission of the Glance program has changed to being an application catalog service, not an image streaming service. Best, -jay Oslo isn’t the only program that can produce reusable libraries, though. If the Glance team is going to manage this code anyway, it makes sense to leave it in the Glance program. Agreed. Honestly it's better to keep the review teams close to the expertise for the function at hand. It needs to be ok that teams besides oslo create reusable components for other parts of OpenStack. Oslo should be used for things where there isn't a strong incumbent owner. I think we have a strong incumbent owner here so living in Artifacts program makes sense to me. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
On 08/04/2014 10:29 AM, Sean Dague wrote: On 08/04/2014 09:46 AM, Doug Hellmann wrote: On Aug 4, 2014, at 9:27 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/04/2014 09:09 AM, Duncan Thomas wrote: Duncan Thomas On Aug 1, 2014 9:44 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Yup. Though I'd love for this code to live in olso, not glance... Why Oslo? There seems to be a general obsession with getting things into Oslo, but our (cinder team) general experiences with the end result have been highly variable, to the point where we've discussed just saying no to Oslo code since the pain is more than the gain. In this case, the glance team are the subject matter experts, the glance interfaces and internals are their core competency, I honestly can't see any value in putting the project anywhere other than glance 2 reasons. 1) This is code that will be utilized by 1 project, and is a library, not a service endpoint. That seems to be right up the Oslo alley. 2) The mission of the Glance program has changed to being an application catalog service, not an image streaming service. Best, -jay Oslo isn’t the only program that can produce reusable libraries, though. If the Glance team is going to manage this code anyway, it makes sense to leave it in the Glance program. Agreed. Honestly it's better to keep the review teams close to the expertise for the function at hand. It needs to be ok that teams besides oslo create reusable components for other parts of OpenStack. Oslo should be used for things where there isn't a strong incumbent owner. I think we have a strong incumbent owner here so living in Artifacts program makes sense to me. Sure, fair points from all. If it can be imported/packaged without including all the legacy Glance code, then I'd be more behind keeping it in Glance... -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
On 08/04/2014 05:56 PM, Jay Pipes wrote: On 08/04/2014 10:29 AM, Sean Dague wrote: On 08/04/2014 09:46 AM, Doug Hellmann wrote: On Aug 4, 2014, at 9:27 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/04/2014 09:09 AM, Duncan Thomas wrote: Duncan Thomas On Aug 1, 2014 9:44 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Yup. Though I'd love for this code to live in olso, not glance... Why Oslo? There seems to be a general obsession with getting things into Oslo, but our (cinder team) general experiences with the end result have been highly variable, to the point where we've discussed just saying no to Oslo code since the pain is more than the gain. In this case, the glance team are the subject matter experts, the glance interfaces and internals are their core competency, I honestly can't see any value in putting the project anywhere other than glance 2 reasons. 1) This is code that will be utilized by 1 project, and is a library, not a service endpoint. That seems to be right up the Oslo alley. 2) The mission of the Glance program has changed to being an application catalog service, not an image streaming service. Best, -jay Oslo isn’t the only program that can produce reusable libraries, though. If the Glance team is going to manage this code anyway, it makes sense to leave it in the Glance program. Agreed. Honestly it's better to keep the review teams close to the expertise for the function at hand. It needs to be ok that teams besides oslo create reusable components for other parts of OpenStack. Oslo should be used for things where there isn't a strong incumbent owner. I think we have a strong incumbent owner here so living in Artifacts program makes sense to me. Sure, fair points from all. If it can be imported/packaged without including all the legacy Glance code, then I'd be more behind keeping it in Glance... FWIW, it's already like that. I'm working on the Glance port now[0], which passes locally but not in the gate due to glance.store not being released yet. [0] https://review.openstack.org/#/c/100636/ Cheers, Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Store Future
cc'ing ML since it's an important discussion, IMO...
On 07/31/2014 11:54 AM, Arnaud Legendre wrote:
Hi Jay,
I would be interested if you could share your point of view on this
item: we want to make the glance stores a standalone library
(glance.stores) which would be consumed directly by Nova and Cinder.
Yes, I have been enthusiastic about this effort for a long time now :)
In fact, I have been pushing a series of patches (most merged at this
point) in Nova to clean up the (very) messy nova.image.glance module and
standardize the image API in Nova.
The messiest part of the current image API in Nova, by far, is the
nova.image.glance.GlanceImageService.download() method, which you
highlight below. The reason it is so messy is that the method does
different things (and returns different things!) depending on how you
call it and what arguments you provide. :(
I think it would be nice to get your pov since you worked a lot on
the Nova image interface recently. To give you an example:
Here
https://github.com/openstack/nova/blob/master/nova/image/glance.py#L333,
we would do:
1. location = get_image_location(image_id),
2. get(location) from the
glance.stores library like for example rbd
(https://github.com/openstack/glance/blob/master/glance/store/rbd.py#L206)
Yup. Though I'd love for this code to live in olso, not glance...
Plus, I'd almost prefer to see an interface that hides the location URIs
entirely and makes the discovery of those location URIs entirely
encapsulated within glance.store. So, for instance, instead of getting
the image location using a call to glanceclient.show(), parsing the
locations collection from the v2 API response, and passing that URI to
the glance.store.get() function, I'd prefer to see an interface more
like this:
```python
# This code would go in a new nova.image.API.copy() method:
import io
from oslo.image import move
from oslo.image.move import exception as mexc
from nova import exception as exc
...
def copy(image_id_or_uri, stream_writer):
try:
config = {
# Some Nova CONF options...
}
mover = move.Mover(image_id_or_uri, config)
success, bytes_written = mover.copy(stream_writer)
if success:
if bytes_written == 0:
LOG.info(Copied image %s using zero-copy
transfer., image_id_or_uri)
else:
LOG.info(Copied image %s using standard
filesystem copy. Copied %d bytes.,
image_id_or_uri, bytes_written)
return success
except mexc.ImageNotFound:
raise exc.NotFound(...)
except mexc.ImageInvalidApi:
# Fall back to pull image from Glance
# API server via HTTP and write to disk
# via the stream_writer argument's write()
# interface... and return True or False
# depending on whether write()s succeeded
```
And then, the caller of such an nova.image.API.copy() function would be
in the existing various virt utils and imagebackends, and would call the
API function like so:
```python
# This code would go in something like nova.virt.libvirt.utils:
from nova import image
IMAGE_API = image.API()
write_file = io.FileIO(dst_path, mode='wb')
writer = io.BufferedWriter(write_file)
image_id_or_uri = https://images.example.com/images/123;
result = IMAGE_API.copy(image_id_or_uri, writer)
# Test result if needed...
```
Notice that the caller never needs to know about the locations
collection of the image -- and thus we correct the leaked implementation
details that currently ooze out of the download() method in
nova.image.glance.GlanceImageService.download.
Also note that we no longer pass a variety of file descriptors, file
writers, file destination paths to the download method. Instead, we
always just pass the image ID or URI and a writeable bytestream
iterator. And we always return either True or False, instead of None or
a file iterator depending on the supplied arguments to download().
The same kind of logic could be added in Cinder.
Sure.
We see that as a benefit for Nova, which would be able to directly
consume the stores instead of going through the glance api.
Exactly.
We had a vote today to figure out if we continue the effort on the
glance.stores library. We had a majority of +1 but there was a couple
of -1 due to the fact that we don’t have enough concrete examples of
this will be useful or not.
It will definitely be useful in the following:
1) Making the copy/zero-copy/transfer/download methods consistent
between all the various places in the Nova virt drivers that do similar
things.
2) Allowing a single place to innovate for the transfer of image bits
between sources and destinations
Hopefully, the above sample code and interfaces will spark some renewed
interest in this. I'd love
