Re: [openstack-dev] Filtering by metadata values

2015-02-10 Thread Miguel Grinberg
at 8:20 AM, Miguel Grinberg miguel.grinberg at gmail.com mailto:miguel.grinberg-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: Hi, We had a discussion yesterday on the Heat channel regarding patterns for searching or filtering entities by its metadata values. This is in relation to a feature

Re: [openstack-dev] [api] [glance] conclusion needed on functional API

2015-02-18 Thread Miguel Grinberg
Out of all the proposals mentioned in this thread, I think Jay's (d) option is what is closer to the REST ideal: d) POST /images/{image_id}/tasks with payload: { action: deactivate|activate } Even though I don't think this is the perfect solution, I can recognize that at least it tries to be

[openstack-dev] Filtering by metadata values

2015-02-10 Thread Miguel Grinberg
Hi, We had a discussion yesterday on the Heat channel regarding patterns for searching or filtering entities by its metadata values. This is in relation to a feature that is currently being implemented in Heat called “Stack Tags”. The idea is that Heat stack lists can be filtered by these

[openstack-dev] [api] tagging guideline up for review

2015-02-13 Thread Miguel Grinberg
Hi all, I would like to invite you to review my proposal on tagging guidelines for the API-WG. The proposal is heavily based on the recent nova tagging spec, but I decided to deviate from it in a couple of places (I noted in the document my reasons). Feedback welcome. Thanks, Miguel

Re: [openstack-dev] [api] tagging guideline up for review

2015-02-13 Thread Miguel Grinberg
I'm sure it would be helpful if I give you the link to the document :) https://review.openstack.org/#/c/155620/ On Fri, Feb 13, 2015 at 11:01 AM, Miguel Grinberg miguel.s.grinb...@gmail.com wrote: Hi all, I would like to invite you to review my proposal on tagging guidelines for the API-WG

[openstack-dev] [api] metadata and tagging guidelines up for review

2015-03-09 Thread Miguel Grinberg
Hi all, I would like to invite you to review the guidelines for metadata and tagging that I proposed to the API-WG. Links: https://review.openstack.org/#/c/141229/ https://review.openstack.org/#/c/155620/ The idea with these guidelines is to come up with a set of recommendations to be used

Re: [openstack-dev] [glance] [trove] [heat] [nova] [all] Handling forwarded requests

2015-03-03 Thread Miguel Grinberg
Ian, thanks for raising the issue here. The X-Forwarded headers are the standard way to deal with URLs for services behind proxies. I already commented on the Heat proposal to that effect, I think that is the proper way to support services behind proxies. Now in our case, there is also another

[openstack-dev] [heat] autoscaling and load balancers

2015-04-07 Thread Miguel Grinberg
prefer the full update, seems cleaner to me. Anyway, sorry for the long email. If you can provide guidance on which of the approaches are preferred, or if you have other ideas, I would appreciate it. Regards, Miguel Grinberg

Re: [openstack-dev] [heat] autoscaling and load balancers

2015-04-08 Thread Miguel Grinberg
Thomas, I stand corrected. If you use Neutron's LBAAS plugin you do get the correct autoscaling behavior because Neutron updates the loadbalancer when pool members are added or removed (Heat does not seem to participate in this update, as far as I can see). Still my #1 issue still exists,

Re: [openstack-dev] [heat] autoscaling and load balancers

2015-04-08 Thread Miguel Grinberg
Zane, replies inline. On Wed, Apr 8, 2015 at 3:46 PM, Zane Bitter zbit...@redhat.com wrote: On 07/04/15 22:02, Miguel Grinberg wrote: Hi, The OS::Heat::AutoScalingGroup resource is somewhat limited at this time, because when a scaling even occurs it does not notify dependent resources

Re: [openstack-dev] [heat] autoscaling and load balancers

2015-04-08 Thread Miguel Grinberg
:03 AM, Miguel Grinberg miguel.s.grinb...@gmail.com wrote: Zane, replies inline. On Wed, Apr 8, 2015 at 3:46 PM, Zane Bitter zbit...@redhat.com wrote: On 07/04/15 22:02, Miguel Grinberg wrote: Hi, The OS::Heat::AutoScalingGroup resource is somewhat limited at this time, because when