20:00:55 <zaneb> #startmeeting heat
20:00:55 <openstack> Meeting started Wed Aug 27 20:00:55 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:59 <openstack> The meeting name has been set to 'heat'
20:01:22 <zaneb> #topic roll call
20:01:26 <jpeeler> o/
20:01:26 <pas-ha> o/
20:01:27 <shardy> o/
20:01:27 <ryansb> o/
20:01:35 <stevebaker> \o
20:02:18 <mspreitz> hi
20:02:31 <skraynev> hey
20:02:32 <andrearosa_home> hi
20:03:04 <zaneb> #topic Review action items from last meeting
20:03:14 <zaneb> zaneb to email out details of when/where to meet up
20:03:18 <zaneb> I did that :)
20:03:24 <zaneb> skraynev document mob wisdom on bug 1356084 in launchpad
20:03:25 <uvirtbot`> Launchpad bug 1356084 in heat "Cannot delete the stack after replacing image during stack-update" [Medium,Triaged] https://launchpad.net/bugs/1356084
20:03:39 <skraynev> zaneb: done
20:03:42 <zaneb> yep, that's in there
20:03:50 <zaneb> stevebaker raise a launchpad bug for rstrip(None) issue from ask.openstack
20:04:25 <skraynev> I tried to sort all ideas ;) hope result is nice
20:04:28 <zaneb> I'm not finding that
20:04:53 <zaneb> stevebaker: shall I re-action that for you?
20:04:56 <stevebaker> totally didn't do that, but it looks like this happens on havana->icehouse upgrade because the resulting paste.ini is still the havana one
20:05:10 <zaneb> aha
20:05:26 <stevebaker> which sounds like a packaging bug, because paste.ini should be considered code, not configuration
20:05:47 <zaneb> well, let's file a bug to help people find it anyway
20:06:04 <stevebaker> yep, #action me!
20:06:12 <zaneb> #action stevebaker raise bugs for rstrip(None) issue from ask.openstack
20:06:21 <ryansb> might it be creating a "paste.ini.rpmnew" since the paste.ini was edited?
20:06:26 <ryansb> stevebaker: ^
20:06:30 <zaneb> I removed the launchpad part, since we may want downstream bugs too
20:06:49 <stevebaker> ryansb, could be.
20:07:14 <zaneb> yeah, that's a distinct possibility
20:07:25 <zaneb> #topic Adding items to the agenda
20:07:32 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-08-27_2000_UTC.29
20:07:59 <zaneb> anything else?
20:08:07 <mspreitz> Is therve here, interested in discussing alternate design for scaling across AZs?
20:08:10 <stevebaker> zaneb, functional test dir structure
20:08:32 <zaneb> mspreitz: he usually doesn't make it to this one
20:08:33 <zaneb> stevebaker: ok
20:08:54 <zaneb> bring popcorn for that
20:09:21 <zaneb> #topic Juno blueprint status
20:09:31 <zaneb> #link https://launchpad.net/heat/+milestone/juno-3
20:10:24 <zaneb> can everybody please make sure that status of their bps is up to date
20:10:45 <zaneb> if you don't think something is going to land by next week, let me know
20:10:54 <mspreitz> Can I lobby for https://blueprints.launchpad.net/heat/+spec/implement-autoscalinggroup-availabilityzones?  It was approved a long time ago, and there is a spec and code in progress
20:11:20 <zaneb> #info juno-3 + Feature Freeze is next week
20:11:24 <stevebaker> zaneb, I've just added the 3 bps I'm working on to j-3
20:11:37 <shardy> zaneb: did we decide contrib resources aren't part of feature freeze, as they're disabled by default?
20:12:18 <zaneb> yep, and the next item was to say that if you have blueprints that *are* going to land or have landed that are not on that list, please target them to juno-3 or ask me to do it
20:12:30 <pas-ha> zaneb, just bumped mine mutually exclusive props (low priority) to next, most probably won't make it
20:12:39 <pas-ha> ok, have one :)
20:12:43 <zaneb> shardy: if we didn't, let's decide that now :)
20:13:07 <shardy> zaneb: Ok, cool, the Ironic resources may slip due to unexpectedly hostile reactions from the Ironic PTL ;(
20:13:11 <stevebaker> zaneb, could you set the Priority on my 3?
20:13:59 <zaneb> stevebaker: will do, but nothing stopping you from doing it yourself afaik
20:14:05 <zaneb> shardy: really? why?
20:14:07 <mspreitz> zaneb, can you please target https://blueprints.launchpad.net/heat/+spec/implement-autoscalinggroup-availabilityzones for Juno-3?  huangtianhua seems to have stopped working on this topic, but I am
20:14:15 <stevebaker> critical all!
20:15:02 <shardy> zaneb: You can see in the comments to https://review.openstack.org/#/c/104222/
20:15:40 <shardy> I had a follow-up conversation on IRC and he's -1 on them still, so I'm working on a spec with use-cases and justification
20:15:45 <zaneb> mspreitz: done
20:15:53 <mspreitz> thanks
20:16:07 <shardy> ultimately, we don't need his approval, but I thought it wise to at least seek consensus before pressing ahead with them
20:16:56 <zaneb> shardy: interesting, yes
20:18:11 <mspreitz> I'll admin I have not been following the heat/ironic debate.  What is the reason for heat to deal directly with ironic instead of through nova?
20:18:18 <mspreitz> s/admin/admit
20:18:35 <pas-ha> mspreitz, mostly that Ironic is admin only
20:18:42 <pas-ha> no user API
20:19:06 <pas-ha> and that it physical, not virtual resources
20:19:06 <mspreitz> OK, I have not been following Ironic closely.  I thought the lack of user API is because users do not need an API
20:19:25 <shardy> mspreitz: basically for integration with management intergfaces, like drac/ilo for setting up the hardware (bios, firmware, raid)
20:19:42 <shardy> the idea is to prepare the hardware to a known state before nova boots it
20:19:48 <zaneb> shardy: so we want them for TripleO?
20:20:16 <shardy> zaneb: that is the target use-case, yes, although they are focussed on in-band management right now
20:20:55 <shardy> https://etherpad.openstack.org/p/heat-ironic-spec-draft
20:21:07 <shardy> If anyone wants to help with the spec, there's a first draft
20:21:15 <zaneb> and and end-user can request a bare-metal server from Ironic, but they would do so using the Nova API if I'm reading correctly?
20:22:07 <shardy> zaneb: Yes, but there's a bunch of stuff you can't control via nova, pre-deployment configuration which is possible via various interfaces to the out-of-band management interfaces on some hardware
20:22:48 <shardy> e.g stuff you can do via the ironic api which you can't do via nova
20:23:07 <shardy> it's admin-only stuff which would happen via the tripleo undercloud
20:24:56 <zaneb> ok, our bp list got a lot longer and all the new ones are "needs code review" not "completed" :(
20:25:06 <zaneb> review harder :D
20:25:14 <zaneb> the gate will be a zoo next week
20:25:37 <zaneb> #topic juno-3 milestone release management
20:26:04 <zaneb> so somehow I have managed to time it so I will be away *again* for the juno-3 milestone
20:26:12 <zaneb> sigh
20:26:13 <stevebaker> lol
20:26:19 <ryansb> allergic to milestones?
20:26:37 <zaneb> luckily the process is much simpler than it used to be
20:26:49 <zaneb> pick an SHA you like the look of
20:26:53 <zaneb> tell the release manager
20:26:58 <zaneb> release gets tagged
20:27:00 <ryansb> also aren't US folks off for Labor day next week?
20:27:00 <zaneb> simples
20:27:06 <zaneb> ryansb: yes
20:27:16 <stevebaker> zaneb, I don't mind doing it
20:27:19 <ryansb> man, the gate'll be an extra-zoo then.
20:27:56 <shardy> zaneb: likewise, I should be around to help out if needed
20:28:02 <zaneb> #info stevebaker volunteers as the release management cza^W liason for juno-3
20:28:30 * zaneb will try to actually be around for the final release
20:28:57 <zaneb> #topic Mission Statement
20:29:09 <zaneb> I know how much you all love discussing this :)
20:29:20 <stevebaker> ttx, fyi, I'll be heat release management monkey for j-3
20:29:21 <zaneb> #link https://review.openstack.org/#/c/116703/
20:29:44 <zaneb> so I put a review up, as we're required to do for our gap-closing
20:29:50 <stevebaker> looks perfect
20:30:02 <zaneb> it's using the text supplied by lifeless a year ago
20:30:27 <zaneb> I am personally concerned that it makes it sound like Mistral is in-scope for Heat, and I don't think it should be
20:30:45 <zaneb> but anyway, please everybody either vote +1 or make suggestions on that review
20:30:45 * lifeless blinks
20:30:51 <mspreitz> By "infrastructure" it means virtual infrastructure created by OpenStack?  Or also the physical infrastructure on which OpenStack runs?
20:30:58 <pas-ha> the "application" word makes me a bit uneasy given Murano and Solum
20:31:02 <zaneb> mspreitz: the first one
20:31:11 <ryansb> maybe "service for data-driven lifecycle management within openstack clouds"
20:31:17 <mspreitz> zaneb: but... but... see Ironic discussion earlier
20:31:35 <ryansb> never mind. I'll toss it on the review.
20:31:52 <zaneb> mspreitz: let's say that /contrib is not in-scope
20:32:03 <mspreitz> zaneb: ah, good dodge
20:32:08 * zaneb bows
20:32:20 <mspreitz> The wording could use some clarification on this point.
20:33:05 <zaneb> let's bikeshed on the review :)
20:33:12 <zaneb> #topic functional test directory structure
20:33:26 <shardy> mspreitz: TripleO already blurs those lines by using heat to deploy both ;)
20:33:27 * zaneb reaches for popcorn
20:33:53 <zaneb> stevebaker: which part are we still discussing?
20:34:20 <stevebaker> zaneb, we're down to the specifics now, its basically integration vs functional
20:34:53 <stevebaker> we have a job called check-heat-dsvm-functional, the job name won't change but we need to choose a top level dir/package to put our functional tests
20:35:03 <zaneb> it seems like we will eventually want both, but the ones we have at the moment are integration tests
20:35:07 <stevebaker> which are technically integration tests
20:35:54 <stevebaker> so contenders are heat-integrationtests or heat-functionaltests which will initially contain scenario tests which interact will a full openstack
20:36:19 <zaneb> let's be technically correct - the best kind of correct
20:36:59 <stevebaker> so we have devstack hooks in /functionaltests. should they move to heat-integrationtests too?
20:37:54 <zaneb> pass, I don't know how devstack hooks work
20:38:04 <stevebaker> and there is a tox environment 'functional', should that be renamed 'integration'?
20:38:42 <zaneb> probably, if there is going to be a separate functional one later
20:39:04 <stevebaker> zaneb, its just a couple of shell scripts, there will need to be an infra config change if we move them but it hasn't landed yet so might be better to move them now
20:39:23 <zaneb> +1
20:39:39 <stevebaker> ok, cool. thats all I need to know
20:39:59 <shardy> If we're going for unit/integration/functional we should probably write something somewhere to define the scope of each type of test
20:40:10 <mspreitz> shardy: +1
20:40:19 <shardy> folks (myself included) got confused enough with the whole api/scenario thing in tempest
20:40:31 <shardy> which I considered functional tests in both cases
20:40:32 <stevebaker> shardy, there should be a heat-integrationtests/README.rst
20:40:40 <shardy> stevebaker: +1, sounds good
20:40:44 <zaneb> +1
20:40:52 <mspreitz> I was also wondering what is the practical use of the distinction.  Will integration tests be run under different circumstances the functional ones?
20:41:01 <zaneb> mspreitz: yes
20:41:07 <stevebaker> I think the API tests are functional tests, but the scenario tests are integration tests
20:41:10 <skraynev> stevebaker: also will be good to have same for functional
20:41:15 <zaneb> integration tests run against other services, functional tests against fakes
20:41:24 <stevebaker> some of our unit tests are technically functional tests (test_engine_service)
20:41:35 <mspreitz> zaneb: thanks, that should be part of what is written down
20:42:18 <shardy> zaneb: It would be great if we could somehow move towards a model where functional tests have less coupling with the code, e.g not like the current "unit" tests
20:42:22 <stevebaker> mspreitz, functional tests test all the heat bits working together. integration tests heat against all the other components in the system
20:43:27 <shardy> the current test structure is bordering on unworkable IMO, for certain types of changes which impact a lot of stuff
20:43:31 <mspreitz> OK, I understand the difference in dependencies.  Is there a difference in usage?  Are both run at the same point in a change's lifecycle?
20:43:41 * shardy is just grumpy after two days of poking at broken tests ;)
20:44:08 <zaneb> shardy: only two days?
20:44:14 * zaneb usually spends weeks
20:44:19 <shardy> zaneb: well, I've not finished yet ;)
20:44:24 <zaneb> lol
20:44:51 * stevebaker needs to go soon
20:45:09 <zaneb> I think we're agreed on this
20:45:13 <zaneb> #topic Critical issues sync
20:45:26 <zaneb> anyone got issues?
20:45:33 <zaneb> try to keep it project-related
20:47:09 <zaneb> no issues
20:47:18 <zaneb> #topic Open Discussion
20:47:21 <zaneb> anything else?
20:47:27 <pas-ha> how much attention should be devoted to failing check-tripleo-novabm-overcloud-precise-nonha?
20:47:50 <shardy> A couple of folks have showed up in #heat with issues after following the ubuntu install guide (the openstack docs)
20:48:15 <shardy> are there any heat ubuntu users who would be prepared to review/test the steps to spot issues?
20:48:30 <pas-ha> is it considered being more towards reasonable?
20:48:56 <zaneb> pas-ha: afaik it's an unstable non-voting job
20:49:33 <pas-ha> shardy, I use ubuntu, could try (though I'm using devstack exclusively now)
20:49:34 <shardy> pas-ha: If you're making an interface change, I'd like to see it pass, but it is somewhat flaky atm
20:50:18 <pas-ha> shardy, any links on bugs/questions?
20:50:26 <shardy> pas-ha: Ok, I think it's the package based installs a couple of folks had issues with
20:50:29 <mspreitz> shardy: I could also give it a try, starting from a heatless DevStack install.
20:50:29 <shardy> http://docs.openstack.org/havana/install-guide/install/apt/content/heat-install.html
20:50:47 <shardy> Oops, or the Icehouse version rather
20:50:49 <skraynev> shardy: I use ubuntu too, so I may help pas-ha with it (if necessary ) :)
20:51:27 <shardy> Cool, well I just wanted to get some heat-dev eyes on it, as tbh I never run heat on Ubuntu, so am not the best person to do it ;)
20:51:47 <mspreitz> shardy: so you want review on the Icehouse version?  What about the current version?
20:52:13 <zaneb> cool, let's wrap up and give everyone 8 minutes of their life back
20:52:23 <shardy> mspreitz: well Icehouse is the current stable (packaged) release
20:52:34 <mspreitz> Is there some place in Gerrit to put reviews for this?
20:52:45 <mspreitz> Or do we open bugs?
20:53:20 <shardy> mspreitz: almost certainly, in both cases, you can let me know where when you find out ;)
20:53:41 <shardy> I'm not actually sure what launchpad component relates to the install guide
20:53:44 <zaneb> shardy: is the source in our repo or a docs repo?
20:53:51 <shardy> zaneb: docs repo
20:54:09 <shardy> I couldn't find which one when I looked a few days ago, but I didn't try that hard
20:54:51 <mspreitz> shardy: is that a meta-bug?
20:55:01 <mspreitz> (the place being hard to find)
20:55:29 <ryansb> mspreitz++
20:55:56 <mspreitz> If I have difficulty I will open a bug on some doc about doc
20:56:15 <zaneb> splendid
20:56:24 <zaneb> thanks everyone!
20:56:25 <shardy> mspreitz: well feel free, I just assumed I lacked sufficient coffee ;)
20:56:34 <zaneb> #endmeeting