20:00:16 <sdake_> #startmeeting heat
20:00:17 <openstack> Meeting started Wed Feb 27 20:00:16 2013 UTC.  The chair is sdake_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:20 <openstack> The meeting name has been set to 'heat'
20:00:27 <sdake_> #topic rollcall
20:00:35 <sdake_> hidey ho
20:00:46 <shadower> o/
20:00:52 <stevebaker> o/
20:01:25 <jpeeler> o/
20:01:28 <zaneb> yo
20:01:40 <asalkeld> hey
20:01:54 <sdake_> looks like we have enough to get started
20:02:02 <sdake_> #topic g3-rc1 bug review
20:02:21 <sdake_> I'd like to go through the unfixed bugs for rc1 and see if there are any that can be ditched
20:02:46 <sdake_> we have approximately two weeks left (March 14th)
20:02:55 <sdake_> #link https://wiki.openstack.org/wiki/GrizzlyReleaseSchedule
20:03:31 <sdake_> #link https://bugs.launchpad.net/bugs/1128486
20:03:33 <uvirtbot> Launchpad bug 1128486 in heat/grizzly "creating a stack without a required param, fails correctly but leaves the stack created" [High,New]
20:04:04 <sdake_> asalkeld that look ok for a march 14th deadline?
20:04:50 <asalkeld> looking
20:05:10 <asalkeld> yea that's 2 weeks
20:05:13 <sdake_> ya
20:05:15 <asalkeld> heaps of time
20:05:18 <sdake_> coupled with your other work tho :)
20:05:35 <sdake_> #link https://bugs.launchpad.net/bugs/1133381
20:05:36 <uvirtbot> Launchpad bug 1133381 in quantum "Upgrade to Quantum client 2.2" [High,In progress]
20:05:47 <asalkeld> I'll drop, so someone else _could_ take it
20:06:03 <sdake_> only concerned about shardy - he has alot on his plate atm
20:06:17 <sdake_> shardy you mind dropping that bug on someone else?
20:06:39 <stevebaker> I could take 1133381
20:07:04 <sdake_> sounds good
20:07:19 <sdake_> #link https://bugs.launchpad.net/bugs/1131303
20:07:22 <uvirtbot> Launchpad bug 1131303 in heat "Rollback deletes all events by default" [Medium,Confirmed]
20:07:27 <sdake_> guess shardy didn't make it back from dinner ;)
20:07:29 <stevebaker> shardy isn't actually here right now
20:07:35 <sdake_> yes i know
20:08:03 <sdake_> i'll have to sync up with him on 1131303 later but seems like we want to fix that one
20:08:17 <sdake_> #link https://bugs.launchpad.net/bugs/1130898
20:08:18 <uvirtbot> Launchpad bug 1130898 in heat/grizzly "Should add 'break's in for loops in instance.py" [Low,Confirmed]
20:08:25 <sdake_> this is a two liner fix
20:08:29 <sdake_> pretty sure ian can handle it ;)
20:08:40 <sdake_> #link https://bugs.launchpad.net/bugs/1072949
20:08:41 <uvirtbot> Launchpad bug 1072949 in heat/grizzly "Reset DB migrations" [Critical,Triaged]
20:09:08 <sdake_> the original bug indicates there won't be an upgrade path from heat v7 to heat grizzly
20:09:36 <sdake_> zaneb this look ok for 14th?
20:09:54 <zaneb> should be, I'm about to actually start on it :)
20:09:58 <sdake_> nice
20:10:17 <sdake_> #link https://bugs.launchpad.net/bugs/1134258
20:10:18 <uvirtbot> Launchpad bug 1134258 in heat "Stack updates ignore changes in dynamic attributes" [High,Triaged]
20:11:06 <sdake_> hey shardy
20:11:13 <sdake_> https://bugs.launchpad.net/bugs/1134258
20:11:18 <shardy> sdake_: sorry I'm late, got stuck in traffic
20:11:26 <sdake_> our deadline for rc1 is march 14th
20:11:27 <sdake_> no sweat
20:11:36 <sdake_> that bug look ok for march 14th?
20:11:49 <sdake_> coupled with the numerous other things your working on ? :)
20:12:21 <shardy> sdake_: Yep, I think they should all be OK
20:12:29 <sdake_> ok
20:12:45 <sdake_> other purpose of this topic is to deep six bugs we are not going to fix
20:12:47 <shardy> most fairly simple, the LoadBalancer stuff is most complex, and that's nearly fixed now
20:13:00 <sdake_> https://bugs.launchpad.net/bugs/1096017
20:13:02 <uvirtbot> Launchpad bug 1096017 in heat/grizzly "AutoScalingGroup missing VPCZoneIdentifier property" [Medium,Triaged]
20:13:05 <sdake_> jpeeler didn't you fix this?
20:13:27 <jpeeler> no, i'm looking at it now
20:13:32 <sdake_> ok
20:13:45 <sdake_> 14th look ok?
20:13:57 <jpeeler> yes
20:14:14 <sdake_> #link https://bugs.launchpad.net/bugs/1097430
20:14:15 <uvirtbot> Launchpad bug 1097430 in heat/grizzly "heat: doesn't use EC2 tags API" [Medium,Triaged]
20:14:59 <shardy> I don't think the tags stuff got merged into Nova did it?
20:15:01 <sdake_> so reading bug, looks like that is in progress
20:15:06 <stevebaker> that should really be a blueprint
20:15:53 <sdake_> #info https://bugs.launchpad.net/bugs/1097430 should likely be a blueprint and moved to Havana
20:15:54 <uvirtbot> Launchpad bug 1097430 in heat/grizzly "heat: doesn't use EC2 tags API" [Medium,Triaged]
20:16:14 <sdake_> #link https://bugs.launchpad.net/bugs/1131283
20:16:15 <uvirtbot> Launchpad bug 1131283 in heat "--disable-rollback doesn't work for heat-boto" [Medium,Triaged]
20:16:34 <shardy> I had a look at that, should be simple to fix I think
20:16:37 <sdake_> shardy that looking ok for 14th?
20:16:38 <sdake_> ok
20:16:50 <sdake_> #link https://bugs.launchpad.net/bugs/1131759
20:16:52 <uvirtbot> Launchpad bug 1131759 in heat "Cannot query stack by ARN via ReST API/heatclient" [Medium,Triaged]
20:16:57 <sdake_> this is not assigned
20:17:01 <sdake_> any victims
20:17:33 <shardy> That should be fairly simple too, just needs an identifier lookup like in the CFN API
20:17:34 <stevebaker> I'm not sure the ReST API should support ARNs. zaneb?
20:18:06 <shardy> stevebaker: If we don't support ARNs then we need some other unique identifier format, so we can reference nested resources
20:18:32 <zaneb> I think it will have to
20:18:35 <shardy> I've implemented AWS::StackId to use the ARN format, so at least for now, IMO the ReST API should support it
20:18:38 <stevebaker> if it shouldn't go into the API then it could be supported client side
20:18:58 <zaneb> stevebaker: that's true, ARN contains the uuid
20:19:13 <shardy> In the cfn API it's just another accepted format for stack name, can we just do the same?
20:19:41 <zaneb> yes, what shardy said is what I was originally thinking
20:20:03 <stevebaker> ok, that most likely would require any client changes
20:20:14 <sdake_> would or wouldn't?
20:20:22 <stevebaker> ugh, wouldn't
20:20:56 <sdake_> ok, so anyone willing to take besides shardy :)
20:21:23 * stevebaker whistles and kicks the ground
20:21:38 <sdake_> ok, guess we can come back to that ;)
20:21:53 <sdake_> #link https://bugs.launchpad.net/bugs/1072938
20:21:55 <uvirtbot> Launchpad bug 1072938 in heat/grizzly "nosetests -a does not return error if credentials not loaded on functional tests" [Low,Triaged]
20:21:59 <sdake_> 14th look ok jpeeler?
20:22:27 <jpeeler> yeah, although what's the state for functional tests now?
20:22:35 <jpeeler> there's a comment that says "no longer affects heat"
20:22:46 <stevebaker> since we'll be switching to testr early in H should we WONTFIX it?
20:23:02 <sdake_> jpeeler this is my ineptitude with launchpad ;)
20:23:32 <sdake_> ya lets close it
20:24:10 <sdake_> #link https://bugs.launchpad.net/bugs/1102101
20:24:11 <uvirtbot> Launchpad bug 1102101 in heat/grizzly "--host option to heat-boto is ignored" [Low,Triaged]
20:24:30 <shardy> Should be ok, easy fix
20:24:44 <sdake_> ok
20:24:48 <sdake_> rest bugs are in progress
20:24:50 <shardy> well, easy to remove the --host option, boto won't support it
20:25:18 <sdake_> need to have speedy reviews over next couple weeks to get the bugs fixed
20:25:42 * shardy hopes we don't lose any more days due to broken gates
20:25:47 <sdake_> #topic image building
20:26:13 <sdake_> a few of us had a conversation in heat channel about our model going  forward re images
20:26:16 <sdake_> i'll summarize that
20:26:32 <sdake_> 1. We want our jeos images to come from providers, rather  then us creating them with heat-jeos
20:26:39 <sdake_> 2. images that work with heat should have cloud-init
20:26:52 <sdake_> 3. we will install pypi at  runtime via  a runcmd or change to the logusredata.py shell script
20:27:04 <sdake_> sorry we will install via pypi heat-cfntools
20:27:25 <stevebaker> (or direct inject, yet to be determined ;) )
20:27:32 <sdake_> 4. heat-cfntools is going into the github.com/openstack repo for packaging by distros
20:27:55 <sdake_> was there anything I missed or any concerns with this approach?
20:28:40 <stevebaker> to reduce dependencies, in heat-cfntools boto will be replaced with a bare-bones client
20:28:41 <sdake_> ok, since this is a fairly large change, i'd like to have a vote on it from the devs
20:28:53 <sdake_> oh right, removing boto from dep list of heat-cfntools
20:29:00 <shardy> presume pypi is a stopgap until (4) packaging is completed?
20:29:14 <sdake_> remains to be seen
20:29:15 <zaneb> so, this all sounds good...
20:29:45 <sdake_> #vote approve 1-5 for image building (focus on default images from providers with cloudinit installed)
20:29:48 <zaneb> but is it worth investing in, e.g. removing boto dependency if we plan to switch to aws tools?
20:29:49 <stevebaker> shardy: even then, figuring out what package manager to use and if the distro is new enough will be a drag
20:29:53 <zaneb> that's my only question
20:30:23 <sdake_> #startvote approve 1-5 for image building (focus on default images from providers with cloudinit installed)
20:30:24 <openstack> Unable to parse vote topic and options.
20:30:29 <stevebaker> zaneb: I don't think it is too much work.
20:30:40 <zaneb> ok, then +1
20:30:48 <shardy> zaneb: I asked the same question earlier
20:30:52 <sdake_> well apparently im a dummy and need to rtfm :)
20:30:57 <sdake_> so lets jus thave a manual vote for now
20:30:58 <sdake_> +1
20:31:00 <stevebaker> sdake_: voting instructions?
20:31:01 <asalkeld> well will it be more work to edit aws cfn?
20:31:03 <shardy> +1 provided it's not a huge effort and it happens in H
20:31:05 <stevebaker> #vote yes
20:32:08 <sdake_> shardy we were planning to do this in g
20:32:27 <shardy> sdake_: way too risky IMO - this should be a blueprint for H
20:32:41 <sdake_> problem is once its out in the wild - its out in the wild
20:32:59 <stevebaker> shardy: it would be nice to sort this in G. Most guest distros have dependency dramas right now
20:32:59 <sdake_> we are going to keep heat-jeos around for the time being
20:33:05 <asalkeld> shardy, a big problem is getting the cfntools dynamically installable
20:33:25 <stevebaker> I think dynamic install is for H
20:33:43 <shardy> Ok, but we have a proven capability with the cfntools, hacking in a new client library and changing the deployment method a couple of weeks before release is a bad idea (very bad IMO)
20:33:44 <asalkeld> that is what we are talking about?
20:34:07 <sdake_> well original vote was for g
20:34:17 <sdake_> since there is some heartburn over that, we can push it to h
20:34:28 <shardy> Look at the bug list - we already have loads of problems, why introduce more?
20:34:37 <shardy> (IMHO) ;)
20:35:05 <sdake_> however, please approve https://bugs.launchpad.net/bugs/1105806 since this is what brought about all this discussion
20:35:06 <uvirtbot> Launchpad bug 1105806 in heat "/var/lib/cloud belongs to cloud-init, heat should not write files there" [Medium,In progress]
20:35:09 <sdake_> which needs to be fixed in g
20:35:21 <sdake_> #info dynamic image build for H rather then G
20:35:37 <stevebaker> just +1 it for now, until there is a matching change for heat-cfntools
20:35:54 <sdake_> #topic blueprints review
20:37:01 <sdake_> so, as I said, I'd like to do some bp review during our meetings on the 21st and 28
20:37:11 <sdake_> to pick out the ones that require discussion at summit
20:37:18 <sdake_> vs the ones that are not all that controversial
20:37:30 <sdake_> this will be on demand - ie if we have a ton of bugs to sort out in rc2, we may put this off
20:38:11 <asalkeld> k
20:38:16 <sdake_> ones that are controversial, I'll invite the bp submitter to present a design session at summit on topic
20:38:18 <stevebaker> sdake_: when is the cutoff for filing blueprints?
20:38:34 <sdake_> the actual proces is we do bp review at start of h
20:38:58 <asalkeld> this is more do you want it discussed at summit
20:39:06 <sdake_> asalkeld is correct
20:39:34 <sdake_> expect bp cuttoff will be around h-1
20:39:42 <sdake_> the H schedule hasn't been published yet
20:39:52 <sdake_> #topic open items
20:39:57 <zaneb> I won't be at summit, so I don't care what y'all talk about ;)
20:40:05 <sdake_> thats the spirit ;)
20:40:30 <sdake_> any pressing issues
20:40:40 <sdake_> i know there have been some complaints on the review overhead
20:40:44 <asalkeld> I would assume it's more external bp
20:40:48 <sdake_> this is typical for a project that takes on more governance
20:40:56 <sdake_> learn to like :)
20:41:14 <shardy> Did we want to discuss the gating process - we've had a couple of simple but serious problems slip through recently
20:41:38 <shardy> I'm wondering if there's anything we can do to do some sort of integration style smoke test in addition to the unit tests
20:41:48 <sdake_> i fixed those problems with pyflakes patch in https://review.openstack.org/#/c/23102/
20:42:13 <shardy> sdake_: Ah, ok cool, I've not looked at that yet
20:42:28 <stevebaker> It seems reasonable to just write a new test each time something like this happens
20:42:48 <shardy> sdake_: would that have caught e.g the missing resources import?
20:42:48 <sdake_> well, what happened is an undefined reference
20:42:49 <zaneb> sdake_: that's going to break it again
20:42:52 <asalkeld> the worst is when no test run
20:43:06 <asalkeld> and it says all is great
20:43:12 <sdake_> the tests for the oslo import was ok
20:43:12 <zaneb> shardy: that*reintroduces* the missing resources import!
20:43:36 <sdake_> what happened was the import was not done
20:43:42 <sdake_> pyflakes catches these problems
20:43:43 <asalkeld> yea, don't listen too much to pyflacks
20:43:58 <sdake_> and now its part of the gate
20:44:00 <stevebaker> we're all pyflacks around here
20:44:17 <asalkeld> hah
20:44:18 <sdake_> or will be once that patch is fixed
20:44:24 <sdake_> rather merged ;)
20:44:41 <shardy> zaneb: gah - that's a horrible failure mode, cos everything looks fine, until you realize heat isn't actually doing anything ;)
20:45:05 <asalkeld> zaneb, maybe we need a code comment there
20:45:08 <zaneb> just gave that patch -2, sorry sdake_ ;)
20:45:30 <zaneb> asalkeld: yes, good idea
20:45:56 <asalkeld> # ok, just ignore pyflacks and hit your pagedown button please
20:46:12 <sdake_> what is the problem with pyflakes?
20:46:29 <asalkeld> it does not understand magic
20:46:41 <asalkeld> esp. zaneb magic ;)
20:46:53 <zaneb> maybe we should move that line into heat/engine/__init__.py so folks are less tempted to delete it
20:46:53 <sdake_> indication to stop doing magic tricks ;)
20:47:11 <asalkeld> (driver/plugin loading)
20:47:12 <sdake_> ok well i'll have a look at the review
20:47:40 <sdake_> we can add a special case for one particular import
20:48:12 <zaneb> I'll check properly for others after this
20:48:19 <shardy> zaneb: could we add a type check to resource.py::create() which makes sure the resource it's creating matches the template type via the resource map?
20:48:41 <shardy> At least then we could raise a hard error instead of creating GenericResource
20:48:50 <zaneb> shardy: we could, but the unit tests will not catch it
20:49:01 <zaneb> because they all import stuff from the resources
20:49:09 <asalkeld> ckoverflow.com/questions/5033727/how-do-i-get-pyflakes-to-ignore-a-statement
20:49:20 <zaneb> (actually, we should get rid of GenericResource altogether)
20:49:33 <shardy> zaneb: At least then the engine would blow up in a more spectaular/obvious way ;)
20:49:54 <asalkeld> You can also import with __import__. It's not pythonic, but pyflakes does not warn you anymore.
20:49:59 <shardy> zaneb: +1, I was going to say that until I realized I'm using it in some tests ;)
20:50:08 <zaneb> shardy: yes, +1.  there is no sensible reason for us to have a default resource type
20:50:41 <asalkeld> that was only there when we had so little impl. that I needed a placeholder
20:50:42 <shardy> maybe move it into heat/tests as it is useful for testing the parser logic
20:51:02 <zaneb> yes, it made sense at the time, but not now
20:51:13 <sdake_> ok well running short on time - we can discuss in the review
20:51:28 <sdake_> one thing that patch also does is introduce nova's hacking requirements
20:51:44 <sdake_> over time, i'd suggest we match up with their added pep rules
20:52:00 <sdake_> they put em in for a reason and they have been at it alot longer then heat community has
20:52:12 <shardy> I thought we aligned with all pep rules, and nova ignores some?
20:52:23 <sdake_> we do, but nova introduces more
20:52:27 <sdake_> it has about 15 extra rules
20:52:47 <shardy> Ah, ok, I thought that list was exceptions to the default pep check
20:53:03 <sdake_> nova actually ignores some pep8 rules which i think make sense like the aligning multi-line calls
20:53:19 <sdake_> i find that annoying coupled with the 80 char limit of pep8
20:53:46 <jog0> sdake_:  nova ignores all E12 pep8 errors
20:54:19 <sdake_> jog0 thx
20:54:35 <sdake_> well we can introduce those nova rules over time - they are excluded atm
20:54:40 <sdake_> (but in the patch)
20:54:42 <sdake_> ok anything else?
20:55:12 <asalkeld> nope
20:55:27 <sdake_> thanks folks
20:55:29 <sdake_> #endmeeting