20:00:31 <zaneb> #startmeeting heat
20:00:32 <openstack> Meeting started Wed Aug  7 20:00:31 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:35 <SpamapS> o/
20:00:36 <openstack> The meeting name has been set to 'heat'
20:00:41 <sdake_> o/
20:00:42 <zaneb> that's better
20:01:21 <spzala> Hello zaneb and all,
20:01:21 <zaneb> who else is awake?
20:01:22 <spzala> I am new to heat and looking forward to work with you to learn and contribute actively. I have been contributing to keystone development for sometime now.
20:01:24 <therve> Hi!
20:01:35 <sdake_> welcome aboard spzala
20:01:36 <radix> good afternoon
20:01:37 <zaneb> spzala: welcome :)
20:01:46 <spzala> Thanks!!! :)
20:02:04 <zaneb> so, shardy is away today, I think he's back on Friday
20:02:09 <radix> ok I was just about to ask
20:02:14 <topol> hi
20:02:20 <zaneb> was I supposed to send out the agenda for this?
20:02:26 <sdake_> angus still sawing logs
20:02:27 <zaneb> that didn't happen :D
20:02:35 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:02:44 <sdake_> zaneb agenda 24 hours in advance, meeting notes after meeting
20:02:54 <tspatzier> hi
20:03:01 <timductive> o/
20:03:17 <jasond> hi
20:03:24 <zaneb> ok, I think we have a quorum
20:03:34 * stevebaker was in #openstack-metering :/
20:03:45 <tspatzier> lol
20:03:49 <zaneb> stevebaker: lol
20:03:57 <zaneb> stevebaker: any action over there?
20:03:58 <adrian_otto> hi
20:04:05 <zaneb> #topic Review last week's actions
20:04:15 <stevebaker> confusingly quiet
20:04:17 <randallburt1> sorry I'm late
20:04:18 <andrew_plunk1> hey
20:04:35 <TravT> o/
20:04:41 * zaneb shardy to send mission ML statement
20:04:52 <zaneb> how did that work out? I didn't see it
20:05:13 <stevebaker> I'm not sure it has been sent yet, but there was more etherpad action
20:05:31 <zaneb> #link https://etherpad.openstack.org/heat-mission
20:05:51 <zaneb> so, thanks asalkeld and kebray for input
20:06:10 <stevebaker> I think it should just be posted at this point
20:06:13 <zaneb> I added some more justification for what I think would be good to include
20:06:20 <zaneb> so if anyone still cares, have a look
20:06:33 <zaneb> I expect shardy will post something when he gets back
20:06:46 <zaneb> that was the only action, so moving on...
20:06:57 <zaneb> #topic Choose date for Havana_Release_Schedule FeatureProposalFreeze
20:07:02 <stevebaker> so..
20:07:10 <adrian_otto> the term "enforce policy" appears first in the mission. Is that really what the mission should be emphasizing as its first stated goal?
20:07:21 <stevebaker> #link https://wiki.openstack.org/wiki/FeatureProposalFreeze
20:07:46 <stevebaker> As a project we can choose to set a FeatureProposalFreeze date
20:08:06 <stevebaker> https://wiki.openstack.org/wiki/Havana_Release_Schedule <-- other project's dates are appearing here
20:08:19 <zaneb> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
20:08:20 <topol> after reading the extra input on the mission are we changing it or going with the original?
20:08:58 <zaneb> topol: if you have feedback add it to the etherpad, it will be up to shardy to sort it out I think
20:09:19 <topol> zaneb I was good with his original
20:09:34 <randallburt1> stevebaker:  so that means no more bps or reviews for new stuff. if its not in the pipe by then, its got to be a bug, yes?
20:09:43 <stevebaker> If we choose a date, any blueprint that doesn't have an active review by that date is deemed to have missed the feature freeze
20:09:43 <therve> stevebaker, The freeze is Sep 4th right?
20:09:52 <zaneb> so nova have their feature freeze on August 22nd
20:09:54 <topol> Since heat is at the top of openstack food chain perhaps it can have a late featurefreezedate than somehting like keystone or nova
20:10:26 <randallburt1> well, we still have lots to review and test, so we may need more time than the other projects too
20:10:28 <zaneb> I don't think where we are in the food chain makes much difference
20:10:29 <stevebaker> I'm not aware of other project features that we're blocked on though
20:10:37 <therve> randallburt1, reviews don't count
20:10:40 <zaneb> I think we are slightly faster to review than some other projects
20:10:48 <zaneb> that's what would make a difference
20:10:50 <m4dcoder> if i'm readying the policy correctly, as long as we get our 1st patchset in, subsequent patchsets for the feature is still allowed after the freeze date?
20:10:51 <therve> The FPF is for new blueprints
20:10:59 <radix> so the freeze is only for when the change gets submitted to gerrit, not for when the change gets merged?
20:11:01 <stevebaker> The point is to avoid a review stampede the day before the feature freeze, smooth out the reviewing process
20:11:01 <zaneb> m4dcoder: correct
20:11:07 <radix> ok
20:11:07 <zaneb> stevebaker: +1
20:11:08 <radix> got it
20:11:13 <randallburt1> therve:  ah, ok
20:11:19 <therve> Well not after the freeze data
20:11:30 <therve> After the feature proposal freeze date :)
20:11:32 <zaneb> so the freeze for stuff getting merged is the Havana-3 deadline
20:11:39 <zaneb> on the 6th of September
20:11:40 <topol> zaneb, well with keystone if we dont freeze the the APi early there is no way for the other core projects to adopt.  Im assuming heat doesnt need the core projects to adopt their apis so much
20:12:00 <therve> topol, Yeah it's more a workflow problem
20:12:03 <zaneb> topol: that's what the release milestone is for
20:12:05 <stevebaker> zaneb: yep, although some features I think can have explicit extensions
20:12:08 <sdake> zaneb the actual freeze is the 4th
20:12:09 <zaneb> this is about managing the review queue
20:12:21 <zaneb> sdake: quite right, thanks
20:12:38 <stevebaker> So I propose that we have a FeatureProposalFreeze on August 23, because Friday deadlines are *awesome* ;)
20:12:48 <randallburt1> :P
20:12:51 <therve> +1 :)
20:12:59 <sdake> should make it a monday so the poor sobs can work through the weekend ;)
20:13:12 <randallburt1> so cruel.
20:13:15 <radix> sdake: hehe, I was going to say the same ;)
20:13:42 <zaneb> so, if anybody is planning a whole massive patch queue on August 23rd, you're doing it wrong anyway
20:14:02 <stevebaker> but if you are, at least there is a chance of it being reviewed
20:14:16 <zaneb> yeah
20:14:25 <zaneb> and after that, it's increasingly dicey
20:14:58 <stevebaker> so 23rd?
20:15:13 <zaneb> sounds reasonable
20:15:30 <stevebaker> doneburgers. I'll tell ttx
20:15:40 <zaneb> not saying I would -2 everything after that
20:16:01 <zaneb> but it would be even better if folks posted whatever they have *before* that
20:16:14 <randallburt1> so picky… ;)
20:16:15 <stevebaker> yep, its just setting expectations
20:17:02 <zaneb> if you have incremental steps that are ready, post 'em
20:17:16 <zaneb> (it's not always that easy, I realise)
20:17:21 <zaneb> ok, moving on?
20:17:27 <stevebaker> yes
20:17:30 <zaneb> #topic h3 blueprint prioritization
20:17:37 <zaneb> heh
20:17:40 <stevebaker> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
20:17:44 <stevebaker> whoops
20:17:50 <stevebaker> #link https://launchpad.net/heat/+milestone/havana-3
20:17:54 <zaneb> stevebaker: what did ttx have to say yesterday?
20:18:17 <stevebaker> we need to be more realistic about our bp list for this cycle
20:18:28 <stevebaker> ...obviously
20:18:50 <zaneb> so I see that some people have updated their blueprints
20:18:57 <zaneb> which is great! thank you all
20:19:00 <stevebaker> Anything that is Not started, Started or Slow progress might need some scrutiny
20:19:21 <zaneb> if anybody has out-of-date status on their blueprints, please double-check them
20:19:36 <stevebaker> jasond: where is multiple-engines at?
20:19:42 * SpamapS is a bit sad that rolling-updates is slipping. :-P
20:20:02 <jasond> stevebaker: still testing.
20:20:21 <jasond> can someone mark it approved?
20:20:27 <stevebaker> jasond: could you update the Delivery field to reflect where it is at?
20:20:34 <jasond> oh, nevermind
20:20:36 <jasond> sure, will do
20:20:58 <radix> my instance-group-nested-stack bp is up for review, has a couple positive reviews: https://review.openstack.org/#/c/38571/
20:21:32 <stevebaker> randallburt: open-api-dsl is a bit of an umbrella bp - it is too broad to be useful really
20:21:46 <randallburt> stevebaker:  agreed.
20:22:16 <randallburt> per last couple of meetings, will be fine changing it and coloring it done once the param work is sorted
20:22:29 <stevebaker> I don't really know where HOT is at and what is left to be done, so that would be helpful
20:22:31 <randallburt> or we can get rid of /archive as superceded
20:23:24 <SpamapS> is there a single unifying HOT v1 blueprint dependent on the other bits so we can see all the things in flight to make it a reality?
20:24:07 <stevebaker> we could use open-api-dsl for that, but set it to milestone next
20:24:14 <zaneb> +1
20:24:23 <adrian_otto> +1
20:24:29 <adrian_otto> that was the intent of that blueprint anyway
20:24:32 <randallburt> SpamapS:  sorta. the dependencies of  #link https://blueprints.launchpad.net/heat/+spec/open-api-dsl are there but not complete
20:25:01 <randallburt> need to add the param constraints work from tspatzier et al
20:25:20 <SpamapS> randallburt: that looks like what we need tho. Lets not add anymore. ;)
20:25:22 <stevebaker> ok, I've set the milestone to heat next
20:25:25 <zaneb> vijendar: are you about?
20:25:44 <randallburt> he's on his way
20:25:53 <zaneb> 'k
20:26:03 <stevebaker> agordeev: are you about?
20:26:09 <vijendar> zaneb: hi
20:26:23 <zaneb> vijendar: what's the progress on https://blueprints.launchpad.net/heat/+spec/parallel-delete ?
20:26:46 <zaneb> is "Started" still a fair assessment?
20:27:21 <vijendar> zaneb: it's in code review
20:27:40 <spzala> stevebaker: fyi on HOT, I am wrapping up some keystone work but I am going to learn and work on HOT.
20:27:48 <zaneb> vijendar: excellent, thanks for updating it :)
20:27:52 <radix> spzala: nice :)
20:27:55 <stevebaker> spzala: cool, ok
20:27:57 <vijendar> zaneb: currently I am fixing couple of tests that are failing
20:28:08 <zaneb> ok, cool
20:28:11 <spzala> radix: stevebaker: thanks!
20:28:18 <stevebaker> sdake, how be native-nova-instance?
20:28:33 <sdake> was blocked by various problems with devstack
20:28:34 <zaneb> stevebaker: agordeev has posted some patches, at least, toward to olso db stuff
20:28:39 <sdake> now unblocked once the neutron review is approved
20:28:52 * stevebaker really wants that feature
20:29:28 <stevebaker> no pressure ;)
20:29:30 <sdake> looks like the neutron review was approved
20:29:38 <sdake> so we should be good to proceed now
20:29:44 <fvollero> Howdy
20:29:44 <zaneb> ok, so it looks like we are not in terrible shape
20:30:05 <zaneb> the open bps are fairly evenly spread across people
20:30:34 <stevebaker> yep
20:30:51 <zaneb> so, if everybody can keep their bps up to date, that will be a big help to whichever poor sap has to go to the release status meetings ;)
20:31:12 <zaneb> and if you think something is not going to land in time, please flag it
20:31:25 <zaneb> either in irc or during a meeting
20:31:27 <therve> Let's try to have a quick review cycle, too
20:31:31 <therve> Talk to people :)
20:31:32 <radix> by the way, is feature freeze going to involve a new branch so feature work can continue?
20:31:37 <zaneb> therve: +1
20:31:43 <radix> or are we going to be locked out for a month and a half?
20:31:57 <SpamapS> radix: you're not supposed to continue feature work.
20:31:58 <zaneb> radix: typically the latter, as far as I understand
20:32:05 <SpamapS> radix: fix bugs, document, test, etc.
20:32:06 <zaneb> that was pretty much the case last time
20:32:12 <radix> zaneb: ok
20:32:17 <zaneb> radix: the good news for you is that there will be heaps of bugs :)
20:32:23 <radix> yes, of course
20:32:26 <stevebaker> I'd like to think we could do that code re-org during feature freeze
20:32:34 <therve> Also documentation
20:32:43 <stevebaker> and everyone can write tempest tests
20:32:54 <zaneb> stevebaker: only if you keep it very quiet ;)
20:33:29 <zaneb> ok, let's move on
20:33:34 <zaneb> #topic Discussion about "Heat config" and the bug related to.
20:33:40 <zaneb> fvollero: go
20:33:45 <EmilienM> o/
20:33:51 <zaneb> #link https://bugs.launchpad.net/heat/+bug/1209141
20:33:52 <uvirtbot> Launchpad bug 1209141 in heat "Heat config: all options related to binding should be splited from DEFAULT" [Undecided,New]
20:33:53 <fvollero> \o/
20:34:11 <EmilienM> I found this bug this morning, I think we should create groups in options
20:34:15 <EmilienM> like we have in Nova
20:34:16 <fvollero> zaneb: Yeah, I guess we should thank EmilienM that reported this bug i just figured out later
20:34:48 <zaneb> kudos, EmilienM ;)
20:34:56 <EmilienM> since we have 3 API which could running on a single node, the bindings options should be splited
20:34:56 <fvollero> As we discussed earlier shouldnt be difficult to have them grouped a la nova
20:34:57 <stevebaker> can it fall back to [DEFAULT] if the other block has no setting?
20:35:16 <EmilienM> we should
20:35:17 <fvollero> stevebaker: yeah
20:35:32 <SpamapS> Sp we dpm
20:35:33 <SpamapS> dohh
20:35:38 <stevebaker> wow
20:35:47 <SpamapS> so we don't all collide .. Triaged/High seems appropriate.
20:35:51 <EmilienM> with the new fashion of config, I'm scared about all OpenStack projects which have several config files
20:36:18 <EmilienM> specific to Heat, where we have some flags duplicated
20:36:25 <EmilienM> i.e. bind_host
20:36:28 <EmilienM> i.e. bind_port
20:36:58 <fvollero> EmilienM: in one host configuration, the only concern are the bind_port since the host still the same
20:37:01 <stevebaker> so should the rules be:
20:38:38 <stevebaker> 1. if heat.conf exists use it, otherwise fall back to heat-*.conf
20:38:39 <stevebaker> 2. if [API|CFN|CLOUDWATCH] blocks exist, use them otherwise fallback to [DEFAULT]
20:38:39 <stevebaker> that way, old configs will continue to work, new configs will work, and mixtures of old and new won't cause random pain
20:38:45 <SpamapS> Given the collision possible, I think bind_port and bind_host should be removed from default.
20:38:51 <SpamapS> Each service can have its own default in its own section.
20:39:01 <fvollero> stevebaker: Sounds great this way.
20:39:01 <EmilienM> stevebaker: +1
20:39:09 <fvollero> yes, +1
20:39:47 <EmilienM> cool, thank's for consideration guys
20:39:56 <fvollero> SpamapS: Yeah, maybe as subset of the specific services
20:40:05 <SpamapS> The using old config files is tricky..how long do we keep supporting the old ones? Do we issue a deprecation warning?
20:40:20 <fvollero> EmilienM: I guess you found a case the developers initially didn't considered :)
20:40:31 <fvollero> SpamapS: That seems the way to go.
20:40:33 <SpamapS> Technically we already broke configs completely this release.. so I'm more inclined to say "just get rid of the old ones now" than have to do that dance.
20:40:42 <EmilienM> the fact is the new fashion in Oslo has not been adopted in all projects
20:40:47 <SpamapS> Perhaps provide a tool to automatically convert if you've been testing H
20:40:47 <EmilienM> only Ceilometer & Heat AFIK
20:40:55 <stevebaker> yep, we've already caused packaging pain with the paste.ini changes
20:41:14 <stevebaker> may as well get it all done
20:41:18 <SpamapS> make the painful change now and people will have time to adapt before h3
20:41:23 <fvollero> SpamapS: To join them in 1 single file you mean ?
20:41:30 <SpamapS> make it later, and we just have to keep these old files around forever.
20:41:40 <SpamapS> fvollero: yes, if we want one config file, lets just do it.
20:41:46 <fvollero> SpamapS: yeah, that's actually very possible.
20:41:53 <SpamapS> we already broke things horribly between grizzly and H
20:42:09 <SpamapS> so breaking h2 and h3.. I personally don't care.
20:42:16 <EmilienM> so maybe you are agree I should abandon https://review.openstack.org/#/c/40257/
20:42:28 <SpamapS> As long as it is advertised and well known.
20:43:07 <SpamapS> EmilienM: no, I think you should enhance it to also make sure those old config files are not read by oslo.config.
20:43:10 <fvollero> SpamapS: yes indeed. So I guess now, the main goal is to solve the bug and make 1 file to be compliant as before
20:43:21 <andrew_plunk1> it would be cool to have a config migration tool
20:43:31 <SpamapS> andrew_plunk1: should be really easy to write too
20:43:35 <SpamapS> and the packagers would love us
20:43:44 <stevebaker> and production defaults!
20:43:53 <andrew_plunk1> +1 stevebaker
20:43:59 <EmilienM> SpamapS: ack
20:44:00 <fvollero> +1 stevebaker
20:44:13 <fvollero> SpamapS: +1
20:44:22 <SpamapS> everybody else feel comfortable with this radical approach?
20:44:34 <andrew_plunk1> It sounds good to me
20:44:43 <stevebaker> yes
20:44:44 <SpamapS> I don't want to guide EmilienM into conflict... ;)
20:44:47 <fvollero> SpamapS: Well, if we state it clearly in all the documentation, why not
20:45:12 <stevebaker> is there a bp for this? that is a good way of highlighting the change in the release notes
20:45:16 <EmilienM> lol I'll say your name :P
20:45:19 <fvollero> SpamapS: Even if we should need to have steve hardy for some more discussion
20:45:21 <SpamapS> what documentation mentions any config files at this point? Thats probably a question worth answering before this gets done.
20:45:35 <SpamapS> EmilienM: sounds like a threat. ;)
20:46:55 <fvollero> SpamapS: I mean, the EmilienM changes could be also: Put the stuff in heat.conf and not here. Check http://blablabla
20:47:54 <zaneb> ok, I think we've covered this one
20:48:04 <zaneb> #topic Open Discussion
20:48:11 <stevebaker> i gotta go
20:48:16 <fvollero> me too...
20:48:18 <zaneb> stevebaker: o/
20:48:24 <zaneb> anybody got anything else
20:48:25 * SpamapS does as well..
20:48:26 <zaneb> ?
20:48:28 <spzala> I have a review request for #link https://review.openstack.org/#/c/38921/
20:48:29 <spzala> (nanji, owner of the patch, could not make it to the meeting so requesting on his behalf)
20:48:37 <fvollero> Thanks guys for your quick approach on the spotted bug :)
20:48:41 <fvollero> Have a wonderful evening!
20:48:52 <zaneb> it's not actually compulsory for this meeting to run for an hour, so I'm happy to end it soon ;)
20:49:03 <spzala> zaneb: :)
20:49:34 <zaneb> spzala: that patch is on my list, hopefully I will get a chance to take a look tomorrow
20:49:35 <radix> I don't have anything else (other than whining for more reviews)
20:49:54 <spzala> zaneb: that would be great. Thanks!
20:50:01 <zaneb> anybody want to bikeshed the mission statement some more?
20:50:06 * zaneb ducks
20:50:17 <zaneb> (don't even think about it, btw)
20:50:25 <adrian_otto> I want to contribute to the mission statement, but need time to work on it.
20:50:51 <zaneb> adrian_otto: cool, that's a better way to have the discussion I think
20:50:51 <adrian_otto> is putting my input into the etherpad the best way, or is that something we should do in #heat?
20:50:56 <zaneb> add it to the etherpad
20:51:16 <zaneb> maybe ping folks in #heat to let evryone know there are changes
20:51:20 <randallburt> spzala I'm trying to make time to look at that as well
20:51:44 <spzala> randallburt: awesome, thanks :)
20:51:51 <randallburt> np
20:52:16 <adrian_otto> ok, will do. I will be out on vacation, so will miss your next IRC meeting, but will send a proxy to speak to it.
20:52:17 <zaneb> spzala: I tuned out somewhere between patch sets 7 and 15, but it looks a bit more stable now ;)
20:52:36 <zaneb> adrian_otto: cool, cheers
20:52:49 <adrian_otto> when do you want to conclude all Mission related work?
20:52:50 <spzala> zaneb: yes, I think and hope so too :)
20:53:21 <zaneb> adrian_otto: I expect shardy will want to look at it when he gets back
20:53:35 <zaneb> or rather, he won't want to, but he'll probably feel he has to ;)
20:54:05 <zaneb> adrian_otto: but I will let him know you're planning on adding some feedback
20:54:12 <adrian_otto> tx
20:54:43 <zaneb> ok, if there is nothing else I'm going to wrap this show up with 5mins to spare :)
20:55:18 <zaneb> thanks everyone!
20:55:21 <zaneb> #endmeeting