12:00:52 <therve> #startmeeting heat
12:00:53 <openstack> Meeting started Wed May 28 12:00:52 2014 UTC and is due to finish in 60 minutes.  The chair is therve. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:56 <openstack> The meeting name has been set to 'heat'
12:00:57 <therve> Let's do this!
12:01:03 <therve> #topic Roll call
12:01:10 <zaneb> o/
12:01:12 <pas-ha> o?
12:01:16 <pas-ha> o/
12:01:17 <tspatzier> hi all
12:01:18 <skraynev> o/
12:01:22 <Qiming> o/
12:01:23 <kanabuchi> o/
12:01:39 <zaneb> (I asked therve to chair because it's 8am & I am not with it yet) ;)
12:02:05 <therve> shardy, around maybe?
12:02:22 <skraynev> therve: I wanted to ask same
12:02:31 <zaneb> pas-ha: you'll want to get that arm looked at
12:02:40 <skraynev> looks like we lose him
12:02:46 <therve> o§
12:03:25 <therve> Moving on, hopefully he'll catch up
12:03:27 <therve> #topic Adding items to the agenda
12:03:32 <zaneb> therve: wasn't he going to OpenStack in Action? might be travelling
12:03:33 <pas-ha> zaneb, that was scratching my head :)
12:03:35 <therve> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
12:03:46 <therve> zaneb, Ah maybe. I'm here and haven't seen him though :)
12:04:35 <therve> Not much going on this week, it may be a short meeting
12:05:16 <therve> #topic Review last meeting's actions
12:05:21 <skraynev> therve: may be
12:05:43 <therve> We had actions for andrew and cyli, not around of course...
12:05:55 <therve> zaneb, Can you sync with them later today?
12:05:56 <zaneb> the specs repo thing happened
12:06:03 <therve> Ah sweet
12:06:22 <zaneb> has anyone seen evidence of the jenkins job?
12:06:49 <skraynev> nope :(
12:06:50 <tspatzier> Did not notice anything so far. Will there be some announcement on the ML when this gets activated?
12:06:51 <pas-ha> more info on specs repo?
12:06:58 <zaneb> #action zaneb to sync with andrew_plunk on status of Rackspace CI Jenkins job
12:07:29 <zaneb> #link http://git.openstack.org/cgit/openstack/heat-specs
12:07:29 <therve> Cool
12:07:48 <therve> zaneb, What's the next step for spec repo?
12:07:55 <zaneb> after a discussion on the ML it was changed from orchestration-specs back to heat-specs
12:08:28 <zaneb> mordred added the cookiecutter framework contents for us
12:08:41 <zaneb> SpamapS: already has a review up for the first one I think
12:09:06 <zaneb> the plan is that new bp proposals should be added there
12:09:06 <skraynev> zaneb: So currently it is empty, right?
12:09:14 <zaneb> instead of launchpad
12:09:45 <therve> Cool, moving on
12:09:45 <zaneb> keep it lightweight
12:09:55 <zaneb> only fill in as much info as it appropriate
12:10:01 <zaneb> s/it/is/
12:10:10 <shardy> oops sorry I'm late
12:10:13 <tspatzier> zaneb: will we not be using launchpad at all any longer?
12:10:18 * shardy forgot the new meeting time
12:10:25 <skraynev> shardy: not much
12:10:35 <tspatzier> I mean for features like dependency handling of BPs it was nice.
12:10:44 <zaneb> tspatzier: launchpad will remain around, but it won't be the entry point for new bps
12:11:03 <zaneb> I believe there is provision for dependencies in the repo
12:11:31 <zaneb> #info new blueprint proposals should go into heat-specs, not into launchpad
12:12:51 <therve> zaneb, What's the git URL?
12:12:54 <zaneb> tspatzier: there's going to be a script to copy bps from the repo into launchpad
12:13:04 <zaneb> therve: http://git.openstack.org/cgit/openstack/heat-specs
12:13:16 <therve> #info http://git.openstack.org/cgit/openstack/heat-specs Spec URL
12:13:27 <tspatzier> zaneb: ok, that's good. So nothing to be done. Because I opened a BP earlier this week.
12:13:28 <pas-ha> therve, github.com/openstack/heat-specs
12:13:29 <asalkeld> o/
12:13:32 <zaneb> I #linked it above already ;)
12:13:41 <therve> Oh sorry
12:13:42 <Qiming> looks like the dependencies are managed manually... see the last few lines here: http://git.openstack.org/cgit/openstack/heat-specs/tree/specs/template.rst?id=199101dec864ceed395fbe4e1e0c5f4c98d1e818
12:14:19 <therve> Anything else on that topic?
12:14:36 <zaneb> Qiming: yeah, not sure if the script will be able to import those into launchpad. hopefully.
12:14:49 <Qiming> right, hopefully
12:15:41 <zaneb> we can move on, unless people want to hear the gory details ;)
12:16:07 <therve> #topic Critical issues sync
12:16:39 <therve> shardy posted a patch for that worker issue
12:16:44 <shardy> #link https://review.openstack.org/#/c/94737/
12:17:06 <shardy> feedback appreciated, as we've had various discussions about if we want to enable workers at all
12:18:04 <therve> Yeah, it's pretty tricky
12:18:11 <shardy> I'm somewhat conflicted, having invested time looking into the fix, I'd kinda like it to go in, but I'm also fully appreciative of the argument for forcing heat-engine to one worker
12:18:37 <shardy> AFAICT provided you remember the service entry point is start(), all should work OK
12:19:05 <skraynev> shardy: I have seen oslo code and you are correct
12:19:05 <shardy> but there's undoubtedly some hidden complexity which can be avoided if we say spawning multiple processes is systemd's problem
12:19:13 <zaneb> shardy: yeah, I am a bit sceptical of this approach
12:19:26 <zaneb> workers are effectively separate engines
12:19:31 <zaneb> but not managed as such
12:19:58 <zaneb> e.g. if the parent dies probably all hell breaks loose?
12:20:03 <therve> Yeah eg we don't have engine id in the logs
12:20:26 <shardy> Well the other option is to revert 0bb1232 and disallow the config option
12:20:34 <zaneb> only the init process can properly manage multiple engines
12:20:37 <therve> zaneb, Or if one process goes crazy you need to restart everything
12:20:49 <shardy> therve: That will still be an issue if you start multiple engines via a script though won't it?
12:21:08 <zaneb> and only the deployer can decide what the Right Way to do that is
12:21:10 <therve> shardy, Because we log to a single file?
12:21:29 <shardy> therve: yes, although there are pid's logged IIRC
12:21:33 <zaneb> I know Clint wants it to be automatic, without the deployer involved...
12:21:59 <shardy> zaneb: yeah, that was the main reason for persevering trying to find a solution which didn't just rip out his stuff
12:22:17 <shardy> If everyone's -2 on it, I'll abandon and propose a revert of his patch
12:22:32 <zaneb> shardy: but I think the deployer _has_ to be involved
12:22:43 <zaneb> shardy: what is the default on that config option?
12:22:55 <therve> The default in master is 1
12:23:07 <shardy> zaneb: now, it's 1, but with 5604168 (which we already reverted) it's the number of CPUs
12:23:18 <shardy> which is when things started breaking
12:23:24 <zaneb> ok, then I am not -2 on this patch
12:23:34 <shardy> with my patch, #cpu's works fine
12:23:35 <zaneb> I am very -2 on the default not being 1
12:23:41 <shardy> but I think we should leave the default as 1
12:23:57 <therve> That sounds like a reasonable trade-offs
12:24:00 <zaneb> shardy: btw, everything is going to one log file?
12:24:01 <shardy> then folks can explicitly choose the forking behavior if they want
12:24:19 <therve> Although it'd be nice to test this option in the gate somehow
12:24:20 <shardy> zaneb: yes, but there are PID's in the log lines so you can see what is what
12:24:36 <skraynev> I agree default should be 1
12:24:41 <zaneb> that's a bit icky
12:24:41 <shardy> and I added some ppid's in the log from start() which makes it a bit clearer
12:25:20 <zaneb> it would be nice to have a command-line arg to specify a log suffix
12:25:39 <shardy> zaneb: we can probably add a config option to do that easily enough
12:26:22 <zaneb> so then you could do "systemctl start heat-engine@1.service",  "systemctl start heat-engine@2.service" &c. and have them all go to separate log files
12:27:05 <therve> Should we create a bp? Or a spec now I guess
12:27:11 <shardy> zaneb: Ok, if we're going ahead with my patch I can look into adding the log config
12:27:21 <shardy> therve: is a logging tweak really BP worthy?
12:27:59 <shardy> zaneb: jasond made the valid observation that having the forking behavior defaulted to off risks it becoming fragile and breaking over time
12:28:04 <therve> shardy, Maybe not :)
12:28:14 <shardy> so we should probably work towards a gate test if we're keeping this in
12:29:00 <therve> You mean a different gate with workers > 1?
12:29:20 <zaneb> shardy: btw http://0pointer.de/blog/projects/instances.html
12:29:25 <shardy> therve: I mean some way of spinning up a devstack with num_engine_workers>1 for some subset of tests
12:29:57 <shardy> maybe we could do something like have the grenade smoke tests use that config when we eventually get them working
12:30:09 <skraynev> shardy: as non-voting gates ?
12:30:40 <shardy> zaneb: thanks, useful link :)
12:31:05 <shardy> skraynev: no, eventually we'd want to gate on the fact that multiple workers work
12:31:27 <shardy> so e.g someone doesn't stick another RPC object assignement in the service constructor and break things
12:31:35 <skraynev> shardy: but it will be included in Jenkins report, right?
12:32:20 <shardy> skraynev: yes
12:33:47 <therve> OK, anything else on that issue? Other subjects?
12:34:04 <skraynev> shardy: so I think it makes sense. also will be useful have a set of num_engine_workers f.e. [1, 2, 4] for show performance or troubles
12:34:36 <Qiming> Gentlemen, I'm wondering how can we apply SoftwareConfig into some/all members of an InstanceGroup or ResourceGroup ...
12:34:49 <therve> zaneb, I saw your comments on the metadata resource interface. Should we do something?
12:35:46 <zaneb> therve: imo we should. I learned at the summit that there are a _lot_ of out-of-tree plugins being created
12:35:56 <shardy> Qiming: create a nested stack template containing a SoftwareDeployment resource and instance, and pass in the SoftwareConfig ID as a parameter?
12:36:10 <zaneb> that seems like a pretty big break of the API contract
12:36:30 <zaneb> for reasons that were unclear
12:36:39 <Qiming> shardy, that worth a try, thanks.
12:37:15 <shardy> therve: is this the cinder json/dict thing?
12:37:18 <therve> zaneb, Performance optimization was the reason AFAIU. But I think you're right
12:37:34 <therve> shardy, No, the metadata property on the Resource class that disappeared
12:37:50 <asalkeld> we should look at versioning the plugin api at some point
12:37:51 <zaneb> therve: how does it perform better if you just s/metadata/get_metadata()/ ?
12:37:57 <zaneb> it's still a db lookup
12:38:23 <therve> zaneb, get_metadata will only do it once?
12:38:47 <zaneb> asalkeld: you're probably right, but that is really hard :/
12:38:49 <therve> Actually no
12:39:09 <therve> zaneb, metadata_get uses the metadata passed at load, which are loaded in one query
12:39:28 <zaneb> therve: so if we add an @property metadata that just calls metadata_get()... what difference does it make?
12:39:39 <therve> zaneb, Probably none
12:40:05 <therve> We need metadata_get to have the refresh parameter though
12:40:13 <zaneb> that's why I it's unclear to me why we're breaking the API
12:40:34 <zaneb> we can have both
12:40:39 <zaneb> sounds like an easy fix
12:40:40 <therve> Yeah I think so
12:40:50 <therve> We missed it at that time
12:41:56 <therve> zaneb, Can you sync with Steve on that subject?
12:42:36 <zaneb> #action zaneb to sync with stevebaker on metadata in resource plugin API
12:43:16 <asalkeld> zaneb, what would be interesting is get last cycles resources and see if they work on master
12:43:16 <therve> Thanks
12:43:47 <zaneb> asalkeld: yeah, that *would* be interesting :)
12:44:04 <therve> They use more than what I would consider a public API though
12:44:04 <shardy> asalkeld: that would be an interesting thing to try and automate via grenade ;)
12:44:09 <therve> Like utils modules and stuff
12:44:19 <asalkeld> yip
12:45:13 <shardy> EmilienM: ^^ FYI since we discussed help with getting heat/grenade working
12:47:21 <zaneb> this turned out to be a not-so-short meeting after all :)
12:47:28 <therve> Do we have anything else?
12:47:30 <skraynev> I have one question about babrbican resources ...
12:47:49 <therve> skraynev, Shoot
12:47:51 <zaneb> therve: let's move to open discussion
12:47:59 <therve> #topic Open discussion
12:48:09 <shardy> Do we have any clarity yet on who's doing what re convergence?
12:48:27 <skraynev> I hope, that all see situation on review with barbican resources
12:48:27 <shardy> Seems like we all need to be reviewing SpamapS spec and figuring out how we can divide the work
12:48:35 <zaneb> shardy: last I heard, Clint was in Bangalore
12:48:43 <asalkeld> any convergence on the design:-O
12:48:47 <skraynev> some properties have only one allowed values and it 's default in that time
12:48:51 <therve> shardy, I don't know about convergence, but I should work on the observer part
12:49:05 <zaneb> shardy: but I believe he put up a specs review
12:49:21 <skraynev> Is it normal , or default values is redundant in this situation ?
12:50:10 <therve> skraynev, Possibly it's for future enhancements?
12:50:29 <asalkeld> https://review.openstack.org/#/c/95907/
12:50:40 <zaneb> skraynev: if only one allowed value exists, then a default value is needed otherwise it will fail if you don't specify anything. obviously the whole property is redundant atm
12:50:52 <skraynev> therve: may be, but existing documentation is very poor
12:51:25 <zaneb> skraynev: link?
12:51:54 <skraynev> #link https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
12:51:55 <shardy> asalkeld: thanks, looks like we need a lot more detail on the proposed steps to implement
12:52:12 <asalkeld> it's just a problem statement
12:52:55 <skraynev> zaneb:may be but, the biggest part of values in documentation are marked as optional
12:52:56 <therve> shardy, +1
12:52:58 <asalkeld> -spec is a bad name it should also have design elements
12:53:17 <skraynev> so it looks confused.
12:53:40 <zaneb> asalkeld: traditionally specs = requirements + high-level design
12:54:14 <zaneb> not defending that tradition btw ;)
12:54:19 <asalkeld> not really, spec == how it should behave
12:54:21 <shardy> Ok, well we need much more work on the design part then ;)
12:54:45 <shardy> so we can clarify the work to do and order it needs to be done in etc
12:54:49 <skraynev> shardy: and more pictures ;)
12:54:55 <shardy> skraynev: +100 ;)
12:55:56 <asalkeld> some is going to have fun with ascii art
12:56:04 <asalkeld> someone
12:56:06 <zaneb> lol
12:56:38 <skraynev> no - no - no ;)
12:56:48 <zaneb> does anyone else hate the new line-numbers-on-the-right thing in Gerrit as much as I do?
12:57:16 <shardy> zaneb: yes
12:57:28 <skraynev> zaneb: +1 , I prefer that they will be configured with option "hide all"
12:57:31 <shardy> I wish you could turn them off completely to make it easier to cut/paste
12:57:33 <therve> It doesn't bother me too much :)
12:57:43 <pas-ha> i have them on the left...
12:58:01 <pas-ha> with the n"new" design
12:58:30 <therve> zaneb, You can use the new change view, it has numbers on the left
12:58:38 <skraynev> zaneb: well about barbican. As I understand the right way is to ask guys from barbican team about what should be ? and then share their answers.
12:58:39 <therve> Oh pas-ha just said that :)
12:59:01 <zaneb> therve, pas-ha: interesting, thanks
12:59:03 * asalkeld heads off to bed ...
12:59:10 <therve> On that none
12:59:12 <therve> note
12:59:17 <therve> Thanks all!
12:59:20 <therve> #endmeeting