Re: [Openstack] libvirt vs. Xen driver handling of local storage
Vish, We've talked about this idea in the past and I agree this works for *nix hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB. If we went with a 10gb base disk solution this obviously won't work. Even if we went with a 20gb partition it could become a problem as users install programs to C: and then try to do system updates that expect to have some reasonable disk available on C:. Providing a clean install with 10gb usable doesn't feel like a good customer experience. We could go with a 30gb or 40gb fixed disk but that doesn't sound very flexible for all users. I wanted to include some context to why we do it this way and how I envisioned this working. We have some users that wish to format their disk with other filesystems for performance reasons or encrypt them for security reasons. Both of these are completely valid. However, this poses a problem if we were to try to resize these partitions for them. Easy solution is don't touch the partitions and let them do it themselves. I think this type of solution works well for power users and developers. This does pose a problem for less technical users who would resize a disk and then wonder why they don't see the extra space as expected. This would create extra support costs that not all providers are willing to shoulder. To address this, we designed what we felt was a compromise and let the users decide what they feel is the best solution. It would be an extension that would let users define what kind of disk management they wish to use, 'manual' or 'auto'. Manual would be the hands off approach that would tell the system to expand the disk, but not touch the partition. Auto would expand the disk along with the partition. The caveat with the auto expand would be the filesystem would have to be in a format that the host understood. If it is a FS that the compute node isn't prepared to deal with, it errors.If this instance is set to auto and the customer requests a resize, the compute node would mount the FS, check for the right partition boundaries and type and expand the disk. If the partition boundaries aren't what the system expects, it errors. This scheme would allow users that wish to scale vertically with their instance inflate their instance then deflate it. It would entail copying the data to a smaller disk, but the customers that use this feature see this as unique and useful. The proposal as I understand it would help in all manual situations but not with customers that wish to use obtuse filesystem options. If anyone can think of other ways to handle this, I would love to discuss. pvo On Wed, Aug 31, 2011 at 4:24 PM, Chris Behrens chris.behr...@rackspace.comwrote: Vish, I think Rackspace ozone/titan has some upcoming work to do for the resizing for xenserver that might close some of the gap. I think we need some options (flags) if we are to synchronize libvirt/xen. At some point, Rackspace also needs an API extension to support a couple different ways of handling resizes. Until we get there, we at least need an option to keep the xenserver code working as-is for now. I assume others need the current libvirt implementation to stay as well. That said, I think it's probably not too difficult to do the 'libvirt way' for Xen, but I don't know about it making diablo. Adding support into libvirt to do the 'xen way' should be easier, I'd think. But I'm the opposite of you, Vish. I don't know the libvirt layer as well. :) If we can FLAG the way it works... and make these options work in both libvirt/xen, I think we can all remain happy. - Chris On Aug 31, 2011, at 11:45 AM, Vishvananda Ishaya wrote: Hey guys, We have a very annoying discrepancy between how local space is used in the xen driver vs the libvirt driver. I think it is vital that this is rectified before the Diablo release. We already have a few functional gaps between the drivers, but the fact that disks are partitioned completely differently between the two is very confusing to users. Bug is here: https://bugs.launchpad.net/nova/+bug/834189 The libvirt driver: * downloads the image from glance * resizes the image to 10G if it is 10G (in the case of a separate kernel and ramdisk image it extends the filesystem as well. In the case of a whole-disk image it just resizes the file because it doesn't know enough to change the filesystem) * attaches a second disk the size of local_gb to the image (when using block device mapping through the ec2 api, more swap/ephemeral disks can be attached as volumes as well) The XenServer driver (I'm less familiar with this code so please correct me if i am wrong here): * downloads the image from glance * creates a vdi from the base image * resizes the vdi to the size of local_gb The first method of resize to 10G and having separate local_gb is essentially the strategy taken by aws. Drawbacks of the first method: 1) The actual space used by
Re: [Openstack] A possible alternative to Gerrit ...
Understood and thanks for the clarification Thierry ... just a developer scratching an itch. Although it could be argued that it was a bit of a bait-n-switch on our ultimate github usage and the suitability of Gerrit. But as you say, let's wait for the guys to respond. Thanks -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Thierry Carrez [thie...@openstack.org] Sent: Friday, September 02, 2011 4:09 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] A possible alternative to Gerrit ... Sandy Walsh wrote: Last night I did some hacking on HubCap. HubCap is a simple script that monitors Pull Requests in GitHub. It spits out a static HTML page of the requests workflow status. [...] I won't speak on behalf of Monty Taylor, Jim Blair (or Jay) who are unfortunately all in limited availability while this anti-Gerrit revolt is being sent on the ML. Please wait for their reply, which should come soon. Not judging on the merits of that particular option, as a PPB member, I just would like to stress that we voted on having a single set of tools for core projects, so each project is not really free to choose its code review tool. The codehosting/codereview set of tools that was recently chosen is git/github/Gerrit... Glance and Keystone are already migrated, and Swift, Nova and Dashboard are scheduled for migration. So your alternative appears to be a bit late. Though we haven't formally voted on that, I think it's also general PPB feeling that we shouldn't change systems every 6 months (or every 2 months) just because something cooler exists. Switching systems might not be costly for you, but it's definitely costly for others (the openstack-ci team obviously, but also release management) -- and we should all have better use of our limited time. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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
Re: [Openstack] libvirt vs. Xen driver handling of local storage
2011/9/2 Paul Voccio openst...@substation9.com: Vish, We've talked about this idea in the past and I agree this works for *nix hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB. Yikes. If we went with a 10gb base disk solution this obviously won't work. Even if we went with a 20gb partition it could become a problem as users install programs to C: and then try to do system updates that expect to have some reasonable disk available on C:. Providing a clean install with 10gb usable doesn't feel like a good customer experience. What we do now is grow the image if it's smaller than size X. If it's already of size X or larger, we leave it alone. I guess we should add a check to verify that the image isn't larger than the disk size granted to the requested flavour so that people can't abuse this. We have some users that wish to format their disk with other filesystems for performance reasons or encrypt them for security reasons. Both of these are completely valid. However, this poses a problem if we were to try to resize these partitions for them. Easy solution is don't touch the partitions and let them do it themselves. I think this type of solution works well for power users and developers. This does pose a problem for less technical users who would resize a disk and then wonder why they don't see the extra space as expected. This would create extra support costs that not all providers are willing to shoulder. I think this is the difference between a cloud and a VPS with an API making its appearance. I'm all for building something on top of which someone can provide a VPS, but that's not the core of what Nova is. It's meant to be a cloud. It's a piece of infrastructure on top of which amazing, scalable technology can be built. If we document this is how this thing behaves. Deal with it that should be fine. I'd be really sad if we weren't able to make the best choice because the best choice might surprise less technical users using it as a VPS and who haven't read the documentation. If a deployer of OpenStack thinks this demographic is particularly appealing, they can extend the images they offer to notify users about these things or perhaps even take action on their part. E.g.: * E-mail the user telling them this is what they need to do * Show a pop-up on login telling them there's unpartitioned space. Click here to extend C: to use this space or Click here to fire up 'Microsoft Genuine Partitioning Tool 2008 XP'. * We've detected you've grown your Cloud Server. C: has been extended to use this new space. Have a nice day. I don't believe this should be a core concern for Nova. Do you think we can get that separation of concern to work out for everyone? To address this, we designed what we felt was a compromise and let the users decide what they feel is the best solution. It would be an extension that would let users define what kind of disk management they wish to use, 'manual' or 'auto'. Manual would be the hands off approach that would tell the system to expand the disk, but not touch the partition. Auto would expand the disk along with the partition. The caveat with the auto expand would be the filesystem would have to be in a format that the host understood. The potential for filesystem bugs that could bring the host down gives me the heebie jeebies. I really, really don't want to mount people's filesystems. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] Dashboard Diablo update
Hi Devin, thanks for this update. Below you mentioned support for managing Nova volumes, floating IPs. Can you tell us a bit more about this? I cannot see a volume section in the dashboard UI, are there specific extensions to pull into the code? Thanks, Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Devin Carlen Sent: 01 September 2011 22:18 To: openstack@lists.launchpad.net Subject: [Openstack] Dashboard Diablo update Hey everyone, I wanted to update everyone on where we've made it so far in the Diablo release. First off, along with the Keystone project, the Dashboard project has been promoted to OpenStack core, meaning it is now an officially recognized part of the OpenStack ecosystem. There are a few outstanding things we need to do to fully integrate with existing processes, though we are pretty far along: * Move code reviews from Github to Gerrit * Synch up on packaging efforts * Redouble efforts on documentation * Pick an official codename for the project I'll be sending out a list of codename candidates soon for us to decide on as a community. :) We put a lot of work into Dashboard in the Diablo timeframe. Some of the highlights: * uses OpenStack API instead of EC2 API for underlying calls * full support for Keystone for authentication * support for managing Swift containers and objects * support for managing Quantum networks and ports * support for managing Nova volumes, floating IPs, etc (mostly got feature parity with EC2 API) * a new look and feel * new features for sysadmins * ... and more! There are three phases to a project's life: 1) make it work (austin/bexar) 2) more is better (cactus/diablo) 3) better is more I feel that as a project we've fulfilled our more is better phase, as in having more features is more important than perfecting each piece. During the Essex release, we're going into our better is more phase. We'll be focusing on user experience and interaction design and making this project a world class web application. We'll be talking quite a bit about this at the design summit as well, so we'll look for you all there! Devin ___ 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] libvirt vs. Xen driver handling of local storage
On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen so...@linux2go.dk wrote: 2011/9/2 Paul Voccio openst...@substation9.com: Vish, We've talked about this idea in the past and I agree this works for *nix hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB. Yikes. Tell me about it. If we went with a 10gb base disk solution this obviously won't work. Even if we went with a 20gb partition it could become a problem as users install programs to C: and then try to do system updates that expect to have some reasonable disk available on C:. Providing a clean install with 10gb usable doesn't feel like a good customer experience. What we do now is grow the image if it's smaller than size X. If it's already of size X or larger, we leave it alone. I guess we should add a check to verify that the image isn't larger than the disk size granted to the requested flavour so that people can't abuse this. We have some users that wish to format their disk with other filesystems for performance reasons or encrypt them for security reasons. Both of these are completely valid. However, this poses a problem if we were to try to resize these partitions for them. Easy solution is don't touch the partitions and let them do it themselves. I think this type of solution works well for power users and developers. This does pose a problem for less technical users who would resize a disk and then wonder why they don't see the extra space as expected. This would create extra support costs that not all providers are willing to shoulder. I think this is the difference between a cloud and a VPS with an API making its appearance. Soren, I agree with you that this is a subtle difference. The big think that I'm not sure we always consider is the support costs of using Nova. If the customers were responsible for expanding the disk there will always be some that are unable (or unwilling) to do this. If the software was able to do this you could reduce the staff needed to handle support. IMHO, this is what we're tasked to do, is automate those support features. I'm all for building something on top of which someone can provide a VPS, but that's not the core of what Nova is. It's meant to be a cloud. It's a piece of infrastructure on top of which amazing, scalable technology can be built. If we document this is how this thing behaves. Deal with it that should be fine. I'd be really sad if we weren't able to make the best choice because the best choice might surprise less technical users using it as a VPS and who haven't read the documentation. This is why I think we can give users the choice in how they want to manage this. You can currently use Nova to do both. You can use it entirely as a cloud as is and treat everything ephemeral (even if it isn't). I agree with you on this point and this is how I build my apps on virtualized infrastructure. However, this is not what everyone actually does. Some people just a want a few developer machines to test with. If I'm working on a feature and I'm running out of memory on a test, I think you would agree it would be an interesting feature to increase the VM to a different size, run the test and confirm that it was a memory problem, then resize do a smaller instance once I was finished. I shouldn't have to copy all the data around to do this. You could accomplish this by taking a snapshot and launching a larger instance but I don't know if that will always be the case (I'm thinking of single use licensed softwares). If a deployer of OpenStack thinks this demographic is particularly appealing, they can extend the images they offer to notify users about these things or perhaps even take action on their part. E.g.: * E-mail the user telling them this is what they need to do * Show a pop-up on login telling them there's unpartitioned space. Click here to extend C: to use this space or Click here to fire up 'Microsoft Genuine Partitioning Tool 2008 XP'. * We've detected you've grown your Cloud Server. C: has been extended to use this new space. Have a nice day. Option #3 above is exactly what I'm describing. I don't believe this should be a core concern for Nova. Do you think we can get that separation of concern to work out for everyone? To address this, we designed what we felt was a compromise and let the users decide what they feel is the best solution. It would be an extension that would let users define what kind of disk management they wish to use, 'manual' or 'auto'. Manual would be the hands off approach that would tell the system to expand the disk, but not touch the partition. Auto would expand the disk along with the partition. The caveat with the auto expand would be the filesystem would have to be in a format that the host understood. The potential for filesystem bugs that could bring the host down gives me the heebie jeebies. I really, really don't want to
Re: [Openstack] Dashboard Diablo update
Hi Armando, Actually I misspoke and the volumes branch hasn't landed yet. But it will soon! Sorry for the confusion, Devin On Sep 2, 2011, at 8:02 AM, Armando Migliaccio wrote: Hi Devin, thanks for this update. Below you mentioned support for managing Nova volumes, floating IPs. Can you tell us a bit more about this? I cannot see a volume section in the dashboard UI, are there specific extensions to pull into the code? Thanks, Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Devin Carlen Sent: 01 September 2011 22:18 To: openstack@lists.launchpad.net Subject: [Openstack] Dashboard Diablo update Hey everyone, I wanted to update everyone on where we've made it so far in the Diablo release. First off, along with the Keystone project, the Dashboard project has been promoted to OpenStack core, meaning it is now an officially recognized part of the OpenStack ecosystem. There are a few outstanding things we need to do to fully integrate with existing processes, though we are pretty far along: * Move code reviews from Github to Gerrit * Synch up on packaging efforts * Redouble efforts on documentation * Pick an official codename for the project I'll be sending out a list of codename candidates soon for us to decide on as a community. :) We put a lot of work into Dashboard in the Diablo timeframe. Some of the highlights: * uses OpenStack API instead of EC2 API for underlying calls * full support for Keystone for authentication * support for managing Swift containers and objects * support for managing Quantum networks and ports * support for managing Nova volumes, floating IPs, etc (mostly got feature parity with EC2 API) * a new look and feel * new features for sysadmins * ... and more! There are three phases to a project's life: 1) make it work (austin/bexar) 2) more is better (cactus/diablo) 3) better is more I feel that as a project we've fulfilled our more is better phase, as in having more features is more important than perfecting each piece. During the Essex release, we're going into our better is more phase. We'll be focusing on user experience and interaction design and making this project a world class web application. We'll be talking quite a bit about this at the design summit as well, so we'll look for you all there! Devin ___ 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] libvirt vs. Xen driver handling of local storage
On Sep 2, 2011, at 8:07 AM, Paul Voccio wrote: On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen so...@linux2go.dk wrote: [...] The potential for filesystem bugs that could bring the host down gives me the heebie jeebies. I really, really don't want to mount people's filesystems. Can you explain a bit more here? I would like to understand your concerns. I would advocate mounting in a utility VM if you mean to protect from mounting instance with malicious data. We may have to do this to expand partitions or resize down for Windows. Mounting someone's filesystem should not be necessary if we have certain restrictions on the management. I.e., we could say we will only resize the last filesystem in the partition table. That would avoid needing to know the filesystem layout in the image (looking at /etc/fstab or updating it). Not sure that's a desired restriction, however. That said, we'd still need to attach the VM disk somewhere and run fs resize utils... and it might still be best to do this in a utility VM. - Chris 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] EC2 compatibility?
Is there any doc on how complete the openstack EC2 api is with a fixed version of amazon's actual release API. Maybe some table that says which functions are implemented and which ones aren't for a given version of the EC2 api and a given version of openstack? -Josh ___ 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] libvirt vs. Xen driver handling of local storage
My first thought was to do a singled fixed disk and never resize that disk at all. If you need space, you have to use a volume service. Ultimately, I don't think this the right approach either, but it solves the initial use case of needing more storage space. On Fri, Sep 2, 2011 at 11:34 AM, Chris Behrens chris.behr...@rackspace.comwrote: On Sep 2, 2011, at 8:07 AM, Paul Voccio wrote: On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen so...@linux2go.dk wrote: [...] The potential for filesystem bugs that could bring the host down gives me the heebie jeebies. I really, really don't want to mount people's filesystems. Can you explain a bit more here? I would like to understand your concerns. I would advocate mounting in a utility VM if you mean to protect from mounting instance with malicious data. We may have to do this to expand partitions or resize down for Windows. Mounting someone's filesystem should not be necessary if we have certain restrictions on the management. I.e., we could say we will only resize the last filesystem in the partition table. That would avoid needing to know the filesystem layout in the image (looking at /etc/fstab or updating it). Not sure that's a desired restriction, however. That said, we'd still need to attach the VM disk somewhere and run fs resize utils... and it might still be best to do this in a utility VM. - Chris 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] libvirt vs. Xen driver handling of local storage
Yeah, I think that can be rather fair for Unix. It's just that as you pointed out... Windows is a huge pain. Need to make sure there's enough space on C: and I think there are still a lot of things that stupidly rely on being installed on C: On Sep 2, 2011, at 10:32 AM, Paul Voccio wrote: My first thought was to do a singled fixed disk and never resize that disk at all. If you need space, you have to use a volume service. Ultimately, I don't think this the right approach either, but it solves the initial use case of needing more storage space. On Fri, Sep 2, 2011 at 11:34 AM, Chris Behrens chris.behr...@rackspace.com wrote: On Sep 2, 2011, at 8:07 AM, Paul Voccio wrote: On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen so...@linux2go.dk wrote: [...] The potential for filesystem bugs that could bring the host down gives me the heebie jeebies. I really, really don't want to mount people's filesystems. Can you explain a bit more here? I would like to understand your concerns. I would advocate mounting in a utility VM if you mean to protect from mounting instance with malicious data. We may have to do this to expand partitions or resize down for Windows. Mounting someone's filesystem should not be necessary if we have certain restrictions on the management. I.e., we could say we will only resize the last filesystem in the partition table. That would avoid needing to know the filesystem layout in the image (looking at /etc/fstab or updating it). Not sure that's a desired restriction, however. That said, we'd still need to attach the VM disk somewhere and run fs resize utils... and it might still be best to do this in a utility VM. - Chris 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 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] S3 Compatability (Was RE: EC2 compatibility?)
Joshua Harlow asked: Is there any doc on how complete the openstack EC2 api is with a fixed version of amazon's actual release API. Maybe some table that says which functions are implemented and which ones aren't for a given version of the EC2 api and a given version of openstack? The same thing is also needed for Swift compatibility with the Amazon S3 protocol. Reading the code suggest that there are whole features not supported, but having a list of which ones were deliberately deferred would be useful. Aside from helping users who might need a given feature, it will also let them know whether to request a new feature or to file a bug report. ___ 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] S3 Compatability (Was RE: EC2 compatibility?)
Hi Caitlin, Right now the best source of what S3 features are available through the S3 compatibility layer are here: http://swift.openstack.org/misc.html#module-swift.common.middleware.swift3 -- Chuck On Fri, Sep 2, 2011 at 2:59 PM, Caitlin Bestler caitlin.best...@nexenta.com wrote: Joshua Harlow asked: Is there any doc on how complete the openstack EC2 api is with a fixed version of amazon's actual release API. Maybe some table that says which functions are implemented and which ones aren't for a given version of the EC2 api and a given version of openstack? The same thing is also needed for Swift compatibility with the Amazon S3 protocol. Reading the code suggest that there are whole features not supported, but having a list of which ones were deliberately deferred would be useful. Aside from helping users who might need a given feature, it will also let them know whether to request a new feature or to file a bug report. ___ 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] S3 Compatability (Was RE: EC2 compatibility?)
Seems useful to have some versioned documents that compare a specific openstack release (swift or nova) against a specific ec2/s3 release (whichever one is aimed for for a given openstack release). This way bug reporting and feature requests become easier to create (and determine if they need to be created). From looking at the http://wiki.openstack.org/Nova/EucalyptusFeatureComparison its hard to tell which version of openstack to compare this to since it looks from the diablo-3 release certain apis are there that are not shown in this document as being active (ie StartInstances). Maybe the same kind of wiki is needed for both swift and nova. On 9/2/11 1:30 PM, Chuck Thier cth...@gmail.com wrote: Hi Caitlin, Right now the best source of what S3 features are available through the S3 compatibility layer are here: http://swift.openstack.org/misc.html#module-swift.common.middleware.swift3 -- Chuck On Fri, Sep 2, 2011 at 2:59 PM, Caitlin Bestler caitlin.best...@nexenta.com wrote: Joshua Harlow asked: Is there any doc on how complete the openstack EC2 api is with a fixed version of amazon's actual release API. Maybe some table that says which functions are implemented and which ones aren't for a given version of the EC2 api and a given version of openstack? The same thing is also needed for Swift compatibility with the Amazon S3 protocol. Reading the code suggest that there are whole features not supported, but having a list of which ones were deliberately deferred would be useful. Aside from helping users who might need a given feature, it will also let them know whether to request a new feature or to file a bug report. ___ 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
