20:00:19 <zaneb> #startmeeting heat
20:00:20 <openstack> Meeting started Wed Aug 28 20:00:19 2013 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:23 <openstack> The meeting name has been set to 'heat'
20:00:34 <sdake_> o/
20:00:38 <zaneb> evening all
20:00:40 <asalkeld> o/
20:00:40 <stevebaker> yop
20:00:47 <spzala> Hello!
20:00:57 <bgorski> o/
20:01:06 <jasond> o/
20:01:15 <zaneb> shardy can't make it this evening, so y'all are stuck with me again ;)
20:01:16 <andrew_plunk> hello everyone
20:02:26 <jpeeler> hey
20:02:34 <zaneb> ok, I think that qualifies as a quorum
20:02:39 <SpamapS> o/
20:02:43 <radix> hello!
20:02:44 <asalkeld> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:02:47 <zaneb> #topic Review last week's actions
20:02:51 <m4dcoder> o/
20:03:01 <zaneb> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-08-21-20.01.html
20:03:10 <zaneb> only one, shardy to post mission statement, again
20:03:16 <zaneb> that actually happened!
20:03:18 <zaneb> woohoo!
20:03:23 <radix> finally :)
20:03:43 <zaneb> let's call that success, unless anybody wants to bikeshed some more ;)
20:04:04 <SpamapS> isn't that what meetings are for?
20:04:07 <zaneb> #topic Reminder re FeatureProposalFreeze
20:04:18 <zaneb> #link https://wiki.openstack.org/wiki/FeatureProposalFreeze
20:04:39 <zaneb> hopefully y'all have proposed your features
20:04:43 <stevebaker> that seemed to go well
20:04:46 <SpamapS> came and gone no?
20:04:52 <zaneb> SpamapS: yep
20:05:06 <stevebaker> when is feature freeze?
20:05:08 * zaneb suspects copy-and-paste fail on the agenda here ;)
20:05:26 <zaneb> stevebaker: 4th September
20:05:31 <adrian_otto> am I in a time machine?
20:05:34 <zaneb> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
20:05:55 <zaneb> so, good job everybody
20:06:13 <stevebaker> so features still being reviewed after the 4th need explicit exceptions?
20:06:17 <zaneb> and it looks like we don't have a huge review backlog, so we should be in good shape for feature freeze
20:06:39 <zaneb> stevebaker: well, havana-3 release is on the 6th
20:06:51 <zaneb> so there shouldn't really be any _features_ going in after that
20:07:35 <zaneb> review queue looks about as long as always
20:07:44 <zaneb> #link https://review.openstack.org/#/q/status:open+project:openstack/heat,n,z
20:07:44 <radix> I'm trying to help :)
20:07:44 <SpamapS> Do we have features which are racing to land?
20:08:01 <zaneb> good question
20:08:06 <radix> yeah it'd be nice if I could filter gerrit by feature vs bugfix
20:08:08 <zaneb> #topic h3 blueprint status
20:08:15 <stevebaker> my review queue alarm threshold is "does it scroll?"
20:08:31 <SpamapS> https://launchpad.net/heat/+milestone/havana-3
20:08:32 <asalkeld> zaneb, http://status.openstack.org/reviews/#heat
20:08:32 <zaneb> stevebaker: it's been scrolling for quite a while though ;)
20:08:36 <kebray> jasond is multi-engine stuff a feature or bug?
20:08:54 <stevebaker> kebray: yes!
20:08:57 <SpamapS> looks like all targetted BP's are in review
20:09:00 <zaneb> asalkeld: ooh, fancy :)
20:09:17 <jasond> kebray: we decided it was a BP since the original commit was reverted
20:09:32 <radix> ah there we go
20:09:49 <stevebaker> reviews on this are lacking https://review.openstack.org/#/c/43205/
20:09:54 <kebray> ok.. so, zaneb, we're racing a bit on the multi-engine one.  I think jasond has it under control though.. it's down to more tests I believe.
20:10:09 <zaneb> ok, thanks for the info
20:10:42 <zaneb> #link https://launchpad.net/heat/+milestone/havana-3
20:11:14 <zaneb> trusts and multi-engine are the two diciest, I think
20:11:33 <zaneb> but I'm reasonably confident
20:11:49 <kebray> I want trusts... if help is needed, let me know and I can see what resources we can spare to help the effort.
20:12:11 <stevebaker> kebray: reviews would be good
20:12:16 <kebray> k.
20:12:31 <zaneb> kebray: we all want trusts ;) I think shardy has got it to the point where it's not going to be lack of resources causing a problem
20:12:39 <zaneb> it will be random stuff out of left field
20:12:49 <timductive> yes +1 on trusts :)
20:13:02 <kebray> zaneb: that's what I thought... and I figure throwing more people at the problem would actually slow it down.  so, also happy to stay out of the way :-)
20:13:11 <zaneb> after studiously ignoring reviews for a few days to get the update stuff posted, my plan is to focus on reviews for the next few days
20:13:23 <kebray> but, stevebaker comment on reviews is appropriate.  we'll try to help with that.
20:13:42 <zaneb> the gate will be crazy next week, so if everybody can try to get the review backlog down that would be very helpful
20:14:21 <asalkeld> also can we stick to looking for bugs in the reviews
20:14:38 <radix> hm?
20:14:42 <asalkeld> uploading new patches is very time expensive
20:15:02 <zaneb> yeah, y'all would be surprised about how little anybody will care about typos in hte commit message a year from now ;)
20:15:43 <asalkeld> radix, just saying very little value in fixing nits
20:15:44 <zaneb> s/hte/the/
20:15:44 <zaneb> #topic Single Config file?
20:15:44 <zaneb> asalkeld: you have the floor
20:15:46 <sdake_> the commit message is the most important part of the change
20:15:53 <asalkeld> haah
20:16:11 <asalkeld> so the change for the single config is in
20:16:23 <asalkeld> so little to motivate for now
20:16:38 <asalkeld> but to let you know we are moving to a single heat.conf
20:16:49 <asalkeld> I'll do the devstack change
20:17:02 <radix> the docs still need updated, right?
20:17:02 <stevebaker> yay
20:17:03 <asalkeld> then kill the old heat-<>.conf's
20:17:11 <asalkeld> radix, yes
20:17:16 <asalkeld> good point
20:17:35 <asalkeld> that's all from me
20:17:42 <stevebaker> asalkeld: so the devstack change will start with heat.conf.sample and customize?
20:17:48 <asalkeld> yip
20:17:55 <stevebaker> sweet
20:18:02 <sdake_> is devstack broken atm with master/
20:18:15 <stevebaker> not for me
20:18:18 <zaneb> sounds good, I guess the question was answered in the affirmative ;)
20:18:18 <asalkeld> really
20:18:47 <asalkeld> I have some environment and template patches for devstack
20:18:49 <stevebaker> you can always run heat standalone against some other cloud
20:18:51 <adrian_otto> yes it is broken
20:18:57 <asalkeld> not sure if they have made it in
20:18:58 <zaneb> #info we will move to a single config file and remove the legacy configs
20:19:22 <asalkeld> https://review.openstack.org/#/c/43631/
20:19:45 <asalkeld> that not being in might be causing issues
20:20:41 <stevebaker> yes, we'll be needing that
20:20:49 <spzala> zaneb: asalked: is there a doc/link to learn more about single config?
20:21:03 <SpamapS> wait when are the legacy configs being removed?
20:21:08 <SpamapS> "icehouse" right?
20:21:09 <asalkeld> no, what do you need?
20:21:28 <asalkeld> SpamapS, we still support them
20:21:34 <SpamapS> ok, just examples.
20:21:44 <asalkeld> just removing the examples from master
20:21:46 <asalkeld> ya
20:21:56 <SpamapS> roger, nothing to see here, move along
20:22:14 <asalkeld> zaneb, SpamapS 's next topic...
20:22:24 <zaneb> :)
20:23:10 <zaneb> #topic moving rackspace cloud server specific resources out of heat tree
20:23:10 <zaneb> so, can I just redefine something here?
20:23:10 <zaneb> in-repo = in openstack/heat git repo
20:23:15 <zaneb> in-tree = under heat/engine/resources
20:23:39 <zaneb> so, SpamapS, what we're talking here is moving out of the repo?
20:23:52 <stevebaker> or into a contrib dir
20:23:58 <SpamapS> Ok, I think they should be out of the repo, in the direct control of rackspace-cloud-interested people.
20:24:04 <asalkeld> well what really matters is what the rackers want
20:24:08 <zaneb> because I was under the impression we agreed to have it under /contrib, and then when it landed it was in-tree
20:24:18 <zaneb> and I don't know what happened there
20:24:20 <SpamapS> I think the rackers are looking to us, heat-core, for guidance.
20:24:23 <zaneb> miscommunication?
20:24:48 <asalkeld> hello rackers, what do you want...
20:24:51 <SpamapS> contrib still carries the problem that rackspace public cloud does not follow the openstack release cadence.
20:25:03 <radix> ping kebray
20:25:07 <zaneb> SpamapS: fair point
20:25:11 <kebray> From the Racker perspective, we want wants best for the project and all parties who want to contribute in a similar manner...
20:25:29 <SpamapS> This isn't like a driver in the kernel where it is there to support pieces of hardware that are "out there".
20:25:38 <kebray> there's an obvious advantage to us if our resources get tested as part of CI, as a change to a base resource could affect our resources... but, we also understand not everyone may be able to contribute a fix to our resources.
20:25:53 <zaneb> SpamapS: but then again, having them out of tree requires us to be more disciplined about the interface to plugins
20:26:01 <kebray> s/what's/wants
20:26:03 <asalkeld> I am not stressed it being there
20:26:06 <SpamapS> The rackspace public cloud is a special snowflake and will always be that way as long as it is not conformant with the rest of OpenStack.
20:26:16 <radix> hmm, do the rackspace resource tests actually get run in CI? aren't they protected by a "if pyrax is available" clause?
20:26:22 <stevebaker> for now I would prefer to have no discipline about our plugin interface
20:26:41 <SpamapS> zaneb: that much discipline will only help adoption of Heat and grow the ecosystem around Heat.
20:26:54 <asalkeld> I think that is a strong point of somewhen in tree stevebaker
20:27:09 <zaneb> stevebaker: too long. "I would prefer to have no discipline." <- better
20:27:21 <andrew_plunk> I just wonder about the priority that will be given to heat bugs that break plugins
20:27:23 <SpamapS> radix: yeah, no pyrax, no testing
20:27:56 <SpamapS> actually hm
20:27:58 <radix> SpamapS: actually
20:28:00 <radix> hehe :)
20:28:11 <radix> I just saw the tests force the registration of the resource so it can be tested.
20:28:24 <SpamapS> yeah and they just side-step the pyrax calls.
20:28:33 <kebray> what about resources like Trove?   they should remain in-tree, no?
20:28:35 <SpamapS> kebray: nobody is saying you can't be in stackforge of course. :)
20:28:39 <radix> (that's probably what neutron tests should do too... therve has been writing the tests so they skip if neutronclient isn't available even if neutronclient isn't really used)
20:28:44 <SpamapS> kebray: absolutely
20:28:50 <andrew_plunk> SpamapS: we still run unit tests without pyrax
20:28:59 <andrew_plunk> we completely mock out pyrax
20:29:01 <SpamapS> Any resource that is implementing an OpenStack API should be in-tree.
20:29:03 <zaneb> kebray: yes, as long as it uses regular keystone
20:29:19 <kebray> SpamapS.  Understood.. I feel I understand the arguments on both sides... so, I'm pretty neutral on this.
20:29:36 <andrew_plunk> I feel like the contrib idea is a good middle road
20:29:43 <zaneb> for my part I would still at least like to see it moved to /contrib
20:29:52 <stevebaker> +1 for contrib
20:29:57 <zaneb> as a packager, I really don't feel it belongs where it is
20:29:58 <asalkeld> sure
20:30:01 <jasond> +1 for /contrib
20:30:07 <kebray> We hope the RS Cloud Server resources goes away soon.. we're working internally to converge compatibility such that the generic nova server resource is sufficient.
20:30:19 <SpamapS> I feel like we are holding the rax developers back, and they are putting code in front of us that has almost nothing to do with Heat's core mission (whether you like the one we all came up with, or Robert Collins succinct one)
20:30:24 <zaneb> who wants an action to move it?
20:30:29 <asalkeld> kebray, cool
20:30:38 <stevebaker> kebray: i home when native nova server lands you can switch to subclassing that?
20:30:53 <andrew_plunk> zaneb: you can give it to me
20:30:56 <kebray> Load Balancer is another issue though.  I think HP and other vendors will have similar one off special implementations potentially.
20:31:10 <SpamapS> kebray: even more reason to get them out of the repo and into a place that can just be shut down when the unicorns are finally harnessed. ;)
20:31:16 <zaneb> #action andrew_plunk to move Rackspace resources to /contrib directory
20:31:22 <kebray> SpamapS  I don't disagree.
20:31:23 <jasond> SpamapS: i like getting feedback from the core devs
20:31:39 <SpamapS> kebray: HP's LBaaS is a published API (Atlas) IIRC.
20:32:21 <jasond> when something is clearly up to us, the core devs can just approve based on votes from other rackers
20:32:32 <zaneb> so, on the in-repo/out-of-repo question, I'm relaxed. If the current situation is not working for Rackspace folks, feel free to move it. And if it is, I'm not worried about leaving it in /contrib
20:32:40 <SpamapS> jasond: thats a fair counter-argument.. resources are still a bit mysterious and core devs can help make them better.
20:32:57 <radix> if it's in /contrib, will it get CI?
20:33:20 <asalkeld> radix, as long as you have tests
20:33:22 <zaneb> radix: I'm sure there's a way to arrange it so it will
20:33:22 <SpamapS> It would be harder to test them from contrib
20:33:34 <SpamapS> I'm kind of "meh" on contrib
20:33:41 <SpamapS> heat/engine/resources/rackspace == contrib in my mind.
20:34:08 <zaneb> SpamapS: I don't know about Debian, but that's just a PITA to package in an RPM
20:34:15 <asalkeld> looks like we have come full circle
20:34:30 <adrian_otto> you can have multiple repos in heat, and contrib could be its own repo, and it could still have CI.
20:35:04 <kebray> Is there a way to have contrib (or heat/engine/resources/rackspace be "optional" on test gates?  Maybe adrian_otto's suggestion accounts for that.
20:35:08 <jasond> SpamapS: except contrib/rackspace could have its own heat tree (engine, api, etc..)
20:35:22 <SpamapS> Ok lets take a step back from the ideas on how. Am I in a minority in suggesting that these resources should be out of the repo/tree?
20:35:50 <asalkeld> I don't mind either way
20:35:53 <SpamapS> zaneb: no its not hard with Debian, but it is far less automatic than just "let setup.py do its thing"
20:35:55 <andrew_plunk> SpamapS I know that RandallBurt's vote is with you
20:35:56 * zaneb is not taking a side
20:35:57 <kebray> I'm neutral.
20:36:01 <adrian_otto> then let's KISS
20:36:19 <SpamapS> Yeah, if its just me and Randall who care.. leave them be.
20:36:22 <adrian_otto> if having htem in tree is not causing objections, then let's revisit it once there is an objection to field.
20:36:54 <adrian_otto> I think we already worked around the test gate concern, right kebray?
20:37:13 <SpamapS> My objection mainly pertains to the fact that by having them in-tree we raise the barrier for other projects who want to write custom resources.. as it is not obvious _at all_ how to do that and not be in-tree.
20:37:34 <kebray> adrian_otto issue is if someone makes change to base resource and RS resource tests break, is that gating that change until someone fixes the RS resource?
20:37:39 <andrew_plunk> SpamapS: that can be documented
20:37:56 <zaneb> SpamapS: true, but we weren't exactly fighting them off before either ;)
20:38:26 <zaneb> andrew_plunk: that *is* documented https://wiki.openstack.org/wiki/Heat/Plugins
20:38:27 <stevebaker> SpamapS: we'd need to decide that our resource interface was going to have proper change control before encouraging that though
20:38:31 <SpamapS> zaneb: An ecosystem starts with one user though.. and we have done the one in a special way that we will likely never do again.
20:38:35 <kebray> SpamapS: does moving them to contrib not address your main objection?
20:39:17 <adrian_otto> contrib is stuff that does not get tested, right?
20:39:18 <asalkeld> there is just a plugins_dir config option isn't there
20:39:24 <SpamapS> kebray: moving them to contrib would make it more obvious, but would we accept a resource to control vagrant, or CloudStack, in contrib?
20:39:30 <adrian_otto> and it's use-at-your-own-risk
20:39:48 <zaneb> adrian_otto: I think we'd want to keep testing it
20:39:59 <adrian_otto> then it should probably be in your tree
20:40:03 <zaneb> SpamapS: I would
20:40:15 <adrian_otto> if you are supporting it, then treat it as such
20:40:16 <andrew_plunk> Keeping these resources in the repo helps with collaboration outside of any specific company. Everyone gets visibility to Rackspace specific code and the converse
20:40:23 <adrian_otto> if it's unsupported, then it's contrib, right?
20:40:28 <kebray> SpamapS I would be ok with it for now until we find a concrete objection.
20:41:06 <SpamapS> Mmk, if we would, and we'd be happy with the review load being centralized, then we should push to move resources out of tree en masse eventually.
20:41:29 <SpamapS> But for now, nothing is broken, and nobody is stifled, so I suggest we move on.
20:41:54 <zaneb> SpamapS: is this worth a mailing list post?
20:42:01 <adrian_otto> but to repeat kebray's comment, if it aids the project, we will not object to moving them elsewhere
20:42:02 <zaneb> seems like this is a long-form argument ;)
20:42:05 <kebray> I agree it some point it will happen.. if enough special contribs are there, centralized review from core team will become difficult in the long run.  But, it's still early.. we don't have many yet, so there's benefit to collaborating on the reviews.
20:42:39 <kebray> adrian_otto, correct.  I don't object to moving them out.  I defer to the core team's recommendation.
20:43:15 <zaneb> ok
20:43:16 <zaneb> #topic Open discussion
20:43:19 <zaneb> have at it
20:43:39 <radix> is there a way to schedule/plan individual meetings at the summit? like, things that aren't talks
20:43:56 <zaneb> radix: yes, the design summit
20:43:58 <kebray> is there a documented plan somewhere around native heat tools to replace heat-cfn, and overlap with what cloud-init provides?
20:44:18 <SpamapS> radix: that is the entire point of the design summit. :) the talks were an after thought :)
20:44:22 <zaneb> radix: that hasn't been organised yet though
20:44:33 <SpamapS> kebray: yes, .. blueprint native-in-instance-tools
20:44:53 <stevebaker> kebray: I'll propose a design summit session for that
20:44:56 <kebray> SpamapS does that address the overlap in functionality with cloud-init?  I may just need to reread it.
20:45:01 <kebray> stevebaker:  awesome!
20:45:10 <radix> zaneb: wait, is the "design summit" something different from what is happening in HK?
20:45:11 <SpamapS> kebray: there are 3 sub-blueprints
20:45:21 <SpamapS> kebray: and there is no overlap.. cloud-init != a config management tool. :)
20:45:24 <zaneb> radix: it's a separate track
20:45:33 <kebray> stevebaker: can you also propose the design summit happen in a place that isn't so expensive to travel to?  I'd love to send more people :-)
20:45:39 <zaneb> radix: but don't worry, it'll be in Hong Kong ;)
20:45:43 <radix> hehe, ok
20:45:48 <SpamapS> kebray: though for the bootstrap-config tool... it might work out :)
20:45:54 <stevebaker> kebray: heh
20:46:05 <kebray> SpamapS I know cloud-init isn't config management.  I guess my knowledge of cnf tools is lacking.  I'll read up on that :-)
20:46:26 <asalkeld> ansible as  a service?
20:46:38 <stevebaker> ansible as a metadata snippet?
20:46:40 <SpamapS> aaas is a horrible, horrible name
20:46:51 <asalkeld> :)
20:47:02 * stevebaker drops the kids off at the school
20:47:18 <zaneb> radix: it's basically a bunch of rooms that are essentially developer-only design sessions. Official/incubated projects get allocated time. It'll be organised shortly.
20:47:25 <kebray> I'm going to ansiblefest.  I'm actually very interested in the convergence of the configuration tools with orchestration.. they are moving into orchestration, and some people think orchestration engine should solve config management (don't want to debate that now thought).
20:47:33 <radix> zaneb: okay, cool
20:47:44 <radix> zaneb: even though I'm not going to be there :( I want to propose some discussions
20:48:08 <SpamapS> kebray: I may join you there.
20:48:11 <asalkeld> kebray, it would be nice to support ansible/salt
20:48:21 <kebray> fwiw, I don't think many of us Rackspace devs will be at the summit :-(
20:48:34 <asalkeld> :(
20:48:41 <zaneb> :(
20:48:48 <zaneb> kebray: that's disappointing
20:48:48 <asalkeld> heat summit in kebray's garage
20:48:49 <kebray> asalkeld feel free to take up a collection :-)
20:48:57 <SpamapS> kebray: are you _asking_ us to kidnap your devs and take them to HK? ;)
20:49:11 <kebray> SpamapS:  fine by me :-)
20:49:11 <andrew_plunk> I don't know if you can kidnap the willing
20:49:13 * asalkeld not rolling in cash
20:49:34 <adrian_otto> I will represent radix
20:49:36 <radix> I know therve and adrian_otto are going to be there, not sure who else
20:49:37 <kebray> Anyway, we'll figure out how to contribute. We like working with you all :-)
20:50:46 <zaneb> ok, there no *law* that says we have to go the full hour ;)
20:50:57 <asalkeld> w00t
20:50:58 <zaneb> so if we're done here I'll wrap it up
20:51:03 <asalkeld> coffee time
20:51:04 <SpamapS> re ansible and salt.. we already integrate well with both of them, anything new would be syntactic sugar to make federating our instances into a salt/ansible grouping easier.
20:51:06 <kebray> SpamapS asalkeld  I'd love to review more of ya'lls thoughts on config management, Salt/Ansible, orchestration, etc.
20:51:19 <SpamapS> kebray: we can chat about it in #heat after if you have time.
20:51:28 <kebray> Ok.
20:51:31 <SpamapS> zaneb: please yes lets wrap
20:51:36 <zaneb> ok
20:51:40 <zaneb> #endmeeting