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 tags,
b 11, 2015 at 8:20 AM, Miguel Grinberg
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 feat
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
___
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
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
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 so
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 going
/170634/. I honestly 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.
Regar
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, referenc
Zane, replies inline.
On Wed, Apr 8, 2015 at 3:46 PM, Zane Bitter 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 d
M, Angus Salkeld wrote:
>
> On Thu, Apr 9, 2015 at 8:03 AM, Miguel Grinberg <
> miguel.s.grinb...@gmail.com> wrote:
>
>> Zane, replies inline.
>>
>> On Wed, Apr 8, 2015 at 3:46 PM, Zane Bitter wrote:
>>
>>> On 07/04/15 22:02, Miguel Grinberg wrot
11 matches
Mail list logo
