20:00:12 <shardy> #startmeeting heat
20:00:13 <openstack> Meeting started Wed Sep 11 20:00:12 2013 UTC and is due to finish in 60 minutes.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:16 <openstack> The meeting name has been set to 'heat'
20:00:22 <shardy> #topic rollcall
20:00:27 <shardy> hey, who's around?
20:00:31 <bgorski> o/
20:00:32 <m4dcoder> o/
20:00:33 <andrew_plunk> o/
20:00:36 <timductive> o/
20:00:36 <tspatzier> Hi
20:00:38 <kebray> o/
20:00:38 <spzala> Hi
20:00:56 <stevebaker> \o
20:00:57 <SpamapS> ahoy
20:01:00 <obondarev> hi
20:01:00 <zaneb> I'm sort-of awake
20:01:01 <kebray> randall burt is close by... currently engaged in something, but he and I are sitting in the same room.
20:01:29 <radix> here I am
20:02:56 <shardy> therve, sdake, jpeeler around?
20:03:14 <shardy> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:03:15 <jpeeler> ah yes
20:03:27 <shardy> #topic Review last week's actions
20:03:41 <shardy> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-09-04-20.00.html
20:03:59 <shardy> #info  randallburt to move Rackspace resources to /contrib directory
20:04:08 <shardy> I don't think that happened yet?
20:04:21 <kebray> shardy  he is on his way.. can you come back to this one in a moment?
20:04:31 <randallburt> hithere, sorry I'm late
20:04:33 <kebray> He's worked on it... but, moving it borked a lot of other stuff, tests etc.
20:04:34 <randallburt> working on the move
20:04:41 <randallburt> testing is proving very difficult
20:04:48 <shardy> #action randallburt to move Rackspace resources to /contrib directory
20:04:49 <randallburt> may ask for a hand later this afternoon
20:04:55 <SpamapS> Perhaps we should defer that change to icehouse. :p
20:04:58 <randallburt> will submit wip soonish
20:04:58 <radix> that's going to be a fun rebase for me :P
20:05:21 <shardy> randallburt: why is just moving them causing test issues?
20:05:45 <radix> python path issues for the test runner maybe?
20:05:48 <randallburt> I'm not sure how to get the tests to run
20:05:57 <randallburt> radix:  essentially, yes
20:06:12 <radix> randallburt: is "rackspace" going to be a toplevel python package?
20:06:17 <randallburt> fwiw I moved the tests to contrib as well
20:06:17 <radix> or something like that?
20:06:26 <randallburt> radix:  no
20:06:56 <randallburt> its a copy of the heat package tree after contrib/rackspace. I'll submit a WiP and let folks see what I'm doing and hopefully offer some suggestions
20:07:18 <shardy> randallburt: Ok, wip review sounds good then we can help work out the issues
20:07:19 <radix> hum
20:07:28 <randallburt> shardy:  thanks
20:07:34 <shardy> anything else to raise from last week?
20:08:01 <shardy> #topic RC1 bugs
20:08:13 <shardy> #link https://launchpad.net/heat/+milestone/havana-rc1
20:08:37 <shardy> So the plan is to get the RC1 bug list to zero, then cut RC1 (which also opens master for Icehouse)
20:09:03 <shardy> So if anyone has anything they think needs to be fixed for Havana which is not on that list, please add it :)
20:09:21 <shardy> and we need to ensure any new bugs get appropriately targetted
20:09:45 <shardy> Any questions re RC1 or the release cycle?
20:09:56 <radix> shardy: what should I target kind of generic non-important bugs to? (I filed one earlier)
20:10:26 <SpamapS> shardy: how long do we have?
20:10:37 <shardy> radix: either heat-ongoing, or icehouse-1
20:10:45 <radix> ok
20:10:50 <shardy> depending on how soon we need to fix it (or plan to)
20:11:15 <shardy> SpamapS: the plan is to have all RC1's cut by the end of the month, so couple of weeks
20:11:34 <SpamapS> Ok, then I would propose any Low bugs not already In Progress be kicked to icehouse.
20:11:37 <shardy> but if we get the bug list to zero before that, we can branch sooner
20:12:27 <shardy> SpamapS: Sure, we can do that
20:12:33 <SpamapS> there are several that I see.. none of which look like they're set to the wrong priority
20:12:57 <shardy> We also need assignees for all those (Med/High) priority which are unassigned
20:13:13 <shardy> so please all take a look through and see if you can take one ;)
20:13:19 <SpamapS> there are an alarming number with Status == New
20:13:25 <SpamapS> I suspect that is just oversight though
20:14:03 <shardy> SpamapS: well there's 7, three of which are assigned, so I assume they should be Triaged
20:14:24 <shardy> in comparison to Nova, we've got no problems (IIRC they have like 200 New bugs!)
20:14:32 <stevebaker> As a heat core member, can I raise a bug and set it to Confirmed myself?
20:14:44 <SpamapS> stevebaker: please do :)
20:14:55 <shardy> stevebaker: Yes, but I normally just set it to Triaged if I'm self-confirming
20:15:04 <stevebaker> ok
20:15:05 <SpamapS> Though I'd set it to Triaged. Confirmed is for users who have also experienced the issue.
20:15:19 <shardy> as it's verified by a heat core member (the reporter), but not confirmed by anyone
20:15:56 <shardy> Ok, anything else re RC1 before we move on?
20:16:16 <SpamapS> no FFE's right?
20:16:30 <shardy> SpamapS: no, we didn't need any in the end
20:16:34 <SpamapS> I think that is pretty awesome.
20:16:44 <shardy> So great work everybody getting stuff done and reviewed on time :)
20:16:51 <zaneb> m4dcoder's patch didn't make it though
20:16:52 <SpamapS> (or deferred on time ;)
20:17:09 <SpamapS> zaneb: the awesome part is that we are not freaking out about it :)
20:17:09 <shardy> zaneb: Yeah was still in heavy review iterations so will have to wait for I-1
20:17:20 <zaneb> fair enough
20:17:24 <shardy> zaneb: It's shaping up now tho right?
20:17:35 <zaneb> yeah, it should be basically ready
20:17:40 <stevebaker> was that parallel delete?
20:17:56 <shardy> zaneb: Ok, we'll get that in soon after we branch then
20:17:58 <zaneb> stevebaker: no, it was incremental update for autoscaling
20:18:05 <shardy> stevebaker: no, UpdatePolicy
20:18:06 <stevebaker> ah
20:18:24 <zaneb> I think parallel delete made it
20:18:41 <shardy> zaneb: Yeah it did, as did trusts and VPNaaS, all of which were close
20:18:58 <zaneb> and parallel update, which was also very close :)
20:19:13 <shardy> parallel-all-the-things ;)
20:19:24 * zaneb needs to rest now
20:19:26 <shardy> #topic Summit design session proposals
20:19:44 <shardy> #link http://summit.openstack.org/
20:19:53 <shardy> So we only have two (!) so far
20:19:55 <obondarev> hi folks, I filed this one - http://summit.openstack.org/cfp/details/59
20:20:04 <obondarev> my name is Oleg Bondarev, I'm dev in neutron
20:20:12 <shardy> I think we all have topics in mind, but we need to start adding them
20:20:13 <obondarev> focusing on lbaas development but aware of other features in neutron
20:20:15 <MikeSpreitzer> I have one coming
20:20:18 <shardy> hey obondarev
20:20:19 <MikeSpreitzer> I hope
20:20:19 <stevebaker> obondarev: welcome!
20:20:25 <randallburt> I'm thinking of a design proposal around separating out the cloud-init stuff like we talked about yesterday shardy unless is too trivial
20:20:28 <obondarev> I'm newbie to heat but would be happy to help with neutron support improvements
20:20:36 <shardy> I added a comment to that, what did you want to cover, which we haven't implemented for Havana?
20:20:36 <bgorski> I add multi-region and multi-cloud  	Heat support for multi-region and multi-cloud
20:20:44 <bgorski> http://summit.openstack.org/cfp/details/58
20:20:47 <shardy> bgorski: yup, saw that, thanks
20:21:00 <obondarev> shardy: I updated the description with some details
20:21:07 <stevebaker> so core/ptl get to decide what sessions will happen right? how many slots do we have?
20:21:10 <shardy> obondarev: Ok, thanks, will check it out! :)
20:21:12 <spzala> shardy: qq- for design session ideas, should we submit on summit.openstack.org directly or discuss with you/core team first?
20:21:21 <obondarev> shardy: thanks!
20:21:23 <tspatzier> we have maybe 3 or 4 coming, but have to do some internal consolidation yet
20:21:36 <zaneb> stevebaker: 9 sounds familiar
20:21:39 * zaneb looks
20:21:40 <MikeSpreitzer> I am working on a design summit proposal, have to get it through some internal processes before you guys see it.
20:22:00 <shardy> Yeah I think it's 9, looking for the schedule
20:22:14 <zaneb> stevebaker: 9
20:22:19 <zaneb> https://docs.google.com/spreadsheet/ccc?key=0AmUn0hzC1InKdDdPRXFrNjV4SW91SWF5N2gwYnRHYWc#gid=1
20:22:50 <zaneb> 1 more than Portland
20:22:54 <shardy> zaneb: thanks
20:22:59 <zaneb> taking over the world one step at a time :)
20:23:03 <shardy> #link https://docs.google.com/spreadsheet/ccc?key=0AmUn0hzC1InKdDdPRXFrNjV4SW91SWF5N2gwYnRHYWc#gid=1
20:23:45 <SpamapS> Things I think need to be discussed: HOT Next Steps, 100% Native Resources, Locking for multi-engine, Event table backends
20:24:00 <SpamapS> 1 more than Portland?
20:24:11 <SpamapS> Don't we have something like 3x the active developers now?
20:24:28 <radix> oh
20:24:34 <radix> I need to propose some sessions
20:24:38 <stevebaker> we should do one of them git animations
20:24:55 <shardy> software config resources, in-instance users, autoscaling roadmap
20:25:09 <shardy> There are lots, but good to hear we've got ideas in the pipeline
20:25:22 <SpamapS> stevebaker: I put one together last summit, it takes about 32 minutes.
20:25:25 <SpamapS> err
20:25:26 <SpamapS> 2 minutes
20:25:43 <shardy> then we can start discussion over the next few meetings to decide what the shortlist is
20:25:49 <SpamapS> shardy: any chance we can lobby for 1 or 2 more slots?
20:26:02 <shardy> SpamapS: probably not, I think it's all decided now
20:26:05 <SpamapS> I just think we have a _lot_ more work coming down the pipe than Portland.
20:26:24 <SpamapS> Ok, then we should make sure to consolidate where there is any overlap.
20:26:25 <radix> shardy: I didn't see a response to spzala, I have the same question
20:26:31 <zaneb> SpamapS: so do most projects, I'm guessing
20:26:37 <radix> sorry, I have been distracted and missed some of the meeting
20:26:43 <shardy> I think we just have to prioritize those discussions which will most benefit from f2f brainstorming, vs realtively well defined stuff
20:27:13 <stevebaker> just submit anything you want, then we can know where the interest lies
20:27:16 <SpamapS> spzala: I'd say submit then discuss.
20:27:18 <radix> ok
20:27:28 <radix> where do we submit exactly? (sorry, I've never done this)
20:27:41 <spzala> OK, sounds great. Thanks!
20:27:45 <stevebaker> Click the Suggest Session button
20:27:50 <stevebaker> http://summit.openstack.org/cfp/create
20:28:00 <SpamapS> radix: The session submission place is right next to the place where you buy level 34 tower swords.
20:28:08 <shardy> spzala, radix: just submit the suggestion
20:28:16 <radix> ok cool
20:28:18 <radix> thanks :)
20:28:19 <spzala> radix: on http://summit.openstack.org/ there is a "submit session"
20:28:23 <shardy> but obviously make sure there isn't an existing similar proposal
20:28:27 <radix> yeah
20:28:36 <spzala> shardy: OK, thanks!
20:29:19 <shardy> we won't be able to do all proposed sessions, but getting the ideas up relatively early gives us time to discuss and decide which to do
20:29:34 <obondarev> proposals table really lacks some kind of sorting :)
20:29:43 <obondarev> by project at least
20:30:03 <zaneb> just be grateful they gave you a list to look at this time :D
20:30:13 <SpamapS> One important thing.. is do not wait for the summit to start discussions on the mailing list.
20:30:19 <obondarev> oh, there is, my bad :)
20:30:32 <shardy> http://summit.openstack.org/cfp/topic/8
20:30:37 <SpamapS> There are plenty of things that do not need an entire hour of everyone's discussion time to resolve.
20:30:39 <shardy> that's the Heat list
20:30:51 <obondarev> yeah
20:31:14 <shardy> SpamapS: agreed
20:31:19 <SpamapS> The idea with the summit sessions is that when the issue requires high bandwidth communication and there are lots of opinions that need expressing, thats when we need a session.
20:31:44 <SpamapS> But, if you just have an idea for how to make the bikeshed better.. mailing list is fine. ;)
20:31:46 <stevebaker> SpamapS: yes, I'm about to kick of a discussion on HOT components, bootstrap config and hot-software-config
20:31:58 <shardy> anything else re summit before we continue?
20:32:33 <spzala> SpamapS: +1
20:32:46 <shardy> #topic Documentation
20:33:02 <shardy> So yeah we need a push on docs soon
20:33:09 <shardy> who added this item?
20:33:11 <stevebaker> I think soon is now
20:33:13 <stevebaker> me
20:33:40 <shardy> stevebaker: Yeah, now, but also we need to focus on more testing in the runup to RC1
20:33:49 <stevebaker> so we need volunteers to pick one of these and add the heat chapters https://github.com/openstack/openstack-manuals/tree/master/doc
20:33:57 <shardy> should we have a docs-sprint over a couple of days maybe?
20:34:11 <SpamapS> The two are not mutually exclusive.
20:34:27 <SpamapS> It is quite helpful to write a piece of documentation and hand it to a tester to see if it actually works for them too.
20:34:30 <stevebaker> https://github.com/openstack/openstack-manuals/tree/master/doc/install-guide is probably the most important
20:34:57 <radix> is help needed for adding property descriptions to all the resources?
20:35:24 <SpamapS> On that note, do we auto-generate any docs from those?
20:35:33 <stevebaker> radix: yes. I was thinking of raising an RC1 doc bug for every resource that lacks descriptions
20:35:35 <SpamapS> Because.. that would be pretty sweet. :)
20:35:39 * randallburt remembers he had some doc things to do somewhere...
20:35:42 <shardy> radix: that is automated now I think
20:35:43 <radix> stevebaker: sounds good, I'll take some
20:35:47 <spzala> SpamapS: do we have a dedicated test team? that's cool.
20:35:49 <stevebaker> SpamapS: yes we do http://docs.openstack.org/developer/heat/template_guide/
20:35:58 <SpamapS> spzala: yes, they're called "you"
20:36:01 <radix> shardy: well, I mean adding the descriptions to the schema
20:36:10 <SpamapS> spzala: oh and the secondary team, "me"
20:36:18 <spzala> SpamapS: ha ha .. OK that makes sense :)
20:36:21 <stevebaker> So if people worked on particular resources, I would strongly encourage to assign these doc bugs to yourselves
20:36:26 <SpamapS> spzala: but we usually just blame it on the backup team.. "them"
20:36:27 <shardy> radix: Ah Ok, cool
20:36:33 <spzala> SpamapS: that was my understanding too
20:36:57 <spzala> SpamapS: :)
20:37:30 <stevebaker> shardy: So I'm about to raise a pile of RC1 bugs, should I make them Medium priority?
20:37:47 <shardy> stevebaker: Yup, if you can raise them that would be great
20:37:57 <shardy> then we all have to pitch in and take some ;)
20:38:05 <stevebaker> so doc sprint after RC1 is out the door?
20:38:31 <stevebaker> ah, another thing
20:38:39 <radix> hooray
20:38:57 <shardy> stevebaker: IMO it would be good to get RC1 proven and branched, but I guess we can have docs progressing at the same time
20:38:58 <radix> I love writing words
20:39:08 <shardy> provided we have enough folks willing to contribute
20:39:26 <stevebaker> When the template writers guide is written, what style of template are we guiding them to write? HOT isn't ready, and cfn json is puke
20:39:37 <radix> hm
20:39:41 <radix> stevebaker: why isn't HOT ready?
20:39:48 <stevebaker> some things can be done with native resources, others are still AWS only
20:40:09 <radix> so... do you mean YAML vs JSON, or OS:: vs AWS::? those should be separate I think
20:40:15 <shardy> stevebaker: what things?  You can use AWS compatible resources in HOT templates
20:40:23 <radix> I think we should use YAML everywhere
20:40:26 <randallburt> stevebaker:  I don't think that the dirth of native resources is a big issue WRT hot
20:40:29 <stevebaker> maybe HOT is ready enough
20:40:35 <shardy> (I know we've got loads to do on HOT btw, just want to clarify the details)
20:40:41 <zaneb> yaml++
20:40:54 <randallburt> there is one issue I found today that I'm about to raise, but dunno if its a Big Deal.
20:41:03 <randallburt> you can't use HOT as a provider template
20:41:08 <shardy> stevebaker: I think if we can, we should focus docs on HOT, since there's no point in dedicating time to re-documenting AWS derived stuff
20:41:49 <shardy> randallburt: bug please! We should fix that
20:41:56 <randallburt> bugging now
20:42:12 <randallburt> its something to do with the schemata stuff; I'll keep digging
20:42:38 <stevebaker> so I think we should document the "best" way of doing things in heat's current state. Which will be yaml always, HOT where possible, native resources where possible, then fallback to AWS resources for all the autoscaling/waitcondition stuff
20:43:17 <stevebaker> and everyone should read this http://stevelosh.com/blog/2013/09/teach-dont-tell/
20:43:19 <shardy> stevebaker: You are confusing native/AWS-compatible resource types with template formats I think
20:43:54 <shardy> But yeah, lets document what works, but lets *not* re-document stuff which people can get from AWS docs
20:44:06 <shardy> even if we are doing a YAML rendered version of the same thing
20:44:08 <stevebaker> shardy: I'm not. I'm trying to figure out what we should tell our users as the one best way to write templates that achieve everything they want to do
20:45:35 <shardy> stevebaker: IMO the best way to do that is to get all our example templates up to date (ie working on recent Fedora), and to generate *lots* more HOT examples
20:45:36 <randallburt> shardy:  https://bugs.launchpad.net/heat/+bug/1224111
20:45:39 <uvirtbot> Launchpad bug 1224111 in heat "HOT cannot be used as a provider template" [Undecided,New]
20:46:20 <shardy> stevebaker: I get your point re docs, but there's no point IMHO in generating a super comprehensive template authors guide if the whole thing will immediately get obsoleted as HOT adoption increases
20:47:14 <radix> I would guess that it's more of "some details will change" instead of "everything is obsolete"
20:47:21 <kebray> In case it's helpful, here are some HOT templates that work on RS could.. .we could easily modify the resource types for generic Openstack clouds... good place to start for some examples.
20:47:22 <kebray> github.com/heat-ci/heat-prod-templates
20:47:25 <stevebaker> I think there will always be an excuse not to start the guide. Once we have the structure, it can be updated with more HOTness over time
20:48:08 <shardy> stevebaker: Ok, well IMO documenting the providers/environments stuff is a much higher priority right now
20:48:08 <radix> stevebaker: +
20:48:17 <stevebaker> shardy: please read http://stevelosh.com/blog/2013/09/teach-dont-tell/
20:48:19 <stevebaker> working example templates are not enough.
20:48:21 <shardy> stevebaker: but I don't disagree ;)
20:48:25 * kebray thinks we should have named (rename) heat-ci to rs-heat-ci since it's a RS CI user.
20:48:45 <kebray> btw, ignore the Windows template in that link.  It's a proof of concept on our specific heat API endpoint.
20:49:26 <shardy> kebray: you could contribute some non-RS-specific examples to heat-templates ;)
20:49:32 <stevebaker> sorry, I need to go, school run
20:49:37 <kebray> shardy Yep :-0
20:49:43 <kebray> We can help with that.
20:50:25 <kebray> Starting to work on that actually.  jasond is out of office right now though.  he had started converting/testing on standard vanilla openstack.
20:50:40 <shardy> Ok 10mins, lets go to open discussion
20:50:50 <shardy> #topic Open Discussion
20:51:04 <shardy> Anyone have anything to raise?
20:51:22 <m4dcoder> shardy: just trying to understand process. when will exceptions be allowed after feature freeze?
20:51:47 <shardy> m4dcoder: So we're in Feature Freeze now, until RC1 is branched
20:51:50 <MikeSpreitzer> I have a discussion topic: relationship between heat and the instance-group blueprint
20:51:55 <shardy> which we expect to be in a couple of weeks
20:52:13 <shardy> m4dcoder: at which point master is opened for Icehouse, so we can merge your patch
20:52:36 <shardy> MikeSpreitzer: You mean the nova grouped instances?
20:53:00 <MikeSpreitzer> I mean https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
20:53:01 <m4dcoder> shardy: but i mean, are exceptions typically allowed after freeze but before rc1 branch? if so, under what conditions?
20:53:52 <shardy> m4dcoder: Feature Freeze exceptions can be requested, but IMO it's too late for that now
20:54:17 <randallburt> Um, isn't that what Heat is for? Defining a group of artifacts and their semantic relationship to one another?
20:54:19 <shardy> m4dcoder: most folks were requesting their FFE's last week right after h3 got cut
20:54:32 <MikeSpreitzer> RB: yeah, that's my question
20:54:39 <shardy> MikeSpreitzer: I've been meaning to reply to the ML thread
20:54:51 <randallburt> Sounds like that blueprint has a lot of overlap there, IMO.
20:54:56 <MikeSpreitzer> "ML thread"?
20:55:03 <randallburt> Mailing List
20:55:03 <shardy> So, when the nova grouped instance stuff was discussed in portland, I raised this exact point
20:55:10 <radix> huh
20:55:11 <m4dcoder> shardy: what's the formal procedure for FFE? for next time...
20:55:41 <shardy> I was shot down by the nova devs, who said the scheduler needed to know about all the instances and affinity/anti-affinity etc to make smarter placement decisions
20:55:59 <m4dcoder> shardy: hopefully i won't use that next time. but good to know the procedure.
20:56:02 <shardy> IMO it's a bit of a corner case (when your cloud is running on the edge of capacity)
20:56:04 <MikeSpreitzer> Well, yeah, my agenda is to enable something somewhere to make smarter decisions
20:56:10 <randallburt> I thought they were going to extend hint semantics to accomplish that?
20:56:14 <shardy> m4dcoder: email with justifcation to openstack-dev, ref other FFE requests
20:56:50 <m4dcoder> shardy: thanks
20:56:56 <shardy> MikeSpreitzer: So FWIW, I would've preferred if more hint logic was added, and the instance group stuff remained in Heat
20:57:06 <MikeSpreitzer> I want to enable one decision-maker to get a look at all of the resources in a pattern/template/topology at the same time and make a joint decision.
20:57:33 <shardy> MikeSpreitzer: but the nova guys seem to want grouped instances (which don't have any dependency relationshops necessitating orchestration)
20:58:00 <MikeSpreitzer> The instance grouping API is explicitly disclaimed to be just the first step on a longer roadmap...
20:58:01 <shardy> it may be that we wire up the InstanceGroup resource to use that API in due course
20:58:15 <randallburt> 2 min
20:58:28 <radix> I don't understand why there isn't a list of use cases in that spec
20:58:41 <shardy> MikeSpreitzer: well we can take this up on the ML and at the summit, but I agree we need to be wary of scope-creep and any overlap in goals
20:58:54 <MikeSpreitzer> OK, let's continue those ways.
20:58:54 <shardy> MikeSpreitzer: but also see where there is stuff we can leverage ;)
20:59:24 <shardy> MikeSpreitzer: thanks for raising this though :)
20:59:30 <shardy> Ok, out of time, thanks all!
20:59:35 <MikeSpreitzer> thank you. bye
20:59:35 <shardy> #endmeeting