Re: [Openstack] Name it Hood!
From: Monty Taylor mord...@inaugust.com f) Hood is only 4 letters. Think about that when you think about typing hatfield a lot. Also, if we name it hatfield, we're going to have to have the M summit somewhere that has a town called McCoy. There's a McCoy in Virginia. Sorry, but being able to use Hatfield and McCoy is just too good to pass up. :-) -Doug___ 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] delete a wiki id
when I first created by Wiki id I messed up and I need to erase it to start over - but I don't see any option to do that. Does someone have a URL to a page that will let me do that? 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.___ 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] summit web site down?
I was trying to find the name of the person who ran one of the sessions at the San Diego summit, but the session [1] doesn't list the name of the moderator (this would probably be a good thing to require for session description for the next summit). And so I then thought I might be able to find it via summit session proposal site [2] but that appears to be down. What is the best way to track down the names of the moderators of each session? thanks -Doug [1] http://openstacksummitfall2012.sched.org/event/3bc5e12963c0d9a98c134dcdd2e816b4#.UJKPu67IvYU [2] http://summit.openstack.org/___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] summit web site down?
Perfect - found it! thanks! 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. From: Thierry Carrez thie...@openstack.org To: openstack@lists.launchpad.net, Date: 11/01/2012 12:33 PM Subject:Re: [Openstack] summit web site down? Sent by:openstack-bounces+dug=us.ibm@lists.launchpad.net Doug Davis wrote: I was trying to find the name of the person who ran one of the sessions at the San Diego summit, but the session [1] doesn't list the name of the moderator (this would probably be a good thing to require for session description for the next summit). And so I then thought I might be able to find it via summit session proposal site [2] but that appears to be down. What is the best way to track down the names of the moderators of each session? yes we'll include them as a comment next time. To solve your issue, I started up the site again. FWIW it will be brought down in the future, but let's just wait for the Grizzly planning to be completed first :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp inline: graycol.gif___ 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] Compute API behavior
Agreed - the resources used to create a server should be copied into the server's data if those resources can be deleted (or even modified independently of the servers using them). 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. From: Luis Gervaso l...@woorea.es To: openstack@lists.launchpad.net, Date: 10/04/2012 10:10 AM Subject:[Openstack] Compute API behavior Sent by:openstack-bounces+dug=us.ibm@lists.launchpad.net Hi, I have found an use case which breaks the compute api. May be I'm not doing the stuff in the right way. Anyway I want to share with you. 1. Supose I create a server with an image and flavor. 2. Then I delete the image or flavor. 3. Now, when I list the server the image/flavor associated with the server is not found (actually the api returns a link to image/flavor that no longer exists) I think the link is not the correct way to store these info of a server. The links (following HATEOAS) should be for actions performed on a server: let's say reboot, pause, show console and so on ... Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 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 inline: graycol.gif___ 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-dev] [nova] Call for Help -- OpenStack API XML Support
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. 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. 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. 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 XML Support 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 cal: http://tungle.me/GeorgeReese ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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
On the flip side - to refresh people's memory it might be useful to send out a link to some of the email threads (or wikis) that explained why this move is critical to OS's success. Perhaps some of those reasons aren't as valid any more given the impact people are now seeing it will have. Never hurts to measure again before you cut :-) 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. Stefano Maffulli stef...@openstack.org Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 07/12/2012 06:38 PM To openstack@lists.launchpad.net cc Subject Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom [launchpad is slow at delivering messages to the list. Please everybody keep it in mind and slow down your replies too to give people the chance to comment, too.] On 07/12/2012 12:47 PM, Matt Joyce wrote: Yes we maintain v2 api compatibility but there will be a cost to users in the confusion of decisions like this. Any change has costs, all decisions are the result of compromises. I'm sure you all know this, it's a fact of life. We can't change that fact but we can change how we get to an agreement of what compromise is acceptable. From what I understand, some people are regretting the decision to create cinder. We should start from the beginning then: How many people regret the decision to start cinder? Where were you when the decision was taken? What prevented you to speak up then? I'd appreciate your answers to these questions and your suggestions on how to modify the decision-making process (if you think it's broken). thanks, 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 ___ 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
+1 to option 1, rip the band-aid off quickly :-) -Doug -Original Message- From: openstack-bounces+gregory_althaus=dell@lists.launchpad.net [mailto:openstack-bounces+gregory_althaus=dell.com@lists.launchpad. net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, July 11, 2012 10:27 AM To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom 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 ___ 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 and asynchronous instance launching
Right - examining the current state isn't a good way to determine what happened with one particular request. This is exactly one of the reasons some providers create Jobs for all actions. Checking the resource later to see why something bad happened is fragile since other opertaons might have happened since then, erasing any error message type of state info. And relying on event/error logs is hard since correlating one particular action with a flood of events is tricky - especially in a multi-user environment where several actions could be underway at once. If each action resulted in a Job URI being returned then the client can check that Job resource when its convinient for them - and this could be quite useful in both happy and unhappy situations. And to be clear, a Job doesn't necessarily need to be a a full new resource, it could (under the covers) map to a grouping of event logs entries but the point is that from a client's perspective they have an easy mechanism (e.g. issue a GET to a single URI) that returns all of the info needed to determine what happened with one particular operation. 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. Eoghan Glynn egl...@redhat.com 06/29/2012 06:00 AM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.net, Jay Pipes jaypi...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. So the latter approach at least provides a way to poll on the resource status, so as to figure out if and when it becomes usable. In the happy-path, eventually the instance status transitions to ACTIVE and away we go. However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? For example even just an indication that failure occurred in the scheduler (e.g. resource starvation) or on the target compute node. Is the thought that such information may be operationally sensitive, or just TMI for a typical cloud user? Cheers, Eoghan ___ 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 and asynchronous instance launching
You don't really expect a client (think ec2-like-user) to analyze debug info do you? I really think we need a nice consistent way for people to see what's going on with long-running operations. Debug info isn't that to me. 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. Jay Pipes jaypi...@gmail.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/29/2012 01:46 PM To Huang Zhiteng winsto...@gmail.com cc openstack@lists.launchpad.net Subject Re: [Openstack] Nova and asynchronous instance launching On 06/29/2012 04:25 AM, Huang Zhiteng wrote: Sound like a performance issue. I think this symptom can be much eased if we spend sometime fixing whatever bottleneck causing this (slow AMQP, scheduler, or network)? Now that Nova API has got multprocess enabled, we'd move to next bottleneck in long path of 'launching instance'. Devin, is it possible that you provide more details about this issue so that someone else can reproduce it? Actually, Vish, David Kranz and I had a discussion about similar stuff on IRC yesterday. I think that an easy win for this would be to add much more fine-grained DEBUG logging statements in the various nova service pieces -- nova-compute, nova-network, etc. Right now, there are areas that seem to look like performance or locking culprits (iptables save/restore for example), but because there isn't very fine-grained logging statements, it's tough to say whether: a) A process (or greenthread) has simply yielded to another while it waits for something b) A process is doing something that is blocking or c) A process is doing some other work but no log statements are being logged about that work, which makes it seem like some other work is taking much longer than it really is This would be a really easy win for a beginner developer or someone looking for something to assist with -- simply add informative LOG.debug() statements at various points in the API call pipelines Best, -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] Nova and asynchronous instance launching
True that's all useful info but I thought the original problem being addressed was how the end-user could know what's going on for long-running ops. 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. Jay Pipes jaypi...@gmail.com 06/29/2012 06:03 PM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.net, Huang Zhiteng winsto...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching I'm not expecting a client to do anything, and I'm not sure where you got that from my response below... I'm talking about adding debug statements into the nova-compute/nova-network logs that an *operator* or *core developer* would use to determine which parts of the code are taking that most amount of time. -jay On 06/29/2012 05:45 PM, Doug Davis wrote: You don't really expect a client (think ec2-like-user) to analyze debug info do you? I really think we need a nice consistent way for people to see what's going on with long-running operations. Debug info isn't that to me. 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. *Jay Pipes jaypi...@gmail.com* Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/29/2012 01:46 PM To Huang Zhiteng winsto...@gmail.com cc openstack@lists.launchpad.net Subject Re: [Openstack] Nova and asynchronous instance launching On 06/29/2012 04:25 AM, Huang Zhiteng wrote: Sound like a performance issue. I think this symptom can be much eased if we spend sometime fixing whatever bottleneck causing this (slow AMQP, scheduler, or network)? Now that Nova API has got multprocess enabled, we'd move to next bottleneck in long path of 'launching instance'. Devin, is it possible that you provide more details about this issue so that someone else can reproduce it? Actually, Vish, David Kranz and I had a discussion about similar stuff on IRC yesterday. I think that an easy win for this would be to add much more fine-grained DEBUG logging statements in the various nova service pieces -- nova-compute, nova-network, etc. Right now, there are areas that seem to look like performance or locking culprits (iptables save/restore for example), but because there isn't very fine-grained logging statements, it's tough to say whether: a) A process (or greenthread) has simply yielded to another while it waits for something b) A process is doing something that is blocking or c) A process is doing some other work but no log statements are being logged about that work, which makes it seem like some other work is taking much longer than it really is This would be a really easy win for a beginner developer or someone looking for something to assist with -- simply add informative LOG.debug() statements at various points in the API call pipelines Best, -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] Nova and asynchronous instance launching
Understood but I'd rather solve this more generically once instead of each possible async op doing its own thing. I like consistency :-) Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. 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. Jay Pipes jaypi...@gmail.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/28/2012 12:01 PM To openstack@lists.launchpad.net cc Subject Re: [Openstack] Nova and asynchronous instance launching On 06/27/2012 06:51 PM, Doug Davis wrote: Consider the creation of a Job type of entity that will be returned from the original call - probably a 202. Then the client can check the Job to see how things are going. BTW - this pattern can be used for any async op, not just the launching of multiple instances since technically any op might be long-running (or queued) based on the current state of the system. Note that much of the job of launching an instance is already asynchronous -- the initial call to create an instance really just creates an instance UUID and returns to the caller -- most of the actual work to create the instance is then done via messaging calls and the caller can continue to call for a status of her instance to check on it. In this particular case, I believe Devin is referring to when you indicate you want to spawn a whole bunch of instances and in that case, things happen synchronously instead of asynchronously? Devin, is that correct? If so, it seems like returning a packet immediately that contains a list of the instance UUIDs that can be used for checking status is the best option? Or am I missing something here? -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] Nova and asynchronous instance launching
Consider the creation of a Job type of entity that will be returned from the original call - probably a 202. Then the client can check the Job to see how things are going. BTW - this pattern can be used for any async op, not just the launching of multiple instances since technically any op might be long-running (or queued) based on the current state of the system. 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. Devin Carlen de...@openstack.org Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/27/2012 03:53 PM To openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net cc Subject [Openstack] Nova and asynchronous instance launching We filed a blueprint for this yesterday: https://blueprints.launchpad.net/nova/+spec/launch-instances-async Currently if a user attempts to create a lot of instances with a single API call (using min_count) the request will hang for a long time while all RPC calls are completed. For a large number of instances this can take a very long time. The API should return immediately and asynchronously make RPC calls. We are looking for creative ways to work around this problem, but in the meantime I'd like to hear from folks on what they think the preferred solution would be. Devin___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] WADL [was: v3 API draft (update and questions to the community)]
I don't see this as an either-or type of thing. Totally agree with Mark that the APIs need to be more clearly documented and that should be independent of any kind of IDL (ala WADL) artifact. I say this mainly because I think we always need to have something that's human readable and not machine readable. There will always be semantics that can not be expressed via the machine readable artifacts. Having said that, there are people that like to have IDL-like artifacts for some kind of tooling. So, along with the well-documented APIs should be whatever artifacts that can makes people's lives easier. This means XSD, WASL, WSDL, etc... whatever - pick your favorite. No matter what artifact you choose to use to guide your coding (even if its just the well documented human readable API doc), you're still bound to that particular version of the APIs. Which means a change in the APIs/server-code might break your client. In this respect I don't think WADL or docs are more or less brittle than the other. To me the key aspects are the extensibility points. Once the APIs are deemed 'stable', we just need to make sure that new stuff is backwards compatible which usually means defining and leveraging well placed extensibility points. 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. Mark Nottingham m...@mnot.net Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/14/2012 08:20 PM To Nguyen, Liem Manh liem_m_ngu...@hp.com cc openstack@lists.launchpad.net openstack@lists.launchpad.net Subject [Openstack] WADL [was: v3 API draft (update and questions to the community)] Hi Liem, I'm one of the folks who helped Marc get WADL off of the ground. At the time, my use cases were exactly as you describe: documentation (e.g., https://github.com/mnot/wadl_stylesheets) and testing. Even back then, there was a lot of discussion in the community; e.g., see: http://bitworking.org/news/193/Do-we-need-WADL http://old.nabble.com/Is-it-a-good-idea-to-make-your-WADL-available--tc6087155r1.html http://www.25hoursaday.com/weblog/CommentView.aspx?guid=f88dc5a6-0aff-44ca-ba42-38c651612092 I think many of the concerns that were expressed then are still valid -- some even within these limited uses. In no particular order: * People can and will use WADL to represent a contract to a service (really, an IDL), and bake client code to a snapshot of it in time. While it's true that the client and server need to have agreement about what goes on the wire and what it means, the assumptions around what guarantees WADL makes are not well-thought-out (in a manner similar to WSDL), making clients generated from it very tightly bound to the snapshot of the server they saw at some point in the past. This, in turn, makes evolution / extension of the API a lot harder than it needs to be. * WADL's primitives are XML Schema datatypes. This is a horrible match for dynamic languages like Python. * WADL itself embodies certain patterns of use that tend to show through if you design for it; these may or may not be the best patterns for a particular use case. This is because HTTP and URLs are very flexible things, and it isn't expressive enough to cover all of that space. As a result, you can end up with convoluted APIs that are designed to fit WADL, rather than do the task at hand. From what I've seen, many developers in OpenStack are profoundly uninterested in working with WADL. YMMV, but AFAICT this results in the WADL being done by other folks, and not matching the reality of the implementation; not a good situation for anyone. What we need, I think, is a specification of the API that's precise, unambiguous, and easy to understand and maintain. I personally don't think WADL is up to that task (at least as a primary artefact), so (as I mentioned), I'm going to be proposing another approach. Cheers, On 15/06/2012, at 2:08 AM, Nguyen, Liem Manh wrote: IMHO, a well-documented WADL + XSD would say a thousand words (maybe more)... And can serve as a basis for automated testing as well. I understand that the v3 API draft is perhaps not at that stage yet; but, would like to see a WADL + XSD set as soon as the concepts are solidified. Liem -Original Message- From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Tuesday, June 12, 2012 8:43 PM To: Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community) On 13/06/2012, at 1:24 PM, Gabriel Hurley wrote: Totally agree with all of Jay's points, and I also couldn't agree more with Mark on the importance of being crystal
Re: [Openstack] hidden / phasing out instance_types/flavors
Just wondering, is there any reason flavors are not limited to just create-time? Meaning, use it to create a new instance and then copy all of the flavor data into the new instance's data. This breaks the relationship between the instance and the flavor, allow each to be changed independently - or even deleted. Doing this would mean you wouldn't need to add a disabled flag at all - just delete the flavor if you don't want anyone to use it. This would also allow for an easier modification of existing instances - just modify the instance's property that needs to change w/o creating a whole new flavor (avoids the proliferation of flavors too). 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. Matthew Sherborne matt.sherbo...@rackspace.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/01/2012 10:41 AM To openstack@lists.launchpad.net cc Subject [Openstack] hidden / phasing out instance_types/flavors Hi Openstack community, We recently uploaded this change: https://review.openstack.org/#/c/8007/ It adds a 'disabled' field to the 'instance_type' or 'flavor' concept. The usage scenario we had in mind was to phase out a flavor that's already in use; people shouldn't be able to build new instances from that flavor, nor should customers see it in the list of available flavors. But when they view an existing instance with that flavor type, they should still be able to see the name of it at least. But should you change your mind later and wish to re-enable it, it's easy to just flip the flag. We'd appreciate feedback on the added field and the use of the namespace in the core code. (Line 56 here: https://review.openstack.org/#/c/8007/1/nova/api/openstack/compute/views/flavors.py ) The reasoning behind this is: * If we did it as an extension, it would greatly complicate the code. The code is much simpler being right in the core code. * We can't just add a field to the API quickly, so we need to use the namespace. * The hope is that eventually it would be accepted into the main API anyway, then the coding would be just removing the namespace. Many thanks in for reading. All feedback appreciated. Kind Regards, Matthew Sherborne___ 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] hidden / phasing out instance_types/flavors
Glad to hear that. Just FYI, CIMI [1] does this type of thing so if we ever do manage to harmonize the two APIs this might be a good place to start. [1] http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0d.pdf 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. Chris Behrens cbehr...@codestud.com 06/01/2012 02:42 PM To Doug Davis/Raleigh/IBM@IBMUS cc Chris Behrens cbehr...@codestud.com, Matthew Sherborne matt.sherbo...@rackspace.com, openstack@lists.launchpad.net Subject Re: [Openstack] hidden / phasing out instance_types/flavors Doug, That's the behavior I'd like to see and think it makes the most sense. It's really a requirement if we want a great cells implementation. instance_types table should only be used at the top level API cell. The data contained in the table is passed in the messaging and stored with the newly built, re-built, or re-sized instance. I brought this up a couple days ago internally at Rackspace while this current patch was being developed and I think we were going to start to look at that next?. assuming everyone loves the idea. :) - Chris On Jun 1, 2012, at 9:54 AM, Doug Davis wrote: Just wondering, is there any reason flavors are not limited to just create-time? Meaning, use it to create a new instance and then copy all of the flavor data into the new instance's data. This breaks the relationship between the instance and the flavor, allow each to be changed independently - or even deleted. Doing this would mean you wouldn't need to add a disabled flag at all - just delete the flavor if you don't want anyone to use it. This would also allow for an easier modification of existing instances - just modify the instance's property that needs to change w/o creating a whole new flavor (avoids the proliferation of flavors too). 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. Matthew Sherborne matt.sherbo...@rackspace.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/01/2012 10:41 AM To openstack@lists.launchpad.net cc Subject [Openstack] hidden / phasing out instance_types/flavors Hi Openstack community, We recently uploaded this change: https://review.openstack.org/#/c/8007/ It adds a 'disabled' field to the 'instance_type' or 'flavor' concept. The usage scenario we had in mind was to phase out a flavor that's already in use; people shouldn't be able to build new instances from that flavor, nor should customers see it in the list of available flavors. But when they view an existing instance with that flavor type, they should still be able to see the name of it at least. But should you change your mind later and wish to re-enable it, it's easy to just flip the flag. We'd appreciate feedback on the added field and the use of the namespace in the core code. (Line 56 here: https://review.openstack.org/#/c/8007/1/nova/api/openstack/compute/views/flavors.py ) The reasoning behind this is: * If we did it as an extension, it would greatly complicate the code. The code is much simpler being right in the core code. * We can't just add a field to the API quickly, so we need to use the namespace. * The hope is that eventually it would be accepted into the main API anyway, then the coding would be just removing the namespace. Many thanks in for reading. All feedback appreciated. Kind Regards, Matthew Sherborne___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Third Party APIs
Vish wrote on 05/17/2012 02:18:19 PM: ... 3 Feature Branch in Core We are doing some work to support Feature and Subsystem branches in our CI system. 3rd party apis could live in a feature branch so that they can be tested using our CI infrastructure. This is very similar to the above solution, and gives us a temporary place to do development until the internal apis are more stable. Changes to internal apis and 3rd party apis could be done concurrently in the branch and tested. can you elaborate on this last sentence? When you say changes to internal apis do you mean in general or only when in the context of those 3rd party APIs needing a change? I can't see the core developers wanting to do internal API changes in a 3rd party api branch. I would expect 3rd party api branches to mainly include just stuff that sits on top of the internal APIs and (hopefully very few) internal API tweaks. Which to me means that these 3rd party API branches should be continually rebased off of the trunk to catch breaking changes immediately. If I understand it correctly, of those options, I like option 3 because then the CI stuff will detect breakages in the 3rd party APIs right away and not until some later date when it'll be harder to fix (or undo) those internal API changes. -Doug Davis d...@us.ibm.com___ 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] 3rd Party APIs
Mark McLoughlin wrote on 05/08/2012 10:58:45 AM: ... What I'd like to see us get to is: Deep overlap between the OpenStack developer community and the community of folks drafting whatever IaaS standard(s) wind up being dominant. e.g. prominent, active Nova developers developers contributing to the CIMI or OCCI standards and bringing the needs of OpenStack to the standard and bringing ideas from the standards process to OpenStack. This isn't a question of asking existing OpenStack developers to join these standards bodies. It's about enabling members of those standards bodies to become as much a part of OpenStack as any other developer. How to do that? Encourage members the various standards communities to actively contribute an implementation of their standard to OpenStack and, more importantly, stick around to become an ongoing active member of the OpenStack developer community. While the issue of what goes into the core vs is a plug-in is certainly an important one, I think the above touches on a higher-order issue that I think is just as important. And it's around the proliferation of IaaS APIs. Certainly each IaaS author is going to favor their own APIs - as expected. As a result there will be resistance to adopt, or even look at, others. They will also try to push their favorite IaaS API on others. In the end though, and this may be hard for some to believe :-), it's just an API. What matters more is the functionality behind the APIs. E.g. we all have our favorite API to mock and yet there are people out there using it. Why? Because they want the features behind it despite any odd use of HTTP/REST. One of the first things we noticed in our CIMI work was that pretty much every IaaS input contribution was basically the same - not syntactically but semantically. This made our lives so much easier. It's also evidenced by the fact that adapter projects (like DeltaCloud) can exist. If there wasn't semantic similarities between all of those IaaS providers then I doubt DC would be able to work. So, why am I bringing this up? Because while I agree with Mark that getting standards folks into OS is a good idea, I think having it be a good two-way communication is even better. Meaning, I think it would be good for Nova folks to find a way to influence the standards too. Just as I'm sure some Nova guys are already running from their keyboards at the prospect of talking to standards weenies :-) I know there are plenty of standards folks who will never join Openstack (for a variety of technical and business reasons). Yet for the sake of the broader community I think we need to find a way to make them work together. Additionally, and now the hard part, I think it would be good for people to realize that there is a spot in the middle where both sides can meet. Having looked at a variety of IaaS APIs, and more recently looking at how CIMI can map to Nova, I'm (again) struck at how similar they are. And if I were to play God for a moment, I'd slap both sides upside their heads and tell them to each bend a little and find a spot in the middle. CIMI can change, and Nova can change - after all, it's just an API. With the recent folks that joined Openstack, the amount of overlap between CIMI authors and Openstack members is actually quite large. Just off the top of my head (and this is just me talking, I have no idea how any of these folks feel about this), but there's RedHat, HP, Rackspace, IBM, Cisco, Dell and I'm sure others. I'm pretty sure that folks from those companies would be willing to help bridge the communications between the standards folks and the Openstack folks - thus allowing the OS devs who want to avoid standards bodies to do so, but still have a voice over there. Or at least, speaking just for myself, I'd be more than happy to work to make that happen - been doing it already for a while behind the scenes. But course, this would require at least some commitment from the various Openstack groups to entertain the idea of this collaboration. At a minimum it means both sides being willing to see what the other has and to offer suggestions on how to find that middle ground. I'd be more than willing to help get those harmonization discussions going but only if there's interest. May not be the easiest thing, but I also don't see it is as that hard either, once a decision to explore that option is made. Just my 2 cents... -Doug Davis d...@us.ibm.com ___ 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] Canonical AWSOME
+1 if you want people to care about something then it should be part of the main repo and part of the regular regression testing. 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. Russell Bryant rbry...@redhat.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 04/23/2012 02:16 PM To openstack@lists.launchpad.net cc Subject Re: [Openstack] Canonical AWSOME On 04/23/2012 10:42 AM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. This makes sense. It also makes project management easier, as the people interested in maintaining it can focus on the separate repository. I'm not sure I buy into this, though. Why is it harder for people that are interested in EC2 support to work in the existing nova repo? If people want to collaborate before pushing into mainline, that can be done via feature branches, too. It risks making EC2 development harder, as well. Pulling it out of nova completely risks allowing the people that don't care about EC2 to care even less. It could make it easier for people to make changes that make EC2 compatibility harder to maintain. -- Russell Bryant ___ 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] Just JSON, and extensibility
Mark Nottingham wrote on 04/13/2012 12:56:46 PM: In particular, if people are actually using these tools to do data binding, it's going to lead them to place dependencies upon the structure of our interfaces, and unless the scheme is constructed *exactly* right, we'll get lots of bug reports in the future when these tools base their contracts on their interpretation of a Schema that got published on the Web site at some point in the past. Be a bit careful here. If you're suggesting that JSON is better because it doesn't force (or even give you the option) of being precise in what your interfaces looks like, implying that you won't get bug reports when the JSON changes, I think this is probably wrong. IMO, the stuff around XML like XSDs (and I include in this topic things like IDLs) just makes it easier for people to write tooling if they want. But in the end, changing an interface is just as brittle regardless of whether its in XML or JSON - both have extensibility points and both will have clients that will break with the 'expected' data goes missing. IMO, both JSON and XML have their places. And I do agree with Mark on one key thing... don't add all of the stuff to JSON that people claimed was too heavy in XML. And, to me, this includes namespaces. In the end, once you start down that road you'll just end up with a curl-braced version of XML and won't we look silly at that point. :-) Earlier you said: It's not that just our dev community isn't seeing much value in XML, it's a good portion of the world. Again, this needs to be weighed very carefully. With emerging technologies its easy to assume that the entire world agrees with you while things are still too new to be part of the mainstream. This xml vs json fight has been going on for a while, and I've heard a number of times from a number of different companies that they will not touch JSON simply because its too new, too unstructured, doesn't have the tooling and validation capabilities of XML, blah blah blah. Now, ideally these same folks should be speaking up in the community to express their concerns and desires, but for whatever reason they may not choose to - or can't. Now, I'm not suggesting that we MUST keep XML just to satisfy people who choose not to participate in OS, rather I want the decision to be made with all of the implications considered. And to me, knowing that Openstack might not be as easy a sell to some folks because their shop is so heavily invested in XML and not JSON (when, IMO, support for both isn't that hard - its just a matter of making it part of the normal code development/approval process) seems like it might be a mistake - at least given the current state of the world. After all, if XML were really as dead as some people imply I doubt we would even be having this conversation. -Doug___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
