20:00:19 <sdake> #startmeeting heat
20:00:20 <openstack> Meeting started Wed Jan 23 20:00:19 2013 UTC.  The chair is sdake. 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:37 <sdake> #topic rollcall
20:00:41 <zaneb> o/
20:00:42 <sdake> sdake here
20:00:45 <cody-somerville> Hi
20:00:47 <sdake> howdy zaneb
20:00:48 <SpamapS> o/
20:00:48 <stevebaker> \O
20:00:56 <shardy> shardy here
20:00:58 <sdake> stevebaker has a big head ;)
20:01:01 <zaneb> DSL works this week :)
20:01:07 <sdake> nice zaneb
20:01:18 <shadower> hey
20:01:22 <asalkeld> hi
20:01:24 <jpeeler> jpeeler here
20:01:36 <stevebaker> full house
20:01:41 <echohead> hi
20:01:59 <sdake> #info sdake, cody-somrville, spamaps, stevebaker, shardy, zaneb, shadower, asalkeld, jpeeler, echohead present
20:02:04 <sdake> #topic action review
20:02:16 <sdake> #info http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-01-16-20.00.html
20:03:29 <sdake> not sure what i was supposed to do with moving vpc resources to defn->approved - I think stevebaker was going to file separate blueprints for each vpc type
20:03:48 <stevebaker> I've just done the blueprints
20:03:59 <sdake> ok, i'll move that to next week then :)
20:04:12 <sdake> #action sdake to follow up on stevebaker's vpc blueprints
20:04:21 <stevebaker> #link https://blueprints.launchpad.net/heat/+spec/vpc-resources
20:04:23 <sdake> stevebaker to take on ubuntu ppa
20:04:26 <stevebaker> They should all be hanging off that now
20:04:26 <sdake> any progress there?
20:04:40 <stevebaker> nothing this week, thats a long term project l)
20:04:42 <stevebaker> 0
20:05:00 <sdake> ok, will move off the weekly beating on that one ;)
20:05:13 <stevebaker> beat away
20:05:15 <sdake> #action ubuntu PPA long term action
20:05:20 <sdake> #topic blueprint review for g3
20:05:28 <sdake> https://launchpad.net/heat/+milestone/grizzly-3
20:05:51 <sdake> ttx had asked us to sort out "Delivery" field
20:06:03 <sdake> if unknown, should go to started or not started
20:06:42 <sdake> can the assignees of the blueprint do that, since they are best suited to know the correct answer?
20:07:23 <asalkeld> when i go to the bp there is no delivery
20:07:30 <zaneb> how do you even do that?
20:07:38 <zaneb> yeah, what asalkeld said
20:07:44 <sdake> "Implementation"
20:07:45 <SpamapS> I think you mean Implementation
20:07:46 <stevebaker> Does the Definition need to be set to something other than New before that happens?
20:08:15 <zaneb> ah yeah, Implementation did it
20:08:35 <zaneb> that seems like a bug in Launchpad
20:08:36 <sdake> click through to the blueprint, then click "Implementation"
20:08:57 <Slower> sorry here
20:09:29 <sdake> ok, so asalkeld, shardy, stevebaker, jpeeler all have BPs, can you set the "Implementation" field then?
20:09:36 * stevebaker does it now
20:09:41 <sdake> thanks
20:09:44 <asalkeld> yip
20:09:47 <shardy> sdake: done
20:09:56 <sdake> #action asalkeld, shardy, stevebaker, jpeeler to set implementation field in BPs
20:10:01 <jpeeler> is the implementation only changeable by the person who registered?
20:10:07 <sdake> yes
20:10:15 <SpamapS> or assignee should also be able to do it
20:10:16 <sdake> or maybe only the asignee
20:10:38 <jpeeler> i'm assigned, but have no way i see to change it. can sort it later
20:11:05 <sdake> we should go through these vpc priorities
20:11:11 <sdake> i'd personally say they all should be hi
20:11:13 <SpamapS> Its entirely possible that New has to be changed to a "defined" state for assignee to be allowed to mess with Implementation
20:11:14 <sdake> gh
20:11:23 <SpamapS> the whole thing is rather opaque and designed to fit the ubuntu dev workflow
20:11:35 <sdake> jpeeler use the force (ie: play with it ;)
20:12:13 <stevebaker> They should all be the same priority, whatever it is
20:12:26 <sdake> anyone have objections for high?
20:12:29 <SpamapS> usually there's an approver (track lead) that sets Definition to Approved, and then the assignee is responsible from there
20:12:32 <stevebaker> nope
20:12:59 <sdake> thanks spamaps, new to launchpad here ;)
20:13:00 <SpamapS> so, if you want asignees to have full control, make them approvers too
20:13:10 <sdake> they are approvers I believe
20:13:30 <sdake> we can chat after meeting if you have a moment
20:13:49 <sdake> #action sdake to set all VPC blueprints to high
20:14:19 <SpamapS> https://blueprints.launchpad.net/heat/+spec/prebuilding-images <-- jpeeler is not approver, and definition is still Drafting
20:14:19 <sdake> #topic preservation of resources
20:14:36 <sdake> #link https://blueprints.launchpad.net/heat/+spec/preserve-resources
20:14:53 <SpamapS> oh thats me :)
20:15:25 <sdake> my initial thought is we have alot on our plate already for H - only 4 weeks left in the dev cycle
20:15:27 <SpamapS> So, I think this will take a good discussion at the summit to fully flesh out, but I need to put together some PoC implementations before then so I thought I'd bring it up now
20:15:30 <sdake> 15 blueprints, about 25 bugs to fix
20:15:59 <sdake> ya, open to discussions at summit
20:16:07 <stevebaker> This looks like another umbrella blueprint, which could do with a sub blueprint that specifies what each resource should do
20:16:08 <asalkeld> SpamapS, that behaviour is what we want
20:16:10 <sdake> poc sounds good so people have a chance to see whats there
20:16:13 <SpamapS> I wanted to spitball a few ideas here and get people thinking about it now.
20:16:20 <asalkeld> no need for poc
20:16:27 <asalkeld> just implement
20:16:47 <zaneb> is this proposal somehow different from what AWS has already?
20:16:57 <SpamapS> as I say in the description, I'm not sure whether a new field, UpdatePolicy, or a whole new resource type would be best.
20:17:03 <SpamapS> zaneb: yes
20:17:08 <zaneb> in what way?
20:17:36 <shardy> SpamapS: I believe that behavior will be provided by the UpdateStack blueprint I have for instance resources
20:17:37 <SpamapS> zaneb: as far as I can tell, AWS will not let you update an instance's userdata without at least rebooting (EBS) or at worst terminate/create(instance store)
20:17:54 <asalkeld> aaaa
20:18:06 <SpamapS> Its also not well defined what happens if you just update Metadata
20:18:07 <asalkeld> yes userdata is readonly
20:18:07 <shardy> SpamapS: we can just re-parse the template via UpdateStack and then update the instance metadata
20:18:17 <shardy> that will then get picked up via cfn-hup
20:18:25 <shardy> which AFAICT is exactly what AWS does
20:18:27 <asalkeld> but can't you put your data into metadata
20:18:39 <asalkeld> ya
20:18:49 <asalkeld> userdata is bootup only
20:18:51 <shardy> No, cfn hup reads the metadata via the CFN API now (or at least it can
20:19:01 <SpamapS> So perhaps I just didn't read the AWS docs well.. I couldn't find anywhere that Metadata's update behavior was defined.
20:19:09 <shardy> if you provide credentials it will poll the CFN API for metadata updates
20:19:09 <zaneb> Update requires:
20:19:09 <zaneb> Update requires: some interruptions (EBS-backed AMIs)
20:19:09 <zaneb> Update requires: replacement (instance-store backed AMIs)
20:19:25 <zaneb> AWS docs ^
20:19:32 <SpamapS> zaneb: for userdata, or metadata?
20:19:36 <zaneb> UserData
20:19:50 <SpamapS> Yeah so I need it to not reboot or replace.
20:20:04 <SpamapS> And I do think Metadata should be changable without replacement. Right?
20:20:04 <asalkeld> the trick is to put as much as possible in the metadata
20:20:15 <asalkeld> should be
20:20:25 <asalkeld> yes
20:20:29 <shardy> but what we call metadata internally (for AWS::Cloudformation::Init) is not the same as EC2 metadata
20:20:50 <shardy> we send that metadata via user data, and it can be updated via the CFN API route described above
20:21:11 <shardy> ie we can update the stuff done by cfn-init, but not cloud-init
20:21:12 <asalkeld> you need to poll it using cfn-hup
20:21:15 <SpamapS> shardy: yes I nyes, thats yes, the heat metadata is what I call it
20:21:26 <SpamapS> sorry, lag issues here causing keyboard fail
20:21:58 <sdake> ok, sounds like some debate about what can/can't be done - perhaps can sort out if this is already possible in #heat over the coming week and bring up for discussion next week?
20:22:10 <shardy> asalkeld: yep, but we already have that, so we just need to implement the capability to update the metadata parsed as part of the AWS::Cloudformation::Init section of the intance definition in the template
20:22:10 <SpamapS> Yes that sounds great
20:22:28 <SpamapS> shardy: not just AWS::Cloudformation::Init though
20:22:34 <SpamapS> shardy: the whole Metadata block
20:22:42 <shardy> sdake: FWIW, I was planning to implement (or at least try to implement) this next week
20:22:44 <sdake> #action heat devs to sort out if updatestack can update rather then delete in coming week
20:22:59 <sdake> cool sounds good :)
20:23:01 <SpamapS> Cool, I have cycles to help with this btw
20:23:08 <shardy> SpamapS: Ok, lets pick this up and work together to figure it out :)
20:23:13 <SpamapS> indeed
20:23:18 <sdake> #topic open discussion
20:23:30 <sdake> ok good work on the bugs - making good progress
20:23:41 <sdake> remember our deadline is t-4 weeks
20:23:52 <sdake> need to fix the bugs and fix the blueprints by then
20:24:07 <sdake> if you have something assigned to you that isn't going to make it, earlier notification better then later
20:24:12 <SpamapS> I poked at a few. Not many unassigned.. will continue to sift through them though.
20:24:16 <asalkeld> SpamapS, shardy another option is to support configdrive
20:24:26 <SpamapS> asalkeld: not an option for my use case.
20:24:32 <asalkeld> ok
20:24:46 <SpamapS> nova baremetal may one day support configdrive..
20:24:52 <shardy> asalkeld: Not looked into that myself, was thinking, lets just use cfn-hup since we already have it working
20:24:59 <SpamapS> but that would require some iscsi hackery that we haven't done yet
20:25:17 <SpamapS> +1 cfn-hup is the way to go IMO
20:25:23 <asalkeld> sure
20:26:11 <sdake> if you have alot of bugs assigned to you (I think this applies mostly to shardy) might think about releasing some of the easier ones for new community members to take on
20:26:42 <shardy> sdake: most of mine are pretty easy I think, should be OK but will check
20:26:49 <sdake> ok - well up to you ;)
20:26:59 <sdake> just dont need to work a million hours a week - community effort here
20:27:00 <zaneb> SpamapS, shardy: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks.html implies that a standard UpdateStack is always able to update metadata
20:27:57 <shardy> sdake: k, will release any I'm not confident I'll finish
20:27:59 <sdake> ok any other open discussion?
20:28:24 <asalkeld> nope
20:28:33 <SpamapS> zaneb: lets discuss further in #heat :)
20:28:36 <sdake> ok thanks guys short meeting today ftw ;)
20:28:38 <sdake> #endmeeting