20:00:03 <stevebaker> #startmeeting heat
20:00:04 <openstack> Meeting started Wed Feb 12 20:00:03 2014 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:07 <openstack> The meeting name has been set to 'heat'
20:00:08 <stevebaker> #topic rollcall
20:00:19 <bgorski> o/
20:00:20 <skraynev> o/
20:00:21 <zaneb> greetings
20:00:22 <jasond`> o/
20:00:23 <radix> here!
20:00:34 <sdake> o/
20:00:34 <shardy> o/
20:00:39 <radix> cyli is here too but her wifi just died
20:00:51 <arbylee> o/
20:01:20 <jpeeler> hi
20:01:22 <kebray> o/
20:01:29 <stevebaker> #topic Review last meeting's actions
20:01:48 <stevebaker> everybody to scrub their assigned blueprints for icehouse-3
20:02:13 <stevebaker> everybody: did you do that?
20:02:15 <radix> kinda
20:02:46 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-3
20:03:05 <cyli> hello!
20:03:09 <andersonvom> o/
20:03:12 <stevebaker> we have 3 that are not started, we should consider kicking those
20:03:13 <wirehead_> heya
20:03:17 <tango> o/
20:03:45 <sdake> looks like launchpad just imploded
20:03:50 <stevebaker> auto heat/converge will have no chance, correct?
20:04:11 <stevebaker> systemd should be trivial
20:04:47 <arbylee> stevebaker: converge won't make it
20:04:48 <stevebaker> and therve was going to get back to me about https://blueprints.launchpad.net/heat/+spec/parameter-nested-schema already being done due to other work
20:04:50 <zaneb> not sure about trivial
20:05:07 <sdake> stevebaker re https://blueprints.launchpad.net/heat/+spec/systemd-integration some folks are working on putting that in oslo-incubator, but I suspect the review cycle won't finish in time for me to make the deadline
20:05:16 <radix> I want to talk about the autoscaled ResourceGroup idea too
20:05:21 <stevebaker> zaneb: its just writing to a socket after the daemon has started.
20:05:24 <radix> not sure if we should do that now or later :)
20:05:32 <zaneb> ok
20:05:53 <stevebaker> sdake: if you're busy with oslo.messaging maybe systemd would be good for jpeeler?
20:06:11 * jpeeler looks
20:06:13 <sdake> stevebaker I think the dependency we have (getting into oslo-incubator) wont finish in time
20:06:14 <tspatzier> hi
20:06:29 <sdake> the code to add to heat is actually pretty straight forward
20:06:52 <sdake> shoudl be done with oslo.messaging this week
20:06:52 <dhellmann> sdake: if you share the link to the review, I can try to help prioritize it
20:06:53 <stevebaker> sdake: we could just do it in heat.common for now and move over to the oslo version as and when it is available
20:07:41 <stevebaker> arbylee: ok, I've kicked it
20:07:55 <sdake> stevebaker wfm if jeff  wants to tackle it that also wfm
20:08:13 <radix> if I refocus on kfox's resourcegroup stuff, then as-lib will be kicked (though maybe it should just be closed resolved since I guess it has kind of a nebulous resolution)
20:08:15 <sdake> dhellmann trying to find link
20:08:27 <stevebaker> jpeeler: do you think AWS::EC2::Route will make the feature proposal freeze?
20:08:30 <radix> (since the module is _there_, but it will grow a lot)
20:08:44 <zaneb> radix: I definitely don't think it's resolved
20:08:50 <radix> zaneb: ok :)
20:09:00 <jpeeler> stevebaker: i hate to say, but i got pulled off that right when i started. it essentially isn't started, so probably not.
20:09:09 <sdake> dhellmann https://review.openstack.org/72683
20:09:11 <stevebaker> jpeeler: lets kick it
20:09:13 <zaneb> radix: resolved would be "next blueprint in the queue is unblocked"
20:09:26 <zaneb> s/queue/graph/
20:09:37 <radix> zaneb: I think I'll need to start working on the next one before I can even know that
20:09:40 <radix> but yeah, that's cool
20:10:06 <stevebaker> https://blueprints.launchpad.net/heat/+spec/cancel-update-stack looks more than started
20:10:32 <zaneb> radix: that's true, and let's not pretend that a discrete list of bugs/blueprints accurately reflects reality
20:10:39 <radix> +1 :)
20:10:57 <dhellmann> sdake: ok, could you associate that with a bug or blueprint, so I can put it on our i-3 priority list?
20:11:24 <sdake> dhellmann I'll add a review comment to the effect
20:11:32 <radix> stevebaker: can we just add an agenda item to talk about AutoScalingGroup?
20:11:52 <dhellmann> sdake: if you have a bug in heat, you can add oslo as impacted -- I need something I can put a "high" priority on
20:12:06 <stevebaker> shardy: is https://blueprints.launchpad.net/heat/+spec/native-waitcondition still needed? The native signal API was delivered in a different blueprint
20:12:22 <stevebaker> radix: do it
20:12:29 <shardy> stevebaker: we still don't have any way to connect to that API from an instance
20:12:46 <shardy> stevebaker: ec2 signed auth only works via the cfn API
20:13:13 <stevebaker> shardy: well, there is that. Technically it is not a heat release thing though. Lets leave it open for now
20:13:14 <shardy> so I was planning a resource which provided a way to do an auth_token authenticated request for the wait condition notification
20:13:29 <radix> stevebaker: done
20:13:50 <stevebaker> ok that will do for blueprints for now
20:13:52 <shardy> stevebaker: I was thinking of creating a new WaitHandle type which provided a token, if so it's a heat thing
20:14:04 <shardy> stevebaker: although we could just say it's the clients problem to get a token
20:14:09 <stevebaker> zaneb add summary of this discussion to the router-properties-object blueprint
20:14:12 <sdake> dhellmann for heat, this is medium priority - eg something we could kick if we need to
20:14:21 <zaneb> stevebaker: I did that
20:14:25 <sdake> dhellmann but I'll impact oslo in launchpad with it
20:14:25 <shardy> still need to provide the credentials tho, so there's are several unsolved aspects I wasnted to look at
20:14:32 <shardy> have to see how time goes..
20:14:40 <dhellmann> sdake: ok, I can set it the same, I just don't want to be holding you up because we don't know that we are :-)
20:14:53 <stevebaker> #topic Adding items to the agenda
20:15:04 * radix added something
20:15:23 <sdake> dhellmann dummy q, how do I actually have it impact oslo in launchpad?
20:15:43 <stevebaker> anything else to add?
20:15:44 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-2-12.29
20:15:55 <sdake> quescing servers
20:16:05 <sdake> we had a big long chat in irc yesterday about it
20:16:08 <sdake> but not eveyrone was around
20:16:25 <stevebaker> sdake: done
20:16:32 <sdake> the use case is for autoscaling and update models where we want to shut down the server in a controlled way
20:16:39 <sdake> stevebaker that is done?
20:16:42 <stevebaker> #topic Gate check job is now enabled
20:16:47 <radix> woo
20:16:50 <stevebaker> sdake: its on the agenda now
20:16:54 <sdake> cool
20:17:06 <dhellmann> sdake: for bugs you can just add the project, for blueprints you have to file a second one under oslo and mark it as a dependency of yours (this will improve when we move to storyboard)
20:17:13 <stevebaker> great news everybody, heat-slow is now a non-voting job on gating
20:17:23 <zaneb> awesome
20:17:28 <sdake> dhellmann I'll let Jakub do that since I requested it in the review already and it might cause duplicate blueprints and confusion :)
20:17:42 <dhellmann> sdake: ack
20:17:43 <wirehead_> That sounds gate.  pun intended.
20:18:02 <stevebaker> I want to know how stable it is. It should never fail unless your code breaks it. If it does fail and you think it is not your fault then please let me know
20:18:03 <sdake> sweet
20:18:17 <sdake> I would also like to point out some new contributors have picked up some tempest work which is hugely important to heat's quality :)
20:19:17 <stevebaker> It is likely that we'll see issues related to load and races of other openstack components, it would be great if you could spend the time to raise a tempest bug so we can start collecting recheck stats
20:19:18 <zaneb> stevebaker: from someone who had a crack at automated testing of Heat and failed miserably, kudos for getting this going :)
20:19:28 <stevebaker> zaneb: its been a long road
20:19:44 * stevebaker remembers being volunteered for this in Portland
20:19:48 <sdake> ya 2 years to functional testing :)
20:20:18 <stevebaker> I'd like to make this a voting job at least on heat if it proves stable enough
20:20:27 <stevebaker> and add it to our gate too
20:20:42 <stevebaker> (unless new generation gate doesn't run tempest)
20:21:02 <stevebaker> fungi: ^ ?
20:21:05 <shardy> stevebaker: great news, it's failing on all my patches atm, but that may be because of a domains/devstack issue I'm currently fixing
20:21:21 <stevebaker> shardy: so it works!
20:21:45 <shardy> stevebaker: it works, aka my code doesn't :D
20:22:06 <skraynev> stevebaker: really cool news) I will restore my tempest patch ;)
20:22:15 <fungi> stevebaker: not sure what you mean by new generation gate. we run lots of tempest jobs in the gave for a variety of projects
20:22:19 <stevebaker> heat-slow is also checking on devstack, tempest and nova
20:23:02 <stevebaker> fungi: I was wondering if there was still plans to not run tempest at all in gate in the future, so the gate continues to scale
20:23:53 <stevebaker> #topic Unassigned icehouse-3 bugs
20:24:03 <fungi> stevebaker: no, the tempest team is working on speeding tempest up even more, and the plan would be to probably only perform integration testing (like tempest) in the gate and leave things like unit and static analysis/style jobs for the check pipeline
20:24:04 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-3
20:24:12 <radix> wait, isn't it more important for it to be in gate (vs check)?
20:24:23 <stevebaker> fungi: ok
20:24:51 <stevebaker> There are 8 unassigned bugs in i-3 that need friends
20:25:12 <fungi> zuul will very soon be requiring that your check jobs got a passing grade before allowing your change to be approved into gating
20:25:18 <stevebaker> SpamapS_: about?
20:25:27 <zaneb> fungi: I hope that'll be configurable? Heat's unit tests don't take long to run. I sure would be uncomfortable not having them in the check job.
20:25:49 <tspatzier> stevebaker: I can take #1271008. I'm actually fixing it as part of some HOT cleanup for another bug
20:25:58 <stevebaker> tspatzier: thanks
20:26:02 <zaneb> er s/check/gate/
20:26:11 <radix> :)
20:26:34 <fungi> zaneb: it'll be configurable, yes
20:26:41 <zaneb> ok, cool
20:26:53 <stevebaker> jasond`: can someone be assigned to https://bugs.launchpad.net/bugs/1274201 ?
20:26:54 <uvirtbot> Launchpad bug 1274201 in heat "Rackspace authentication is broken" [High,Triaged]
20:26:55 <zaneb> I know other projects have _much_ slower unit tests
20:27:27 <stevebaker> zaneb: shall we kick https://bugs.launchpad.net/bugs/1193269 ?
20:27:28 <uvirtbot> Launchpad bug 1193269 in heat ""Updated" timestamps store the Wrong Thing" [Low,Triaged]
20:27:39 <zaneb> sure, why not
20:27:48 <jasond`> stevebaker: sure, i'll talk to the team
20:28:09 <stevebaker> I'm going to kick https://bugs.launchpad.net/bugs/1072955 too, unless somebody cares
20:28:10 <uvirtbot> Launchpad bug 1072955 in heat "Implement Fn::Base64" [Low,Triaged]
20:28:39 <zaneb> I'm starting to think maybe we should just close the Base64 one
20:28:59 <stevebaker> yep
20:29:02 <zaneb> remove the function from HOT and forget about it
20:29:28 <stevebaker> or add a function to HOT when somebody needs to deploy some binary chunk
20:30:06 <sdake> we should probably just clos that base64 bug, if you actually encode your template in base64, it breaks heat
20:30:48 <zaneb> sdake: well, the idea would be that the UserData property could detect Base64 and correctly include it in the cloudinit config
20:30:51 <stevebaker> https://bugs.launchpad.net/bugs/1263787 is quite a disruptive change at this point. But it would improve running heat at scale
20:30:52 <uvirtbot> Launchpad bug 1263787 in heat "stack table's uuid primary key wastes resources in other tables" [High,Triaged]
20:31:35 <zaneb> wut
20:31:57 <sdake> i get that there is an optiimization there, but high prioirty?
20:32:01 <radix> o.O
20:32:05 <sdake> imo high priority is "this stuff wont work without it" :)
20:32:44 <stevebaker> SpamapS_ isn't here, maybe lifeless can elaborate on why int primary keys are a GoodThing
20:32:58 <zaneb> 'Wishlist" would be the appropriate priority for that IMO
20:33:21 <sdake> agree with zaneb
20:33:47 <stevebaker> zaneb: not if you can't run heat at scale without this
20:34:15 <zaneb> oh come on
20:34:34 <radix> I'm skeptical that this is actually a blocker for anyone deploying heat
20:34:37 <radix> but hey, data speaks best :)
20:34:40 <zaneb> every record in the database contains multiple 256-byte strings
20:35:03 <zaneb> saving most of a quarter of one of those does not move the needle for anyone
20:35:24 <sdake> we would be better off length-encoding the strings :)
20:36:02 <stevebaker> rackspace changed nova instance primary key to int for scalablity reasons
20:36:24 <stevebaker> I'm assuming this is not a storage overhead thing, its an index lookup overhead thing
20:36:33 <zaneb> stevebaker: who knows what their database looks like
20:36:49 <zaneb> stevebaker: that can't be right, because we still need an index for it
20:36:50 <sdake> imo this is more like a feature request without an interested party willing to implement it
20:37:14 <stevebaker> anyhoo, I'll kick it for now. Maybe that will force someone to step up
20:37:17 <sdake> if there was someone bringing code, i think it would be a different story
20:37:20 <zaneb> sdake: s/feature request/micro-optimisation/
20:37:35 <sdake> zaneb yes that is micro-optimized thanks :)
20:38:02 <stevebaker> this looks like another optimisation bug https://bugs.launchpad.net/heat/+bug/1263911
20:38:03 <uvirtbot> Launchpad bug 1263911 in heat "event_create is the wrong place to count events" [Medium,Triaged]
20:38:53 <sdake> based upon comment #1, looks like another micro opt
20:39:16 <sdake> if we optimize, imo we should aim for a big impact
20:39:17 <stevebaker> which leaves https://bugs.launchpad.net/heat/+bug/1247147
20:39:18 <uvirtbot> Launchpad bug 1247147 in heat "HEAT-Engine Startup Error" [Medium,Triaged]
20:39:24 <stevebaker> sdake: I've kicked it
20:39:52 <stevebaker> we just need to check that engine doesn't actually fail to start if /etc/heat/environment.d is missing
20:40:03 <lifeless> [6~[6~[6~st	hi
20:40:06 <stevebaker> a log error is fine
20:40:09 <radix> heh, hello lifeless :)
20:40:11 <lifeless> ba, sorry
20:40:15 <lifeless> stevebaker: hi
20:40:20 <stevebaker> lifeless: hai
20:40:21 <radix> I see you use a terminal-based IRC client
20:40:27 <sdake> so environment.d woudl be nice if heat just ran without it, but heat should not create directories in the filesystem imo :)
20:40:34 <stevebaker> radix: don't judge man!
20:40:36 <lifeless> radix: The One True IRC client
20:40:38 <radix> :-)
20:41:12 <lifeless> stevebaker: so, primary keys int vs omgenoughbitstorepresenteveryatomintheuniverseabilliontimesover ?
20:41:17 <lifeless> stevebaker: I don't get how its even a question.
20:41:26 <lifeless> stevebaker: but that may be my 'spent years as a DBA' hat on.
20:41:31 <cmyster> sdake: why not? its being done elsewhere (like lib and log)
20:41:54 <lifeless> There's probably even a site 'shouldmypkbeanintoruuid.com'
20:42:02 <sdake> cmyster as far as I know, nothing actually creates directories
20:42:04 <lifeless> (ok that last bit was silly)
20:42:16 <zaneb> lifeless: it may not be question for dbas implementing this from scratch
20:42:17 <sdake> creating directories is bad server development imo :)
20:42:30 <sdake> packaging shoudl handle the directories (so it can clean up after its removed)
20:42:48 <radix> lifeless: I take it you don't buy the argument that UUIDs are more secure than sequential IDs
20:42:56 <radix> random UUIDs, I should say
20:42:56 <stevebaker> cmyster: heat-engine most likely wouldn't have the privilages to create a dir in /etc
20:42:56 <zaneb> lifeless: the question here is 'is this a High-priority bug even though nobody seems to care enough to fix it'
20:43:20 <lifeless> radix: you can have a random UUID per stack - thats fine. Just don't make it the PK.
20:43:25 <zaneb> radix: I think the point is they serve different purposes
20:43:25 <cmyster> ok, etc is a different story :)
20:43:44 <lifeless> radix: PKs are all about in-DB storage serialisation, not user facing.
20:44:06 <lifeless> zaneb: ah, priority. Uhm - I don't know.
20:44:34 <lifeless> zaneb: its certainly less important than getting keystone to use less than 30GB of storage for its tokens...
20:44:43 <stevebaker> lol
20:45:06 <morganfainberg> lifeless, we're trying!!! ephemeral tokens w/ revocation events!
20:45:13 <morganfainberg> lifeless, no more storing tokens in the DB!
20:45:22 <zaneb> lifeless: I concur :)
20:45:25 <radix> oh! I didn't really understand the ticket at first. okay.
20:45:28 <morganfainberg> :)
20:45:45 <lifeless> morganfainberg: I know :) I'm only slightly teasing :)
20:45:53 * morganfainberg stops jumping into meetings randomly
20:45:58 <stevebaker> lets move on
20:46:04 <stevebaker> #topic Heat security team
20:46:46 <stevebaker> I need to have 2-4 heat-cores to be in the heat security team.
20:46:56 <stevebaker> PTL needs to be in it
20:47:13 <shardy> stevebaker: I'll volunteer
20:47:18 * zaneb raises hand
20:47:19 <stevebaker> shardy: finds and fixes most of our security issues, so I think he should be in it
20:47:32 <bgorski> And what are the security team responsibilities exactly?
20:48:03 <sdake> i'm in
20:48:13 <stevebaker> quoting ttx
20:48:15 <radix> some context would be interesting :)
20:48:23 <zaneb> bgorski: dealing with incoming CVEs, basically
20:48:29 <stevebaker> > with a security mindset that we
20:48:31 <stevebaker> can give early access to security issues so that they can help us debunk
20:48:33 <stevebaker> submitted issues and build patches if necessary. They would be our first
20:48:35 <stevebaker> line of contact within your team (and will be able to pull extra
20:48:37 <stevebaker> developers in to help in resolving the issue in a timely manner).
20:49:15 <stevebaker> zaneb, sdake, I wonder if the team should have a more broad vendor spread
20:49:28 <sdake> stevebaker ya that makes sense to me
20:49:36 <cmyster> stevebaker: do you need me to focus on that as well? thinking of tests from outside the dev pov
20:49:41 <sdake> if any other cores are interested
20:49:49 <stevebaker> I was thinking SpamapS_ just for the tripleo perspective
20:50:01 <zaneb> that's a fair point if we have any volunteers
20:50:20 <stevebaker> and a heat-core from rax for an open cloud perspective
20:50:30 <stevebaker> jasond` or randall?
20:50:35 <sdake> stevebaker maybe you can give people a week to think about it
20:50:41 <sdake> and bring it up next meeting?
20:50:47 <stevebaker> sdake: yep
20:51:07 <wirehead_> I can prod internally.
20:51:18 <radix> yeah, I bet randallburt or jasond` may be interested
20:51:26 <jasond`> stevebaker: sure
20:51:35 <radix> randallburt is gone for the day
20:51:39 <stevebaker> wirehead_: this has to be somebody already in heat-core, of course any efforts on heat security are welcome
20:52:16 <zaneb> stevebaker: wirehead_ wasn't volunteering, just volunteering to poke randallburt
20:52:28 <wirehead_> :)
20:52:39 <stevebaker> jasond`: let me know later who is the lucky one
20:52:47 <stevebaker> #topic Resource-based AutoScalingGroup
20:52:51 <jasond`> stevebaker: will do
20:53:05 <stevebaker> radix: meep
20:53:07 <radix> so there was this discussion yesterday
20:53:13 <radix> stevebaker: I guess you missed the last half of it
20:53:41 <radix> kfox basically mentioned his initiative to make a version of AutoScalingGroup that can work with other resources
20:53:51 <radix> and this may actually be an opportunity to get something _useful_ into icehouse :)
20:54:12 <radix> he was developing it as a third-party plugin, but it's possible this could basically become a part of the "as-intermediate-resource"
20:54:35 <radix> so basically I'm offering my time to work on that now instead of the as-lib BP, which is effectively not useful to end-users
20:54:37 <SpamapS_> o/
20:54:49 <SpamapS_> sorry physical meetings today
20:55:18 <radix> so I want to see if it's something that anyone else thinks is a good idea
20:55:24 <radix> it seemed pretty positive yesterday
20:55:51 <stevebaker> radix: for software config there needs to be one or more deployment resources per server resource, so I'm keen to be able to scale something which isn't just a server
20:56:01 <radix> right, there are pretty strong use cases for it
20:56:17 <SpamapS_> +1 on coalescing resourcegroup with autoscalinggroup
20:56:26 <radix> and my idea is to simply just subclass AutoScalingGroup and making it allow arbitrary resources, in the same way ResourceGroup works
20:56:29 <shardy> radix: The discussion started with funzo's requirement to scale OS::Nova::Servers with multiple neutron networks IIRC:
20:56:32 <shardy> http://paste.openstack.org/show/64765/
20:56:35 <radix> shardy: oh right ok
20:56:37 <SpamapS_> we need exactly that for TripleO
20:56:49 <shardy> maybe kfox chimed in after, I think he had similar issues
20:56:50 <skraynev> I agree with radix native AutoscalingResources will be good additional for heat
20:57:13 <gokrokve> +1 to have it in Icehouse
20:57:15 <radix> now, there's only a week for reviews to be submitted... so I'll try myb est :)
20:57:27 <radix> shardy: was it funzo the whole time? maybe I was confused about kfox
20:57:33 <tspatzier> radix: do you have a link to a BP or wiki page or something?
20:57:40 <stevebaker> I'm all for giving it a go
20:57:48 <zaneb> I think we should do the hack if we think we can build on it to deliver the final feature we planned on in the future
20:57:58 <stevebaker> should we ditch ResourceGroup if it lands?
20:58:18 <radix> stevebaker: hmm, maybe?
20:58:26 <zaneb> if it's just going to involve more backtracking, deprecation, &c. then we should forget about it and concentrate on delivering what we want for Juno
20:58:42 <shardy> zaneb: Yeah, my suggestion was to focus on that use-case from funzo and make it possible in a simple-a way as possible, but ideally with flexibility so we can iterate on it in Juno
20:58:56 <radix> zaneb: I think it has a chance to look at least pretty close to the ultimate resource. i.e. it should be possible to switch out the implementation later
20:59:06 <shardy> an interface which allows scale out of provider resources seems like a good interface to me
20:59:20 <zaneb> radix: if that is the case then +1
20:59:28 <shardy> as it's simple but very flexible
20:59:33 <stevebaker> how do we deal with the fact that an artibrary resource will create something real, but a launchconfiguration doesn't
20:59:47 <radix> stevebaker: not sure what you mean
20:59:59 <funzo> A launch configuration is just used as a template
21:00:19 <zaneb> stevebaker: just hack it like we do now, presumably
21:00:20 <funzo> the arbitrary resources in this context are real ports, floating ips
21:00:24 <jd__> (knock knock)
21:00:27 <radix> basically, look at ResourceGroup, I'm just suggesting making it look like that
21:00:36 <skraynev> time is over(((
21:00:37 <stevebaker> radix: ok, thats fine
21:00:43 <shardy> lets move to #heat..
21:00:46 <stevebaker> woah
21:00:49 <stevebaker> #endmeeting