07:01:31 <stevebaker> #startmeeting heat
07:01:32 <openstack> Meeting started Wed Jun 10 07:01:31 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:01:35 <openstack> The meeting name has been set to 'heat'
07:01:36 <asalkeld> o/
07:01:40 <stevebaker> #topic rollcall
07:01:47 <Qiming> hi
07:01:52 <elynn> o/
07:01:55 <skraynev> o/
07:02:04 <KanagarajM> hi
07:02:12 <ochuprykov> hi
07:03:08 <stevebaker> #topic Adding items to the agenda
07:03:10 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-06-10_0700_UTC.29
07:03:15 <shardy> o/
07:03:21 <stevebaker> shardy: hai!
07:03:32 <shardy> sorry I'm late
07:04:51 <stevebaker> feel free to add anything, or paste it here. lets move on in the meantime
07:04:53 <stevebaker> #topic heat reviews https://etherpad.openstack.org/p/heat-reviews
07:05:02 * asalkeld in-n-out - making food for kids
07:05:23 <stevebaker> https://review.openstack.org/#/c/178046/ is stale, I'll remove it for now
07:06:05 <skraynev> I'd ask to review this one https://review.openstack.org/#/c/180539/
07:06:30 <stevebaker> KanagarajM: I'll make https://bugs.launchpad.net/heat/+bug/1353670 a High
07:06:31 <openstack> Launchpad bug 1353670 in heat "Stack Abandon is unsafe" [Medium,In progress] - Assigned to Kanagaraj Manickam (kanagaraj-manickam)
07:06:33 <skraynev> after that I think, that new job will be green for all clients patches :)
07:06:45 <skraynev> and we will make it voting
07:06:57 <KanagarajM> stevebaker: sure.
07:08:32 <stevebaker> skraynev: what is post_test_hook for?
07:08:57 <stevebaker> ah, heatclient
07:09:32 <skraynev> stevebaker: aha :) for launching functional tests with env variables on the gate
07:09:41 <stevebaker> its already in the list
07:10:15 <stevebaker> no change to the Core feature changes (convergence etc). reviews would be welcome
07:10:19 <skraynev> stevebaker: ok, just wanted to give update about it ;)
07:10:39 <stevebaker> skraynev: I'll take a look tomorrow, unless it is approved before that
07:10:50 <skraynev> stevebaker: cool! thx
07:11:43 <stevebaker> lots of specs to review
07:12:28 <stevebaker> looks like about half of them might be close
07:13:34 <stevebaker> #topic High priority bugs
07:13:53 <stevebaker> take a look at the link in the agenda, too big to paste here https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-06-10_0700_UTC.29
07:14:44 <stevebaker> I'm not seeing anything new there
07:15:20 <asalkeld> no, many could be medium priority
07:15:42 <stevebaker> there are a bunch of High, In Progress which could be put in the heat-reviews list
07:15:51 <stevebaker> I'll do that tomorrow
07:15:55 <asalkeld> ok
07:16:48 <stevebaker> We could discuss what to do about https://bugs.launchpad.net/heat/+bug/1463531
07:16:50 <openstack> Launchpad bug 1463531 in heat "get_attr doesn't work with block_device_mapping" [High,In progress] - Assigned to Rabi Mishra (rabi)
07:17:23 <asalkeld> is rabi around?
07:17:36 <shardy> ramishra: ^^
07:17:37 <stevebaker> rather, about the general issue of validation failing early because non-created resources result in get_attr returning None
07:18:31 <stevebaker> I'm not sure https://review.openstack.org/#/c/190008/ would help
07:19:10 <asalkeld> stevebaker: there is a spec that will help
07:19:11 <stevebaker> None due to not specified is different to None due to get_attr eval
07:19:33 <asalkeld> property groups
07:19:41 <asalkeld> KanagarajM: ^
07:20:02 <asalkeld> that will at least see if a value is provided
07:20:27 <asalkeld> stevebaker: the other option is to look at self.properties.data['property']
07:20:30 <KanagarajM> asalkeld: yes,  it should take care
07:20:44 <asalkeld> that should "see" if a value is provided
07:21:18 <KanagarajM> asalkeld: while evaluating the depenedecy prps.
07:21:31 <skraynev> asalkeld: I have met a lot of potential places, where we can get same issue
07:21:50 <asalkeld> yip, it's a common problem
07:22:04 <stevebaker> asalkeld: yeah, we'll need to decide if resource validation methods need to be aware of provided None vs default None, or if we can handle this in a general way
07:23:00 <stevebaker> asalkeld: maybe something like self.properties.is_provided('property')
07:23:09 <asalkeld> stevebaker: sure
07:23:12 <stevebaker> KanagarajM: which blueprint?
07:23:17 <shardy> stevebaker: amounts to the same thing doesn't it?  We just need to differentiate (provided, default) from get_attr?
07:23:51 <shardy> but then indirect get_attrs are still tricky e.g nested stacks, hence the strict_validate workaround..
07:23:51 <KanagarajM> stevebaker: https://review.openstack.org/#/c/172386/
07:24:37 <stevebaker> KanagarajM: ah, so it just makes more of our validation declarative?
07:24:56 <KanagarajM> stevebaker: yes.
07:25:23 <stevebaker> that would help, we probably need a solution for python validation too
07:26:13 <stevebaker> #topic Open Discussion
07:26:31 <KanagarajM> stevebaker: I missed to ask about a spec,
07:26:46 <KanagarajM> Monasca resource plugin https://review.openstack.org/174262
07:27:35 <KanagarajM> I have recently updated to remvoe the contrib entry
07:27:47 <KanagarajM> based on the decision made in summit.
07:28:07 <stevebaker> KanagarajM: I'm sure you could start that blueprint with the expectation that the spec will be approved soon
07:28:34 <KanagarajM> stevebaker: sure :) Thanks.
07:28:50 <ochuprykov> I'd like to discuss this spec https://review.openstack.org/#/c/183506/9 about batching
07:30:02 <asalkeld> ochuprykov: what is the question about it?
07:30:41 <therve> The fact that this spec needs to exist is super sad :/
07:30:44 <ochuprykov> asalkeld: the main observations were about common parts between asg and resource_group
07:31:21 <stevebaker> ochuprykov: yes that seems like a valid concern
07:31:48 <asalkeld> stevebaker: if it makes sense
07:31:59 <stevebaker> sure
07:32:06 <skraynev> therve: why ?
07:32:18 <skraynev> why is it sad ?
07:32:25 <shardy> skraynev: because we've got two parallel implementations of essentially the same thing :(
07:32:27 <therve> skraynev, "Nova doesn't work, let's work around it in Heat"
07:32:34 <asalkeld> ochuprykov: i think just a little section on what code can/can't be shared
07:32:37 <shardy> oh, and that too ;)
07:32:38 <therve> shardy, Well that too
07:32:44 <ochuprykov> shardy: not the same
07:33:09 <ochuprykov> shardy:  I decided to remove min_in_service from properties as not relevant
07:33:18 <shardy> ochuprykov: functionally, they do the same thing, the diverged implementation is a historical mistake
07:33:22 <asalkeld> shardy: as soon as we made aws vs. openstack resources that was going to be the case
07:33:26 <shardy> which, ideally, it would be good not to perpetuate
07:33:33 <skraynev> therve: honestly, I think that each project on scale with 100 input requests will fails....
07:34:01 <asalkeld> shardy: then we should only do aws resources?
07:34:13 <asalkeld> i think not :-O
07:34:20 <ochuprykov> shardy:  batching can be applied to create, and not only to update of existing resources
07:34:28 <skraynev> therve: anyway I agree, that it's not Heat work in the perfect world :)
07:34:47 <shardy> asalkeld: No, I don't really get why you would say that, inheriting from the AWS implementation was also a mistake
07:35:09 <shardy> I thought we agreed to refactor so we had a library of *group functions, like many months ago
07:35:24 <shardy> but we're still discussing how to duplicate functionality in multiple places instead
07:35:37 <asalkeld> ok, so you just worried about using library code?
07:35:52 <ochuprykov> shardy:  2 main parts that can be common: create_templates and _rolling_update
07:36:09 <shardy> asalkeld: I just would prefer we didn't end up with (potentially complex and hard to maintain) batch replacement code in two or more places
07:36:30 <ochuprykov> but _rolling _update in this case have different logic
07:36:57 <asalkeld> shardy: we dont' live in a perfect world
07:37:10 <skraynev> shardy: so you suggest to make a refactoring with moving common functions for this case. and after that add batching to resource_group, right?
07:37:10 <ochuprykov> no need to have min_in_service instances worked during batching
07:37:16 <asalkeld> i'd rather have the feature than not
07:37:22 <shardy> asalkeld: Sigh, yeah I know, I'm just proposing we stop the divergence, if possible :)
07:37:44 <shardy> skraynev: if that can be done in a sane way, yes
07:38:03 <asalkeld> can we agree to share implementation as much as sanely possible?
07:38:06 <ochuprykov> but there is no many common parts
07:38:37 <ochuprykov> we have different rolling_update logic and different _create_template method
07:38:40 <ramishra> Hi
07:38:41 <therve> ochuprykov, Because ResourceGroup just doesn't suport the feature
07:38:53 <therve> If it did there would be more common parts
07:38:58 <shardy> ochuprykov: that is the whole problem...
07:39:18 <ochuprykov> some places of code can be moved to stack_resource
07:39:36 <ochuprykov> but this implies to many changes on dependant classes
07:39:47 <therve> Yes
07:40:02 <ochuprykov> i'd rather not to do such refactoring in this spec
07:40:05 <asalkeld> ochuprykov: rathe move code out of classes and into utility fuctions
07:40:15 <asalkeld> ochuprykov: why not?
07:40:22 * shardy sighs
07:40:23 <asalkeld> it's a part of development
07:40:36 <asalkeld> shardy: can you explain more details of what you want in the spec review?
07:40:44 <asalkeld> hard to explain stuff here
07:40:54 <ochuprykov> asalkedl: we will get ugly functions with many parameters and if-else logic dependant on resource type
07:41:19 <shardy> asalkeld: Ok, I already stated my opinion, but I can do some deeper analysis if ochuprykov isn't keen to do it
07:41:29 <shardy> (I've already commented on the review)
07:41:36 <asalkeld> ok
07:41:58 <asalkeld> i'll look at the spec too - tomorrow
07:42:22 * asalkeld is getting hungry watching everyone else eat supper
07:42:41 <stevebaker> anything else?
07:42:50 <stevebaker> or I shall #endmeeting
07:42:58 <asalkeld> call it
07:43:06 <stevebaker> #endmeeting