recedent for including non-OpenStack
resource plugins in Heat, in a "contrib" directory (which is still tested
with the CI infrastructure).
--
IRC: radix
Christopher Armstrong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
unit test caught a
> number of problems.
>
> We will make sure to work with Liang Chen to avoid this happening
> again.<https://review.openstack.org/#/dashboard/7135>
>
fwiw Thomas Hervé has posted a patch to revert the introduction of lazy
translation:
https://review.op
I've filed a bug about this, https://bugs.launchpad.net/heat/+bug/1281644
On Tue, Feb 18, 2014 at 9:15 AM, Christopher Armstrong <
chris.armstr...@rackspace.com> wrote:
> This change was recently merged:
>
> https://review.openstack.org/#/c/69133/
>
> Unfortuna
with patches to fix all the problems, while enabling
it for the unit tests so bugs won't be reintroduced in the future.
Interestingly it also didn't fail any of the tempest tests, I'm not sure
why.
--
IRC: radix
Christopher Armstrong
___
O
uming that the autoscaling service outside of the
Heat engine would need to send several pre-calculated template changes in
sequence in order to implement rolling updates for resource groups, but I
think it would be much much better if Heat could take care of this as a
core feature.
--
Christ
m template authors, though not
>> from resource plugin authors. Attributes sound like something where you
>> want the template authors to get involved in specifying, but maybe that
>> was just an overloaded term.
>>
>> So perhaps we can replace this interface with the gener
ources" attribute, which would call hooks on the "parent" when
> actions are happening.
>
>
Yeah, this would be really helpful for stuff like load balancer
notifications (and any of a number of different resource relationships).
--
IRC: radix
http://twitter.com/radi
On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt wrote:
> On Dec 5, 2013, at 6:25 PM, Christopher Armstrong <
> chris.armstr...@rackspace.com>
> wrote:
>
> On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita <
> anderson...@thoughtworks.com> wrote:
>
>>
ons should be addressable REST objects. Of
course there are cases where object status should be updated to reflect an
operating status if it's a completely exclusive operation (BUILDING and
DELETING make sense, for example).
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
gain with Python 3.3.
>
>
And this is a very useful feature for projects that want to have a single
codebase that runs on both python 2 and python 3, so it's worth taking
advantage of.
--
IRC: radix
Christopher Armstrong
Rackspace
___
Ope
On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell wrote:
>
>From: Christopher Armstrong
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, November 26, 2013 4:02 PM
>
> To:
compromise. If you think it's
absolutely mandatory to be able to group them in named groups, then I would
actually propose a prettier syntax:
ParameterGroups:
db:
name: ...
username: ...
password: ...
web_node:
name: ...
keypair: ...
The orderi
On Thu, Nov 21, 2013 at 12:31 PM, Zane Bitter wrote:
> On 21/11/13 18:44, Christopher Armstrong wrote:
>
>>
>> 2) It relies on a plugin being present for any type of thing you
>> might want to notify.
>>
>>
>> I don't understand this point.
On Thu, Nov 21, 2013 at 5:18 AM, Zane Bitter wrote:
> On 20/11/13 23:49, Christopher Armstrong wrote:
>
>> On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter > <mailto:zbit...@redhat.com>> wrote:
>>
>> On 20/11/13 16:07, Christopher Armstrong wrote:
>>
On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter wrote:
> On 20/11/13 16:07, Christopher Armstrong wrote:
>
>> On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter > <mailto:zbit...@redhat.com>> wrote:
>>
>> On 19/11/13 19:14, Christopher Armstrong wrote:
>>
&g
On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter wrote:
> On 19/11/13 19:14, Christopher Armstrong wrote:
>
>>
>>
[snip]
>> It'd be interesting to see some examples, I think. I'll provide some
>> examples of my proposals, with the following caveats:
>&
On Mon, Nov 18, 2013 at 5:57 AM, Zane Bitter wrote:
> On 16/11/13 11:15, Angus Salkeld wrote:
>
>> On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
>>
>>> On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter wrote:
>>>
>>> On 15/11/13 02:48, Christoph
cluding him here.
> He had some reasoning that won out in the original discussion, although
> I don't really remember what that was.
>
>
It's almost always possible to go without metaclasses without losing much
relevant brevity, and improving clarity. I strongly recommend against
On Sun, Nov 17, 2013 at 2:57 PM, Steve Baker wrote:
> On 11/15/2013 05:19 AM, Christopher Armstrong wrote:
> > http://docs.heatautoscale.apiary.io/
> >
> > I've thrown together a rough sketch of the proposed API for
> > autoscaling. It's written in AP
On Fri, Nov 15, 2013 at 4:16 AM, Zane Bitter wrote:
> On 14/11/13 19:58, Christopher Armstrong wrote:
>
>> On Thu, Nov 14, 2013 at 10:44 AM, Zane Bitter > <mailto:zbit...@redhat.com>> wrote:
>>
>> On 14/11/13 18:51, Randall Burt wrote:
>>
>
On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter wrote:
> On 15/11/13 02:48, Christopher Armstrong wrote:
>
>> On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld > <mailto:asalk...@redhat.com>> wrote:
>>
>> On 14/11/13 10:19 -0600, Christopher Armstrong wrote:
>
On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld wrote:
> On 14/11/13 10:19 -0600, Christopher Armstrong wrote:
>
>> http://docs.heatautoscale.apiary.io/
>>
>> I've thrown together a rough sketch of the proposed API for autoscaling.
>> It's written in API-Bl
On Thu, Nov 14, 2013 at 12:52 PM, Randall Burt
wrote:
>
> On Nov 14, 2013, at 1:05 PM, Christopher Armstrong <
> chris.armstr...@rackspace.com> wrote:
>
> On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt <
> randall.b...@rackspace.com> wrote:
>
>>
>&
On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt
wrote:
>
> On Nov 14, 2013, at 12:44 PM, Zane Bitter
> wrote:
>
> > On 14/11/13 18:51, Randall Burt wrote:
> >>
> >> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong
> >> mailto:chris.armstr...@racksp
on top to manage the other
> steps.
>
I'd say that Heat does (or should do) more than just the initial deployment
-- especially with recent discussion around healing / convergence.
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenS
On Thu, Nov 14, 2013 at 10:44 AM, Zane Bitter wrote:
> On 14/11/13 18:51, Randall Burt wrote:
>
>>
>> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong
>> mailto:chris.armstr...@rackspace.com>>
>> wrote:
>>
>> On Thu, Nov 14, 201
you can pass
during group creation (and all the other operations) -- see the Schema
sections under each. In case you didn't notice, you can click on each
action to expand details under it.
> Thanks
> Georgy
>
>
> On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter wro
Thanks for the comments, Zane.
On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter wrote:
> On 14/11/13 17:19, Christopher Armstrong wrote:
>
>> http://docs.heatautoscale.apiary.io/
>>
>> I've thrown together a rough sketch of the proposed API for autoscaling.
>> I
ound one.
> On Nov 14, 2013, at 10:57 AM, Randall Burt
> wrote:
>
>
> On Nov 14, 2013, at 10:19 AM, Christopher Armstrong <
> chris.armstr...@rackspace.com>
> wrote:
>
> http://docs.heatautoscale.apiary.io/
>
> I've thrown together a rough sketch of
ase read and comment :)
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
similar to the EventScheduler API for just saying "run this webhook on this
schedule" would be nice, too, but I wouldn't raise a fuss if they didn't
exist and I had to actually define a trivial workflow.
--
IRC: radix
Christopher Armstrong
Rackspace
_
f the proposed "EventScheduler" becomes a real project,
which OpenStack Program should it live under?
Third question: Is anyone actively working on this stuff? :)
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing lis
r Heat stay
> focused on making HOT template authors' and users' lives better.
>
>
I agree that the specification of which configs go on which servers should
be separated from both. This is how the good configuration tools like
puppet work anyway: you specify your servers, yo
g
> something that had already disappeared usually resulted in an error (i.e.
> we mostly weren't catching NotFound exceptions). I expect this habit dates
> from that era.
>
> I can't think of any reason we still need this, and I agree that it seems
> unhelpf
ore reviewers.
>
>
It would be so much nicer if there were some easy way for the reviewer
himself to fix the typos directly (in a way that can trivially be accepted
by the submitter of the patch into his own patch -- with a click of a
button).
--
Christopher Armstrong
http://radix.twistedm
ed on all points. I think Gerrit is nice in that it automates a lot of
stuff, but unfortunately the workflow has not encouraged the best behavior
for reviewers. This is a good list to follow -- but how can we be sure
people will? This mailing list thread will only be seen by a small number
of reviewer
n of an API matches its
specification and documentation, which is a problem that plagues many
OpenStack projects right now.
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_set(None) in
a check_delete_complete method?
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this leads to more cool stuff for the Openstack community!
>
>
Congrats! I'm glad you guys finally released the code :)
Does Cisco (or anyone else) plan to continue to put development resources
into these projects, or should we basically view them as reference code for
solving particular
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
is would have an
effect is if there's another resource depending on the ComputeReady *that's
also being updated at the same time*, because the only effect that a
dependency has is to wait until it is met before performing create, update,
or delete operations on other resources.
utoScalingGroup, through which the template author can
> request usage of the AS service.
Yes.
> OpenStack in general, and Heat in particular, need to be much better at
> traceability and debuggability; the AS service should be good at these too.
Agreed.
> Have I got this right?
ts the
simplicity of knowing only about Nova and autoscaling.
To conclude, I'd like to just say I basically agree with what Clint,
Keith, and Steven have said in other messages in this thread. I
doesn't appear that the design of Heat autoscaling (informed by Zane,
Clint, Angus and othe
On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2013-08-16 09:36:23 -0700:
> > On 16/08/13 00:50, Christopher Armstrong wrote:
> > > *Introduction and Requirements*
> > >
> > > So there's kind of a perf
On Thu, Aug 15, 2013 at 6:39 PM, Randall Burt wrote:
>
> On Aug 15, 2013, at 6:20 PM, Angus Salkeld wrote:
>
> > On 15/08/13 17:50 -0500, Christopher Armstrong wrote:
>
> >> 2. There should be a new custom-built API for doing exactly what the
> >> autoscali
ying to gradually work the design into the native Heat autoscaling
design, and we will need to solve the autoscale-controlling-InstanceGroup
issue soon.
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rk a review as -1 if it *only* has bikeshedding in it. I would
love to see a culture of reviewing that emphasizes functional correctness,
politeness, and mutual education.
And given the rationale from Robert Collins, I agree that the module-import
thing should be one of the flakes that allows exceptio
vaclient, python-keystoneclient,
and three other clients for OpenStack services. You're suggesting that
its test suite should start up instances of all those OpenStack
services with in-memory or otherwise localized backends, and
communicate with them using standard python-*client functional
case that Alex is discussing, so I
think it can work well.
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e are certainly many other
subjects about autsocale design that we need to thrash out, but I think we
can start separate threads for those other issues.
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStac
if applied properly.
>
It seems we could trivialize the task of keeping your template up to date
by providing an API for fetching a template that reflects the current
stack. Does that sound sensible given the current direction of the design
of Heat?
--
IRC
Hi Adrian, thanks for the response. I'll just respond to one thing
right now (since it's way after hours for me ;)
On Tue, Jun 18, 2013 at 6:32 PM, Adrian Otto wrote:
> On Jun 18, 2013, at 3:44 PM, Christopher Armstrong
>
> wrote:
>
>> tl;dr POST /$tenant/stacks
ma of
inputs and outputs to the resources/ collection -- I'm particular
interested in JSON hyperschema. I'm not sure how it handles
heterogeneous collections like this.
--
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mai
53 matches
Mail list logo
