Re: [openstack-dev] [nova] Let's kill quota classes (again)
On Fri, 6 Jan 2017 12:15:34 -0500, William M Edmonds wrote: Why would someone need to change the defaults via REST API calls? I agree that we should plan for that now if we think that will eventually be needed, but I'm not seeing why it would be needed. The REST API already allows people to change quota defaults. There are also quota defaults config options. When a quota default is changed via the REST API, an entry for the default is made in the DB and is used from then on and the config option is never used again. If a quota default has never been changed via the REST API, it can be changed via the config option. Defaults are looked for in order 1) DB 2) config option. This is confusing and we've been discussing getting rid of one of the methods for changing quota defaults. We're thinking to keep the REST API and ditch the config options, because the REST API (and thus DB) provides a central place for the defaults. It takes one call to the REST API to affect a quota default change everywhere. With the config options, if you wanted to change a default, you'd have to change the configs on all of your API hosts any time you did it, and synchronize that. -melanie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 12/16/2016 05:03 PM, Jay Pipes wrote: > On 12/16/2016 04:36 PM, Matt Riedemann wrote: > > On 12/16/2016 2:20 PM, Jay Pipes wrote: > >> > >> For problems with placing data like this as configuration options, see > >> the hassle we went through in making the allocation_ratio options into > >> fields stored in the DB... > >> > >> Better long-term to have all this kind of configuration live in a data > >> store (not a config file) and be exposed via an HTTP API. > >> > > > > So, we could do that, we already have the quota_classes table and the > > os-quota-class-sets REST API, and as mentioned the only usable thing > > that goes in there is overriding global default quota. > > > > Would you suggest we drop the global quota limit configuration options > > and simply populate the quota_classes table with a 'default' quota class > > and the limits from the config in a DB migration, then drop the config > > options? > > Yeah, I think that's the best long-term strategerization. Why would someone need to change the defaults via REST API calls? I agree that we should plan for that now if we think that will eventually be needed, but I'm not seeing why it would be needed. And if we're not sure this is needed now, we could still always do this later... at which point we could do it a lot better than the current implementation being able to start from scratch. Perhaps as part of the implementation of a new API that allows you to change *any* mutable config option? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 12/16/2016 4:00 PM, Jay Pipes wrote: So, we could do that, we already have the quota_classes table and the os-quota-class-sets REST API, and as mentioned the only usable thing that goes in there is overriding global default quota. Would you suggest we drop the global quota limit configuration options and simply populate the quota_classes table with a 'default' quota class and the limits from the config in a DB migration, then drop the config options? Yeah, I think that's the best long-term strategerization. -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OK, I've noted your point in the spec review, maybe we can discuss the options at the PTG while we're all in the same room. I think we have good options either way going forward so I'm happy. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 12/16/2016 04:36 PM, Matt Riedemann wrote: On 12/16/2016 2:20 PM, Jay Pipes wrote: For problems with placing data like this as configuration options, see the hassle we went through in making the allocation_ratio options into fields stored in the DB... Better long-term to have all this kind of configuration live in a data store (not a config file) and be exposed via an HTTP API. So, we could do that, we already have the quota_classes table and the os-quota-class-sets REST API, and as mentioned the only usable thing that goes in there is overriding global default quota. Would you suggest we drop the global quota limit configuration options and simply populate the quota_classes table with a 'default' quota class and the limits from the config in a DB migration, then drop the config options? Yeah, I think that's the best long-term strategerization. -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 12/16/2016 2:20 PM, Jay Pipes wrote: For problems with placing data like this as configuration options, see the hassle we went through in making the allocation_ratio options into fields stored in the DB... Better long-term to have all this kind of configuration live in a data store (not a config file) and be exposed via an HTTP API. So, we could do that, we already have the quota_classes table and the os-quota-class-sets REST API, and as mentioned the only usable thing that goes in there is overriding global default quota. Would you suggest we drop the global quota limit configuration options and simply populate the quota_classes table with a 'default' quota class and the limits from the config in a DB migration, then drop the config options? -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 12/15/2016 09:00 AM, Matt Riedemann wrote: On 12/15/2016 3:11 AM, Andrey Volkov wrote: Hi, I totally agree with Matt than `os-quota-class-sets` is inconsistent. It has that hardcoded default class can't be changed. API call is documented neither Nova nor Cinder (has the same API for quotas). With defaults in the configuration I have some concerns: - As it was mentioned before, possibly we need to update configs in several places. We're moving quotas to the API and we're going to stop doing the reservation/commit/rollback race dance between API and compute nodes per this spec: https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html So that would mean you really only need the default quota configuration on the API node, so I don't think this is as much of a problem after that change. - To make changes be applied we need to restart service, possibly SIGHUP can help but I'm not sure. I'd think we could make these mutable config options so we could pickup the changes without restarting the service. For problems with placing data like this as configuration options, see the hassle we went through in making the allocation_ratio options into fields stored in the DB... Better long-term to have all this kind of configuration live in a data store (not a config file) and be exposed via an HTTP API. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
> We're moving quotas to the API and we're going to stop doing the > reservation/commit/rollback race dance between API and compute nodes per > this spec: > > https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html It's very nice spec. If we can remove all quota_usages and reservations stuff it will be great. As I understand a lot of places should be changed I'd happy to take part and to help. Matt Riedemann writes: > On 12/15/2016 3:11 AM, Andrey Volkov wrote: >> Hi, >> >> I totally agree with Matt than `os-quota-class-sets` is inconsistent. >> It has that hardcoded default class can't be changed. >> API call is documented neither Nova nor Cinder (has the same API for >> quotas). >> >> With defaults in the configuration I have some concerns: >> - As it was mentioned before, possibly we need to update configs in >> several places. > > We're moving quotas to the API and we're going to stop doing the > reservation/commit/rollback race dance between API and compute nodes per > this spec: > > https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html > > So that would mean you really only need the default quota configuration > on the API node, so I don't think this is as much of a problem after > that change. > >> - To make changes be applied we need to restart service, possibly SIGHUP >> can help >> but I'm not sure. > > I'd think we could make these mutable config options so we could pickup > the changes without restarting the service. > >> >> Alternatives I see are: >> - Update `os-quota-sets` and give it possibility to work with defaults. >> - Use external centralized quota service on which the work's doing actively. >> Please see [1] spec for limits in keystone and doc [2] having information >> how it can be applied in Nova and Cinder. >> >> [1] https://review.openstack.org/#/c/363765/ >> [2] >> https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit# >> >> -- Thanks, Andrey Volkov, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 12/15/2016 3:11 AM, Andrey Volkov wrote: Hi, I totally agree with Matt than `os-quota-class-sets` is inconsistent. It has that hardcoded default class can't be changed. API call is documented neither Nova nor Cinder (has the same API for quotas). With defaults in the configuration I have some concerns: - As it was mentioned before, possibly we need to update configs in several places. We're moving quotas to the API and we're going to stop doing the reservation/commit/rollback race dance between API and compute nodes per this spec: https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html So that would mean you really only need the default quota configuration on the API node, so I don't think this is as much of a problem after that change. - To make changes be applied we need to restart service, possibly SIGHUP can help but I'm not sure. I'd think we could make these mutable config options so we could pickup the changes without restarting the service. Alternatives I see are: - Update `os-quota-sets` and give it possibility to work with defaults. - Use external centralized quota service on which the work's doing actively. Please see [1] spec for limits in keystone and doc [2] having information how it can be applied in Nova and Cinder. [1] https://review.openstack.org/#/c/363765/ [2] https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit# -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
Hi, I totally agree with Matt than `os-quota-class-sets` is inconsistent. It has that hardcoded default class can't be changed. API call is documented neither Nova nor Cinder (has the same API for quotas). With defaults in the configuration I have some concerns: - As it was mentioned before, possibly we need to update configs in several places. - To make changes be applied we need to restart service, possibly SIGHUP can help but I'm not sure. Alternatives I see are: - Update `os-quota-sets` and give it possibility to work with defaults. - Use external centralized quota service on which the work's doing actively. Please see [1] spec for limits in keystone and doc [2] having information how it can be applied in Nova and Cinder. [1] https://review.openstack.org/#/c/363765/ [2] https://docs.google.com/document/d/1AqmmRvd_e-4Hw2oLbnBf5jBtjLgMj-kqAaQfofp_NYI/edit# On Thu, Dec 15, 2016 at 6:32 AM, joehuang wrote: > If we don't update the default quota configuration at the same time for > Nova services in different > physical nodes, then there is a chance for the quota control in dis-order > period: for example, > 30 cores qutoa limit in one node, 20 cores quota limit in the other node. > > Best Regards > Chaoyi Huang (joehuang) > > > From: Matt Riedemann [mrie...@linux.vnet.ibm.com] > Sent: 15 December 2016 10:42 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again) > > On 7/18/2016 6:36 PM, Sean Dague wrote: > > On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote: > >> The original concept of quota classes was to allow the default quotas > >> applied to a tenant to be a function of the type of tenant. That is, > >> say you have a tiered setup, where you have gold-, silver-, and > >> bronze-level customers, with gold having lots of free quota and bronze > >> having a small amount of quota. Rather than having to set the quotas > >> individually for each tenant you created, the idea is that you set the > >> _class_ of the tenant, and have quotas associated with the classes. > >> This also has the advantage that, if someone levels up (or down) to > >> another class of service, all you do is change the tenant's class, and > >> the new quotas apply immediately. > >> > >> (By the way, the turnstile integration was not part of turnstile itself; > >> there's a turnstile plugin to allow it to integrate with nova that's > >> quota_class-aware, so you could also apply rate limits this way.) > >> > >> Personally, it wouldn't break my heart if quota classes went away; I > >> think this level of functionality, if it seems reasonable to include, > >> should become part of a more unified quota API (which we're still > >> struggling to come up with anyway) so that everyone gets the benefit…or > >> perhaps shares the pain? ;) Anyway, I'm not aware of anyone using this > >> functionality, though it might be worth asking about on the operators > >> list—for curiosity's sake, if nothing else. It would be interesting to > >> see if anyone would be interested in the original idea, even if the > >> current implementation doesn't make sense :) > > > > We've already dropped the hook turnstile was using, so I don't see any > > reason not to drop this bit as well. I don't think it will work for > > anyone with the current code. > > > > I agree that this probably makes way more sense in common quota code > > then buried inside of Nova. > > > > -Sean > > > > Following up on this, I missed the boat for Ocata, but got to talking > with melwitt about this again today and while I had it all in my head > again I've written a spec for Pike to deprecate the os-quota-class-sets > API: > > https://review.openstack.org/#/c/411035/ > > This essentially means no more custom quota classes (they aren't > functional today anyway), and no more controlling global default quota > limits via the REST API - that has to be done via the configuration > (after the microversion). > > -- > > Thanks, > > Matt Riedemann > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Thanks, Andrey Volkov, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
If we don't update the default quota configuration at the same time for Nova services in different physical nodes, then there is a chance for the quota control in dis-order period: for example, 30 cores qutoa limit in one node, 20 cores quota limit in the other node. Best Regards Chaoyi Huang (joehuang) From: Matt Riedemann [mrie...@linux.vnet.ibm.com] Sent: 15 December 2016 10:42 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again) On 7/18/2016 6:36 PM, Sean Dague wrote: > On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote: >> The original concept of quota classes was to allow the default quotas >> applied to a tenant to be a function of the type of tenant. That is, >> say you have a tiered setup, where you have gold-, silver-, and >> bronze-level customers, with gold having lots of free quota and bronze >> having a small amount of quota. Rather than having to set the quotas >> individually for each tenant you created, the idea is that you set the >> _class_ of the tenant, and have quotas associated with the classes. >> This also has the advantage that, if someone levels up (or down) to >> another class of service, all you do is change the tenant's class, and >> the new quotas apply immediately. >> >> (By the way, the turnstile integration was not part of turnstile itself; >> there's a turnstile plugin to allow it to integrate with nova that's >> quota_class-aware, so you could also apply rate limits this way.) >> >> Personally, it wouldn't break my heart if quota classes went away; I >> think this level of functionality, if it seems reasonable to include, >> should become part of a more unified quota API (which we're still >> struggling to come up with anyway) so that everyone gets the benefit…or >> perhaps shares the pain? ;) Anyway, I'm not aware of anyone using this >> functionality, though it might be worth asking about on the operators >> list—for curiosity's sake, if nothing else. It would be interesting to >> see if anyone would be interested in the original idea, even if the >> current implementation doesn't make sense :) > > We've already dropped the hook turnstile was using, so I don't see any > reason not to drop this bit as well. I don't think it will work for > anyone with the current code. > > I agree that this probably makes way more sense in common quota code > then buried inside of Nova. > > -Sean > Following up on this, I missed the boat for Ocata, but got to talking with melwitt about this again today and while I had it all in my head again I've written a spec for Pike to deprecate the os-quota-class-sets API: https://review.openstack.org/#/c/411035/ This essentially means no more custom quota classes (they aren't functional today anyway), and no more controlling global default quota limits via the REST API - that has to be done via the configuration (after the microversion). -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 7/18/2016 6:36 PM, Sean Dague wrote: On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote: The original concept of quota classes was to allow the default quotas applied to a tenant to be a function of the type of tenant. That is, say you have a tiered setup, where you have gold-, silver-, and bronze-level customers, with gold having lots of free quota and bronze having a small amount of quota. Rather than having to set the quotas individually for each tenant you created, the idea is that you set the _class_ of the tenant, and have quotas associated with the classes. This also has the advantage that, if someone levels up (or down) to another class of service, all you do is change the tenant's class, and the new quotas apply immediately. (By the way, the turnstile integration was not part of turnstile itself; there's a turnstile plugin to allow it to integrate with nova that's quota_class-aware, so you could also apply rate limits this way.) Personally, it wouldn't break my heart if quota classes went away; I think this level of functionality, if it seems reasonable to include, should become part of a more unified quota API (which we're still struggling to come up with anyway) so that everyone gets the benefit…or perhaps shares the pain? ;) Anyway, I'm not aware of anyone using this functionality, though it might be worth asking about on the operators list—for curiosity's sake, if nothing else. It would be interesting to see if anyone would be interested in the original idea, even if the current implementation doesn't make sense :) We've already dropped the hook turnstile was using, so I don't see any reason not to drop this bit as well. I don't think it will work for anyone with the current code. I agree that this probably makes way more sense in common quota code then buried inside of Nova. -Sean Following up on this, I missed the boat for Ocata, but got to talking with melwitt about this again today and while I had it all in my head again I've written a spec for Pike to deprecate the os-quota-class-sets API: https://review.openstack.org/#/c/411035/ This essentially means no more custom quota classes (they aren't functional today anyway), and no more controlling global default quota limits via the REST API - that has to be done via the configuration (after the microversion). -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote: The original concept of quota classes was to allow the default quotas applied to a tenant to be a function of the type of tenant. That is, say you have a tiered setup, where you have gold-, silver-, and bronze-level customers, with gold having lots of free quota and bronze having a small amount of quota. Rather than having to set the quotas individually for each tenant you created, the idea is that you set the _class_ of the tenant, and have quotas associated with the classes. This also has the advantage that, if someone levels up (or down) to another class of service, all you do is change the tenant's class, and the new quotas apply immediately. (By the way, the turnstile integration was not part of turnstile itself; there's a turnstile plugin to allow it to integrate with nova that's quota_class-aware, so you could also apply rate limits this way.) Personally, it wouldn't break my heart if quota classes went away; I think this level of functionality, if it seems reasonable to include, should become part of a more unified quota API (which we're still struggling to come up with anyway) so that everyone gets the benefit…or perhaps shares the pain? ;) Anyway, I'm not aware of anyone using this functionality, though it might be worth asking about on the operators list—for curiosity's sake, if nothing else. It would be interesting to see if anyone would be interested in the original idea, even if the current implementation doesn't make sense :) We've already dropped the hook turnstile was using, so I don't see any reason not to drop this bit as well. I don't think it will work for anyone with the current code. I agree that this probably makes way more sense in common quota code then buried inside of Nova. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Let's kill quota classes (again)
The original concept of quota classes was to allow the default quotas applied to a tenant to be a function of the type of tenant. That is, say you have a tiered setup, where you have gold-, silver-, and bronze-level customers, with gold having lots of free quota and bronze having a small amount of quota. Rather than having to set the quotas individually for each tenant you created, the idea is that you set the _class_ of the tenant, and have quotas associated with the classes. This also has the advantage that, if someone levels up (or down) to another class of service, all you do is change the tenant's class, and the new quotas apply immediately. (By the way, the turnstile integration was not part of turnstile itself; there's a turnstile plugin to allow it to integrate with nova that's quota_class-aware, so you could also apply rate limits this way.) Personally, it wouldn't break my heart if quota classes went away; I think this level of functionality, if it seems reasonable to include, should become part of a more unified quota API (which we're still struggling to come up with anyway) so that everyone gets the benefit…or perhaps shares the pain? ;) Anyway, I'm not aware of anyone using this functionality, though it might be worth asking about on the operators list—for curiosity's sake, if nothing else. It would be interesting to see if anyone would be interested in the original idea, even if the current implementation doesn't make sense :) On Wed, 2016-07-13 at 14:47 -0500, Matt Riedemann wrote: > We got a bug that the os-quota-class-sets API isn't documented: > > https://bugs.launchpad.net/nova/+bug/1602400 > > That's probably because we hate it and no one understands it. > > See this previous thread about trying to sort this out from the long > long ago: > > https://lists.launchpad.net/openstack/msg12200.html > > We tried killing it before, but it turns out, it's actually used by > something! > > http://lists.openstack.org/pipermail/openstack-dev/2014-May/036031.html > > But we didn't have integration testing in Tempest for default quotas at > that time (we added those tests in when we reverted the delete of the > API back in Juno). > > I got looking at this because of the quota_class attribute in the nova > RequestContext: > > https://github.com/openstack/nova/blob/93cc5e3ffd2867bdb39a707a230c1efc6ed2f5f4/nova/context.py#L138-L141 > > That led me to markmc's thread about that only being there for the > turnstile project and some old API rate limiting stuff that Rackspace > was doing out of tree (it appears to set a type of middleware for a > quota class for rate limiting). > > Anyway, super duper out of tree stuff that is probably not even used > anymore (Vek - if you're reading, please speak up). > > I'll also point out that API rate limiting as a paste config was only in > the v2 API and that code was all dropped and the API rate limiting stuff > wasn't carried over for the v2.1 API, for good reason, see: > > http://lists.openstack.org/pipermail/openstack-operators/2016-June/010692.html > > You can still create unique quota classes via the os-quota-class-sets > API (it does a create if the update operation fails), but as far as I > can tell you can't really use those in any meaningful way. > > We really just have the 'default' quota class with a buttload of code > and plumbing to use that, which sucks, because it's all very complicated. > > So I think I'm going to start a pet project of rooting this stuff out > again, starting with nova.context.RequestContext.quota_class, unless > anyone has a good reason we should keep this in tree. > > I think we should also add a microversion to the API in Ocata to disable > the ability to create new quota classes, so that update is only update, > and a 404 for anything else. > -- Kevin L. Mitchell signature.asc Description: This is a digitally signed message part __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
