Re: [Openstack] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
On Aug 10, 2012, at 2:52 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/09/2012 11:05 PM, George Reese wrote: On Aug 9, 2012, at 8:14 PM, Doug Davis d...@us.ibm.com mailto:d...@us.ibm.com wrote: Situations like this are always interesting to watch. :-) On the one hand its open-source, so if you care about something then put up the resources to make it happen. This attitude always bothers me. This isn't some Open Source labor of love. It's a commercial collaboration in which many of the contributors have a significant economic interest. To be more blunt: if I'm writing code, it's for enStratus. Patches always welcome, George. If you can't see that code you may write for enStratus might be globally useful, then you're missing the point of this open development community. And although there are many in this OpenStack community that work for a commercial entity and contribute code as such, there are many who don't -- and dismissing their contributions as some Open Source labor of love is degrading and shows the type of opinion you have towards anything that doesn't fit nicely in your everything-is-a-commercial-agenda worldview. If you care about something, then help to fix it. Either you aren't reading what I am writing or you can't read. I'm willing to bet I have written more lines of Open Source code over more years than you have. So don't start assigning some kind of evil capitalist motives on me. The fact that I don't have code going into enStratus that is not of use to OpenStack is not an indication that a) I have some kind of everything-is-a-commercial-agenda worldview or b) that I don't do Open Source or c) I don't think that some Open Source is a labor of love. OpenStack is a commercial agenda however. Pretending that it's a labor of love and people should feel lucky to get functionality is just daft. -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] Removing support for KVM Hypervisor ...
You're just trying to give me a heart attack :) Sent from my iPhone On Aug 10, 2012, at 15:32, Sandy Walsh sandy.wa...@rackspace.com wrote: Sorry George, couldn't resist. :) ___ 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] Setting Expectations
First, thanks to Andrew for starting this thread. I think it's an important discussion. Second, the problem with the analogies made so far is, IMHO, at the API level and what it does to the ecosystem. Let's take, for example, Apache HTTP Client stuff. 3.1 and 4.x are wildly different object models. But that's OK for the Apache model in a way that isn't for OpenStack. When I decided to move Dasein Cloud to the new stuff, it was on my time frame, not Apache's. With OpenStack, the deprecation of APIs is hugely problematic because the ecosystem is live dependent on the APIs. If I roll out a new version into a infrastructure with rich tool support and that version has API inconsistencies, I immediately and irrevocably break critical operational tools. With the Apache stuff, there's no external visibility into the HTTPclient APIs. It's just my code that I can compile and test pre-deployment. It's a problem for any tool with a public facing RESTful API. That's why I believe in never deprecating except in extreme circumstances. The most successful cloud API out there, the EC2 API, never breaks existing tools. NEVER. Seriously, never. -George On Aug 10, 2012, at 9:33 PM, Frans Thamura fr...@meruvian.org wrote: Openstack is like linux kernel for cloud Anyone welcome to.create distro on it like ubuntu tolinux... and yea ubunti cloud to openstack On Aug 11, 2012 8:46 AM, Eric Windisch e...@cloudscaling.com wrote: On Aug 10, 2012, at 20:49, Nathanael Burton nathanael.i.bur...@gmail.com wrote: I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a cloud kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system. An even better example might be Apache. They have their own foundation and have a number of services that get installed to machines, but they don't have a distribution or any clear deployment solutions. Some of their applications such as the httpd are just core pieces that get installed to a single system and multiple services on multiple machines don't communicate, but others are horizontally scaling solutions with inter-process communication, such as Hadoop. Whatever the case, they're still not building a distribution. OpenStack in some ways appears to be the kernel on which applications run, but its applications are just applications. If the question is where the foundation draws the line at acceptance of projects, it is an interesting one... as long as there is a foundation, you can't really use Linux as any sort of example. Instead, if you want to draw parallels to operating systems, you'll have to look more closely to the BSD systems. With BSD, they've coupled the kernels and the distributions. I do not think this is a model that OpenStack should follow, but I do see a tendency of some toward this. Instead, I believe the community and the foundation should move into the direction of Apache. If someone wants to create their own independent distribution, they should, but it shouldn't be part of the project or blessed by the foundation. Instead, they would follow the steps of Slackware, Debian, and Gentoo; not the steps taken by FreeBSD. The community already has a number of emerging proprietary and/or corporate-sponsored distributions, it would not do the community a favor for the foundation to create its own. Regards, Eric Windisch (sent from my iPad) ___ 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net
Re: [Openstack] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
On Aug 9, 2012, at 8:14 PM, Doug Davis d...@us.ibm.com wrote: Situations like this are always interesting to watch. :-) On the one hand its open-source, so if you care about something then put up the resources to make it happen. This attitude always bothers me. This isn't some Open Source labor of love. It's a commercial collaboration in which many of the contributors have a significant economic interest. To be more blunt: if I'm writing code, it's for enStratus. On the other hand, that doesn't mean that as a developer you get to ignore the bigger picture and only do 1/2 of the work because you don't care about the other 1/2. Overall, I tend to agree with the attitude that as long as XML is officially supported then all code changes need to make sure they run through both the JSON and XML codepaths. And if this means twice the testcases then so be it. People committing code shouldn't have a choice in this - its either you do the full job or your code is rejected. +10 Having said that, it is a valid question to ask whether we want to continue to support both JSON and XML going forward. But, until that decision is formally made letting 1/2 of the APIs atrophy makes the entire community look bad and therefore should not be allowed to happen. Actually, it's not a valid question. That ship has sailed. XML is part of the spec, and we're talking about Folsom not Bexar. The API is the heart of the ecosystem. You never, ever deprecate code unless there's some strong compelling reason like a significant security flaw that can be addressed only through incompatibility. My vote: from now on don't let any code change in unless if works for both. I suspect we'll either see the XML side come up to speed really quickly or it'll force an ugly vote. But either way, this needs to be resolved before the next release. thanks -Doug STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. George Reese george.re...@imaginary.com 08/09/2012 07:02 PM Please respond to OpenStack Development Mailing List openstack-...@lists.openstack.org To OpenStack Development Mailing List openstack-...@lists.openstack.org cc openstack@lists.launchpad.net \(openstack@lists.launchpad.net\) openstack@lists.launchpad.net Subject Re: [openstack-dev] [nova] Call for Help -- OpenStack API XMLSupport And this is why I go off on the developer-oriented mentality of the OpenStack community. The fact that there is no one in the OpenStack developer community writing XML stuff is not a reflection of the fact that there's no huge desire for XML. It's in the spec for a reason: BECAUSE ENTERPRISES USE XML HEAVILY OpenStack developers aren't that audience. They use JSON. That the project can get to this point and not have tests for these things shows a flaw in the development processes, not some grand illustration of supply and demand. Do I really have to point out that if the spec calls for JSON and XML, you should bloody well write integration tests to check for JSON and XML? You don't write whatever happens to please you. You know how I know all of this? I have an API that supports both XML and JSON. I personally prefer JSON. Most of my friends and colleagues prefer and use JSON. Most of my customers use XML. Thank $deity I actually write unit tests for each format. -George File under: - statistics 101 - software development 101 On Aug 9, 2012, at 5:52 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.com wrote: Why aren't the integration tests both XML and JSON? The simple answer is that no one has taken the time to write them. Our devstack exercises use the python client bindings. Tempest has json clients but no xml clients[1]. I think this demonstrates that there just isn't a huge desire for xml. Users that I have chatted with just seem to care that the api works and that they they have good bindings. I am definitely willing to be proven wrong on this point, but I'm secretly hoping everyone agrees with me. It is a lot of work to maintain three APIs (we are still maintaining EC2 as well) and keep them all functioning well, so if people are happy without OpenStack XML I would be perfectly content to deprecate it. Vish [1] https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- George Reese (george.re...@imaginary.com) t: @GeorgeReese m: +1(207)956-0217 Skype: nspollution
Re: [Openstack] Angry People and OpenStack
On Aug 1, 2012, at 11:17 PM, Atul Jha atul@csscorp.com wrote: I don`t see there is any. Its just there are certain section of people who are bound to create FUD and act as TROLL. What we can simply do is to ignore them. :) This is a dangerous attitude here. People who criticize are haters and should be ignored. Stick your head in the sand and ignore the fact that OpenStack governance has a huge trust problem, that the product has stability and compatibility issues. Attack me for criticizing OpenStack when on a daily basis I am doing a lot of work to get into real world deployments. In the mean time, I know people on this list heaping plenty of public praise on OpenStack who are actively pushing people in private towards alternatives. Yeah, that'll work really well. -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] Suspend/Stop VM
I must be missing something, but I can't find any docs on how to suspend or stop a VM via API. Any pointers, please? :) -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] Suspend/Stop VM
Thanks, but I am looking for how this is done via API. -George On Jul 30, 2012, at 11:11 AM, Pengjun Pan panpeng...@gmail.com wrote: I never tried to stop a VM using api. But run a nova help, it has pause, reboot, resume, etc. To bypass nova api, you can use virsh to stop instances. Do a sudo virsh list --all, it will list all the running instances even if nova cannot see it for some reason. And then you can kill all the ghost instances by sudo virsh shutdown id. Hope this helps. PJ On Mon, Jul 30, 2012 at 10:50 AM, George Reese george.re...@enstratus.com wrote: I must be missing something, but I can't find any docs on how to suspend or stop a VM via API. Any pointers, please? :) -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] Suspend/Stop VM
Thanks, this bit is perfect.
-George
On Jul 30, 2012, at 11:57 AM, Eric Windisch e...@cloudscaling.com wrote:
I'm not sure where the actions are documented, but you can infer them from
here:
https://github.com/openstack/python-novaclient/blob/master/novaclient/v1_1/servers.py
Below, I've pasted a few of the methods related to this thread. These are
POST'ed to the action URI, as Mark suggested.
Regards,
Eric Windisch
def stop(self, server):
Stop the server.
return self._action('os-stop', server, None)
def start(self, server):
Start the server.
self._action('os-start', server, None)
def pause(self, server):
Pause the server.
self._action('pause', server, None)
def unpause(self, server):
Unpause the server.
self._action('unpause', server, None)
def lock(self, server):
Lock the server.
self._action('lock', server, None)
def unlock(self, server):
Unlock the server.
self._action('unlock', server, None)
def suspend(self, server):
Suspend the server.
self._action('suspend', server, None)
def resume(self, server):
Resume the server.
self._action('resume', server, None)
--
George Reese - Chief Technology Officer, enStratus
e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep:
+1.207.956.0217
enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese
___
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] Openstack JAVA SDK
If you want something that supports all of the various flavors of OpenStack out there plus will also run against other clouds, have a look at Dasein Cloud at on Source Forge: http://dasein-cloud.sf.net It's the abstraction layer enStratus happens to use for talking to clouds and it's open source. -George On Jul 17, 2012, at 5:09 PM, Jyothsna Padavala wrote: Hello all, I've the openstack (only keystone and swift)setup ready. Now, i want to talk to this setup from my java application. When i tried to google for java sdk for openstack, i got two options. 1) java cloud-files from rackspace (https://github.com/rackspace/java-cloudfiles) 2) Java SDK from (https://github.com/woorea/openstack-java-sdk) My question is which one is reliable and easy to use. How do i go about installing them? Thanks much, Jyothsna ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I definitely agree with everything said here. On Jul 16, 2012, at 8:55 AM, David Kranz wrote: An excellent idea. I believe that if the below message had been sent in April, the tenor of the discussion would have been much different. I think a main source of angst around this was that there was no mention at the Folsom summit of nova-volume being simply removed immediately, except perhaps inside the session devoted to this subject which many could not attend. Stepping up a level, it is hard for a project to move from a developer-centric (no real customers) way of doing things to one driven by having real enterprise users/customers. I know this from past experience. At a certain point, we will have to live with APIs or code organizations that are sub-optimal because it is just too much of a burden on real users/operators to change them. Obviously some members of the community believe this tipping point was the Essex release. It is also inevitable that development will slow down by some measures as the cost of regressions rises and what George Reese called technical debt has to be repaid. Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. -David On 7/16/2012 8:04 AM, Sean Dague wrote: On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote: Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. +1 -Sean ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Because the community has done such a good job in the area of interoperability and compatibility over the past few years that it thus deserves the benefit of the doubt even though we have a thread previously showing blatant disregard for such concerns? No, this community has, by and large, been overtly hostile to concerns of interoperability and compatibility and I jumped into this thread exactly because it was in active expression of that ongoing overt hostility. As I said before, that needs to change. If you don't like my methods, oh well. But this is a serious problem that is a distinct threat to the viability of OpenStack. Much, much, much more so than whether block storage is represented by the nova-volumes model or the Cinder model. Having said that, I believe I've made my point. I think the net result is that some people better understand the pain caused by the lack of OpenStack interoperability and compatibility, and others are still interested in just paying it lips service. We'll see what wins out come GA of Folsom, won't we? -George On Jul 13, 2012, at 10:47 AM, Stefano Maffulli wrote: On 07/12/2012 03:54 PM, George Reese wrote: This community needs offending. This is your opinion and you're entitled to it but let me assure you that *nobody* here wants to be offended by you. This community is made of smart people that deserve respect: stop offending them, now. Make your point in a civil way and try to build consensus around it: that's how this community operates. /stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] [nova] [cinder] Nova-volume vs. Cinder in Folsom
This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I certainly wasn't picking on Vish, but instead the entire community so eagerly interested in option #1. You see, the OpenStack community has a perfect record of making sure stuff like that ends up breaking everyone between upgrades. So, if you take offense by my comments… err, well, I'm not at all sorry. It's time for this community to grow the hell up and make sure systems upgrade nicely now and forever and that OpenStack environments are actually compatible with one another. Hell, I still find Essex environments that aren't even API compatible with one another. You have the Rackspace CTO wandering around conferences talking about how the value proposition of OpenStack is interoperability among clouds and yet you can't even get interoperability within the same OpenStack distribution of the same OpenStack version. I smell a pile of bullshit and the community just keeps shoveling. -George On Jul 12, 2012, at 12:22 PM, Jay Pipes wrote: On 07/12/2012 12:32 PM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? a) Please don't be inappropriate on the mailing list b) Vish sent the email below to the mailing list *precisely because* he cares about compatibility. He wants to discuss the options with the community and come up with a reasonable action plan with the Cinder PTL, John Griffith for the move Now, would you care to be constructive with your criticism? Thanks, -jay On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.com mailto:george.re...@enstratus.com Skype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com http://www.enstratus.com/ To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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 -- George Reese - Chief Technology Officer, enStratus
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReese p: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
This ain't the first time I've had a run in with you where your response was essentially if you don't like it, go code it. And obviously you missed the entire constructive point in my response. It's this: The proposed options suck. It's too late to do anything about that as this ship has sailed. What you need to understand going forward is that this community has an abysmal history when it comes to compatibility and interoperability. Abysmal. Not checkered. Not patchy. Not lacking. Abysmal. Horizontally. Vertically. Abysmal. Actually, shockingly abysmal. You saw one public response laughing at me for expecting this community to care about compatibility. I also received private responses with the same sentiment. If you guys really think you care about compatibility, you need to go sit in a corner and do some heavy thinking. Because the history of this project and this thread in particular suggest otherwise. In case you missed it again, here it is in a single sentence: The constructive point I am making is that it's time to wake up and get serious about compatibility and interoperability. -George On Jul 12, 2012, at 2:27 PM, Brian Waldon wrote: Planning the development of the projects is valuable as well as contributing code. If you review my last message, you'll see the words '... or design help', which I intended to represent non-code contribution. You seem to have strong opinions on how things should be done, but I don't see your voice in any of the community discussions. Moving forward, I wish you would share your expertise in a constructive manner. Keep in mind this list reaches 2200 people. Let's not waste anyone's time. WALDON On Jul 12, 2012, at 12:14 PM, George Reese wrote: So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
You are mistaking me for caring about the answer to this question. This ship has sailed. We are faced with two shitty choices as a result of continued lack of concern by this community for compatibility. History? I've been pounding my head against the OpenStack all for years on compatibility and we end up AGAIN in a situation like this where we have two shitty options. I'm not offering an opinion or a third option because I just don't give a damn what option is picked since both will suck. I'm trying to get everyone to get their heads out of their asses and not stick us yet against in this situation in the future. You can discard my position if you want. I really don't give a damn. I just happen to work with a wider variety of OpenStack environments that most others on the list. But whatever. -George On Jul 12, 2012, at 2:40 PM, Jon Mittelhauser wrote: George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.com Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.com Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I don't think Cinder should exist. Sometimes you have to live with the technical debt because that's the best way to preserve the investment your customers have made in your product. Or if you're very smart, you find a way to refactor that technical debt invisibly to customers. But you don't make the customer carry the burden of your refactoring technical debt. -George On Jul 12, 2012, at 2:52 PM, Jon Mittelhauser wrote: How can I disregard a position that you don't have? (or at least I don't understand yet) You have failed to provide a position. Like I said, I'm fairly new to OpenStack….but I am *very* experienced in open source and operating very large and complex production systems… so I am trying to come up to speed and understand your position… Separating out the volume code from the compute code seems like a no-brainer thing that needed to be done. Do you disagree with that basic premise (e.g. That Cinder should exist)? Do you disagree with the way that it was done (e.g. How Cinder is written)? Or do you disagree with the migration strategies proposed (which is what Vish's email was opening discussion about)? Or…?? -Jon From: George Reese george.re...@enstratus.com Date: Thursday, July 12, 2012 12:47 PM To: Jon Mittelhauser jon.mittelhau...@nebula.com Cc: Brian Waldon brian.wal...@rackspace.com, Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom You are mistaking me for caring about the answer to this question. This ship has sailed. We are faced with two shitty choices as a result of continued lack of concern by this community for compatibility. History? I've been pounding my head against the OpenStack all for years on compatibility and we end up AGAIN in a situation like this where we have two shitty options. I'm not offering an opinion or a third option because I just don't give a damn what option is picked since both will suck. I'm trying to get everyone to get their heads out of their asses and not stick us yet against in this situation in the future. You can discard my position if you want. I really don't give a damn. I just happen to work with a wider variety of OpenStack environments that most others on the list. But whatever. -George On Jul 12, 2012, at 2:40 PM, Jon Mittelhauser wrote: George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.com Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.com Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Jul 12, 2012, at 5:08 PM, John Postlethwait wrote: So, in short, your entire purpose here is to troll everyone? Nice… : / If you think that, you're likely part of the problem. You obviously care. You keep responding… You have been asked numerous times what we can do to NOT stick us yet against in this situation in the future. Why is that such a difficult question to answer? Do you have an answer? Is your answer to not change anything, ever? That is not likely or reasonable – so what can be done here? Have you seen the other thread about what this cinder/nova-volume change entails? This is an idiotic question. What can I suggest everyone do about as yet unproposed changes to OpenStack? Seriously? There ARE people here willing to hear it out if you have an answer, or an actionable suggestion, or process, or SOMETHING besides get your heads out of your asses, which is hardly actionable, as it is vague and hopefully not a literal belief/suggestion… So, George: What do you want from us here? You likely have some legitimate pain-points, concerns, and reasons to be upset, but they are absolutely lost in your angry and personally offensive responses. Can you maybe elaborate on what pain THIS change would cause, and how we might assuage that? This community needs offending. How many years has it been? How many OpenStack upgrades can you point to that have been painless? How many interoperable, multi-vendor OpenStack clouds? How reliable is the API as an appropriate abstract representation of an OpenStack implementation that can be used to build an ecosystem? The answer to those questions is: - 3 - 0 - 0 - not at all It is very clear that compatibility and upgradability is a huge issue. And a number of people, obviously including you, don't seem to grasp that. We have silly comments like Michael's I hate to fan the fire, but what would happened in cassandra if they _never_ updated their data structures. 1. Obviously I am not talking about never changing anything. Any suggestion otherwise is being willfully obtuse. 2. There's a big difference between systems like Cassandra that generally can have maintenance windows and environments like clouds which should NEVER have maintenance windows 3. Every single other cloud platform on the planet manages to support a much less painful upgrade path with a much higher level of interoperability. In all of yours and Jon's and Brian's nonsense, I don't see any actual defense of the compatibility and interoperability of OpenStack deployments. I can only assume that's because you can't actually defend it, yet you nevertheless have your head stuck in the sand. -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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] OpenStack Java API
There's also Dasein Cloud if you are interested at http://dasein-cloud.sf.net. -George On Feb 11, 2012, at 12:28 AM, Monty Taylor wrote: Hi! Awesome, and thanks for the work! Just in case you didn't know about it: http://www.jclouds.org/ Is a Java library with multi-cloud support, including OpenStack, which might be a fun place for you to hack - and I know Adrian loves contributors. On the other hand, any amount of Java story for OpenStack is good news. Thanks! Monty On 02/10/2012 12:08 PM, Luis Gervaso wrote: Till i know Nova 1.0 is deprecated, so it will not be implemented. Nova 1.1 is almost implemented (working now with extensions : volumes / snapshots / storagearrays) Nova 2.0 is a must Glance (working now on it, this is the most easy to implement API) Swift Java API from Rackspace is stable enough, so I will integrate at the end. Hope to hear about this roadmap. Luis On Fri, Feb 10, 2012 at 8:56 PM, Marton Kiss marton.k...@gmail.com mailto:marton.k...@gmail.com wrote: Hi, Nice start Luis. Do you have some plans to support different OS API versions? Anybody knows about a similar effort to write a PHP client? Regards, Márton Kiss, CTO Xemeti 2012/2/10 Luis Gervaso l...@woorea.es mailto:l...@woorea.es: Hi, My name is Luis Gervaso. I just upload a developer preview of OpenStack Java SDK on https://github.com/woorea/openstack-java-sdk/ I want to know if other development efforts have been done in this way in order to contribute. Regards -- Luis Alberto Gervaso Martín Java EE Architect Instructor C/ Cuenca 4A, 2ºB Getafe (Madrid) SPAIN l...@woorea.es mailto:l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Luis Alberto Gervaso Martín Java EE Architect Instructor C/ Cuenca 4A, 2ºB Getafe (Madrid) SPAIN mobile: (+34) 627983344 l...@woorea.es mailto:l...@woorea.es ___ 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Nova EC2 API Team
I'd also recommend documenting the version of the EC2 API supported by the project. That can then become a reference for a true standard, instead of the moving non-standard from AWS. -George On Nov 8, 2011, at 3:38 PM, Chuck Short wrote: Hi, At the last Openstack Design Summit we had a session about how we can take care of the EC2 API more affectively. One of the outcomes of this session was to create an EC2 API team, that will help take care of the EC2 API in Nova. Today I would like to announce the formation of the Nova EC2 API team on launchpad. The goal of this team is to take of the EC2 API, which includes bugs on launchpad, making sure the EC2 API is compatible, and testing the current EC2 API on Nova. I would also like to announce the first meeting, next Tuesday at 15:00 UTC on #openstack-meeting. If you have any questions please let me know. Regards chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Push vs Polling (from Versioning Thread)
When you look at the scalability issue solely from the perspective of the cloud provider, requiring polling is the lazier, but not really more scalable solution. Especially if you go nuts with caching. Then it might be even a bit more scalable. But when you look at the distributed systems use cases, it's terrible for the system as a whole. People are polling your API because they want to know whether or not the state of the system is different from what they remember it to be. The more critical it is for them to rapidly know about changes, the more often they poll. Yes, there are ways to determine when changes are more likely to occur and thus optimize the polling interval. Some clients may be, in your eyes as the provider, overly aggressive. But who the hell are you to judge their use case and throttle them? But here's the bottom line: The vast majority of work is completely wasted when polling is the change propagation method. Push notifications don't make your core system any more complex. You push the change to a message queue and rely on another system to do the work. The other system is scalable. It has no need to be stateless and can be run in an on-demand format using agents to handle the growing/shrinking notification needs. Bryan brings up the point that some of these subscription endpoints may go away. That's a total red-herring. You have mechanisms in place to detect failed deliveries and unsubscribe after a time (among other strategies). The bottom line: When you push changes, the vast majority of your work is meaningful work when pushing is the change propagation method. Let's do the math. Let's say I am interested in any change in VM state so I can auto-scale/auto-recover. Let's use a fairly simplistic polling strategy, but do it efficiently (and assume the API enables me to make a single API call to get state for all VMs). Let's pick 1 query/minute (in reality, you wouldn't pick a flat polling rate like this, but it is useful for this thought experiment). Now multiply that times 1,000 customers. Or 100,000. Or 1,000,000. Now let's say that the client is going through a cloud management service. And that service is serving 20% of your customer base. They are likely making queries across a wide range of resources, not just VMs. And they have to scale the polling from their end. Both sides are thus engaged in trying to figure out a way to scale work that is almost entirely pointless work. There's a reason you see the cloud management tools pushing push. We've seen this IaaS polling across a bunch of clouds. It sucks. -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Push vs Polling (from Versioning Thread)
You are describing an all-purpose system, not one that supports the narrow needs of IaaS state notifications. There's no reason in this scenario to guarantee message delivery. Sent from my iPhone On Oct 28, 2011, at 10:09, Jorge Williams jorge.willi...@rackspace.com wrote: On Oct 28, 2011, at 8:11 AM, George Reese wrote: Push notifications don't make your core system any more complex. You push the change to a message queue and rely on another system to do the work. The other system is scalable. It has no need to be stateless and can be run in an on-demand format using agents to handle the growing/shrinking notification needs. Bryan brings up the point that some of these subscription endpoints may go away. That's a total red-herring. You have mechanisms in place to detect failed deliveries and unsubscribe after a time (among other strategies). I think what Bryan is saying is this. Someone, on another system, lets call it a hub, has to do the work of tracking what messages have been received by a particular client. The failure scenarios there can cause a lot of head aches. You can try to scale hubs out horizontally, but each hub will be handling a different set of clients at a particular point in time. So that data needs to be tracked. The best you can do is to have a central data store tracking when a client has received and acknowledged a particular message. If there are a lot of clients that's a lot of data to sort through and partition. If you don't have a central store then a particular hub will be responsible for a certain set of clients. And in this case, how many clients should be tracked by a hub? 100? 1000? 100,000? The more clients a hub handles the more memory it needs to use to track those clients. If a hub is at capacity but you're monitoring system is starting to detect disk failures, how do you migrate those clients to another hub? Do you split the clients up among existing hubs, if so what's the algorithm there? Or do you have to stand up a new hub? As for the other failure states, the issue isn't just about detecting failed deliveries, it's about tracking down successful deliveries too. Say after immediately sending a message to client A, that hub goes down. There's no record in the system that the message was sent to client A. How do we detect that that happened? If we do detect it should we resend the message here? Keep in mind, the client may have received it but may or may not have acknowledged it. If we do resend the message, will that mess up the client? Does the client even care? There's a whole lot of inefficiencies to. Consider that there are some cases where the client also needs to track what messages have been received. Both the client and the hub are tracking the state in this scenario and that's pretty inefficient. I would argue far more inefficient than the polling scenario because it involves memory and potentially storage space. If the client doesn't really care to track state we are tracking it at the hub for no reason. Say we have a client that's tracking sate, maybe saving it to the datastore. (We have a lot of customers that do this.) The client receives a message, but before it can save it, it goes down. Upon coming up again, it has no awareness of the lost message, will it be delivered again? How? How does the client inform the hub of it's state? Other questions arise: How long should you track clients before you unsubscribe them? etc...etc... There's just so many similar scenarios that add a lot of complexity and I would argue, at cloud scale, far greater inefficiencies into the system. With the polling scenario, the work is split between the server and the client. The server keeps track of the messages. The client keeps track of it's own state (what was the last message received? etc). It's scalable and, I would argue more efficient, because it allows the client to track state if it wants to, when it wants to, how it wants to. On the server end statelessness means that each pubsub node is a carbon copy of another -- if one goes down another can replace it with no problem -- no need to transfer sate. What's more, the memory usage of the node is constant, no matter how many clients are hitting it. That's not to say that polling is always the right choice. As Mark said, there are a lot of factors to consider. In cases where there are a large number of messages latencies may increase dramatically. It's just that when we're talking web scale, it is *usually* a good choice. -jOrGe W. ___ 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] Push vs Polling (from Versioning Thread)
There are ways around that without guaranteed message delivery. Sent from my iPhone On Oct 28, 2011, at 11:41, Bryan Taylor btay...@rackspace.com wrote: On 10/28/2011 10:33 AM, George Reese wrote: There's no reason in this scenario to guarantee message delivery. Usage, billing, support all require guaranteed message delivery. Oops, sorry, we don't bill sometimes because we lose messages just doesn't fly with executives, shareholders, and the SEC. With customers, lost messages = credit memos and lost customers. ___ 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] API Versioning and Extensibility
On Oct 27, 2011, at 8:11 AM, Jorge Williams wrote:
Response inline:
On Oct 27, 2011, at 12:50 AM, Bryan Taylor wrote:
On 10/26/2011 04:45 PM, Jorge Williams wrote:
On Oct 26, 2011, at 1:19 PM, Bryan Taylor wrote:
So no pdfs or excel spreadsheets without conneg.
But PDFs and excel spreadsheets are precisely why you want variants!
Reports and spreadsheets are presentation layer resources that should come
from control panels and dashboards and not from a web services API layer.
In fact, it's with some reluctance that I even suggested having HTML in the
services layer, but we said an API goal was to target developers eyeballing
our data formats in a browser. HTML is the best media type to use for this,
leveraging the pre element, perhaps with some syntax highlighting eye
candy.
Here's my usage stats for 2009...
http://usage.api.acme.com/v1.0/jorgew/2009/usage.pdf;
That shouldn't be coming directly from an openstack API.
We're actually building a usage service on top of OpenStack and we don't
have any PDFs in it. Dashboards, control panels, BI systems etc, should host
that resource, not our APIs.
You mean to tell me that I can't send that out as an e-mail? Instead I
have to say
Please run this command to see my usage stats for 2009
Our use case is to show *developers* what the openstack API payloads look
like, not to deal with arbitrary end user presentation desires.
curl -H Accept: application/vnd.acme.com+pdf;version=1.0
http://usage.api.acme.com/jorgew/2009/usage;
That seems silly to me, we're missing an important feature, the ability
to click.
We are adding an important feature by leaving it out: separation of
presentation and data.
In this case you can think of the PDF or excel spreadsheet as simply an
alternate representation of the data. Providing these alternate
representations can lower barriers for a lot of clients and personally I
think they make sense in some cases. It's a pattern I've seen used quite
successfully.
They may be user-centric representations of the data, but from an API
perspective (again, application programming interface), any such unstructured
data is just a blob. There may be valid reasons for delivering blobs through
the API (though as Bryan pointed out, in general, there aren't). But when it is
done, it is done irrespective of content type or version of the underlying
content unless that data is accompanied with meta-data. Under no circumstances
is it about the ability to pull that data through a browser.
That said, I'm not to worried about generating PDFs from our current APIs
because we're just not likely to run into that use case.
What I'm more worried about is being able to support things like feeds. A
feed can be an alternate representation of an existing collection of servers,
for example, and here again we have to deal with the browser as a user agent,
that may not participate in the content negotiation process as we'd like.
The pre element approach your suggesting won't work in this case either.
The current, load balancer, API uses feeds as an alternate representation for
most collection types so that you can track changes, here's an example call.
http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/List_Virtual_IPs-d1e2809.html
The API uses a variant (.atom).
You also see this pattern in stuff like the Netflix API as well See
/users/{user_id}/feeds in:
http://developer.netflix.com/docs/read/REST_API_Reference
Here the parameter output=atom and a (read only) token is placed in the URI
as well, so that one can get access to the feed from a browser.
THE API SHOULD NOT BE SERVING ATOM CONTENT!!!
I am so damn irritated with the state of the OpenStack API.
There's a nasty habit within the OpenStack community of trying to boil the
ocean. And here we are navel gazing over feeds and crap when the API can't yet
support the most basic of functionality.
I've worked with just about every damn cloud API out there. I have a very solid
grasp on how cloud APIs get consumed, what people have done right, what people
have done wrong, and where we need innovation.
We need innovation in pushing data to API consumers.
We don't need people re-inventing API design best practices to suit extraneous
use cases.
Version and content desired belong in the headers for request and response. The
imaginary crap you are dealing with a) don't require them in a URL unless you
are pulling it from the URL bar of a browser, which is NOT an API use case and
b) doesn't help you deal with the core functionality of the API that is now
OVER A YEAR BEHIND where it should be.
-George
--
George Reese - Chief Technology Officer, enStratus
e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f:
+1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus -
http://www.enstratus.com
To schedule
Re: [Openstack] API Versioning and Extensibility
The complete lack of evolution of the OSAPI combined with the irrational resistance to the EC2 API has struck a nerve with me. #1 Feature coverage in the OSAPI is atrocious. And I don't get the feeling there's anyone seriously doing anything about it. Of course, you can always say, George, it's an Open Source project. If you don't like it, feel free to fix it. Of course, I'm not worrying about all kinds of bizarre OpenStack projects that have nothing to do with building a basic, functional cloud platform either. #2 The Netflix API is not an IaaS or PaaS API. Different problems for different audiences and different use cases. #3 Push scales a hell of a lot better than having tools polling a cloud constantly. It doesn't matter whether it is polling the API, polling a feed, or polling a message queue. Polling is one of the most unscalable things you can do in any distributed systems scenario. Calling it a feed doesn't magically solve the problem. Actually, it's quite hard on its own in an IaaS scenario and has scaling issues independent of the polling issue. Push notifications are the only mechanism for solving the scaling issue. You push any changes to a message queue. Agents pick up the changes and send them on to subscriber endpoints. Not that hard. #4 The use cases you mention don't demand API versioning in the URI. #5 For all the reasons I have already outlined, API versioning in the URI is a bad idea. I say this, again, as someone who made the dumb mistake of putting version in the URI. #6 Unstructured content does not belong in an API except in select circumstances in which you are providing mechanisms for machine to machine transfer and the machines themselves don't care about the underlying unstructured content. For example, a document repository pulling a PDF report from a system and storing it in the doc repository. In such cases, it again does not need the meta-data information in the URI. Keep meta-data in structures for describing meta-data. The URI is not such a structure. On EC2 vs OSAPI, I actually have no opinion. I do have an opinion that you pick one and make it work. We have a situation in which certain parties don't like the one that works (EC2), but they spend a bunch of time doing nothing on their alternative solution (OSAPI). And I say this as someone who things the structure of the Rackspace API on which OSAPI is based is one of the more elegant, well-designed APIs. But a well-designed API with no feature coverage isn't an API. -George On Oct 27, 2011, at 9:29 AM, Jorge Williams wrote: Wow, I seem to have struck a nerve there George which was not my intent. To add some context, I was under the impression that we're simply having a discussion here about versioning and extensibility in general, in order to help shape our future APIs in a consistent manner. I don't think that we're re-inventing our current API design, more than discussing how it should evolve. We're also not talking about any particular API (identity, compute, image, object store), but simply discussing things in general in the hopes of moving to some consistency. Overall, I like the idea of push but it's difficult to scale and techniques like atom have proven themselves. I don't think that the use case is extraneous or imaginary, in fact, I presented two APIs that use the technique, today in production, at scale. In the netflix case, I'm simply pointing out that they go out of their way to support variants, precisely to support the browser case. -jOrGe W. -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] API Versioning and Extensibility
You know what it has to do with API versioning? It has to do with people proposing bad versioning ideas to support esoteric stuff WHEN THE BASIC STUFF AIN'T THERE YET. curl is the appropriate mechanism for manually interacting with an API for development purpose. A browser is a very limited tool for interacting with the HTTP protocol and should not be the boundary of what an API should support. On Oct 27, 2011, at 10:59 AM, Bryan Taylor wrote: On 10/27/2011 08:56 AM, George Reese wrote: THE API SHOULD NOT BE SERVING ATOM CONTENT!!! What!? Atom is a fine way to represent a collection. Especially one that is append only. There's a nasty habit within the OpenStack community of trying to boil the ocean. And here we are navel gazing over feeds and crap when the API can't yet support the most basic of functionality. What does that have to do with versioning? I've worked with just about every damn cloud API out there. I have a very solid grasp on how cloud APIs get consumed, what people have done right, what people have done wrong, and where we need innovation. We need innovation in pushing data to API consumers. I disagree, but this isn't the thread to debate push vs pull as it has nothing to do with versioning. Version and content desired belong in the headers for request and response. The imaginary crap you are dealing with a) don't require them in a URL unless you are pulling it from the URL bar of a browser, which is NOT an API use case and b) doesn't help you deal with the core functionality of the API that is now OVER A YEAR BEHIND where it should be. Developers of the API need a way to see the payloads they are developing against. They need it to understand what the data looks like to consume it in code and they need it to troubleshoot data specific problems. Since our data is URI centric, it's quite reasonable for a developer to expect to put those URIs in a browser and get something useful. Whether a particular team has met it's expected roadmap to back it's API with a working implementation seems completely unrelated to the best way to do versioning to maximize the ability of clients to leverage backwards compatible changes. -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OpenStack API Versioning Conventions
On Oct 12, 2011, at 11:26 AM, Soren Hansen wrote: 2011/10/11 George Reese george.re...@enstratus.com: See EC2 for someone doing it damn well. I've never had to write new code to talk to them unless I want to take advantage of new functionality. Now I'm confused. EC2 includes the API version in the URI, but I thought you were opposed to that? No, EC2 includes the version in the parameters. That's not the right place for them either, but keep in mind that the EC2 API is not a RESTful API and should not be used as a reference for RESTful structure. Here, I was using it as an example not of RESTful structure, but instead how an API of any structure should handle past versions. -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OpenStack API Versioning Conventions
On Oct 12, 2011, at 11:23 AM, Soren Hansen wrote: 2011/10/11 George Reese george.re...@enstratus.com: It's wildly inappropriate to equate a thing with its representation. I didn't say I was right in doing so :) It's a discussion that gets philosophical rather quickly: Should we consider a URI to be a reference to a thing or a reference to a representation of a thing? It is a reference to a representation of a thing, but NOT a version of the thing. For example, http://www.enstratus.com/index.jsp does not become http://www.enstratus.com/v2/index.jsp when we change it. The new version is simply served up. Obviously, that's overly simplistic because that is a scenario in which the thing and a version of it are the same thing. HOWEVER, if I had a web page for viewing the server details for server 1234, that web page would not be versioned (in most cases on the web where resources are versioned, the browser specifies it via parameter). Why should the programming URI be versioned? -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OpenStack API Versioning Conventions
The extension has nothing to do with representation in HTTP. It's the content type (in the headers). Sent from my iPhone On Oct 12, 2011, at 17:15, Bryan Taylor btay...@rackspace.com wrote: On 10/11/2011 10:28 AM, George Reese wrote: It's wildly inappropriate to equate a thing with its representation. Unless the thing is itself a representation, yes. A resource can be ANYTHING: a server, a database record about a server, a car, a rock, the concept of love, the act of smiling, or a representation of a second resource, etc... http://example.com/thing is the thing http://example.com/v1/thing is the set of v1 representation of the thing http://example.com/v2/thing is the set of v2 representation of the thing http://example.com/v1/thing.json is the v1 JSON representation of the thing http://example.com/v2/thing.xml is the v2 XML representation of the thing A resource that represents a representation or set of representations of second resource is called a variant resource of the other. 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 ___ 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] OpenStack API Versioning Conventions
Versioning should not be included in the URI. It belongs in the headers. A URI should be a persistent reference to a resource. As such, versioning always breaks that persistent reference. -George On Oct 11, 2011, at 1:40 PM, Brian Waldon wrote: I'm all for exposing only the major version in the URI (/v1). We have fallen into a trap with v1.0 and v1.1 as they are not backckwards-compatible specs while their versioning implies they are. I think we can have a whole separate discussion on how to solve that problem, so like I said earlier, I would like to get buy-in on my original proposal before we move on to spec-specific details. Thanks for the great input, guys! Waldon On Oct 11, 2011, at 2:12 AM, Bryan Taylor wrote: On 10/11/2011 12:26 AM, Mark Nottingham wrote: Where would these versions show up? In URLs? In documentation? In response payloads? If they show up in URLs, then every backwards-compatible change would be made into a backwards-incompatible change. E.g., if you had http://www.example.com/v1.2.3/foo as a resource, and adding a new resource .../bar bumps it to v1.2.4, then that backwards-compatible change (because it doesn't break old clients) now causes everybody to break. Right. This is a trap to be avoided. The only sensible thing to put in URIs is a major version identifier that indicates backwards-incompatible changes (i.e., the slate is wiped clean, it's a different URL tree). E.g., http://www.example.com/v1/ Of course, that can be any arbitrary string, whether it be v1 or v1.1 or essex. However, putting v1.1 in there is going to confuse people, because most people believe that a minor release is, by nature, backwards compatible. I like just plain old v1 as it's short and sweet. If we want to just use them in documentation, there's no harm, of course. Likewise, the client could query the server to find out what it supports, but something more descriptive than a linear version number would be useful; e.g., some sort of linked capability catalogue format. We are usually putting a version info resource at the version root, eg: http://www.example.com/v1/ See here for how compute is doing it: http://docs.openstack.org/trunk/openstack-compute/developer/openstack-compute-api-1.0/content/ch03s09.html Unfortunately the example uses v1.0 and is confusing as you noted above. An idea I've dabbled with is putting the major and minor version number in the WADL filename. It'd be a good addition to WADL to allow it to express what version it is in its conent. ___ 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. -- Brian Waldon Cloud Software Developer Rackspace Hosting ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OpenStack API Versioning Conventions
No, not at all. The object is /servers/1234 regardless of the versioning of the API. It's an object that exists independent of your API and its version. A URI should represent a single, persistent reference to that object. The version is really an attribute of the content type you are accepting. It tells you what kind of content the client is expected to send to you and to receive from you. In particular, the structure of the data representing the persistent object. /servers/1234 should always represent that 1 server. Forever. Unless the URI has changed, in which case a v1 client will respond with a 302 and a v2 client with a 404. A v1 client can then query /instances/1234 and get the version 1 xml or json. A v2 client querying /instances/1234 gets version 2 xml or json. -George On Oct 11, 2011, at 3:11 PM, Soren Hansen wrote: 2011/10/11 George Reese george.re...@enstratus.com: Versioning should not be included in the URI. It belongs in the headers. A URI should be a persistent reference to a resource. As such, versioning always breaks that persistent reference. I don't follow. If the version is included in the URI, that's got to be a more persistent reference to a resource than a URI whose behaviour differs depending on a header that you have to include? -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OpenStack API Versioning Conventions
It's wildly inappropriate to equate a thing with its representation. On Oct 11, 2011, at 4:06 PM, Soren Hansen wrote: I see what you're saying. I guess I'm just used to equating a thing with its representation. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OpenStack API Versioning Conventions
Yes, my proposed solution requires OpenStack implementations to support ALL major versions of ALL APIs. That's absolutely critical for building a healthy ecosystem. See EC2 for someone doing it damn well. I've never had to write new code to talk to them unless I want to take advantage of new functionality. And you can guarantee that the request and response version match, because the server is supposed to respond with the appropriate version of the content and it should provide that version number in the response headers so the client can validate. -George On Oct 11, 2011, at 4:01 PM, Brian Waldon wrote: Your proposed solution to my example implies we would have to support *all* major versions of the compute API to some degree. I absolutely don't want to track redirects from v1 to v2 to v3 to v4 when we are developing v5. That seems like a painful thing to have to do. We also couldn't guarantee that the entity returned from the latest version (like v5) looks anything like that defined in the requested version (like v1). On Oct 11, 2011, at 10:46 AM, George Reese wrote: In the example you use, the proper HTTP behavior is for the API should allow for a HTTP 302 response and clients should follow the permanent move. This provides both a persistent reference based on the URI and a way to handle the alteration of URI structure. -George On Oct 11, 2011, at 2:56 PM, Brian Waldon wrote: I'm not sure I agree with that. A URI should be a persistent reference to a resource within the context of a major version of an API. Between major versions, the URI structure can change completely (for example /servers - /instances), destroying your persistent reference. Additionally, if we only support requests within the context of the latest minor version of an API, the major version is the only piece of information that matters. The mechanism for versioning through content types will only be valid within a single major version, as I do not want to define a spec that resides above all major versions of our api. Waldon On Oct 11, 2011, at 9:14 AM, George Reese wrote: Versioning should not be included in the URI. It belongs in the headers. A URI should be a persistent reference to a resource. As such, versioning always breaks that persistent reference. -George On Oct 11, 2011, at 1:40 PM, Brian Waldon wrote: I'm all for exposing only the major version in the URI (/v1). We have fallen into a trap with v1.0 and v1.1 as they are not backckwards-compatible specs while their versioning implies they are. I think we can have a whole separate discussion on how to solve that problem, so like I said earlier, I would like to get buy-in on my original proposal before we move on to spec-specific details. Thanks for the great input, guys! Waldon On Oct 11, 2011, at 2:12 AM, Bryan Taylor wrote: On 10/11/2011 12:26 AM, Mark Nottingham wrote: Where would these versions show up? In URLs? In documentation? In response payloads? If they show up in URLs, then every backwards-compatible change would be made into a backwards-incompatible change. E.g., if you had http://www.example.com/v1.2.3/foo as a resource, and adding a new resource .../bar bumps it to v1.2.4, then that backwards-compatible change (because it doesn't break old clients) now causes everybody to break. Right. This is a trap to be avoided. The only sensible thing to put in URIs is a major version identifier that indicates backwards-incompatible changes (i.e., the slate is wiped clean, it's a different URL tree). E.g., http://www.example.com/v1/ Of course, that can be any arbitrary string, whether it be v1 or v1.1 or essex. However, putting v1.1 in there is going to confuse people, because most people believe that a minor release is, by nature, backwards compatible. I like just plain old v1 as it's short and sweet. If we want to just use them in documentation, there's no harm, of course. Likewise, the client could query the server to find out what it supports, but something more descriptive than a linear version number would be useful; e.g., some sort of linked capability catalogue format. We are usually putting a version info resource at the version root, eg: http://www.example.com/v1/ See here for how compute is doing it: http://docs.openstack.org/trunk/openstack-compute/developer/openstack-compute-api-1.0/content/ch03s09.html Unfortunately the example uses v1.0 and is confusing as you noted above. An idea I've dabbled with is putting the major and minor version number in the WADL filename. It'd be a good addition to WADL to allow it to express what version it is in its conent. ___ 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] OpenStack API Versioning Conventions
HTTP methods are well defined and the system should behave in accordance with those definitions. Otherwise, even saying the word REST is a joke. On Oct 11, 2011, at 9:10 PM, Caitlin Bestler wrote: George Reese wrote: No, not at all. The object is /servers/1234 regardless of the versioning of the API. It's an object that exists independent of your API and its version. A URI should represent a single, persistent reference to that object. The version is really an attribute of the content type you are accepting. It tells you what kind of content the client is expected to send to you and to receive from you. In particular, the structure of the data representing the persistent object. /servers/1234 should always represent that 1 server. Forever. Unless the URI has changed, in which case a v1 client will respond with a 302 and a v2 client with a 404. A v1 client can then query /instances/1234 and get the version 1 xml or json. A v2 client querying /instances/1234 gets version 2 xml or json. Another angle on this (which leads to the same conclusion) is to state that the API has verbs which reference objects. The object references should not change, ever. It may be possible to come up with additional methods of referencing the same objects but even that would be fairly exceptional. The signature for a given supported verb should also never change. Period. New signatures may supplement the existing set, but should very seldom invalidate a previously valid method signature. Over time a server will typically end up supporting multiple signatures to support the same operation, which will include Some signatures that are now recognized as only supporting a portion of the clients' requirements. So, an API version number is a short hand method of publishing the set of method signatures that a server supports. As a reporting attribute it can be useful, but what is the benefit of encoding it in the URI? Essentially when you go form API version 1 to API version 2 in the URIs you are renaming all the signatures. But why Rename methods that are identical to their prior version? Isn't that supposed to be the *normal* case? If you are going to apply version numbers, why not do it on a per method basis? This is v2 of GET, etc. Having an overall Version number to simplify reporting makes sense, by there is no need to have it in the URI itself. And why have a syntactic Method for renaming methods? What's so bad about calling this radical new method GetV2? -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Standardizing External APIs
See: http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html and http://broadcast.oreilly.com/2010/02/towards-event-driven-cloud-apis.html On Sep 7, 2011, at 7:52 AM, Sandy Walsh wrote: +1 From: George Reese [george.re...@enstratus.com] This should fall under the more general push notifications API. This email may include confidential information. If you received it in error, please delete it. -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] API Spec
The Rackspace compute API is actually one of the better cloud APIs out there. It's a pretty damn good basis for an OpenStack Nova API. EC2, on the other hand, is a pretty obnoxious API and I've already outlined my thoughts on its role as a defacto API on my blog. Having said that, there is basically no difference between the OpenStack API and a Rackspace API that has not changed in 2 years. In other words, there's been no attempt to improve the API based on two year's of learning, no attempt to step back and model the problem of cloud computing in general, it uses some goofy Rackspace terminology like Flavor, and there's been no attempt to expose the features of OpenStack that don't exist in the current Rackspace API. The biggest difference is authentication. That's been left up to the implementor. Yuck! Pick an authentication scheme and live with it! The most important thing right now would not be to re-write the API, but to create specs for other parts of OpenStack like volumes and integrate them into the structure of the current API. It shouldn't be too hard. I absolutely don't understand why, after a year of work, all we have is clone of the Rackspace API labeled 1.1. -George On Aug 27, 2011, at 12:34 PM, Michael Shuler wrote: Preface: I am not very familiar with Nova. On 08/26/2011 01:19 PM, Devin Carlen wrote: I believe we should have had a Rackspace API module just like we have an EC2 API module. Then the OpenStack API wouldn't have been burdened by the historical decisions around the Rackspace API. But that is ancient history at this point. So that I can better understand, as well as for others that may not know, would it be possible to get a basic explanation of why it is hard to modify Nova, now, to modularize the Rackspace API? basic == non-technical highlights in simple english, please. This sounds to me like a bad architectural decision that people are living with - so, why not admit that and make it a priority to change? -- Kind regards, Michael snipped it's been over and year and it is hard sounding excuses(?) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] API Spec
A cloud platform simply isn't functional without an API. It is a core requirement. No API, no cloud. -George On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: I'm also a non-API expert but getting a stable open cloud engine with a reasonable API would seem to be a good target before we look to enhance it. There are lots of potential users of Nova (including Rackspace) who would like to get Nova into production. An API will fully exploits all of the underlying functionality should be discussed/planned in the longer term but let's get Diablo out and deployable first. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] API Spec
I don't necessarily agree with that approach. I'm not sure if that's the way AWS does things or not, but you will note that the AWS APIs are very fragmented across projects. I think there are several principles that may at times be in conflict that need to be in place: * Any GA feature should be exposed via API at the time of its GA-ness. * There needs to be a gatekeeper (possibly the wrong word) ensuring that the APIs are self-consistent And the understanding should exist that modeling something for functionality may not be the same as the way it is modeled in the API. In fact, the underlying model will likely be refactored many times by the API must be timeless (but evolvable). -George On Aug 28, 2011, at 2:29 AM, Jonathan Bryce wrote: This is on the agenda for Tuesday's policy board meeting (in #openstack-meeting 1 hour before the weekly OpenStack team meeting for those interested). Sounds like a potentially acceptable solution is to set some cross-project API standards and then push the remainder of the API definition and implementation into each project. Then the API can progress with the underlying project's features as the developers see fit. Jonathan. On Aug 27, 2011, at 4:16 PM, Tim Bell wrote: I have an api, diablo nova v1.1. What we are talking about is if it covers 100% functionality. I can start my deployment testing with v1.1. The limiting factor is not v1.1 vs v1.x for most sites. It is packaging, user exits and integration, not whether feature X is in the latest API. Tim. - Reply message - From: George Reese george.re...@enstratus.com To: Tim Bell tim.b...@cern.ch Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: [Openstack] API Spec Date: Sat, Aug 27, 2011 20:47 A cloud platform simply isn't functional without an API. It is a core requirement. No API, no cloud. -George On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: I'm also a non-API expert but getting a stable open cloud engine with a reasonable API would seem to be a good target before we look to enhance it. There are lots of potential users of Nova (including Rackspace) who would like to get Nova into production. An API will fully exploits all of the underlying functionality should be discussed/planned in the longer term but let's get Diablo out and deployable first. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] API Spec
You couldn't be more correct. The words I would use to describe this scenario are: unacceptable and inexcusable. On Aug 26, 2011, at 7:19 PM, Devin Carlen wrote: Hey all, I've been following the code vs architect debate that's been unfolding over the past week or so. Here are some of the problems I've seen from my point of view. Fundamentally, the process we have now for defining API specs is broken. I don't believe that this can be argued. The first major misstep in my opinion was forcing backwards compatibility with the Rackspace API in the OpenStack API. I believe we should have had a Rackspace API module just like we have an EC2 API module. Then the OpenStack API wouldn't have been burdened by the historical decisions around the Rackspace API. But that is ancient history at this point. But we have to look at this pragmatically, and realize that 1 year later, the OpenStack API (as spec'd) is still not even close to exposing the underlying core functionality that exists within Nova. For the most part, the OpenStack API is a subset of functionality of the EC2 API. This is a big reason why the Dashboard project used the EC2 API for its underlying communication for so long. There have been a lot of efforts lately to bring the feature set of the OpenStack API in line with the EC2 API, and this is admirable. But this has NOT been happening at the architect level. This has been happening at the developer level, and it is being done with API extensions which make it sound like the feature is somehow not complete or not supported fully, because it's not part of the core API. So the question to all in favor of architecting up front: How do you explain lacking feature parity with the underlying components for over a year now? In my opinion, this has been a big problem in gaining traction around the OpenStack API. 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I'd add a fairly fundamental rule of ID design is that ID should never, ever have any meaning except to serve as identifiers. The minute you tie them to IPv6 values, you are giving them meaning. On Jul 11, 2011, at 6:49 PM, Soren Hansen wrote: 2011/7/11 Ed Leafe ed.le...@rackspace.com: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I can think of a number of reasons why using ipv6 addresses are a bad idea. 1. They only naturally map to VM's. Using them for any other object types seems artifical (why would a snapshot need an ipv6 address?) 2. One of the reasons UUID's were chosen was because it gave us a gigantic key space that made collisions unlikely enough that we needn't worry about them. If you use ipv6 addressses as your ID's, you're limited to the part of the ipv6 address space you've been assigned (rather than the full 128 bit key space). I realise /64's are pretty commonplace, but collisions are ~10 orders of magnitudes more likely in a /64 keyspace than they are in a /128. 3. You'd never be able to recycle IP's. UUID's are (and EC2 ID's are said to be) perpetually unique. They do not get recycled. If an instance's ipv6 address is its instance ID, you'll have to either live with your pool of ipv6 addresses slowly depleting (even though their corresponding instances have been deleted) or recycle the instance ID's (and hence IP's). Neither of those options seem very cool. -- 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
The other piece of the puzzle is that it is very easy to keep a client consistent with the API; it's very hard to keep an implementation up-to-date. I've built an EC2 compatible API and the problem is that understanding what has changed in the API (and it changes fairly frequently) is hard. On the other hand, AWS is great at not breaking clients. So, when they roll out a change, it doesn't impact clients; but anyone implementing an EC2-compatible API will immediately be broken for clients taking advantage of new features. Furthermore, it may not be entirely clear from your end what it is that broke things. -George On Jul 9, 2011, at 9:30 AM, Sandy Walsh wrote: Ok, so let's look at this from another perspective ... how far away are we? I thought our EC2 binding was pretty good (admittedly, I don't use it). Are we radically out in left field or is this a game of inches? Any hardcore EC2 users care to comment? -S From: Jorge Williams Sent: Saturday, July 09, 2011 2:28 AM To: Sandy Walsh Cc: Soren Hansen; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote: Wow, really? Is EC2 really that sporadic/chaotic? I have to plead ignorance because I don't know where the rubber meets the road, but that kinda surprises me. I'm not saying that. In fact let me say that I don't think the Windows API itself is sporadic or chaotic. I used to be a Windows dev way back in the day and I never got that impression. The problem is that the Windows API is not open and is not really designed to be implemented by others. The Wine folks (and the ReactOS folks) have been working really hard to implement it for a long time. And with good reason, there are a lot of incentives to have a free Windows compatible OS. The task the Wine folks have is very hard though. There are no reference implementations for the Windows API, so you can't look at the code, you have to replicate bugs in the implementation and bugs in client apps etc, oh and do you really think MS wants a free Windows compatible OS on the market? -- you have to account for them messing with you as well. Soren was suggesting that supporting EC2 was much like writing an implementation of HTTP or SMTP (both open specs with open reference implementations). All I'm saying is that reverse engineering a living, rapidly changing, closed system and writing another system that behaves like it exactly (bugs and all) is not the same thing as implementing an open spec -- it's harder. -jOrGe W. 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I would just like to re-iterate that I think the entire UUID approach is flawed and issues like this are one of the key reasons why. -George On Jul 8, 2011, at 7:02 AM, Soren Hansen wrote: 2011/7/8 Ed Leafe ed.le...@rackspace.com: On Jul 7, 2011, at 11:46 AM, Trey Morris wrote: If I had to choose between dropping or truncating UUIDs and failing feature parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have already been discussed and decisions made. The EC2 api shouldn't get in the way. A translation layer to sit in between the EC2 and OS APIs would solve this issue without revisiting the UUID argument. The code to use the first 8 chars of the UUID in the ec2 id was created and working well, but discarded in favor of a more limited approach. Why? The only issue was the increased likelihood of a duplicate ec2 id, as we'd be limited to only 4 billion of them or so. I thought that it would be fairly straightforward to add code to detect such dupes, and re-generate a new UUID for the instance in that event. How would that work? The frontend gets a reqeust for a new instance, it sends it on to the backend that starts handling the request and sends back the ID. What then? Either the backend would need to be changed to wait for an yes, I accept this UUID from the frontend, which is unfortunate, or the frontend would have to get the response back, go hm, this collides with an existing ID. Cancel the request, and start over. In the latter case, a cost has already been incurred by starting up and immediately shutting down the instance. Also, if instances had already been created through the OpenStack API and were being queried through the EC2 API, there's no guarantee that colliding ID's don't already exist. In that case, you need to figure how to try to make sure that a request asking for that particular ID always gives a response corresponding to the same actual instance. This sounds crappy for a distributed system. If you want to perform the collision check even for intances created through the OpenStack API, then the reasons for choosing UUID's to begin with are moot. -- 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
This ship may have sailed, but given what I have seen across a wide variety of cloud APIs and what I are here, I strongly question the value of supporting an EC2 API. I think you overestimate the value of supporting existing tools. Sent from my iPhone On Jul 8, 2011, at 19:32, Lorin Hochstein lo...@isi.edu wrote: Stepping back for a moment, I think the two main benefits of supporting the EC2 API are: - Leverage existing 3rd party tools that talk to EC2 API (e.g., euca2ools, boto, Elasticfox/Hybridfox) - Reduce the cost of switching to OpenStack for EC2 users I agree with Soren that these benefits are lost if OpenStack supports the official EC2 spec but breaks compatibility with the existing tools and scripts people already have. Better to not have an EC2 API at all than to lose new users because they think OpenStack is broken when their EC2-based tool fails to work. While the comparison with Wine is apt, I think an even more relevant comparison would be Microsoft trying to stay compatible with third party applications that worked on previous versions of Windows, even ones that broke the API but still worked (See Raymon Chen's excellent The Old New Thing blog for the Herculean efforts that MS developers had to put in to accomplish this http://blogs.msdn.com/b/oldnewthing/). I don't think that the OpenStack project should commit to maintaining EC2 compatibility at all costs, only as long as the benefits outweigh the development costs. In particular, if Amazon deliberately started making changes to break the API, that would be a good time to consider dropping support. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Jul 8, 2011, at 6:59 PM, Jorge Williams wrote: HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were developed and continue to be developed in the open -- and both clients and servers (proprietary and open source) are very compliant to them. I'd like to propose that our APIs take the same approach. You are proposing something different than simply implementing HTTP or SMTP. What you are proposing that we try to achieve with EC2 what the Wine folks want to achieve with the Windows API. It's a different problem. It's a much harder problem because it involves reverse engineering and it's prone to more risk. -jOrGe W. On Jul 8, 2011, at 3:05 PM, Soren Hansen wrote: One thing that keeps coming up in this discussion is the issue of being tied to an API we don't control. People... We're *fantastically* privileged that we get to define an API of our own. Lots and lots and lots of people and projects spend all their time implementing existing (open, but completely static) protocols and specifications. Every HTTP, SMTP, and IMAP server on the planet does it. Every single C compiler on the planet does it. All of these are things that have been defined a long time ago. You can have all the opinions you want about IMAP, but that doesn't mean you can just implement it differently. At least not if you expect people to support your stuff. When there are ambiguities in the spec, sure, you can insist on taking one path even though everyone else has taken a different one, but don't expect the rest of the world to change to accommodate you. If you want to do offer something better by doing something differently, offer it as an alternative that people can switch to once you've won them over. Don't make it a prerequisite. There's a golden rule when implementing things according to an existing specification: Be very conservative in what you deliver, and be very liberal in what you accept. Otherwise, people. will. use. something. else. period. -- 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 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 ___ 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 :
Re: [Openstack] Feedback on HTTP APIs
I hate UUIDs with a passion. * They are text fields, which means slower database indexes * They are completely user-unfriendly. The whole copy and paste argument borders on silliness * The bursting scenario makes no sense to me. Why do two different clouds need to agree on uniqueness of resource IDs? (said as one of the few people actually doing bursting) * And uniqueness across regions for share nothing can be managed with a variety of alternative options without resorting to the ugliness that is UUIDs On Jun 2, 2011, at 7:40 PM, Glen Campbell wrote: There was another specific use case, where someone with a private OpenStack cloud was bursting into a public cloud. UUIDs would help ensure the uniqueness of identifiers in that case. On 5/29/11 8:43 PM, Mark Nottingham m...@mnot.net wrote: Ah -- makes sense. Thanks. On 30/05/2011, at 11:40 AM, Ed Leafe wrote: On May 29, 2011, at 9:01 PM, Mark Nottingham wrote: WIth regards to UUIDs -- I'm not sure what the use cases being discussed are (sorry for coming in late), but in my experience UUIDs are good fits for cases where you truly need distributed extensibility without coordination. In other uses, they can be a real burden for developers, if for no other reason than their extremely unwieldy syntax. What are the use cases here? The primary use case I can think of is a deployment with several zones that are geographically dispersed. Since each zone is shared-nothing with other zones, UUIDs are the most logical choice for instance IDs that need to be unique across zones. This is precisely the use case that UUIDs were created for. In my experience, UUIDs are no more of a programmatic burden than any other sort of PK; the only place where they are unwieldy is when humans have to type them into a command line or a browser URL. But since most humans doing that would have access to copy/paste, it isn't nearly as bad as it might seem. -- Ed Leafe 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. -- Mark Nottingham http://www.mnot.net/ ___ 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 -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] XML and JSON for API's
+1 Sent from my iPhone On Jun 2, 2011, at 22:20, Jorge Williams jorge.willi...@rackspace.com wrote: It's not just about the service itself validating it, its as Joseph said, making sure that the data structures themselves are documented in detail to the client. To my knowledge there is no accepted schema language in JSON though JSON schema is starting to catch on. At the end of the day it should be a matter of providing our customers with a representation that they can readily use. It could be that my perception is wrong, but it seems to me that there's support for both representations. I'll try to get some data to back this up. -jOrGe W. On Jun 2, 2011, at 2:00 PM, Jay Pipes wrote: On Thu, Jun 2, 2011 at 1:54 PM, Rick Clark r...@openstack.org wrote: Hi All, Is it required for new openstack API's to support both JSON and XML, or would it be acceptable to only support JSON? Glance currently does not support XML and I have no plans in the immediate future to add support for it. IMHO, JSON can be validated just as easily as XML. Simply json.loads(req.body) and then, if parsing succeeds, compare the mapping against a model. No need for XSDs, WADLs, or any other acronym. -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
Re: [Openstack] OS API server password generation
I don't agree with this approach. The current Cloud Servers approach is flawed. I wrote about this a year ago: http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html It's a mistake to send OpenStack pursuing a flaw in Cloud Servers. -George On Mar 3, 2011, at 9:32 AM, Ed Leafe wrote: On Mar 3, 2011, at 8:40 AM, George Reese wrote: Any mechanism that requires an agent or requires any ability of the hypervisor or cloud platform to inject a password creates trust issues. In particular, the hypervisor and platform should avoid operations that reach into the guest. The guest should have the option of complete control over its data. Please understand that this is a Rackspace-specific use case. It is not an OpenStack standard by any means. That's why this action is in a specific agent, not in the main OpenStack compute codebase. On an OpenStack list, we should be discussing the OpenStack code, not Rackspace's customization of that code for our use cases. Rackspace sells support. Customers are free to enable/disable/change whatever they want, with the understanding that it will limit the ability to directly support their instances. That decision is up to each customer, but our default is to build in the support mechanism. Other OpenStack deployments will choose to do things quite differently, I'm sure. It's even likely that in the future Rackspace may add a secure option like you describe, but for now we're focusing on parity with the current Cloud Servers product, and that includes password injection at creation. -- Ed Leafe -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OS API server password generation
So why don't we give the provider root access to our machines? Because there's a line between what is our responsibility and what is that of the provider. Agents need to be invited elements, not required elements. -George On Mar 3, 2011, at 12:36 PM, Ewan Mellor wrote: The hypervisor can set your VM's memory or disk contents to anything it likes, set your registers to anything it likes, read all of memory, disk, and network, or even redirect you to a malicious TPM. If you are going to execute code on a VM in the cloud, then you _have_ to trust the service provider -- no crypto in the world can protect you. In-guest agents just make it easier to do things, and they make it more transparent to the customer what we're doing and how. There's no fundamental change in trust by having them. Ewan. -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of George Reese Sent: 03 March 2011 15:36 To: Ed Leafe Cc: Openstack; Mark Washenberger Subject: Re: [Openstack] OS API server password generation I don't agree with this approach. The current Cloud Servers approach is flawed. I wrote about this a year ago: http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html It's a mistake to send OpenStack pursuing a flaw in Cloud Servers. -George On Mar 3, 2011, at 9:32 AM, Ed Leafe wrote: On Mar 3, 2011, at 8:40 AM, George Reese wrote: Any mechanism that requires an agent or requires any ability of the hypervisor or cloud platform to inject a password creates trust issues. In particular, the hypervisor and platform should avoid operations that reach into the guest. The guest should have the option of complete control over its data. Please understand that this is a Rackspace-specific use case. It is not an OpenStack standard by any means. That's why this action is in a specific agent, not in the main OpenStack compute codebase. On an OpenStack list, we should be discussing the OpenStack code, not Rackspace's customization of that code for our use cases. Rackspace sells support. Customers are free to enable/disable/change whatever they want, with the understanding that it will limit the ability to directly support their instances. That decision is up to each customer, but our default is to build in the support mechanism. Other OpenStack deployments will choose to do things quite differently, I'm sure. It's even likely that in the future Rackspace may add a secure option like you describe, but for now we're focusing on parity with the current Cloud Servers product, and that includes password injection at creation. -- Ed Leafe -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217 f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ 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] OS API server password generation
Let me put this another way. You have an option of two methods: one more intrusive and one less intrusive. The more intrusive approach gives the owner of the guest less control and is less transparent. The less intrusive approach gives the guest owner more control and is more transparent. Why opt for the more intrusive option? -George On Mar 3, 2011, at 1:22 PM, Rick Clark wrote: On 03/03/2011 12:40 PM, George Reese wrote: So why don't we give the provider root access to our machines? to be fair, a provider owns the hypervisor and storage, I would always assume providers have root equivalent access if they want it. Because there's a line between what is our responsibility and what is that of the provider. Agents need to be invited elements, not required elements. Agreed. But it is acceptable to require an agent for certain features a provider offers, i.e. password changes or support access. In the end, we can't force anyone to run an agent anyway . -George On Mar 3, 2011, at 12:36 PM, Ewan Mellor wrote: The hypervisor can set your VM's memory or disk contents to anything it likes, set your registers to anything it likes, read all of memory, disk, and network, or even redirect you to a malicious TPM. If you are going to execute code on a VM in the cloud, then you _have_ to trust the service provider -- no crypto in the world can protect you. In-guest agents just make it easier to do things, and they make it more transparent to the customer what we're doing and how. There's no fundamental change in trust by having them. Ewan. -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of George Reese Sent: 03 March 2011 15:36 To: Ed Leafe Cc: Openstack; Mark Washenberger Subject: Re: [Openstack] OS API server password generation I don't agree with this approach. The current Cloud Servers approach is flawed. I wrote about this a year ago: http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html It's a mistake to send OpenStack pursuing a flaw in Cloud Servers. -George On Mar 3, 2011, at 9:32 AM, Ed Leafe wrote: On Mar 3, 2011, at 8:40 AM, George Reese wrote: Any mechanism that requires an agent or requires any ability of the hypervisor or cloud platform to inject a password creates trust issues. In particular, the hypervisor and platform should avoid operations that reach into the guest. The guest should have the option of complete control over its data. Please understand that this is a Rackspace-specific use case. It is not an OpenStack standard by any means. That's why this action is in a specific agent, not in the main OpenStack compute codebase. On an OpenStack list, we should be discussing the OpenStack code, not Rackspace's customization of that code for our use cases. Rackspace sells support. Customers are free to enable/disable/change whatever they want, with the understanding that it will limit the ability to directly support their instances. That decision is up to each customer, but our default is to build in the support mechanism. Other OpenStack deployments will choose to do things quite differently, I'm sure. It's even likely that in the future Rackspace may add a secure option like you describe, but for now we're focusing on parity with the current Cloud Servers product, and that includes password injection at creation. -- Ed Leafe -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217 f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack
