[Openstack-poc] [Bug 967400] [NEW] iniparser needs absolute import
Public bug reported: The use of a relative import for 'iniparser' is causing: http://paste.openstack.org/show/12224/ Changing this to: from openstack.common import iniparser fixes it. ** Affects: openstack-common Importance: Undecided Assignee: Rick Harris (rconradharris) Status: In Progress ** Changed in: openstack-common Assignee: (unassigned) = Rick Harris (rconradharris) ** Changed in: openstack-common Status: New = In Progress -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/967400 Title: iniparser needs absolute import Status in openstack-common: In Progress Bug description: The use of a relative import for 'iniparser' is causing: http://paste.openstack.org/show/12224/ Changing this to: from openstack.common import iniparser fixes it. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-common/+bug/967400/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack] using objects returned from DB layer
++ on moving to a consistent dict-style syntax.
We could attempt to rip the Band-Aid off here by:
1. Rejecting any new patches which use the dot-notation
2. Trying to switch out to using dot-notation access all at once in one big
'fix-it-up' patch.
I'm not convinced 2) is possible. Separating model objects from other kinds of
objects will be time-consuming and error prone. Given the scope of this issue,
I'm not sure this could be done without a real risk of prolonged, recurring
breakage.
Instead, I'd advocate a step-wise approach:
1. Reject any new patches which use the dot-notation
2. Add code which helps us identify and fix dot-notation usage throughout the
codebase.
The basic idea here is that we'd add a flag to fail loudly when a object is
accessed using non-dict methods.
This could be done by adding a decorator to the sqlalchemy/db/api functions
such that instead of returning SQLAlchemy objects directly they instead return
objects of type AttrAccessibleDict.
An AttrAccessibleDict would be defined something like:
class AttrAccessibleDict(dict)
def __getattr__(self, attr):
if FLAGS.enforce_model_dict_access:
raise ModelObjectAccessError('must use dict-style access on model
objects')
else:
return self[attr]
def dictify_model(f):
def wrapper(*args, **kwargs):
rv = f(*args, **kwargs)
attr_dict = convert_to_attr_accessible_dict(rv)
return attr_dict
return wrapper
@dictify_model
def instance_get(…..):
pass
3. Make a concerted effort to fix the code over a period of a few weeks.
Developers could set --enforce_model_dict_access to True and fix up as many
cases as they can find. When they're tired of fixing cases or when more
pressing things come along for the moment, they can temporarily set
--enforce_model_dict_access back to False to that everything goes back to
humming along smoothly.
4. Once the dot-notation has been excised, we can switch over to actually
returning real Python dictionaries instead of AttrAccessibleDict objects.
5. Final step would be removing the cleanup code.
Once everything is returning dictionaries, we would remove the decorator
entirely and any other cleanup code we added along the way.
Feels like this approach would be a bit roundabout, but each step feels safe,
and it seem like it would get us to where we want to be in the course of a few
weeks (perhaps a couple of months, worst case).
Thoughts?
-Rick
On Dec 15, 2011, at 1:10 AM, Chris Behrens wrote:
I've seen a number of patches lately that have code like this:
instance = db.instance_get(...)
instance_uuid = instance.uuid
instead of:
instance_uuid = instance['uuid']
There's a mix of usage throughout the code, and I know some people are just
matching the surrounding code. But, in a number of cases, I've asked for
these to be corrected to the latter, on assumption that the DB layer will be
returning dictionaries at some point vs the models. It also pushes the code
towards consistent usage. But I might be the only Nova Core member looking
at this and/or maybe my assumption is wrong.
So, I ask here: Should Nova Core make an effort to reject patches with the
former format? Or did I miss any DB layer plans where the former format is
now preferred?
- Chris
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] using objects returned from DB layer
I was bringing this up initially as I want to enforce *something* when
reviewing,
Yeah, I was just thinking that it could be a point of confusion if, for an
extended period, we're in a state where new code has to use dict-style instance
access, while nearby, older code still uses attr-accessing.
We may be able to get to a place where we feel we've got everything... then
dictify it all at that time and see what raises in tests
One issue with that is that many of our fakes will already be returning dicts,
so the unit-tests may pass, while the actual code may still trigger an
exception.
The functional tests will help here, but, I don't think there's a substitute
for having --enforce_model=True and having everybody hammering at it for a few
weeks.
If it can survive that with no problems, then I'll be somewhat confident….
On Dec 15, 2011, at 2:49 AM, Chris Behrens wrote:
Agree with both #1s as a start. And I wouldn't try to 'rip off the band-aid'
either.
I was bringing this up initially as I want to enforce *something* when
reviewing, but if we want to start 'fixing' things, we can start hitting
small sections of code to limit conflicts. The 'enforce_model' thing might
be a bit extreme right now. We may be able to get to a place where we feel
we've got everything... then dictify it all at that time and see what raises
in tests., fixing those last things. Hm... although, I guess I really do
like the ability to turn something off if it's broken. :)
- Chris
On Dec 15, 2011, at 12:29 AM, Rick Harris wrote:
++ on moving to a consistent dict-style syntax.
We could attempt to rip the Band-Aid off here by:
1. Rejecting any new patches which use the dot-notation
2. Trying to switch out to using dot-notation access all at once in one big
'fix-it-up' patch.
I'm not convinced 2) is possible. Separating model objects from other kinds
of objects will be time-consuming and error prone. Given the scope of this
issue, I'm not sure this could be done without a real risk of prolonged,
recurring breakage.
Instead, I'd advocate a step-wise approach:
1. Reject any new patches which use the dot-notation
2. Add code which helps us identify and fix dot-notation usage throughout
the codebase.
The basic idea here is that we'd add a flag to fail loudly when a object is
accessed using non-dict methods.
This could be done by adding a decorator to the sqlalchemy/db/api functions
such that instead of returning SQLAlchemy objects directly they instead
return objects of type AttrAccessibleDict.
An AttrAccessibleDict would be defined something like:
class AttrAccessibleDict(dict)
def __getattr__(self, attr):
if FLAGS.enforce_model_dict_access:
raise ModelObjectAccessError('must use dict-style access on model
objects')
else:
return self[attr]
def dictify_model(f):
def wrapper(*args, **kwargs):
rv = f(*args, **kwargs)
attr_dict = convert_to_attr_accessible_dict(rv)
return attr_dict
return wrapper
@dictify_model
def instance_get(…..):
pass
3. Make a concerted effort to fix the code over a period of a few weeks.
Developers could set --enforce_model_dict_access to True and fix up as many
cases as they can find. When they're tired of fixing cases or when more
pressing things come along for the moment, they can temporarily set
--enforce_model_dict_access back to False to that everything goes back to
humming along smoothly.
4. Once the dot-notation has been excised, we can switch over to actually
returning real Python dictionaries instead of AttrAccessibleDict objects.
5. Final step would be removing the cleanup code.
Once everything is returning dictionaries, we would remove the decorator
entirely and any other cleanup code we added along the way.
Feels like this approach would be a bit roundabout, but each step feels
safe, and it seem like it would get us to where we want to be in the course
of a few weeks (perhaps a couple of months, worst case).
Thoughts?
-Rick
On Dec 15, 2011, at 1:10 AM, Chris Behrens wrote:
I've seen a number of patches lately that have code like this:
instance = db.instance_get(...)
instance_uuid = instance.uuid
instead of:
instance_uuid = instance['uuid']
There's a mix of usage throughout the code, and I know some people are just
matching the surrounding code. But, in a number of cases, I've asked for
these to be corrected to the latter, on assumption that the DB layer will
be returning dictionaries at some point vs the models. It also pushes the
code towards consistent usage. But I might be the only Nova Core member
looking at this and/or maybe my assumption is wrong.
So, I ask here: Should Nova Core make an effort to reject patches with the
former format? Or did I miss any DB layer plans where the former format
is now preferred?
- Chris
Re: [Openstack] using objects returned from DB layer
For me, it's not one particular notation versus the other, I'd be happy with either--it's having both. It just needlessly complicates things. Now we're complaining that the ORM we likely aren't using correctly isn't working for us I don't think anyone is complaining that the *ORM* is at fault here. We're just complaining that our abstraction is leaky, and since we went through all of the trouble to have this DB API indirection, we may as well seal it up so we can eventually support other data stores. As it stands now, we have all of the complexity of abstraction without any of the benefits. On Dec 15, 2011, at 12:35 PM, Matt Dietz wrote: I have to confess to being confused here. We deliberately chose sqlalchemy. Then we mapped everything away so it didn't look like the ORM in question when in reality, we partially took some of said ORM's job away from it. Now we're complaining that the ORM we likely aren't using correctly isn't working for us. In short, we chose to use an ORM, and now we're complaining about the O I'm not seeing what taking everything to a dictionary-centric model buys us, and I also don't see anyone actually justifying it. Can we get some actual examples of why one approach is better than the other? On 12/15/11 10:54 AM, Johannes Erdfelt johan...@erdfelt.com wrote: On Thu, Dec 15, 2011, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: 2. However, I violently disagree with the idea that the DB layer must return dicts. It does not, even if you start talking about allowing use of other kinds of databases. We can, and should, wrap these things in objects, upon which we can call methods that do things‹i.e., we should, you know, actually use object-oriented programming. What kinds of things? I'm not against returning back a standardized object that provides __getattr__ so we don't have to use dict notation. Any database backend can do something similar easily. I'm just trying to better understand what is object-oriented about the data returned from a database? What methods would we want to use? JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Johannes Erdfelt to nova-core
Definite +1 On Nov 9, 2011, at 11:05 AM, Trey Morris wrote: +1 On Wed, Nov 9, 2011 at 9:35 AM, Sandy Walsh sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com wrote: 9 * 3 - 26 From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net] on behalf of Brian Waldon [brian.wal...@rackspace.commailto:brian.wal...@rackspace.com] Sent: Wednesday, November 09, 2011 10:02 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) Subject: [Openstack] Proposal to add Johannes Erdfelt to nova-core I'd like to nominate Johannes for nova-core, as he has definitely been doing a good number of reviews lately. ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Kevin Mitchell to nova-core
+1 as well. On Nov 9, 2011, at 11:24 AM, Chris Behrens wrote: Yep... +1 On Nov 9, 2011, at 5:59 AM, Brian Waldon wrote: Vek has absolutely stepped up and started doing quite few reviews, so I'd like to nominate him to be added to nova-core. Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Chris Behrens to nova-core
Definite +1 On Sep 15, 2011, at 4:13 PM, Brian Waldon wrote: Chris (comstud) has been a great help with reviews lately and has quite a bit of knowledge of the system overall. I think he would add a great amount to the team, so I'm proposing we add him to nova-core. Brian Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [NEW DEPENDENCY] Nova will depend on Tempo
Just a quick announcement so no one is caught by surprise: Once https://code.launchpad.net/~rconradharris/nova/backup_schedule_extension/+merge/74665 merges, Nova will have a new dependency on the Tempo project (https://github.com/rackspace/Tempo). Tempo is included in the pip-require and the Debian packages should be updated shortly, so, hopefully this won't cause any problems. Thanks, Rick P.S. Reviews on https://code.launchpad.net/~rconradharris/nova/backup_schedule_extension/+merge/74665 would be much appreciated! This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for Justin Santa Barbara to join Nova-Core
+1 From: openstack-bounces+rick.harris=rackspace@lists.launchpad.net [openstack-bounces+rick.harris=rackspace@lists.launchpad.net] on behalf of Vishvananda Ishaya [vishvana...@gmail.com] Sent: Thursday, April 07, 2011 2:19 PM To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Proposal for Justin Santa Barbara to join Nova-Core +1 On Apr 7, 2011, at 12:18 PM, Jay Pipes wrote: Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme
Ewan: I’d prefer that we allowed vm or vm_rec for a record (that would give us less to fix up, apart from anything else!) In terms of readability, I think we get more bang for the buck if we stick to a single standard, 'vm' or 'vm_rec'. This has the side-benefit of making the code more grep-able and easier to refactor down-the-road. A couple of extra 'cw' keystrokes in Vim won't kill me :) Ed: it should probably be 'instance'. As we're using 'vm' as an alias for instance Within the virt-layer code, 'instance' and 'vm' are two distinct concepts. Instance, what Nova manages, has attributes like 'display_name' and 'internal_id'. 'VM', what the Xen manages, has attributes like 'PV_args' and 'name_label'. From: Ed Leafe Sent: Monday, March 07, 2011 10:27 AM To: Ewan Mellor Cc: Chris Behrens; Rick Harris; openstack-xenapi@lists.launchpad.net Subject: Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme On Mar 6, 2011, at 8:29 AM, Ewan Mellor wrote: I do use _rec for a record, if I feel that it needs distinguishing explicitly. I’d prefer that we allowed vm or vm_rec for a record (that would give us less to fix up, apart from anything else!) In most of the code, the convention is to refer to a modeled object using the singular form of the table name; in this case, it should probably be 'instance'. As we're using 'vm' as an alias for instance, it would seem that either 'instance' or 'vm' would be consistent. I don't know of any other modeled object referred to with the '*_rec' name. But definitely +1 for distinguishing opaque refs and uuids. -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Glance, libvirt/kvm snapshots
Hey Ahmed, TL;DR Glance doesn't appear to be supported with libvirt driver yet. Judging by the stack trace, it looks like the code is taking an S3 code path even though you've selected the GlanceImageService. Looking through the code, it doesn't appear that the libvirt/Glance code is there yet (the patch from the 708673https://bugs.launchpad.net/nova/+bug/708673 doesn't appear to be enough). This should be logged as a bug. I don't *think* the fix will be that hard, we just need to modify images.fetch() to respect the image_service and to stream the data using the Glance client rather than curl. Until then, I think the objectstore or local-store will be your best bet. Hope that helps, Rick From: openstack-bounces+rick.harris=rackspace@lists.launchpad.net [openstack-bounces+rick.harris=rackspace@lists.launchpad.net] on behalf of Ahmed El Gamil [ah...@manhag.org] Sent: Thursday, February 17, 2011 1:48 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Glance, libvirt/kvm snapshots Hi Guys, So The guys over at IRC convinced me that posting that to the mailing list would be cooler to solve/discuss, so don't let me down :). Basically i'm working on launching an instance via the openstack API, using the Bexar release and the python-novatools (the novatools command), The hypervisor is KVM and Glance is used for Imaging(image_service=nova.image.glance.GlanceImageService). After using the boot subcommand in novatools, the instance is marked as build and i get the following errors in the logs: 2011-02-16 09:23:23,535 ERROR nova.compute.manager [F--YCJOZ14LY9LTFHYH1 c9er openstack] instance 7: Failed to spawn (nova.compute.manager): TRACE: Traceback (most recent call last): (nova.compute.manager): TRACE: File /usr/lib/pymodules/python2.6/nova/compute/manager.py, line 211, in run_instance (nova.compute.manager): TRACE: self.driver.spawn(instance_ref) (nova.compute.manager): TRACE: File /usr/lib/pymodules/python2.6/nova/exception.py, line 122, in _wrap (nova.compute.manager): TRACE: raise Error(str(e)) (nova.compute.manager): TRACE: Error: Unexpected error while running command. (nova.compute.manager): TRACE: Command: /usr/bin/curl --fail --silent http://ip address:/_images/2/image -H 'Date: Wed, 16 Feb 2011 14:23:23 GMT' -H 'Authorization: AWS ba97af70-24cf-4054-9185-ecf925d71385:openstack:sIAZBh7GJ7dE8urnZhvwla7upgY=' -o /var/lib/nova/instances/_base/2 (nova.compute.manager): TRACE: Exit code: 22 (nova.compute.manager): TRACE: Stdout: '' (nova.compute.manager): TRACE: Stderr: '' (nova.compute.manager): TRACE: libvir: QEMU error : Domain not found: no domain with matching name 'instance-0007' ttx on IRC told me that it shouldn't fetch a : URL, but that was fixed in a bug at https://bugs.launchpad.net/nova/+bug/708673 Any hints on what could cause that ? did anybody work with novatools against kvm/glance ? Thanks in advance. Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Deprecating nova-objectstore
What's the difference between an image and an object? They're all just blobs of bits as far as I thought. I think of an image as data+metadata. The data is stored as objects where the image can span multiple objects. The metadata maybe stored in the form of a manifest-file, or, as with Glance, is stored as an entry in the registry. As has been discussed on the ML, there is a need for a container format (OVF?), which can encapsulate both the data and metadata if we want to be able to shuffle around fully contained images. As it stands with Glance, the data and metadata are separate; so, in order to replicate an image, you need to pull the image's objects and, in a separate step, fetch its metadata. From: openstack-bounces+rick.harris=rackspace@lists.launchpad.net [openstack-bounces+rick.harris=rackspace@lists.launchpad.net] on behalf of Ewan Mellor [ewan.mel...@eu.citrix.com] Sent: Monday, January 17, 2011 12:12 PM To: 'Jay Pipes' Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Deprecating nova-objectstore -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 17 January 2011 18:08 To: Ewan Mellor Cc: Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] Deprecating nova-objectstore On Mon, Jan 17, 2011 at 12:38 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 17 January 2011 17:17 To: Ewan Mellor Cc: Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] Deprecating nova-objectstore On Mon, Jan 17, 2011 at 10:53 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: We could do it in two steps. You could set up nova-compute - Glance - nova-objectstore (testing purposes only). This would allow us to remove the S3 code from Nova, but people could still use nova- objectstore if they don't want to set up Swift. This is already done in Bexar, as Chris MacGown completed the S3 backend for Glance. What is NOT the same, though, is that people would not be speaking the s3 API as they do now... they would speak the Glance REST-like API instead... Yes, that's what I meant -- make Glance the only thing that speaks S3, and then we can remove the S3 code from Nova in favour of Glance. Plus, objects are a superset of images; Glance only stores images, not all objects... What does this mean? I didn't even know that anyone was distinguishing between an image and an object. All images are objects but not all objects are images. Swift/S3 can be used to store anything, not just images, that's what I meant. :) What's the difference between an image and an object? They're all just blobs of bits as far as I thought. Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
