20:00:09 <asalkeld> #startmeeting heat
20:00:11 <openstack> Meeting started Wed Jan 28 20:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:14 <openstack> The meeting name has been set to 'heat'
20:00:23 <asalkeld> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:00:55 <stevebaker> \o
20:00:58 <shardy> o/
20:00:59 <zaneb> aloha
20:01:04 <tspatzier> hi
20:01:09 <BillArnold> o/
20:01:10 <dgonzalez> hi
20:01:15 <Tango> hi
20:01:21 <jpeeler> hi
20:01:33 <skraynev_> hi o/
20:01:33 <rpothier> hi
20:01:43 <asalkeld> #topic Review action items from last meeting
20:02:03 <skraynev_> zaneb: are you on Hawai ?
20:02:08 <zaneb> I wish
20:02:19 <asalkeld> no actions
20:02:30 <skraynev_> sigh, I too ;)
20:02:36 <asalkeld> #topic Adding items to the agenda
20:03:10 <asalkeld> just realised we really have not progressed with the midcycle online meetup
20:03:17 <asalkeld> :-(
20:03:26 <asalkeld> i'll tag that on the end
20:04:10 <asalkeld> anything else?
20:04:14 <pas-ha> o/
20:04:27 <asalkeld> #topic kilo-2
20:04:32 <asalkeld> #link https://launchpad.net/heat/+milestone/kilo-2
20:05:24 <asalkeld> this look OK'ish
20:05:40 <asalkeld> except for the new blueprints that have appeared
20:05:51 <zaneb> that was me
20:06:01 <stevebaker> hmm, I need to add at least one blueprint
20:06:02 <asalkeld> really no time for those
20:06:11 <zaneb> folks should retarget if they don't think they'll make it
20:06:22 <zaneb> asalkeld: we have 2 more weeks, right?
20:06:31 <asalkeld> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
20:06:48 <asalkeld> zaneb, you getting a spec up?
20:06:53 <asalkeld> and code landing?
20:07:10 <stevebaker> looks like 1 week
20:07:11 <zaneb> oh, only one more week. guess I had the dates wrong
20:07:24 <ryansb> yeah, it was 2 weeks at the meeting last week ;)
20:07:25 <zaneb> asalkeld: working on it when I am not in meetings ;)
20:07:36 <skraynev_> I suggest to re-target these bp-s
20:07:36 <asalkeld> lucky you
20:07:54 <zaneb> agree, I'll retarget for kilo-3
20:07:58 <asalkeld> we can still work on the code and land early k3
20:08:09 <skraynev_> it allows to focus on kil-2 staff
20:08:22 <asalkeld> there are a lot of bugs there
20:08:41 <asalkeld> we need to go through those
20:08:48 <asalkeld> and review if there is code up
20:09:05 <asalkeld> also 6 bugs with no code
20:09:26 <zaneb> done
20:09:40 <asalkeld> (I'll go through them, but if you have one that won't make it please re-target)
20:10:11 <shardy> asalkeld: I've bumped my in-progress ones to k3, they're long-standing bugs I don't have a quick fix for
20:10:26 <asalkeld> jpeeler, i'll push your bp to next
20:10:36 <jpeeler> asalkeld: thanks
20:10:48 <asalkeld> done
20:10:58 <pas-ha> I'll bump scheduler cleanup for later too
20:11:17 <pas-ha> I clearly won't make them all
20:11:24 <asalkeld> really looks like we are doing no work here - only 5 blueprints :-O
20:11:45 <shardy> It was the same last cycle, then 30 or something in M3
20:11:50 <skraynev_> asalkeld: please stay "Add "service list" to heat-manage" I promised to look it tomorrow :)
20:11:55 <shardy> bump, bump, panic ;)
20:12:02 <asalkeld> yeah
20:12:30 <asalkeld> ok, moving on
20:12:39 <asalkeld> #topic convergence tasks/blueprints
20:12:47 <asalkeld> zaneb, what's up
20:12:58 <zaneb> so there is this etherpad:
20:13:13 <zaneb> #link https://etherpad.openstack.org/p/heat-convergence-tasks
20:13:28 <zaneb> and I have started creating blueprints/bugs
20:13:43 <zaneb> all the ones I've created so far are linked from the etherpad
20:13:50 <zaneb> I'll do the rest today
20:14:04 <zaneb> I'm assigning people who added their names on the etherpad
20:14:11 <asalkeld> zaneb, what is the tie in from the specs
20:14:19 <zaneb> in the next step I'll start submitting spec reviews
20:14:29 <asalkeld> ok
20:14:44 <zaneb> but feel free to start work without a spec
20:14:58 <stevebaker> regarding https://blueprints.launchpad.net/heat/+spec/convergence-config-option I have a question/suggestion
20:14:59 <asalkeld> is there enough info in the etherpad to start work?
20:15:23 <zaneb> asalkeld: I hope so. I'm available to answer questions wherever it's not
20:15:32 <skraynev_> stevebaker: what exactly?
20:15:44 <zaneb> stevebaker: let's hear it
20:15:46 <stevebaker> what if legacy or convergence code path could be chosen at stack-create rather than as a config option
20:16:09 <asalkeld> that is serious impl. detail
20:16:14 <skraynev_> do you mean some chages in API?
20:16:18 <zaneb> then it's exposed to the user
20:16:26 <asalkeld> for a user to see
20:16:28 <zaneb> that doesn't seem wise
20:16:29 <stevebaker> it means we don't need a whole new gate job to run convergence vs legacy
20:16:37 <SpamapS> Except..
20:16:38 <zaneb> I think I know why you're suggesting it
20:16:42 <SpamapS> it means you can diverge them
20:16:51 <stevebaker> zaneb: yes, it is exposed to the use, so it would come down to justifying that as a good idea
20:16:55 <stevebaker> to the user
20:16:56 <SpamapS> you don't have to make convergence mimic non-convergence behaviors.
20:17:18 <asalkeld> SpamapS, sounds like api v2
20:17:35 <SpamapS> That seems like coupling two separate things.
20:17:56 <SpamapS> But v2 could add the necessary bits to control convergence and inspect it where v1 didn't need those bits. ;)
20:17:59 <zaneb> the idea of the option was a seamless way of getting rid of the legacy code. what y'all are suggesting involves keeping it around forever
20:18:18 <SpamapS> deprecating it and keeping it around until users are comfortable
20:18:29 <SpamapS> that is one way to increase velocity.. mark it experimental
20:18:48 <stevebaker> zaneb: well, if there was a create option to select which engine, legacy would be the default until convergence is ready, then convergence becomes the default, then legacy gets deprecated...
20:18:57 <asalkeld> but then we need to tell users about it
20:18:59 <SpamapS> "if you want to try our new crazypants thing it will be more resilient and more awesomer, but it might also be more explodey"
20:19:18 <stevebaker> asalkeld: users who don't care can use whatever default
20:19:27 <SpamapS> if you make it deploy-time, deployers have to run two Heat services to try it out
20:20:14 <asalkeld> SpamapS, now they *will* have to run 2 services
20:20:25 <asalkeld> and it's a user option
20:20:29 <stevebaker> also, I'm planning on making changes to functional tests so that a test can be run against multiple scenarios/environments, and this could use that mechanism too
20:21:32 <asalkeld> stevebaker, for stage one what user facing feature will this allow?
20:21:35 <asalkeld> i don't see one
20:21:54 <zaneb> update-during-update
20:22:07 <SpamapS> asalkeld: er sorry what?
20:22:35 <asalkeld> i was just wondering what feature convergence was adding in phase 1
20:22:41 <asalkeld> zaneb, answered
20:22:43 <SpamapS> If you make it a stack-create option, then one heat service will service both old and new stacks.
20:23:15 <stevebaker> so users with really big stacks might prefer to use an experimental convergence engine
20:23:27 <SpamapS> legacy would just stay in whatever engine grabbed the stack. new would be handled in the new convergence-sexy way by all engines. One service.
20:23:41 <asalkeld> i'd sugest if we went for this to call this feature "enable-update-during-update"
20:23:42 <SpamapS> And what's good about this is it removes the 'big bang' hesitance.
20:24:05 <SpamapS> deployers don't have to stress out about when to flip the switch.
20:24:05 <stevebaker> zaneb: what is your thinking on this now?
20:24:22 <SpamapS> It would also enable larger stacks.
20:24:22 <zaneb> SpamapS: that's true for existing stacks with the config option
20:24:50 <shardy> SpamapS: although the whole keystone v3 thing shows that's not really true if we bump the API
20:24:50 <zaneb> my thinking is that it's the deployer's decision when they want to start supporting this code
20:24:50 <SpamapS> I'd suggest the per-stack resource limits we have now be allowed to diverge, so convergence stacks should be allowed many many more resources than non-convergence stacks.
20:25:12 <asalkeld> SpamapS, the decoulpe nested will alos allow larger stacks (if they have nested stacks)
20:25:17 <stevebaker> zaneb: there would still need to be a config option to specify what the default is, so that is a deployer decision
20:25:31 <SpamapS> shardy: not sure I follow.
20:25:45 <zaneb> there's no reason that convergence shouldn't be able to do everything that the legacy code can
20:25:57 <SpamapS> asalkeld: those still end up being RAM killers. You just load the decoupled stacks all into RAM instead of the resources.
20:25:57 <pas-ha> SpamapS, probably the adoption rate of Kv3
20:26:01 <zaneb> if it doesn't, it's a bug
20:26:01 <stevebaker> maybe we should move this to the list
20:26:19 <zaneb> and most folks shouldn't enable it until the major bugs are fixed
20:26:33 <zaneb> stevebaker: agree, this is too big a discussion for this forum
20:26:46 <shardy> SpamapS: migrating to keystone v3 has been hugely painful for folks, precisely because it's not transparent to users and some deployers don't yet support v3
20:27:16 <stevebaker> zaneb: ok, my derailing topic is over - back to actual convergence discussion
20:27:18 <shardy> hopefully we can add some client-level magic which will make things more transparent if we go that way
20:27:18 <SpamapS> For my money, I like the idea of running parallel code and making the batch size for migrations for user workloads a single stack.
20:27:42 <skraynev_> I think, that we should not promote new option as parameter, till we have not really close to finish comvergence staff
20:27:59 <SpamapS> shardy: I don't really think there's an alternative to that. :-/
20:28:30 <asalkeld> skraynev_ sure but the code can be waiting - ready to go
20:28:35 <shardy> SpamapS: well the alternative is the deploy-time option, which is transparent to users
20:29:02 <SpamapS> shardy: the problem I do think could have been handled better was the deprecation of v2.. which I think they were too aggressive on and that has been remedied. It's just life.. stable API's need to keep working for longer than anybody ever thinks.
20:29:04 <shardy> but I agree there's a lot of advantages to an "opt in" experimental approach
20:29:16 <asalkeld> one thing is how do we mark a stack option as experimental?
20:29:31 <SpamapS> asalkeld: make it wear a mask?
20:29:35 <asalkeld> (that the user can actually be made aware of)
20:29:43 <stevebaker> documentation
20:29:49 <shardy> SpamapS: Yeah, but there's remaining unsolved problems like lack of widespread version negotiation in clients, versioned endpoints in the catalog etc etc
20:29:51 <zaneb> by discussing it on the mailing list? :P
20:30:14 <skraynev_> zaneb: +1
20:30:16 <asalkeld> there is no mailing list for end users
20:30:20 <SpamapS> shardy: agree, those things have been exposed by this very problem and luckily we can look to the others going through it for guidance.
20:30:22 <shardy> SpamapS: I'm not opposed to a v2 API btw, just pointing out we shouldn't underestimate the effort and user impact involved
20:30:27 <asalkeld> only devs and operators
20:30:31 <zaneb> asalkeld: soooo missing the point
20:30:39 <SpamapS> asalkeld: openstack@ is for users
20:30:46 <SpamapS> and ask
20:30:57 <asalkeld> ok, you want to move on...
20:31:09 * shardy actually proposed the v2 API a year ago IIRC .. ;)
20:31:15 <SpamapS> but anyway yeah a well reasoned list post would allow a broader audience including those who are going through this in other projects.
20:31:40 <zaneb> #action stevebaker to start mailing list discussion about transition to convergence
20:31:41 <skraynev_> gree with SpamapS
20:31:51 <stevebaker> \o/
20:32:02 <skraynev_> he-he :)
20:32:16 <asalkeld> zaneb, you want to cover any thing else re: convergence specs/bps
20:32:33 <zaneb> not really, and I have another call starting :(
20:33:05 <asalkeld> #topic midcycle online meetup
20:33:19 <asalkeld> do we still need this?
20:33:28 <stevebaker> I'm leaning towards no
20:33:34 <asalkeld> i am inclined to agree
20:33:37 <shardy> getting a bit late for it really..
20:34:03 <asalkeld> shardy, well it's online - so we can jump online anytime
20:34:22 <pas-ha> if zaneb crafts nicely structured set of specs - no, we do not really have to
20:34:25 <stevebaker> the hard bit of deciding on convergence design was hashed out on the list
20:34:33 <shardy> asalkeld: I guess I meant that we've had most of the discussion now, and whatever's not decided probably won't land for kilo anyway
20:34:47 <asalkeld> ok, i'll can this for now
20:34:56 <shardy> I'm happy to do some hangouts or whatever though, if folks feel it's needed
20:35:00 <stevebaker> hashtag agreed
20:35:02 <asalkeld> #topic open discussion
20:35:22 <stevebaker> how about this summer eh?
20:35:30 <asalkeld> :-)
20:35:58 <skraynev_> :)
20:36:16 <skraynev_> one request: I think that Mistral resources are ready for review
20:36:18 <skraynev_> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/mistral-resources-for-heat,n,z
20:36:39 <skraynev_> they have enough "stable, workable" code
20:36:56 <skraynev_> also I plan to share document with examples (use-cases)
20:37:13 <asalkeld> skraynev_ i'll have a look, but probably should land early k3
20:37:30 <skraynev_> I know, agree.
20:37:43 <skraynev_> Just wanted to collect feedback :)
20:38:06 <stevebaker> skraynev_: is mistral in devstack?
20:38:20 <asalkeld> stevebaker, it's easy to setup
20:38:25 <tspatzier> ha, just wanted to ask the same question :-)
20:38:28 <skraynev_> yeah :)
20:38:58 <stevebaker> shadower's stack-breakpoint code looks ready for serious review too, that will be a great feature
20:39:31 <stevebaker> asalkeld: I don't know if it should be targetted for k-2 https://blueprints.launchpad.net/heat/+spec/stack-breakpoint
20:39:33 <asalkeld> https://github.com/stackforge/mistral/blob/master/functionaltests/pre_test_hook.sh
20:39:43 <skraynev_> stevebaker, tspatzier: I will send email with short guide how to make it work (plus link on document with examples)
20:39:59 <skraynev_> probably on openstack-dev
20:40:00 <tspatzier> thanks skraynev_
20:40:13 <asalkeld> stevebaker, done
20:40:39 <asalkeld> skraynev_ that link above works too
20:41:16 <stevebaker> should we make it High priority, since it will be the recommended way to do rolling upgrades of clusters
20:41:31 <zaneb> back
20:41:46 <skraynev_> asalkeld: yeap.
20:42:21 <skraynev_> asalkeld: just want to make sure, that it will store in email list for all guys, who wants to try :)
20:42:44 <asalkeld> stevebaker, huh? people have to do debugging to update a cluster?
20:42:53 <asalkeld> that's wacked
20:43:32 <zaneb> meh, it's just a name
20:43:41 <ryansb> no, if they wanted to deploy in stages they can set breakpoints for points they want to manually verify that things aren't hosed
20:44:22 <stevebaker> asalkeld: per-node manual inspection is very desirable. Easier to roll back one node than the entire cluster
20:44:24 <ryansb> they're not debugging per se, just setting spots for safety checks
20:44:49 <asalkeld> well hopefully not the encouraged mechanism
20:45:13 <asalkeld> (but available to those that want it)
20:45:50 <asalkeld> ok, I can call this meeting the end ... last call for discussion
20:46:18 <asalkeld> #endmeeting