[Openstack] Can someone test this issue about token in keystone
I use a token ), tht last char is ), then when I logon dashboard to instances or images or keypairs web. it occurs: Unable to get instance list: 401 Unauthorized This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required. when I use another server token, it works well. -- 非淡薄无以明志，非宁静无以致远 ___ 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] Glance and configuration files handling
Hi there, As far as I understand, each Glance app uses its own configuration file. However, it seems to me that it induces a couple of weird things. Today, I started taking a look on images cache and prefetch stuff, and bumping my head on the wall because something was not working. Then I discovered that the variable image_cache_enabled was set to true in glance-api.conf, but was not set at all in glance-prefetcher.conf, defaulting to false. The same applies for the reaper and the pruner AFAICS. It does not seem really obvious and user friendly to set the same variable in multiple files, and it even seems kind of dangerous and non sensical, since you can set conflicting values. I think that Glance and its different services should only use on file to be configured, using subsection to configure specific app variable (service port, host, etc). WDYT? -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] How to backup instances and restore it in another storage
I have just installed nova/glance/keystone/dashboard on one controller and compute/network nodes. Images and instances are stored in local disk. I know the instances are (base image + Copy-On-Write) files. Which file should I backup that are enough to restore a instance in another disk? If my machine disk is broken, I hope to restore instances on another node. 非淡泊無以明志，非寧靜無以致遠 ___ 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
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
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] Guidelines for OpenStack APIs
On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham m...@mnot.net wrote: +1 (sorry for the lag, been travelling). I'd like to start two wiki pages; one collecting goals for the APIs, one for collecting common patterns of use in the APIs (not rules, not even guidelines). Maybe split each one into proposed and agreed so that we can keep track of whether there's agreement. Make sense? Very much so. ++ Go ahead and create the wiki pages, outline them and/or add prior suggestions, and we'll take it from there :) Cheers, -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
[Openstack] Reminder: OpenStack team meeting - 21:00 UTC
Hello everyone, Our first post-design-summit meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. PTLs, if you can't make it, please name a substitute on [2]. We'll discuss the final Essex release schedule, get early status on the Essex themes and blueprints for all core projects, and give feedback on the design summit format. Check out how that meeting time translates for *your* timezone: [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111011T21 See the meeting agenda, edit the wiki to add new topics for discussion: [2] http://wiki.openstack.org/Meetings/TeamMeeting Cheers, -- 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
Re: [Openstack] Can someone test this issue about token in keystone
I filed this as a bug. We'll need to fix it so special characters get encoded correctly: https://bugs.launchpad.net/keystone/+bug/872287 Thanks, Ziad From: DeadSun mwjpi...@gmail.commailto:mwjpi...@gmail.com Date: Tue, 11 Oct 2011 16:29:21 +0800 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Can someone test this issue about token in keystone I use a token ), tht last char is ), then when I logon dashboard to instances or images or keypairs web. it occurs: Unable to get instance list: 401 Unauthorized This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required. when I use another server token, it works well. -- 非淡薄无以明志，非宁静无以致远 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API Versioning Conventions
Hi Brian, I think the versioning rules below are fine, but there are some other things to think about: - As others raised, what version (if any) should be in the URIs? We could put the full version number in the URIs so long as we maintain support for the older, compatible versions i.e. the current version is 1.5.3 but clients can still use the 1.4.0, 1.5.2 etc. URIs The only problem I see with that is that it might appear like clients connecting to the 1.4.0 URI should expect only the features that were available in 1.4.0. If we're not going to make it so new features are only exposed to clients requesting the new version, then just including the major version number in the URI is probably the most sane. - Version numbers aren't necessarily the best way to advertise the availability of features - if we made clients query for the availability of the features they're using, you could version the features independently. For example, if we decide we must make an incompatible change to some obscure feature, wouldn't it be nice to version the feature rather than bump the major version of the API. Also, it allows the API to have optional features that not all service providers support. In the API for RHEV-M/oVirt, we went for this approach - all collections are discoverable by link relationships and, if we must make incompatible changes, we will version those relationships. Cheers, Mark. On Mon, 2011-10-10 at 09:55 -0400, Brian Waldon wrote: In talking with several people at the Design Summit about the OpenStack Compute API, I have come to the conclusion that our current method of versioning is broken. I would like to propose that as we move forward, we adopt the following API versioning conventions: 1) Use a three-part version number: A.B.C, where A is the major version, B is the minor version, and C is the revision number. 2) Disallow backwards incompatible changes to existing interfaces within a major version. This means we cannot rename something such as /servers to /interfaces, or remove the resize action from a server. 3) Increment the minor version at OpenStack releases (Cactus, Diablo, Essex, etc). This is used to indicate the 'regrouping' period around the time of release. It doesn't offer much functionality other than to provide a nice round number that can be easily communicated and used to group features together. 4) Increment the revision number with every addition to the API interface. This allows consumers of the API to get a precise list of supported features at any given time. This also allows operators to continuously deploy the API between major releases and know exactly what featureset they have. When the minor version is increased, we reset the revision number to 0. I would assume that if we do agree on these conventions, they would only be a suggestion, not a requirement. I really want to get this right, so I'm looking forward to everybody's feedback! Thanks! Brian Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Searching Brazilian members
Hi, We work at SERPRO (serpro.gov.br), a Brazilian government TI company and also in the CISL (Brazilian federal government committee for open source implementation). We are organizing an event on next 19 with a full day of talks about free software and private clouds. We are seeking an Openstack expert in Brazil who can contribute talking about openstack in this event. The lectures will be transmitted online and will be available in softwarelivre.gov.br. We believe this initiative can boost the implementation of private clouds using free software in government and industry. Trabalho no SERPRO (serpro.gov.br), uma empresa ligada ao governo Brasileiro e também no CISL (comitê de implementação de software livre do governo federal brasileiro). Estamos organizando um evento neste dia 19 com um dia inteiro de palestras sobre software livre e nuvens privadas. Estamos buscando um especialista em Openstack que esteja no Brasil e possa contribuir com nosso evento realizando uma palestra sobre o assunto. As palestras serão transmitidas por vídeoconferencia e ficaram disponiveis para públicamente no portal softwarelivre.gov.br. Acreditamos que com esta inicativa possamos fomentar a implementação de nuvens privadas utilizando software livre em todas as esferas publicas e privadas. Cheers Alexandre Haguiar Coordenação Estratégica de Tecnologia +55-41-3593-8797 alexandre.agu...@serpro.gov.br @ahaguiar ___ 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] Developer conference documentation
Just added slides for Orchestration and Advanced Scheduling to wiki. (sparse etherpad URL's on title slides) -Sandy From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Salvatore Orlando [salvatore.orla...@eu.citrix.com] Sent: Monday, October 10, 2011 5:37 PM To: Dan Wendlandt; Debo Dutta (dedutta) Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Developer conference documentation One of those folks just filled the details he could fill! Salvatore From: openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: 10 October 2011 18:52 To: Debo Dutta (dedutta) Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Developer conference documentation I'm still waiting for folks to fill in some of the details, but here's a wiki page with pointers to Quantum/NetStack related sessions and presentations at the Essex summit: http://wiki.openstack.org/NetstackEssexSummit Dan On Mon, Oct 10, 2011 at 1:26 PM, Debo Dutta (dedutta) dedu...@cisco.commailto:dedu...@cisco.com wrote: Donabe: http://etherpad.openstack.org/Donabe thx debo -Original Message- From: openstack-bounces+dedutta=cisco@lists.launchpad.netmailto:cisco@lists.launchpad.net [mailto:openstack-bounces+deduttamailto:openstack-bounces%2Bdedutta=cisco@lists.launchpad.netmailto:cisco@lists.launchpad.net] On Behalf Of bob.bl...@calxeda.commailto:bob.bl...@calxeda.com Sent: Monday, October 10, 2011 9:23 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Developer conference documentation Several sessions had slide presentations, but the only one I've been able to find is Geoff Arnold's. Where are they? Also, is there an index of the etherpads from the sessions? Bob Blair ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.comhttp://www.nicira.com | www.openvswitch.orghttp://www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~ This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API Versioning Conventions
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 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 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
Re: [Openstack] OpenStack API Versioning Conventions
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/ ___ 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
Thanks for the feedback, Mark! Comments inline: On Oct 11, 2011, at 9:51 AM, Mark McLoughlin wrote: Hi Brian, I think the versioning rules below are fine, but there are some other things to think about: - As others raised, what version (if any) should be in the URIs? We could put the full version number in the URIs so long as we maintain support for the older, compatible versions i.e. the current version is 1.5.3 but clients can still use the 1.4.0, 1.5.2 etc. URIs The only problem I see with that is that it might appear like clients connecting to the 1.4.0 URI should expect only the features that were available in 1.4.0. If we're not going to make it so new features are only exposed to clients requesting the new version, then just including the major version number in the URI is probably the most sane. This is exactly where I stand. Supporting each minor version has already proven to be a pain, so I would love to *only* support the latest, and the easiest way to communicate this is to use the major version in the URI. - Version numbers aren't necessarily the best way to advertise the availability of features - if we made clients query for the availability of the features they're using, you could version the features independently. For example, if we decide we must make an incompatible change to some obscure feature, wouldn't it be nice to version the feature rather than bump the major version of the API. Also, it allows the API to have optional features that not all service providers support. In the API for RHEV-M/oVirt, we went for this approach - all collections are discoverable by link relationships and, if we must make incompatible changes, we will version those relationships. I think there are two key things here: 1) I think we need to look at Nova as a feature of OpenStack. We version *that* independently from the rest of the suite. 2) We have the concept of extensions (which can be versioned independently from the spec) that provide non-standard functionality through the API. This is how we add optional features within Nova. Cheers, Mark. On Mon, 2011-10-10 at 09:55 -0400, Brian Waldon wrote: In talking with several people at the Design Summit about the OpenStack Compute API, I have come to the conclusion that our current method of versioning is broken. I would like to propose that as we move forward, we adopt the following API versioning conventions: 1) Use a three-part version number: A.B.C, where A is the major version, B is the minor version, and C is the revision number. 2) Disallow backwards incompatible changes to existing interfaces within a major version. This means we cannot rename something such as /servers to /interfaces, or remove the resize action from a server. 3) Increment the minor version at OpenStack releases (Cactus, Diablo, Essex, etc). This is used to indicate the 'regrouping' period around the time of release. It doesn't offer much functionality other than to provide a nice round number that can be easily communicated and used to group features together. 4) Increment the revision number with every addition to the API interface. This allows consumers of the API to get a precise list of supported features at any given time. This also allows operators to continuously deploy the API between major releases and know exactly what featureset they have. When the minor version is increased, we reset the revision number to 0. I would assume that if we do agree on these conventions, they would only be a suggestion, not a requirement. I really want to get this right, so I'm looking forward to everybody's feedback! Thanks! Brian Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. -- 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
Re: [Openstack] Guidelines for OpenStack APIs
On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote: +1 (sorry for the lag, been travelling). I'd like to start two wiki pages; one collecting goals for the APIs, one for collecting common patterns of use in the APIs (not rules, not even guidelines). Yeah, it'd be awesome to have the common patterns described somewhere. It's hard to discuss potential guidelines without a crisp summary of the current patterns employed by the APIs. FWIW, we made some effort to do this for a bunch of related REST APIs. The result is neither complete or perfect, but it's something like what I'd imagine would work well here: http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide Btw, which APIs are we talking about here? Just compute and storage. Or image and identity too? Cheers, Mark. ___ 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] Guidelines for OpenStack APIs
Hi Mark, On Tue, 2011-10-11 at 16:17 +1100, Mark Nottingham wrote: On 19/09/2011, at 4:03 PM, Mark McLoughlin wrote: OTOH, POST to update the object's metadata doesn't make much sense. We don't accept the entity enclosed in the request as a new subordinate. PATCH[1] would probably have made more sense. The spec is actually quite clear on the different between PUT and POST: The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request So, perhaps the guidelines should be: * Either POST or PUT creates things, depending on the meaning of the request URI * PUT or PATCH modifies existing things No, no, no. The definitions of POST and PUT in RFC2616 are more harmful than helpful, and we (the HTTPbis WG in the IETF) have updated them; see http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.5 http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.6 In a nutshell, POST is here, process this while PUT is store this here; both can be used to create things (if they aren't there) or update things (if they are). POST can do anything; there may be another method that has more specific semantics that are appropriate, but because of its escape-hatch nature, there really isn't anything it isn't allowed to do, semantically. We're not attempting to enumerating all the valid ways that POST can be used, we're trying to narrow down those possibilities to a set of guidelines which describe the general style and idioms of OpenStack APIs. Cheers, Mark. ___ 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 Tue, Oct 11, 2011 at 9:56 AM, Brian Waldon brian.wal...@rackspace.com 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. ++ -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
Re: [Openstack] OpenStack API Versioning Conventions
On Tue, 2011-10-11 at 16:40 +0200, Soren Hansen wrote: 2011/10/11 Mark McLoughlin mar...@redhat.com: I think the versioning rules below are fine, but there are some other things to think about: - As others raised, what version (if any) should be in the URIs? We could put the full version number in the URIs so long as we maintain support for the older, compatible versions i.e. the current version is 1.5.3 but clients can still use the 1.4.0, 1.5.2 etc. URIs The only problem I see with that is that it might appear like clients connecting to the 1.4.0 URI should expect only the features that were available in 1.4.0. Why is that a problem? That seems entirely reasonable to me. If a client is written for an old version of the API how would it even know to look for these new concepts/features? Not so much a problem, I guess, as a source of confusion - it's unclear why the service would expose an identical API via multiple URIs Cheers, Mark. ___ 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
Pretending we are talking about User resource for me, kiall for moment.
The v1 API might represent the kiall user resource as {name:kiall} while
the v2 API might represent the kiall user resource as {USERname:kiall}.
The kiall resource has not changed, only the API representation. Hence, a
single URL using headers to determine the resource representation
(json_v1, json_v2, yaml_v1, yaml_v2 etc) is correct IMHO.
Some more info on the general idea:
http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
Thanks,
Kiall
On Tue, Oct 11, 2011 at 3:11 PM, Soren Hansen so...@linux2go.dk 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/
___
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] Searching Brazilian members
Hello Alexandre On Tue, 2011-10-11 at 08:42 -0300, Alexandre Haguiar wrote: We work at SERPRO (serpro.gov.br), a Brazilian government TI company and also in the CISL (Brazilian federal government committee for open source implementation). We are organizing an event on next 19 with a full day of talks about free software and private clouds. We are seeking an Openstack expert in Brazil who can contribute talking about openstack in this event. A chunk of OpenStack developers will be in Sao Paulo at LinuxCon Brazil on November 17-18, but most will be coming from US and a group from Argentina. Do you have more details about the event? I can extend your request to other channels. /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
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] dns issue?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have noticed another weird issue with dnsmasq which might be related to the problem. # tail -1 /etc/nova/nova.conf - --dnsmasq_config_file=/etc/dnsmasq.conf #killall dnsmasq # /etc/init.d/openstack-nova-network restart Stopping OpenStack Nova Network Controller:[ OK ] Starting OpenStack Nova Network Controller:[ OK ] # ps -eaf|grep dnsmasq nobody3385 1 0 12:05 ?00:00:00 dnsmasq --strict-order - --bind-interfaces --conf-file= --domain=novalocal - --pid-file=/local/nova/networks/nova-br100.pid --listen-address=10.0.1.1 - --except-interface=lo --dhcp-range=10.0.1.2,static,120s - --dhcp-lease-max=256 - --dhcp-hostsfile=/local/nova/networks/nova-br100.conf - --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro root 3386 3385 0 12:05 ?00:00:00 dnsmasq --strict-order - --bind-interfaces --conf-file= --domain=novalocal - --pid-file=/local/nova/networks/nova-br100.pid --listen-address=10.0.1.1 - --except-interface=lo --dhcp-range=10.0.1.2,static,120s - --dhcp-lease-max=256 - --dhcp-hostsfile=/local/nova/networks/nova-br100.conf - --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro The --conf-file is not taking the dnsmasq_config_file=/etc/dnsmasq.conf flag. I tried this particular change in another identical machine and was able to update dnsmasq properly after restarting nova-network that is - --conf-file showing the dnsmasq.conf. So something is messed up in this machine. Any other suggestions? - --sharif On 10/10/2011 05:23 PM, Sharif Islam wrote: On 10/10/2011 05:01 PM, Jason Kölker wrote: nameserver 10.0.1.1 How does nova assign the nameserver to the VMs? Can I change it someone so it has 8.8.4.4? I assume you are using Vlan or Flatdhcp? If so add --dns-server=8.8.4.4 to your flags file. The network managers that use dnsmasq do not respect the db entries. Yes, I am using FlatDCHP. I am still using cactus release btw. Unfortunately, this fix didn't work. # cat /etc/nova/nova.conf|grep dns --dns-server=8.8.4.4 I restarted the services. Also deleted the network and created it again just in case. root@i-049d:~# ping google.com ping: unknown host google.com root@i-049d:~# ping 72.14.204.147 PING 72.14.204.147 (72.14.204.147) 56(84) bytes of data. 64 bytes from 72.14.204.147: icmp_req=1 ttl=54 time=33.0 ms 64 bytes from 72.14.204.147: icmp_req=2 ttl=54 time=33.7 ms ^C --- 72.14.204.147 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 33.079/33.394/33.709/0.315 ms root@i-049d:~# cat /etc/resolv.conf domain novalocal search novalocal nameserver 10.0.1.1 # ps -aef|grep dnsmasq nobody9850 1 0 14:32 ?00:00:00 dnsmasq --strict-order --bind-interfaces --conf-file= --domain=novalocal --pid-file=/local/nova/networks/nova-br100.pid --listen-address=10.0.1.1 --except-interface=lo --dhcp-range=10.0.1.2,static,120s --dhcp-lease-max=256 --dhcp-hostsfile=/local/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro root 9851 9850 0 14:32 ?00:00:00 dnsmasq --strict-order --bind-interfaces --conf-file= --domain=novalocal --pid-file=/local/nova/networks/nova-br100.pid --listen-address=10.0.1.1 --except-interface=lo --dhcp-range=10.0.1.2,static,120s --dhcp-lease-max=256 --dhcp-hostsfile=/local/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro --sharif ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp - -- Sharif Islam Senior Systems Analyst/Programmer FutureGrid (http://futuregrid.org) Pervasive Technology Institute, Indiana University Bloomington -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOlGoDAAoJEACffes9SivFCBcH/A2qw9Gw/tsPla0XJa/cjvuK QNhW8xe2FKR52IbbGlCMGjb1+eUQkJ3NfGudcYQJOEPwXLifNWx+IzgeEWIicL+f 0ao41v1IDpP+08n+aFjdwWPCXkmsP8+iSI6+AO7IY814CWVoTBtrvOX8DFPioqGD alwdJ3Sj/6f1fsQAY4J3BzNIrCQweqrzO4flrw8raWqDWHvsfZ/pnvgwIOKvALaj 7sT8kE/xzds6UUu5daikZwKFr4I9rgy8F/dbW6aCqAnrkIaEwUCxlde7vEb5aOyU 0/8+4vfYUcrnGVrSkiRWEX5kpI8T+0TX0B7QHVJ4gB4WVS9Q01xTC4RCwPQtMqQ= =vDlN -END PGP 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
[Openstack] donabe meeting timings on IRC
Hi We are planning to have regular meets/syncups for Donabe. Possible timings include Wed 2pm PST (since 2pm seems to work for openstack meets). Please unicast myself/Rick if you want to participate but this time doesn't work for you ... and please suggest some alternatives. Will do my best to fix a consensus slot. Thx! debo ___ 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] OpenStack Academic Alliance|Circle|Initiative #unconference
hello folks, a group of people interested in academia met in Boston during the unconference. I was there to take notes and facilitate this community run initiative. Here is what we agreed so far. I'm sharing it on the list to gather more ideas. /stef OpenStack Academic Initiative Mission: * provide a place for all research academics efforts can be advertised and found, about and around OpenStack (not generic about IaaS or PaaS) * a list of papers published and ongoing research * a list of conferences about cloud * maintain a list of ideas for the companies to sponsor research like a market * a place for the companies to say what they need and research can execute * undergrad level, gsoc-style, time starved but there are many of them. it's important to be easy for them to contribute * masters level, more in depth work, empirical studies like performance evaluation * phd level, exploratory type of research * handle the funding, hr tasks, mentoring: who's going to manage this? * mentoring is intense and time consuming, but crucial for the success of research * provide resources, like hardware for tests, for researchers * advertise this initiative among researchers * Example: setup OpenStack tracks at a couple of relevant conference Next steps: Identify the group responsible for this initiative and define action items, deadlines and deliverables. ___ 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
That is one case that would require a major version change where a URI is still
valid. However, changes to the URI are still allowed across major versions.
That causes me to think content-types are not good enough to handle versioning.
On Oct 11, 2011, at 11:21 AM, Kiall Mac Innes wrote:
Pretending we are talking about User resource for me, kiall for moment.
The v1 API might represent the kiall user resource as {name:kiall} while
the v2 API might represent the kiall user resource as {USERname:kiall}.
The kiall resource has not changed, only the API representation. Hence, a
single URL using headers to determine the resource representation (json_v1,
json_v2, yaml_v1, yaml_v2 etc) is correct IMHO.
Some more info on the general idea:
http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
Thanks,
Kiall
On Tue, Oct 11, 2011 at 3:11 PM, Soren Hansen so...@linux2go.dk 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/
___
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
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
Re: [Openstack] OpenStack API Versioning Conventions
Ceci n'est pas un pipe. ;) -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Oct 11, 2011, at 11:28 AM, George Reese wrote: 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 ___ 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] Guidelines for OpenStack APIs
++ Like the idea..yes I think we should aim to include all OpenStack APIs -- whatever that means :-) -jOrGe W. On Oct 11, 2011, at 9:52 AM, Jay Pipes wrote: On Tue, Oct 11, 2011 at 10:08 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote: +1 (sorry for the lag, been travelling). I'd like to start two wiki pages; one collecting goals for the APIs, one for collecting common patterns of use in the APIs (not rules, not even guidelines). Yeah, it'd be awesome to have the common patterns described somewhere. It's hard to discuss potential guidelines without a crisp summary of the current patterns employed by the APIs. FWIW, we made some effort to do this for a bunch of related REST APIs. The result is neither complete or perfect, but it's something like what I'd imagine would work well here: http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide Btw, which APIs are we talking about here? Just compute and storage. Or image and identity too? Definitely Images and Identity too. :) -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 This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API Versioning Conventions
Putting the version in the URI is a variant resource just like adding .xml or .json . If you want the ability to get to a specific representation in a browser (as opposed to a custom client) you can't rely on content negotiation because browsers hard code their accepts clause. REST is media type centric and so I agree that the preferred way for a client to get a version it understands should be via content negotiation against unversioned permalinks. I recommend representations generally use unversioned URIs in most links for this purpose. I use rel=bookmark to explicitly mean the unversioned permalink of a resource. It's really easy to write a client this way: the client should look at the version info document and determine the media types the API requires and create client code for those media types and form a static accepts clause for all the media types it supports and navigate around the unversioned links. Browsers can't do this, though. If that's all you do, a developer can't manually inspect payloads in a browser. The versioned variants exist mainly for this purpose. We should STRONGLY discourage clients from persisting versioned links as they will all break over the long haul if we EOL older versions of things. Jorge company have solved how to implement this easily using Repose. It basically rewrites requests, so the service only implements it one way, but you get both for free. On 10/11/2011 08: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 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:
[Openstack] nova-network-INPUT (was Re: dns issue?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As Jorge was pointing out last week (https://lists.launchpad.net/openstack/msg04596.html), the problem seems to be iptables related. When I added these two rules, I was able to ping google.com with 10.0.1.1 as the nameserver. # iptables -I nova-network-INPUT 1 -p tcp --dport 53 -j ACCEPT # iptables -I nova-network-INPUT 1 -p udp --dport 53 -j ACCEPT However, as soon as a new instance starts, these two rules goes away. # iptables -L nova-network-INPUT Chain nova-network-INPUT (1 references) target prot opt source destination ACCEPT udp -- anywhere anywhereudp dpt:domain ACCEPT tcp -- anywhere anywheretcp dpt:domain I start a new instance, few seconds later: # iptables -L nova-network-INPUT Chain nova-network-INPUT (1 references) target prot opt source destination I also have these two rules: # iptables -L -n|grep 67 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:67 # iptables -L -n|grep 53 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:53 Can someone explain how these iptables rule get created? I thought these rules were generated by starting nova-network. I also saw this: https://bugzilla.redhat.com/show_bug.cgi?id=734347. Not sure if this is related. I am running RHEL 6.1. thanks. - --sharif - -- Sharif Islam Senior Systems Analyst/Programmer FutureGrid (http://futuregrid.org) Pervasive Technology Institute, Indiana University Bloomington -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOlJEsAAoJEACffes9SivFivEIAKA17GpyNWZb9cyvsJZhEyLL vdvbRH9ywYHR7GJtHcIt4GnH0jBWR6JbqfviuozIpyYg5f6FkFJ8N1rGUBWFVyE+ obb+fPofq7c5Kb9EbH19pKwkccjomNC55lJBZbX4UUzVsAtGubj3yWdwGeFVMyZX tUwyoylnY+PFE38rQ+FWjIBBPdmBkIRJrXmu9xSqKzYqDbJ3Z/5YLZwdc6dOC6le abchZkbYUI1tCEQoSJHnolzXbhXXoNDivdcqPKJRN2DbuWjvi+unE0yYBzAhtK8Y 1y+0DaJzCaDhNr0focz24fbEdXw/qDCdMm+BeerZSo9+WMV2zyeWhF7EdkO7w24= =BVdE -END PGP 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
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? ___ 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] Searching Brazilian members
Hi Stefano, This event is an iniciative from some friends from SERPRO and CISL to present a day with talks about private clouds with open software. *Event date:* 19/10/2011 *Program* 1 - Connectivity Architecture for Cloud Computing Environments - Herlon Fernandes - 9:00 to 10:00 - São Paulo 2 - Virtualization with Xen - Gunther Boeckmann - 10:00 to 11:00 - Salvador 3 - Infrastructure Management with OpenStack - 11:00 to 12:00 4 - Chef: Framework for automatic provisioning and configuration - Alexandre Haguiar - 13:00 to 14:00 - Curitiba 5 - Tool for monitoring: Zabbix - Rodrigo Hjort - 14:00 to 15:00 - Manaus 6 - Scalr: Tool for management of self-balancing, scaling and monitoring in cloud projects - Fabiano Pereira - 15:00 to 16:00 - Florianopolis 7 - Development for the cloud using jclouds - Allison Wilker - 16:00 to 17:00 - Brasilia All talks will be in portuguese. Our event will be broadcast to several locations where there are SERPRO units and we will have speakers in several locations. We will also have an online broadcast at ( assiste.serpro.gov.br/nuvem2011) and after the event all talks will be available on the site softwarelivre.gov.br (with free license). We are looking for a presenter that speak Portuguese because we do not have translators. The lecture will present all about the Openstack Compute features and how it works inside private clouds. If possible show it running so people can understand what to expect from this system. *Online link* assiste.serpro.gov.br/nuvem2011 *Places to watch the event* Serpro - São Paulo - Auditório da regional Socorro Rua Olívia Guedes Penteado, 941 - Socorro São Paulo - (SP) - CEP: 04766-900 Serpro - Florianopolis - Auditório Rodovia José Carlos Daux (SC 401) Km 01, nº 600, Edifício ALFAMA - 2º andar, Parque Tecnológico ALFA Bairro João Paulo - Florianópolis - SC - CEP: 88030-000 Serpro - Belo Horizonte - Auditório Av. José Cândido da Silveira, 1.200 Cidade Nova Belo Horizonte - MG - CEP: 31035-536 Serpro - Recife - Auditório Av. Parnamirim, 295 Parnamirim - Recife - PE - CEP: 52060-901 Serpro - Curitiba - Auditório Rua Carlos Pioli, 133 Bom Retiro - Curitiba - PR - CEP: 80520-170 Serpro - Fortaleza - Auditório Av. Pontes Vieira, 832 São João do Tauapé - Fortaleza – CEARÁ - CEP: 60130-240 Serpro - Rio de Janeiro / Andaraí - Auditório Rua Duquesa de Bragança nº 100 - Grajaú - Rio de Janeiro - RJ Serpro - Rio de Janeiro / Horto - Auditório Rua Pacheco Leão, 1.235 Fundos - Jardim Botânico - Rio de Janeiro - RJ Serpro - Brasília / Regiona - Auditório SGAN Av.L-2 Norte Quadra 601 – Módulo G - Brasília - DF - CEP: 70830-900 Serpro - Salvador - Auditório Av. Luiz Vianna Filho, 2.355 Paralela - Salvador - BA - CEP: 41130-530 Serpro - Brasília / Sede - Auditório SGAN Av.L-2 Norte Quadra 601 – Módulo G - Brasília - DF - CEP: 70830-900 Serpro - Belém - Auditório Av. Perimetral da Ciência, 2.010 Terra Firme - Belém - PARÁ - CEP: 66077-830 Any help are welcome. Thanks Alexandre Haguiar Coordenação Estratégica de Tecnologia +55 - 41 - 3593-8797 alexandre.agu...@serpro.gov.br @ahaguiar 2011/10/11 Stefano Maffulli stef...@openstack.org Hello Alexandre On Tue, 2011-10-11 at 08:42 -0300, Alexandre Haguiar wrote: We work at SERPRO (serpro.gov.br), a Brazilian government TI company and also in the CISL (Brazilian federal government committee for open source implementation). We are organizing an event on next 19 with a full day of talks about free software and private clouds. We are seeking an Openstack expert in Brazil who can contribute talking about openstack in this event. A chunk of OpenStack developers will be in Sao Paulo at LinuxCon Brazil on November 17-18, but most will be coming from US and a group from Argentina. Do you have more details about the event? I can extend your request to other channels. /stef -- Alexandre Haguiar ___ 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 11, 2011, at 1:53 PM, Lorin Hochstein wrote: Ceci n'est pas un pipe. ;) Exactly! -- Ed Leafe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] MySQL drivers in DB
I do not know from where that comes, but I would consider it a bug and
that there is no good reason in this context to be using MyISAM for any
purpose.
On 10/11/2011 01:55 PM, Nick Sokolov wrote:
Hi stackers!
I noticed, that tables in database use two database engines instead of
two, but model descriptions does not override __table_args__ =
{'mysql_engine': 'InnoDB'}.
This is design decision or migration_repo bug, or something else?
mysql select table_name, table_type, engine FROM information_schema.tables;
+---+-++
| table_name| table_type | engine |
+---+-++
system tables here
| agent_builds | BASE TABLE | MyISAM |
| auth_tokens | BASE TABLE | InnoDB |
| block_device_mapping | BASE TABLE | MyISAM |
| certificates | BASE TABLE | InnoDB |
| compute_nodes | BASE TABLE | InnoDB |
| console_pools | BASE TABLE | InnoDB |
| consoles | BASE TABLE | InnoDB |
| export_devices| BASE TABLE | InnoDB |
| fixed_ips | BASE TABLE | InnoDB |
| floating_ips | BASE TABLE | InnoDB |
| instance_actions | BASE TABLE | InnoDB |
| instance_metadata | BASE TABLE | InnoDB |
| instance_type_extra_specs | BASE TABLE | MyISAM |
| instance_types| BASE TABLE | InnoDB |
| instances | BASE TABLE | InnoDB |
| iscsi_targets | BASE TABLE | InnoDB |
| key_pairs | BASE TABLE | InnoDB |
| migrate_version | BASE TABLE | InnoDB |
| migrations| BASE TABLE | InnoDB |
| networks | BASE TABLE | InnoDB |
| projects | BASE TABLE | InnoDB |
| provider_fw_rules | BASE TABLE | MyISAM |
| quotas| BASE TABLE | InnoDB |
| security_group_instance_association | BASE TABLE | InnoDB |
| security_group_rules | BASE TABLE | InnoDB |
| security_groups | BASE TABLE | InnoDB |
| services | BASE TABLE | InnoDB |
| snapshots | BASE TABLE | InnoDB |
| user_project_association | BASE TABLE | InnoDB |
| user_project_role_association | BASE TABLE | InnoDB |
| user_role_association | BASE TABLE | InnoDB |
| users | BASE TABLE | InnoDB |
| virtual_interfaces| BASE TABLE | InnoDB |
| virtual_storage_arrays| BASE TABLE | MyISAM |
| volume_metadata | BASE TABLE | MyISAM |
| volume_type_extra_specs | BASE TABLE | MyISAM |
| volume_types | BASE TABLE | MyISAM |
| volumes | BASE TABLE | InnoDB |
| zones | BASE TABLE | InnoDB |
+---+-++
___
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
OK, I get it now :-) http://en.wikipedia.org/wiki/The_Treachery_of_Images - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Oct 11, 2011, at 2:53 PM, Lorin Hochstein wrote: Ceci n'est pas un pipe. ;) -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Oct 11, 2011, at 11:28 AM, George Reese wrote: 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 ___ 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 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] MySQL drivers in DB
On 10/11/2011 02:15 PM, Vishvananda Ishaya wrote:
For some reason tables are getting created as default type. There is
a migration in the history to convert tables to InnoDB, but anything
created after that migration will go in as the default type. We can
add another migration to convert all of the other tables, but I think
the right method here might be to set the default table type in mysql
to innodb before running nova-manage db sync.
++
Vish
On Oct 11, 2011, at 1:55 PM, Nick Sokolov wrote:
Hi stackers!
I noticed, that tables in database use two database engines instead
of two, but model descriptions does not override __table_args__ =
{'mysql_engine': 'InnoDB'}. This is design decision or
migration_repo bug, or something else?
mysql select table_name, table_type, engine FROM
information_schema.tables;
+---+-++ |
table_name| table_type | engine |
+---+-++
system tables here | agent_builds
| BASE TABLE | MyISAM | | auth_tokens |
BASE TABLE | InnoDB | | block_device_mapping |
BASE TABLE | MyISAM | | certificates |
BASE TABLE | InnoDB | | compute_nodes |
BASE TABLE | InnoDB | | console_pools |
BASE TABLE | InnoDB | | consoles |
BASE TABLE | InnoDB | | export_devices|
BASE TABLE | InnoDB | | fixed_ips |
BASE TABLE | InnoDB | | floating_ips |
BASE TABLE | InnoDB | | instance_actions |
BASE TABLE | InnoDB | | instance_metadata |
BASE TABLE | InnoDB | | instance_type_extra_specs |
BASE TABLE | MyISAM | | instance_types|
BASE TABLE | InnoDB | | instances |
BASE TABLE | InnoDB | | iscsi_targets |
BASE TABLE | InnoDB | | key_pairs |
BASE TABLE | InnoDB | | migrate_version |
BASE TABLE | InnoDB | | migrations|
BASE TABLE | InnoDB | | networks |
BASE TABLE | InnoDB | | projects |
BASE TABLE | InnoDB | | provider_fw_rules |
BASE TABLE | MyISAM | | quotas|
BASE TABLE | InnoDB | | security_group_instance_association |
BASE TABLE | InnoDB | | security_group_rules |
BASE TABLE | InnoDB | | security_groups |
BASE TABLE | InnoDB | | services |
BASE TABLE | InnoDB | | snapshots |
BASE TABLE | InnoDB | | user_project_association |
BASE TABLE | InnoDB | | user_project_role_association |
BASE TABLE | InnoDB | | user_role_association |
BASE TABLE | InnoDB | | users |
BASE TABLE | InnoDB | | virtual_interfaces|
BASE TABLE | InnoDB | | virtual_storage_arrays|
BASE TABLE | MyISAM | | volume_metadata |
BASE TABLE | MyISAM | | volume_type_extra_specs |
BASE TABLE | MyISAM | | volume_types |
BASE TABLE | MyISAM | | volumes |
BASE TABLE | InnoDB | | zones |
BASE TABLE | InnoDB |
+---+-++
___ 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] OpenStack API v1.0 Removal from Nova
++ On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.comwrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: 1) Our implementation is incomplete, and there are no (visible) plans to complete it. Shared IP Groups and Backup Schedules have been unimplemented since I started on the project. 2) The v1.1 spec is not backwards-compatible with v1.0. I would like minor versions to be backwards compatible as we move forward, so I see v1.0 as something we need to just get rid of. 3) As we are trying to complete the v1.1 implementation, we are running into problems created by having to support v1.0 (specifically image and server uuids). 4) Our implementation of v1.0 and v1.1 within the same modules have caused us to compromise code quality. Working on the controllers (specifically servers) is a royal pain. I've already done the work of removing v1.0 from the code, and here's the review of my branch: https://review.openstack.org/840. I think it makes a lot of sense for the community to focus on making our v1.1 implementation solid, rather than constantly worrying about how we are affecting v1.0. If this is something we don't want to do, I would love to hear why :) Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API v1.0 Removal from Nova
+1 On Tue, Oct 11, 2011 at 6:01 PM, Trey Morris trey.mor...@rackspace.com wrote: +1 On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.com wrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: 1) Our implementation is incomplete, and there are no (visible) plans to complete it. Shared IP Groups and Backup Schedules have been unimplemented since I started on the project. 2) The v1.1 spec is not backwards-compatible with v1.0. I would like minor versions to be backwards compatible as we move forward, so I see v1.0 as something we need to just get rid of. 3) As we are trying to complete the v1.1 implementation, we are running into problems created by having to support v1.0 (specifically image and server uuids). 4) Our implementation of v1.0 and v1.1 within the same modules have caused us to compromise code quality. Working on the controllers (specifically servers) is a royal pain. I've already done the work of removing v1.0 from the code, and here's the review of my branch: https://review.openstack.org/840. I think it makes a lot of sense for the community to focus on making our v1.1 implementation solid, rather than constantly worrying about how we are affecting v1.0. If this is something we don't want to do, I would love to hear why :) Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API v1.0 Removal from Nova
+1 On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.comwrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: 1) Our implementation is incomplete, and there are no (visible) plans to complete it. Shared IP Groups and Backup Schedules have been unimplemented since I started on the project. 2) The v1.1 spec is not backwards-compatible with v1.0. I would like minor versions to be backwards compatible as we move forward, so I see v1.0 as something we need to just get rid of. 3) As we are trying to complete the v1.1 implementation, we are running into problems created by having to support v1.0 (specifically image and server uuids). 4) Our implementation of v1.0 and v1.1 within the same modules have caused us to compromise code quality. Working on the controllers (specifically servers) is a royal pain. I've already done the work of removing v1.0 from the code, and here's the review of my branch: https://review.openstack.org/840. I think it makes a lot of sense for the community to focus on making our v1.1 implementation solid, rather than constantly worrying about how we are affecting v1.0. If this is something we don't want to do, I would love to hear why :) Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API v1.0 Removal from Nova
++ On Tue, Oct 11, 2011 at 2:46 PM, Josh Kearney j...@jk0.org wrote: ++ On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon brian.wal...@rackspace.com wrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: 1) Our implementation is incomplete, and there are no (visible) plans to complete it. Shared IP Groups and Backup Schedules have been unimplemented since I started on the project. 2) The v1.1 spec is not backwards-compatible with v1.0. I would like minor versions to be backwards compatible as we move forward, so I see v1.0 as something we need to just get rid of. 3) As we are trying to complete the v1.1 implementation, we are running into problems created by having to support v1.0 (specifically image and server uuids). 4) Our implementation of v1.0 and v1.1 within the same modules have caused us to compromise code quality. Working on the controllers (specifically servers) is a royal pain. I've already done the work of removing v1.0 from the code, and here's the review of my branch: https://review.openstack.org/840. I think it makes a lot of sense for the community to focus on making our v1.1 implementation solid, rather than constantly worrying about how we are affecting v1.0. If this is something we don't want to do, I would love to hear why :) Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API Versioning Conventions
On Oct 11, 2011, at 4: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? I feel like our real product is Nova, and the Compute API is just the interface used to communicate Nova's current state to Nova's clients. Yes, the Compute API is a separate product (and should develop independently of Nova), but without Nova, there would be no need for an API. My point here is that we are designing an HTTP API to expose an underlying system, we aren't designing a pure REST API service. For example, Twitter is nothing without its API. If we turned off our API, you could still ssh into your instances or use nova-manage, which bypasses the API altogether. Your point above about the API being composed solely of different method signatures available to interact with the core objects would be valid if we wanted the API to own those objects. At the end of the day, Nova is going to own an instance, not the API that exposes it. Brian Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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] Searching Brazilian members
-Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Stefano Maffulli Sent: 11 October 2011 08:43 To: Alexandre Haguiar Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Searching Brazilian members Hello Alexandre On Tue, 2011-10-11 at 08:42 -0300, Alexandre Haguiar wrote: We work at SERPRO (serpro.gov.br), a Brazilian government TI company and also in the CISL (Brazilian federal government committee for open source implementation). We are organizing an event on next 19 with a full day of talks about free software and private clouds. We are seeking an Openstack expert in Brazil who can contribute talking about openstack in this event. A chunk of OpenStack developers will be in Sao Paulo at LinuxCon Brazil on November 17-18, but most will be coming from US and a group from Argentina. Citrix is also sending one person (Marcus Granado) to LinuxCon Brazil from the XenServer team in Cambridge, UK. He is Portuguese, and a member of the core Xen toolstack team, so he will be able to talk at a detailed technical level on Xen, Xen Cloud Platform and XenServer in the local language. (We've got a US contingent going as well, of course.) Cheers, Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Merge review requested
Hi, I'd like to request merge reviews on the following. These have been outstanding since September 24. https://review.openstack.org/#change,642 (Soren has +1'd) https://review.openstack.org/#change,643 These are related to the Open vSwitch rules applied in a Xen domain 0, for multi-tenant network isolation. Thanks, Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API v1.0 Removal from Nova
On Tue, 2011-10-11 at 16:59 -0400, Brian Waldon wrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: [snip] +1 -- Kevin L. Mitchell kevin.mitch...@rackspace.com This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API v1.0 Removal from Nova
+3 On Oct 11, 2011, at 1:59 PM, Brian Waldon brian.wal...@rackspace.com wrote: I would like to propose we remove our implementation of OSAPI v1.0 from Nova for the following reasons: 1) Our implementation is incomplete, and there are no (visible) plans to complete it. Shared IP Groups and Backup Schedules have been unimplemented since I started on the project. 2) The v1.1 spec is not backwards-compatible with v1.0. I would like minor versions to be backwards compatible as we move forward, so I see v1.0 as something we need to just get rid of. 3) As we are trying to complete the v1.1 implementation, we are running into problems created by having to support v1.0 (specifically image and server uuids). 4) Our implementation of v1.0 and v1.1 within the same modules have caused us to compromise code quality. Working on the controllers (specifically servers) is a royal pain. I've already done the work of removing v1.0 from the code, and here's the review of my branch: https://review.openstack.org/840. I think it makes a lot of sense for the community to focus on making our v1.1 implementation solid, rather than constantly worrying about how we are affecting v1.0. If this is something we don't want to do, I would love to hear why :) Waldon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Working group for nova-volume changes
Hi All, As it was discussed during the Design Summit, there was a desire to create a Working Group for Nova Volume changes. If you would like to participate, pls feel free to add yourself to: https://launchpad.net/~openstack-volume and/or its mailing list: openstack-vol...@lists.launchpad.net Regards, -Vladimir ___ 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] Guidelines for OpenStack APIs
On 12/10/2011, at 1:00 AM, Mark McLoughlin wrote: We're not attempting to enumerating all the valid ways that POST can be used, we're trying to narrow down those possibilities to a set of guidelines which describe the general style and idioms of OpenStack APIs. Understood. I've been involved in a few different efforts to define API conventions, and IME there's a tricky line between promoting a 'style' and neutering the power of HTTP. I've often seen cases where people try to proscribe a use of POST, for example, only to run into use cases later that directly called for it. So, I tend to advocate educating people about different patterns of use, rather than mandating/requiring them. People often reach for POST when they should be doing something else, but that doesn't mean that it doesn't have legitimate uses in the update case. There are cases where it's necessary to be prescriptive, of course (e.g., to have a sane approach to versioning). Cheers, -- 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
Re: [Openstack] OpenStack API Versioning Conventions
On 12/10/2011, at 12:51 AM, Mark McLoughlin wrote: - Version numbers aren't necessarily the best way to advertise the availability of features - if we made clients query for the availability of the features they're using, you could version the features independently. For example, if we decide we must make an incompatible change to some obscure feature, wouldn't it be nice to version the feature rather than bump the major version of the API. Also, it allows the API to have optional features that not all service providers support. +1 Linear versioning is of very limited use. I'd rather query the API and get back some JSON that enumerates the extensions available -- including their major versions, which is really just part of their names -- and links to their root resources (what some might call 'endpoints'). This is kind of already done in the /extensions resource; it just needs to link to the actual endpoints. The place that it *is* appropriate to put an exact version of the software in use is the Server response header, for debugging; e.g., Server: Nova/1.4.2 and of course, if we want to list extensions, something like: Server: Nova/1.4.2 EC2plugin/3.0 MyFavouriteExtension/3.2.1 Again, this isn't for discovering server capabilities; really just debugging. Likewise, clients should be sending meaningful User-Agents, if they aren't already. While we're talking about versions -- I see that the 1.1 docs allow both URI and media type versioning. That makes me pretty uncomfortable, for a few reasons: * Having two ways to do it is duplication of effort / more opportunities for bugs * There isn't a 1:1 correspondence between URI versioning and media type versioning; for example, a new URI tree can introduce new resources, remove others, or drastically change the semantics of a resource itself. Media type versioning is limited to the semantics of the representation, not the behaviour of the resource. * Major versioning implies a change in core semantics, which is out of scope for media type versioning. I.e., if there's a backwards-incompatible change, it needs a new URI * Using conneg for versioning requires that the server send a Vary header, so that caches won't serve the wrong response to a client. That isn't being done now, AFAICT. This isn't to say that there isn't a place for media type versioning in the APIs, just that it fulfils a very different function (managing change in representation formats). Cheers, -- 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
Re: [Openstack] OpenStack API Versioning Conventions
It might help to talk about *what* might change, and what kinds of versioning are available. E.g., * Changing the methods supported by a resource, or their semantics (in the case of POST) * Changing the URI query parameters available to a resource * Changing the range of formats that a resource consumes / produces * Changes within the individual formats themselves * Changing the HTTP headers produced / consumed * Adding / deleting resources to the overall interface In each of these cases, there are backwards-compatible changes; e.g., supporting a new method or query parameter, adding a new format, adding a new member to a JSON object. Older clients can interoperate just fine, despite these changes, so NO change is necessary to any identifiers (URIs, media types, etc.), assuming that discovery is a separable problem, and debugging information can be made visible without being so intrusive. There are also backwards-incompatible changes in each case; e.g., changing the meaning of POST on a resource, or the meaning of a URI query parameter, or removing support for a method / query parameter, or making substantial changes to the representation formats themselves. All of these changes will, if made incorrectly, break old clients, and so they should be avoided where possible. In cases where we absolutely need to make incompatible changes, we can introduce new URIs or new media types to accommodate it, whilst still supporting the old one. The important thing here is that there isn't *one* versioning strategy that works for all sorts of changes; each type of change is individual. George, when you say that we shouldn't have versions in URIs, I agree as an aspirational goal. I.e., we should strive to NEVER break old clients, and therefore the URIs should not change very quickly -- ideally, at all. I do think, however, that we probably need a major version identifier in the URIs, to allow us to *once in a blue moon* wipe the slate clean and start a fresh API. That doesn't mean that we'd stop supporting the old API, of course; they'd have to run in parallel (for a sunset period, at a minimum, if not forever). One technique we could use to reach that goal is to NOT bake URIs into the specifications, but rather have clients inspect the APIs to discover links to the various kinds of resources they want to use. This decouples the API from the URI space, and makes extensibility and versioning much easier -- but it does require a certain discipline on behalf of the clients, in that they have to first discover the URIs they want to interact with. There are some downsides to this approach (e.g., it is more chatty, and to be efficient, it requires client-side caching), but it might be worth discussing as at least a partial solution. Cheers, On 12/10/2011, at 1:54 AM, 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. -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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Mark Nottingham http://www.mnot.net/ ___
Re: [Openstack] Guidelines for OpenStack APIs
I've started a list of proposed goals here: http://wiki.openstack.org/Governance/Proposed/APIGoals Please pile on... On 11/10/2011, at 11:53 PM, Jay Pipes wrote: On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham m...@mnot.net wrote: +1 (sorry for the lag, been travelling). I'd like to start two wiki pages; one collecting goals for the APIs, one for collecting common patterns of use in the APIs (not rules, not even guidelines). Maybe split each one into proposed and agreed so that we can keep track of whether there's agreement. Make sense? Very much so. ++ Go ahead and create the wiki pages, outline them and/or add prior suggestions, and we'll take it from there :) Cheers, -jay -- 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
[Openstack] glance-api errors and stop
I logon dashboard and when I click to images/instances web, error occurs on terminal. Traceback (most recent call last): File /usr/lib/pymodules/python2.7/eventlet/greenpool.py, line 80, in _spawn_n_impl func(*args, **kwargs) File /usr/lib/pymodules/python2.7/eventlet/wsgi.py, line 508, in process_request proto = self.protocol(socket, address, self) File /usr/lib/python2.7/SocketServer.py, line 641, in __init__ self.finish() File /usr/lib/pymodules/python2.7/eventlet/wsgi.py, line 453, in finish BaseHTTPServer.BaseHTTPRequestHandler.finish(self) File /usr/lib/python2.7/SocketServer.py, line 694, in finish self.wfile.flush() File /usr/lib/python2.7/socket.py, line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File /usr/lib/pymodules/python2.7/eventlet/greenio.py, line 283, in sendall tail = self.send(data, flags) File /usr/lib/pymodules/python2.7/eventlet/greenio.py, line 269, in send total_sent += fd.send(data[total_sent:], flags) error: [Errno 32] Broken pipe And glance-api always stops . -- 非淡薄无以明志，非宁静无以致远 ___ 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] Nova Essex Planning
Hey Everyone, We had a great design summit. Lots of new features were presented, along with some great proposals for cleanup, stability, upgradability, etc. I'm attempting to capture all of the proposed action items in one etherpad, with links to specific blueprints. You can find the etherpad here: http://etherpad.openstack.org/essex My plan over the next two days is to congeal all of the relevant proposals into one or more specific blueprints. If you know of existing blueprints, please feel free to paste in a link next to the item in the etherpad. If there are some plans that I missed, please add them. Once we have all the blueprints defined, we can target them properly. On Thursday at 2100 UTC (2pm pacific/ 4pm central, the same time as the release meeting) I'd like to have an irc meeting to triage the blueprints and assign them to specific people/teams and milestones. We have a lot of groups touching the nova code and we need to stay coordinated. The blueprint system is there to help us understand who is working on what. It would be great if all of nova-core could attend. I would also welcome participation from other teams that aren't in nova-core. There will likely be a number of blueprints that have no one assigned, so it would be great to find a home for them. See you all soon! 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
Re: [Openstack] OpenStack API Versioning Conventions
On 10/11/2011 10:27 AM, George Reese wrote: Yes, my proposed solution requires OpenStack implementations to support ALL major versions of ALL APIs. That's absolutely critical for building a healthy ecosystem. That may be completely impossible if different versions require incompatible underlying data models. Never being able to deprecate designs seems like a ball and chain. ___ 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] Does diablo support lvm block devices instead files for VMs?
Hi!
Could someone answer for my question?
2011/10/7 Roman Sokolkov rsokol...@gmail.com
Hi! For my research I think Diablo doesn't support LVM block devices for
VMs, does it?
In /usr/share/nova/libvirt.xml.template only file supports for main disk
device. I am right?
#if $getVar('rescue', False)
disk type='file'
driver type='${driver_type}'/
source file='${basepath}/disk.rescue'/
target dev='${disk_prefix}a' bus='${disk_bus}'/
/disk
disk type='file'
driver type='${driver_type}'/
source file='${basepath}/disk'/
target dev='${disk_prefix}b' bus='${disk_bus}'/
/disk
#else
#if not ($getVar('ebs_root', False))
disk type='file'
driver type='${driver_type}'/
source file='${basepath}/disk'/
target dev='${root_device}' bus='${disk_bus}'/
/disk
#end if
Thanks
--
Regards, Roman Sokolkov
___
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-poc] Is it Tuesday again, already?
Anyone have any items to discuss? Looks like Mark Nottingham is taking some steps to move the API guideline discussion forward which was something we were going to touch base on after the conference. Anything else we should follow up on? I need to send out a summary of our in-person meeting, but don't really have anything else. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] Is it Tuesday again, already?
Let's skip this week then unless anyone objects. I think we'll have a few things to cover next week. Jonathan. On Oct 11, 2011, at 1:31 PM, Joshua McKenty wrote: I'll need another week with the followup to our FITS discussions before I'm ready to bring it back to the PPB. I have some questions about how the PPB will transition to the foundation, but I imagine that's more on the foundation side of the discussion. Backport branches? I spoke with Todd Deshane about taking over the academic coordination activities, but I'm behind on handing off all of those to him. Nothing else for me. Joshua McKenty Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 jos...@pistoncloud.com On 2011-10-11, at 10:08 AM, Jonathan Bryce wrote: Anyone have any items to discuss? Looks like Mark Nottingham is taking some steps to move the API guideline discussion forward which was something we were going to touch base on after the conference. Anything else we should follow up on? I need to send out a summary of our in-person meeting, but don't really have anything else. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
