20:00:16 <stevebaker> #startmeeting heat
20:00:17 <openstack> Meeting started Wed Aug 26 20:00:16 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:22 <openstack> The meeting name has been set to 'heat'
20:00:25 <stevebaker> hey all
20:00:28 <stevebaker> #topic rollcall
20:00:33 <shardy> o/
20:00:33 <skraynev_> o/
20:00:50 <Drago> hi
20:00:57 <stevebaker> who wants to be co-chair if I need to leave early?
20:01:13 <skraynev_> I may try ;)
20:01:20 <zaneb> this would be a bad time to announce my presence with a o/
20:01:20 <jasond> o/
20:01:21 <prazumovsky> o/
20:01:25 <stevebaker> #chair skraynev_
20:01:26 <openstack> Current chairs: skraynev_ stevebaker
20:01:27 <pas-ha> o/
20:01:45 <stevebaker> #topic adding items to the agenda
20:01:51 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-08-26_2000_UTC.29
20:03:40 <shardy> stevebaker: will you cover feature proposal freeze under l-3 release?
20:03:49 <stevebaker> shardy: I will
20:04:37 <stevebaker> #topic heat reviews https://etherpad.openstack.org/p/heat-reviews
20:04:40 <shardy> stevebaker: cool, thanks
20:06:06 <skraynev_> do we plan to land all convergence related patches befor l3 ?
20:06:17 <stevebaker> this close to feature freeze we're probably better off following the milestone page rather than this etherpad
20:06:22 <skraynev_> or it may be done later ?
20:06:31 <shardy> I rebased the final part of PATCH updates https://review.openstack.org/#/c/205754/
20:06:48 <stevebaker> shardy: oh yeah, lets get that on the list
20:06:50 <shardy> adding that to the list, or just any feedback would be great :)
20:07:16 <shardy> I'll finish the test for the heatclient patch soon, but that should be the last heat patch AFAIK
20:07:20 <stevebaker> skraynev_: I'm assuming any non-landed convergence changes can be framed as bug fixes after feature freeze
20:07:57 <skraynev_> stevebaker: ok. sounds reasonable
20:08:13 <stevebaker> we will need to figure out what we're doing with Refactor ASG and RG resources before freeze though
20:08:16 <zaneb> I'm currently reworking the scaling-library topic
20:08:37 <zaneb> and of course I reposted some reviews and forgot to re-specify the topic
20:08:58 <stevebaker> #topic prep for liberty-3 release
20:09:00 <zaneb> so there's some under https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1488971,n,z
20:09:06 <stevebaker> feature freeze is a week away!
20:09:13 * stevebaker runs in circles
20:09:22 <stevebaker> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
20:09:29 <stevebaker> #link https://launchpad.net/heat/+milestone/liberty-3
20:09:30 <skraynev_> zaneb: do not forget about batching for different actions ;)
20:09:34 <shardy> zaneb: did you and ramishra reach agreement, your patches appear to overlap and I wasn't sure which series to focus on
20:09:56 <zaneb> shardy: I asked him for reviews but never heard anything
20:09:58 <stevebaker> I may be bugging you for blueprint status updates if it is not obvious
20:10:02 <zaneb> but I found some bugs on my own
20:10:13 <zaneb> hence currently reworking with mondo unit tests
20:10:48 <stevebaker> zaneb: can you give us a quick summary on the difference between the series and why yours is better? ;)
20:10:59 <zaneb> by the time that's done hopefully my patches will be self-evidently correct ;)
20:11:40 <shardy> zaneb: so far yours do look good and are definitely easier to review
20:11:45 <zaneb> stevebaker: well, the ResourceGroup implementation of rolling updates is really inefficient from a user point of view, because it comes with all the limitations of resource groups
20:12:03 <zaneb> the InstanceGroup implementation is also really inefficient because of a bug
20:12:11 <zaneb> fix for that is in https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1488971,n,z
20:12:20 <shardy> I just wanted to see if there was scope for collaboration vs wholesale abandonment of the work ramishra started
20:12:45 <zaneb> rabi wants to base ASG on RG, which is a mistake because it is a big regression
20:13:10 <zaneb> I want them all to use code from a common scaling library
20:13:26 <zaneb> (I've been saying this for ~2 years)
20:13:31 <shardy> zaneb: Ok, cool, +1 on the common scaling library for sure
20:13:38 <zaneb> which I'm currently working on
20:13:43 <stevebaker> yeah, that sounds sensible
20:13:44 <pas-ha> I would also think that RG is just an ASG minus A
20:13:44 <zaneb> should have a lot more to show this week
20:13:50 <shardy> I just wanted to avoid taking sides via review if you guys are mid-dispute/discussion ;)
20:13:51 <zaneb> depending on interruptions
20:13:53 <zaneb> which are legion
20:14:27 <zaneb> pas-ha: yes, that's the right way to think of it
20:14:41 <skraynev_> stevebaker: when we plan to bump l3 tag and introduce FF ? I mean particular day ;)
20:14:43 <zaneb> pas-ha: not the other way round, which is how we have always organised things in the code
20:15:04 <stevebaker> zaneb: wrt feature freeze this is probably a feature. i recall a bp for this
20:15:25 <zaneb> rabi had a bp I believe
20:15:31 <jdandrea> \o (late)
20:15:39 <zaneb> I didn't want to try to steal that too ;)
20:15:53 <stevebaker> zaneb: I'd be happy to ask for an extension for that if it is not all landed by ff
20:16:07 <zaneb> when is FF?
20:16:20 <pas-ha> about sept 3
20:16:20 <stevebaker> skraynev_: since we're hardly snowed under with feature reviews, I think FF on the day of l-3 is ok
20:16:36 <zaneb> ok, yeah, could be tight
20:16:42 <shardy> stevebaker: yeah, I'm working on recursive-validation and wondering if I may have enought time wrt FPF
20:17:01 <zaneb> I'm trying to keep the patches either small + easy to review, or with lots of unit test coverage, or both
20:17:20 <stevebaker> shardy: is there a lp bp for that?
20:17:57 <shardy> stevebaker: There's a spec, https://review.openstack.org/#/c/197199/
20:17:58 <skraynev_> stevebaker: FYI, I know, that it's probably late, but we plan to upload on review all rich-network bp stuff...
20:18:05 <shardy> It's been in review limbo for $months
20:18:12 * shardy sees if he raised the BP
20:18:33 <stevebaker> shardy: ok, I'll push that through today
20:18:42 <skraynev_> zaneb: what's about batching for RG? it has merged spec.
20:19:00 <zaneb> skraynev_: the code landed already
20:19:09 <zaneb> I'm refactoring it as we speak
20:20:08 <shardy> stevebaker: Ok, thanks, I'll raise the LP BP, looks like there isn't one yet
20:20:08 <skraynev_> zaneb: I meant this one
20:20:26 <skraynev_> https://review.openstack.org/#/c/185385/
20:20:34 <pas-ha> zaneb, that's on_create batching
20:20:36 <stevebaker> there is this https://blueprints.launchpad.net/heat/+spec/reorg-asg-code
20:20:52 <zaneb> skraynev_: oh, right
20:21:09 <zaneb> I don't think it should be a property, but once that is fixed I'm ok with landing it
20:21:19 <zaneb> it will conflict with what I'm doing though :/
20:21:42 <ochuprykov> what is the proper place to add batch_create?
20:21:54 <skraynev_> zaneb: I just think, that rolling update is a part of batching for create/update/delete ..
20:22:01 <ochuprykov> don't think this place is update_policy
20:22:21 <zaneb> ochuprykov: IMHO it is update_policy
20:22:55 <shardy> stevebaker: raised https://blueprints.launchpad.net/heat/+spec/nested-validation
20:23:19 <zaneb> ochuprykov: if just that changes then that shouldn't be detected as a change to the resource, ergo it's an update_policy
20:24:01 <ochuprykov> zaneb: i mean it works on creation, why we add it to update_policy?
20:24:35 <zaneb> I freely admit the naming makes it a little odd, since we are in uncharted territory here
20:24:47 <zaneb> but it is a policy, not a property imo
20:24:51 <shardy> ochuprykov: arguably, create is just a type of update which starts with an empty template ;)
20:24:52 <skraynev_> shardy: I correctly understand, that re-authentification for expired token will  be done as a bug and may be land after FF ?
20:25:08 <skraynev_> * bug fix
20:25:12 <stevebaker> zaneb: I don't think rabi's changes are against a bp. Could you develop against Qiming's old one? https://blueprints.launchpad.net/heat/+spec/reorg-asg-code
20:25:15 <pas-ha> skraynev_, that is surely a bug
20:25:38 <shardy> skraynev_: Yeah, I'm hoping to get time to work on that too, modulo everything else I'm hoping to get done
20:25:50 <ochuprykov> shardy: exactly my implementation of batch_create)
20:25:52 <zaneb> stevebaker: ok, if that's what floats your boat
20:26:07 <stevebaker> zaneb: just to have something to track against
20:26:28 <skraynev_> shardy: got it. thx
20:26:36 <zaneb> stevebaker: might it be easier to track if I created a new one?
20:26:37 <ochuprykov> zaneb: so i just add batching_actions to existiing rolling update in update_policy?
20:26:44 <zaneb> whiteboard is getting pretty long there
20:27:03 <stevebaker> any other non-asg features to discuss?
20:27:08 <shardy> zaneb: I would, you'll end up writing a new service if you follow that one ;)
20:27:25 <zaneb> ochuprykov: I actually think we should have separate policies for create and rolling_update
20:27:40 <skraynev_> stevebaker: rich network. I hope to upload all related patches on review on Friday
20:27:48 <skraynev_> on this week
20:27:53 <ochuprykov> zaneb: need to add create_policy to parent resource class?
20:27:58 <stevebaker> skraynev_: cutting it fine ;)
20:28:04 <zaneb> ochuprykov: thinking about tripleo use case, I can can definitely see a case for them being different
20:28:15 <stevebaker> skraynev_: but that would be good
20:28:44 <skraynev_> stevebaker: ok. will spent all time on this work
20:28:46 <ochuprykov> zaneb: we have the third case actually, for full update
20:28:56 <pas-ha> zaneb, even if they are the same, you can update it in the same updated template
20:28:58 <zaneb> ochuprykov: no, not a new section in the template. there can be multiple keys in the update_policy section. we just need another one in addition to rolling_update
20:29:18 <skraynev_> stevebaker: probably we may go to the next topic about RG
20:29:20 <skraynev_> ;)
20:29:31 <zaneb> pas-ha: true, because it's a policy! ;) still a major pita for tripleo though
20:29:36 <stevebaker> #topic batching for create in ResourceGroup
20:29:54 <skraynev_> stevebaker: because discussionalready in progress ;)
20:29:57 <zaneb> I thought we were already talking about this ;)
20:30:09 <pas-ha> yep :)
20:30:10 <ochuprykov> zaneb: rolling_create would be fine?
20:30:31 <stevebaker> y'all jumped the gun
20:30:47 <zaneb> ochuprykov: maybe 'batch_create'? but just bikeshedding at this point
20:30:48 <pas-ha> let's make more - rolling_suspend :)
20:30:50 <skraynev_> ochuprykov: wow. what's about actions in this case ?
20:31:09 <skraynev_> separate policy for each action looks expansive and heavy, IMO
20:31:23 <ochuprykov> zaneb: batch_create looks fine tome too
20:31:30 <stevebaker> zaneb: I'll leave it up to you whether you create a new bp or use reorg-asg-code, just target it to l-3
20:31:41 <zaneb> stevebaker: ack
20:32:04 <skraynev_> zaneb: ochuprykov: what if we want to add batching for another actions ?
20:32:07 <ochuprykov> zaneb: i'm just wondering about repetition of max_batch_size and pause_time in theirs schemas
20:32:19 <skraynev_> for "delete" it looks reasonable
20:32:47 <ochuprykov> skraynev: don't think about delete for now
20:33:00 <skraynev_> zaneb: I'd prefer one batching policy with option for create/update or sonmething else
20:33:12 <zaneb> ochuprykov: easy to avoid that duplication in code. user has to duplicate that in their schema, but that is the price for being more flexible. I still think flexible wins
20:33:16 <pas-ha> yes, deletes are usually lightweight on Nova (sans SC/SD with on_delete actions)
20:33:22 <zaneb> s/schema/template/
20:33:50 <shardy> skraynev_: What if you want to create everything as fast as possible, but keep your application running during update?
20:34:44 <ochuprykov> skraynev: ok, add batch_crete to update_policy and batching_actions to existing rolling update (i.g. update_existing and update)
20:34:47 <pas-ha> shardy, as it is a policy - you update it in the same updated template, and use new value during update
20:35:02 <skraynev_> shardy:  you mean separate options (pause, min in service , etc) for each action ?
20:35:12 <shardy> pas-ha: I guess, not very declarative though :\
20:35:18 <ochuprykov> zaneb: ok, add batch_crete to update_policy and batching_actions to existing rolling update (i.g. update_existing and update)
20:35:33 <zaneb> skraynev_, shardy: what if you want to create your compute nodes in batches of 10, but then update them 1 at a time so you can migrate user workloads off <- potential tripleo use case
20:35:36 <pas-ha> or we are talking on (auto)scaling actions? that might need different for create and update
20:35:39 <shardy> skraynev_: yes, I think optionally supporting that (even if there's a way to specify common values) would be good
20:36:20 <stevebaker> skraynev_: I need to go soon. can you topic Open Discussion, and endmeeting?
20:36:29 <zaneb> ochuprykov: I don't understand the batching_actions one
20:36:41 <skraynev_> shardy:  default batching parameters like for nested stacks :)
20:36:59 <skraynev_> stevebaker: sure
20:37:29 <ochuprykov> zaneb: we have 3 actions: create (just discussed), update_existing (exactly what rolling_update do) and for full update
20:37:53 <zaneb> what does full update mean? how is that different from rolling_update?
20:38:34 <ochuprykov> if we need to create new resources, we will create in batches
20:38:40 <ochuprykov> in update
20:38:46 <zaneb> rolling update does that already
20:38:50 <ochuprykov> no
20:38:59 <ochuprykov> in only replace existing resources
20:39:19 <ochuprykov> and after that make resize
20:40:14 <zaneb> actually it depends
20:40:14 <zaneb> it may create extras to maintain the min_in_service
20:40:14 <zaneb> and if it does, it creates them in batches
20:40:24 <zaneb> but you're right, not if you change the size to > efft_capacity
20:40:34 <ochuprykov> so, for example, we have 10 res and want to have 20 res', ru updates 10 res in batches and then creates 10 res simultaneously
20:40:34 <skraynev_> zaneb, ochuprykov: guys, do not you mind if we continue it in Open discussion ?
20:40:53 <zaneb> however, when I am done refactoring, that will be trivial to fix with a ~2-line change
20:41:06 <zaneb> skraynev_: go ahead
20:41:26 <skraynev_> #topic Open Discussion
20:41:54 <zaneb> ochuprykov: I think we should see that as an enhancement to rolling_update, not a new policy. I'm planning to implement it anyway
20:42:29 <ochuprykov> zaneb: but i think rolling_update is only about updating existing resources
20:42:48 <zaneb> ochuprykov: my goal is to have all creates and updates go through the rolling update code :)
20:42:49 <ochuprykov> zaneb: so we need to distinguish this 2 cases
20:43:21 <pas-ha> why should we? do we have to keep strict compat with something here?
20:43:39 <zaneb> pas-ha: not for RG
20:44:29 <pas-ha> even for AWS ASG - does it really matter if new will be created in batches or not (like now)?
20:45:34 <ochuprykov> pas-ha: at least it has different time to update for this 2 cases
20:45:34 <zaneb> ochuprykov: so I guess the question is if the user increases the size of the RG and has differing update_policy for both batch_create and rolling_update, which would they expect to apply?
20:46:15 <ochuprykov> zaneb: rolling_update
20:46:25 <ochuprykov> zaneb: because they want to update
20:47:23 <ochuprykov> zaneb: and i'd like to add additional options, for applaying batching to replace or to full update
20:47:33 <zaneb> ochuprykov: I'd say rolling_update if the launch config/resource definition has also changed, and batch_create if it has not
20:47:57 <pas-ha> zaneb, that's not too declarative
20:48:17 <pas-ha> there should be one meaning, otherwise it is confusing
20:48:35 <ochuprykov> zaneb: i think about this actions in terms of a whole stack
20:48:52 <pas-ha> or the RG itself
20:49:08 <ochuprykov> zaneb: create -- means stack create, not create of resource ( that may be performed on update)
20:50:28 <zaneb> the original purpose of rolling_update was to update to a new launch config (we corrupted the meaning when we adopted it)
20:50:40 <ochuprykov> zaneb: i;d like you to look at this spec https://review.openstack.org/#/c/183506/
20:51:10 <zaneb> if you're rolling out new stuff you might have requirements to go slowly, stop and test that you might not have if just rolling out more of the same
20:51:15 <stevebaker> I'm back
20:51:33 <shardy> You could have a series of options, with the first taking precedence if the others aren't defined, batch_size->update_batch_size->rolling_update_batch_size
20:52:00 <shardy> Then, you can either just define batch_size, or all the options if you want very granular control
20:52:06 <skraynev_> stevebaker: cool. we are in Open discussion, but still talk about RG batching ;)
20:52:14 <stevebaker> heh
20:52:53 <zaneb> shardy: that's actually sounding pretty good
20:53:01 <ochuprykov> zaneb: don't know the history of appearance of rolling_update
20:53:36 <zaneb> ochuprykov: it came from CloudFormation originally
20:53:53 <zaneb> or EC2, to be more precise
20:54:33 <pas-ha> actually for that it would be cool to be able to pause the update until explicit signal from user (like it is possible with stack breakpoints)
20:54:35 <zaneb> AWS allows you to change the launch config for future instances *without* doing a rolling update
20:54:45 <zaneb> of existing ones
20:55:10 <zaneb> pas-ha: yes, we desperately need that for tripleo
20:55:18 <zaneb> I thought there was a review up at some point
20:55:48 <skraynev_> zaneb: agree. I saw something similar...
20:55:50 <pas-ha> not that I remeber of. I mean inf pause between batches
20:56:04 <pas-ha> until user signal
20:56:09 <ochuprykov> zaneb: what is the conclusion? add batch_create to update_policy now?
20:56:36 <zaneb> pas-ha: I think ryansb put a review up for hooks between batches (i.e. same impl as breakpoints)
20:56:53 <pas-ha> oh, cool, missed that
20:58:35 <shardy> zaneb: we discussed the hook for update breakpoint in one of ramishras RG patches IIRC
20:58:39 <skraynev_> anything else ? or we may finish ?
20:58:59 <skraynev_> 2 mins
20:59:02 <shardy> but it's not actually been implemented
20:59:08 <skraynev_> 1 ;)
20:59:14 <shardy> skraynev_: Ok to finish IMO :)
20:59:23 <stevebaker> +1
20:59:31 <skraynev_> ok cool. thx everyone !
20:59:36 <skraynev_> #endmeeting