07:01:51 <asalkeld> #startmeeting heat
07:01:52 <openstack> Meeting started Wed Jul  8 07:01:51 2015 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:01:56 <openstack> The meeting name has been set to 'heat'
07:01:58 <asalkeld> https://wiki.openstack.org/wiki/Meetings/HeatAgenda
07:02:03 <asalkeld> not filled in ^
07:02:15 <asalkeld> #topic rollcall
07:02:26 <sirushti> o/
07:02:28 <asalkeld> stevebaker: feel free to take over
07:02:32 <kairat_kushaev> o/
07:02:35 <huangtianhua> ：）
07:02:37 <skraynev> o/
07:02:40 <Qiming> hi
07:02:45 <KanagarajM> hi
07:03:02 <tspatzier> hi
07:03:02 <asalkeld> #topic Adding items to agenda
07:03:10 <shardy> o/
07:03:25 <asalkeld> we have seriously no agenda :-O
07:03:31 <asalkeld> so come on folks
07:03:53 <shardy> I wanted to add the nested validation BP as it's not had much feedback other than from jdob
07:04:04 <asalkeld> k
07:04:10 <asalkeld> maybe any important bugs
07:04:31 <asalkeld> well let's get started and add more as needed
07:04:50 <asalkeld> #topic the nested validation BP that is not getting reviewed ... grrr
07:04:54 <asalkeld> ;)
07:05:08 <shardy> haha
07:05:09 <asalkeld> shardy: link
07:05:16 <shardy> #link https://review.openstack.org/#/c/197199/
07:05:37 <shardy> So, this one is supposed to compliment the constraints/capabilities one which has gotten pretty good feedback
07:05:57 <asalkeld> shardy: were you not the cause for that issue? i seem to remember you didn't want nest stack validation at some point
07:06:14 <xek> o/
07:06:17 <shardy> The idea is to enable discovery of the parameters required/possible for the entire tree, e.g accessible via parameter_defaults
07:06:44 <shardy> asalkeld: No, I disabled *value* validation, because most values are None at the time of validation and all the new custom constraints broke everthing
07:06:51 <ramishra> hi
07:07:06 <shardy> This is about generating a schema for the tree, which was irrelevant before parameter_defaults existed
07:07:36 <asalkeld> shardy: my patch might help?
07:07:46 <shardy> but now that they do, it opens the possibility of "pluggable" templates, which may take additional parameters (other than the subset provided from the parent template)
07:07:50 <asalkeld> https://review.openstack.org/#/c/197402/
07:08:16 <shardy> asalkeld: Yeah that's maybe part of it
07:08:18 <asalkeld> mmm, i need to read the spec
07:08:37 <shardy> my main question is do we need a new "template-inspect" API, or can we piggy-back this recursive validation on template-validate
07:08:39 <pas-ha> hi all
07:08:39 <asalkeld> not a fan of too much plugg'n
07:09:18 <shardy> I prefer the latter, because it extends the existing parameters schema template-validate exposes
07:09:31 <shardy> asalkeld: easy to say until you're dealing with a tree of 90 nested stacks :\
07:09:48 <shardy> then you realize the limitations of our current composition model :)
07:09:51 <skraynev> shardy: I will add your spec to this list https://etherpad.openstack.org/p/heat-reviews
07:09:58 <shardy> skraynev: Ok, thanks
07:09:59 <asalkeld> shardy: you write way too much text - phew
07:10:15 * shardy sighs
07:10:18 <asalkeld> that's a book
07:10:48 <shardy> In the other review folks wanted *more* detail because they couldn't understand the use-case
07:10:50 <asalkeld> shardy: i'll have a look a bit later
07:10:58 <shardy> Add a comment and I'll strip it back to minimal
07:11:10 <asalkeld> shardy: mostly joking - just takes time to read:-O
07:11:47 <Qiming> a book on Heat is actually not a bad idea, ;)
07:12:16 * shardy offers to help given his apparent excessive wordiness ;D
07:12:33 <shardy> anyway, that's all, please add comments if you can manage to read it all
07:12:46 <shardy> I'd like to start coding both specs fairly soon, if possible
07:12:53 <asalkeld> #topic importing bugs ...
07:12:57 <asalkeld> grr
07:13:01 <asalkeld> #topic important bugs ...
07:13:11 <asalkeld> any?
07:13:57 <pas-ha> is triple-o stable lately? last week AFAIR one could not trust its job result too much
07:14:18 <asalkeld> i don't see any new high priority bugs...
07:14:18 <shardy> pas-ha: there was an outage last week, stable again now AFAIK
07:14:30 <pas-ha> shardy, cool, thanks
07:14:33 <sirushti> btw, does this count as important? -> https://bugs.launchpad.net/heat/+bug/1470709?
07:14:33 <openstack> Launchpad bug 1470709 in heat "Using wrong auth encryption key can lead to data loss" [Undecided,New]
07:14:33 <asalkeld> #topic open discussion
07:14:48 <ritesh> hi all I wanted to dicussu about https://review.openstack.org/#/c/187524/13
07:14:55 <ritesh> heat stack pause and unpause
07:15:19 <asalkeld> sirushti: wouuld require major config messup
07:15:26 <asalkeld> ritesh: shoot
07:15:34 <shardy> asalkeld: I'm not sure how we could fix that, without storing the key in the DB, which is obviously impossible
07:15:53 <ritesh> I got comment from steve baker, I am not able to go up with the specs
07:15:57 <ritesh> can we have conclusion here
07:16:01 <pas-ha> ritesh, I'm actually in favor of stevebaker's suggestion
07:16:02 <sirushti> asalkeld, cool
07:16:11 <skraynev> asalkled: about high priority bugs, we can take a look link from previous meeting  http://bit.ly/1FnhaIK
07:16:21 <skraynev> #link  http://bit.ly/1FnhaIK
07:16:27 <pas-ha> we should not replicate Nova's states
07:16:35 <therve> sirushti, The new fernet algo fixes that
07:16:37 <ritesh> ok <<pas-ha>> If we use the suspend or pause porlicy then we have to write to each resoucre of Nova:OS:Sever.  When we are talking about Suspend / Pause to a stack , the main intention is to have on whole stack . Flaver or Image update policy are applicable to servers which demands.
07:17:22 <shardy> ritesh: does pause/unpause affect any other resource except Servers?
07:17:30 <sirushti> therve, oh cool, I'll take a look at that then, thanks
07:17:31 <pas-ha> shardy, yep
07:17:41 <ritesh> no it will not effect apart of servers @shardy
07:17:43 <shardy> ritesh: for example, suspend resume does stuff like disabling users when the stack is suspended IIRC
07:18:09 <asalkeld> ritesh: having lots of actions is a large maintenance burden, it should be widely useful and applicable to most resource types
07:18:24 <asalkeld> imho
07:18:33 <pas-ha> that's why I also do not like adding an extra stack action just for server
07:18:42 <asalkeld> yeah
07:19:01 <ritesh> so how do we handle now for pausing a stack in heat ?
07:19:22 <asalkeld> ritesh: you mean the servers within the stack?
07:19:27 <ritesh> yes
07:19:31 <pas-ha> server pause is simply not supported as of now AFAIU
07:19:49 <asalkeld> pas-ha: he is suggesting adding it
07:19:54 <asalkeld> as a new stack action
07:19:58 <ritesh> yes I am suggesting adding it
07:20:13 <shardy> So, stevebaker is proposing a suspend_policy property which only affects OS::Nova::Server
07:20:19 <pas-ha> yes, and I prefer approach stevebaker pointed in his comment
07:20:20 <shardy> which other resources would need it?
07:20:28 <asalkeld> it would be nice to beable to discover what actions each resource type supported and have them as links for each resource
07:20:47 <shardy> it seems a bit wrong to declare state in the template, but I can see why he proposes it, it's much less code to write and maintain
07:20:58 <pas-ha> well, that's what ideal REST world would be :)
07:21:50 <ritesh> I have alredy wirteen the code for puase and unpause , it is not to complicated to maintain the code
07:21:51 <shardy> pas-ha: well FWIW the idea of the "actions" API was for stuff which only affects stack state, and not it's definition
07:22:03 <shardy> we had this same debate back when I added suspend/resume
07:22:05 <ritesh> actually we are supporing snapshot and resume also
07:22:08 <asalkeld> ritesh: i suspect your spec is not progressing because people are reluctant to +2, but there is not really a nice solution
07:22:37 <asalkeld> ritesh: yeah, tho' i am not sure that was the best idea
07:22:56 <asalkeld> (just cos' there is something there doen't mean we should extend it)
07:22:58 <inc0> while I dislike idea of adding stack pause just for server...maybe stack call-method resume would be nice?
07:23:05 <ritesh> to pause / suspend a stack thorugh template, it means we have to udpate the stack
07:23:27 <ritesh> we are not updating the stack here
07:23:31 <shardy> maybe we need an improved resource level interface, so you have an "action schema" or something, avoiding all the boilerplate handle_foo when a new action is needed
07:23:46 <inc0> while call_method $method will call handle_$method for add applicable resources?
07:23:59 <pas-ha> ritesh, yes, I agree update+suspend instead of than just "pause" is ugly
07:24:00 <shardy> then you can have a generic passthrough inside the engine with the actions supported only defined inside the resource
07:25:02 <asalkeld> ok, well if anyone has ideas, please add to ritesh 's spec review
07:25:15 <shardy> ritesh: I agree, it's the same argument I had with suspend/resume, it's not really a stack update
07:25:18 <ritesh> yes please
07:25:29 <shardy> ritesh: I'll try to refine my ideas re resource interfaces and comment later today
07:25:42 <ritesh> Thank you shardy
07:25:50 <Qiming> there are many resource level actions that are useful, but it may not be a good solution to expose them as stack actions
07:26:27 <asalkeld> +1
07:26:29 <Qiming> e.g. for a nova server, you can do resize, image generation, change password, reboot, rebuild
07:26:32 <shardy> Qiming: You mean we need a resource level actions API?
07:26:36 <kairat_kushaev> So we need to think about common solution for such cases?
07:26:39 <therve> shardy, I don't think suspend_policy means to declare state? It means suspend will do pause on servers, I think?
07:26:57 <pas-ha> Qiming, the idea is to have "any" stack action (REST endpoint) can propagate to resource actions (REST-endpoints)
07:26:57 <shardy> therve: ah!  Ok that might be OK
07:26:58 <ritesh> as sugested by by <inc0> we can have generic call_method <suuspend/resume/pauxe/unpuasu/resize>
07:27:15 <Qiming> shardy, I doubt it, but I'm reluctant to make these things stack actions
07:27:32 <inc0> maybe do this as resource call?
07:27:38 <shardy> Qiming: The argument for making them stack actions is if ordering is important
07:28:06 <shardy> e.g if you must pause/unpause the servers in dependency order, then it has to be a stack action
07:28:39 <shardy> Probably, in many cases, that ordering *is* important
07:28:48 <Qiming> shardy, okay, dependency ...
07:28:49 <shardy> e.g you won't want to unpause your webapp before the DB
07:29:17 <inc0> if we make it generic tho, how do we specify direction of dependency?
07:29:43 <shardy> inc0: the DAG is walked in dependency order on pause and reverse dependency order on unpause
07:29:44 <inc0> you'd like to pause webapp before DB
07:29:51 <shardy> same as for suspend/resume
07:30:20 <shardy> inc0: the dependency order is already known by heat, either implicitly due to get_resource/get_attr or explicitly via depends_on
07:30:29 <inc0> yeah, true
07:30:55 <inc0> and in handle_call we could specify which direction is applicable to this method
07:31:41 <asalkeld> any review requests?
07:31:59 <xek> https://review.openstack.org/#/c/190183/ - looking for reviews
07:32:02 <sirushti> would it be possible to get mistral to do these arbitrary actions? expose the things mistral needs via the api to find out the dependencies and then let it execute these arbitrary actions
07:32:33 <shardy> asalkeld: https://review.openstack.org/#/c/196656/ (I know you've already commented on this a lot but want wider feedback)
07:32:35 <asalkeld> sirushti: i was think that, but it's going to take some time integrating
07:32:44 <asalkeld> and providing examples etc..
07:33:24 <sirushti> probably, but it's a cleaner solution else we'd have arbitrary resource actions and api
07:33:32 <sirushti> maybe
07:33:39 <sirushti> re: review request - https://review.openstack.org/#/c/190641/
07:33:39 <shardy> sirushti: that's an interesting idea, although it sounds a bit like mistral is just proxying some API calls
07:34:14 <shardy> e.g the workflow is inside heat derived from the dependency graph.
07:34:23 <asalkeld> shardy: maybe we could have a way of registing a workflow per resoruce_type/action
07:34:24 <shardy> I suppose we could create the workflow and push it to mistral
07:34:38 <asalkeld> then heat runs the applicable workflow in order
07:34:41 <shardy> asalkeld: Hmm, yeah, I'd be interested to see what that would look like
07:35:04 <asalkeld> yeah, anyones todo list looking super low? ;)
07:36:22 <asalkeld> ooo tour de france highlights on telly
07:36:46 <shardy> asalkeld: it's a good stage :)
07:36:56 <asalkeld> cobbles
07:37:17 <asalkeld> should we end this stage/meeting
07:37:23 <ritesh> Hi, all, could you pleas comment
07:37:24 <ritesh> https://ask.openstack.org/en/question/69487/unable-to-launch-stack-in-kilo-heat/
07:37:26 <ritesh> on this
07:37:35 <asalkeld> looking
07:38:19 <asalkeld> ritesh: that looks like a bug
07:38:23 <skraynev> asalkeld: I suppose, that we can
07:38:33 <sirushti> since everyone's here. I have a question on functional testing actually that's been lingering for some time in my mind - How do we scale the gate with all these new resources?
07:38:59 <ritesh> <asalkeld> so I will file a bug on this
07:39:14 <asalkeld> ritesh: need more info - template etc...
07:39:42 <asalkeld> sirushti: not sure, potentially multiple jobs?
07:39:59 <asalkeld> some projects have 3rd party jobs
07:40:07 <pas-ha> ritesh, and actual procedure how it was installed "converted _my_ heat to debian" is vague
07:40:12 <sirushti> I'm wondering if conditional testing would be a possible idea now that we have devstack plugins
07:40:12 <ritesh> description: stack template generated from OVF file heat_template_version: '2013-05-23' resources:   PL4:     properties:       config_drive: 'True'       flavor: m1.tiny       image: test_final        name: PL4       networks:       - network: 4020952c-9405-4a64-9615-8bea4bdb5009      type: OS::Nova::Server
07:40:33 <pas-ha> ritesh - add that to the bug when you file it
07:40:45 <sirushti> so if someone proposes a patch for a particular resource, we register the endpoint for that resource in keystone, run tests for those resources, else just skip it
07:41:11 <asalkeld> sirushti: need a functional test config option
07:41:12 <ritesh> using pydist tool converted the heatclient and heat source code into depabains and installed that into ubuntu using apt-get install heat debains
07:41:27 <shardy> sirushti: FWIW I think we should avoid adding individual coverage for every single resource, and instead focus on getting good scenario tests which give us good "real world" coverage
07:41:45 <pas-ha> shardy, +1
07:41:53 <shardy> e.g resist turning functional tests into expensive unit tests checking stuff like interfaces
07:42:03 <sirushti> shardy, pas-ha, sure, but we might regress on all the non-important use cases
07:42:23 <shardy> sirushti: I'm saying get coverage for more trivial tests via unit tests
07:42:27 <shardy> which are far cheaper to run
07:42:28 <asalkeld> sirushti: we have our limits
07:42:46 <shardy> then have more complex multi-resource tests run as functiona/scenario tests
07:42:51 <asalkeld> the gate is limited we need to make the best use of it
07:42:59 <shardy> asalkeld: +1
07:43:14 <asalkeld> ok, lets move over to #heat
07:43:19 <asalkeld> #endmeeting