20:00:04 <asalkeld> #startmeeting heat
20:00:05 <openstack> Meeting started Wed Mar 25 20:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:09 <openstack> The meeting name has been set to 'heat'
20:00:20 <asalkeld> #topic rollcall
20:00:30 <stevebaker> \o
20:00:37 <tspatzier> hi all
20:00:38 <ryansb> \o
20:00:38 <jasond> o/
20:00:39 <Tango|2> hi
20:00:45 <dgonzalez> hi
20:00:53 <asalkeld> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:00:59 <jruano> hi folks, new to openstack, looking to focus on heat project. just wanted to introduce myself
20:01:12 <asalkeld> hi jruano
20:01:13 <stevebaker> jruano: hi!
20:01:35 <asalkeld> #topic Adding items to the agenda
20:01:49 <skraynev_> hey all
20:02:04 <asalkeld> any more topics for today?
20:02:08 <skraynev_> welcome jruano
20:02:23 <pas-ha> o/
20:02:24 <jruano> thanks
20:02:37 <stevebaker> I'll piggyback on the heat_integrationtests topic
20:02:50 <asalkeld> ok, well i get started
20:02:59 <asalkeld> #topic  rc1 status
20:03:07 <asalkeld> #link https://launchpad.net/heat/+milestone/kilo-rc1
20:03:36 <asalkeld> first bps
20:03:41 <asalkeld> #link https://review.openstack.org/161306
20:03:53 <asalkeld> we need some reviews ^
20:04:04 <asalkeld> just one patch
20:04:19 <asalkeld> #link https://blueprints.launchpad.net/heat/+spec/mistral-resources-for-heat
20:04:37 <asalkeld> I have not gotten around to reviewing that - sorry
20:04:43 <asalkeld> but i will
20:05:04 <stevebaker> if they are in contrib they could land any time, not subject to feature freeze
20:05:14 <stevebaker> (we should still review though)
20:05:19 <asalkeld> stevebaker: yeah less of an issue
20:05:21 <skraynev_> stevebaker: yeah :)
20:05:33 <skraynev_> a lot of new lines :)
20:05:46 <asalkeld> ok, so onto bugs
20:05:57 <pas-ha> about skraynev's patch - can we catch zaneb to take a look?
20:06:02 <pas-ha> as we discussed bug #1393268 is not that urgent, and I would not complete all the places until Kilo (too many unit tests rewrites), can be safely bumped to l-1
20:06:03 <openstack> bug 1393268 in heat "cleanup scheduler tasks in resources" [High,In progress] https://launchpad.net/bugs/1393268 - Assigned to Pavlo Shchelokovskyy (pshchelo)
20:06:05 <stevebaker> I wonder in the Big Tent world what criteria do we have for moving contrib resources to the main tree?
20:06:27 <asalkeld> stevebaker: not sure, we need to check
20:06:29 <stevebaker> the project moving to the openstack namespace I guess
20:06:47 <stevebaker> and the resource reaching some threshold of quality
20:06:55 <pas-ha> I would think so, but that means incubated in old terms too
20:06:58 <asalkeld> main issue is putting the cient in global requirements
20:07:03 <asalkeld> client
20:07:19 <stevebaker> lets talk about that at summit
20:07:23 <pas-ha> how about we demand version >=1?
20:07:32 <pas-ha> but then heat is out of picture...
20:07:54 <asalkeld> pas-ha: i don't think that is a useful benchmark
20:08:10 <asalkeld> so we have a lot of bugs
20:08:20 <asalkeld> we need to fix them!
20:08:24 <pas-ha> sure, just dumping ideas on how to measure maturity and stability(?) of clients
20:09:03 <stevebaker> pas-ha: do you think bug 1393268 can be done in rc1?
20:09:04 <openstack> bug 1393268 in heat "cleanup scheduler tasks in resources" [High,In progress] https://launchpad.net/bugs/1393268 - Assigned to Pavlo Shchelokovskyy (pshchelo)
20:09:26 <pas-ha> stevebaker, ^^^^^ some lines above
20:09:34 <pas-ha> don't think so
20:09:42 <stevebaker> ah, ok
20:09:55 <asalkeld> pas-ha: i'll move from rc1
20:10:02 <pas-ha> (y)
20:10:06 <asalkeld> one note about bugs
20:10:21 <asalkeld> what's in rc1 are blockers
20:10:32 <asalkeld> and here:https://bugs.launchpad.net/heat/+bugs?field.tag=kilo-rc-potential
20:10:36 <asalkeld> are nice to haves
20:10:51 <asalkeld> so if you are looking for a bug to fix pull from there too
20:11:38 <asalkeld> i'll move on
20:11:47 <skraynev_> asalkeld: I uploaded raw fix for https://bugs.launchpad.net/heat/+bug/1428434
20:11:48 <openstack> Launchpad bug 1428434 in heat "Stack deletion failed for the subnet" [High,In progress] - Assigned to Sergey Kraynev (skraynev)
20:12:06 <asalkeld> nice  skraynev_ thanks
20:12:09 <asalkeld> #topic make heat_integration tests more independent from Heat tree (pas-ha)
20:12:18 <skraynev_> stevebaker: https://review.openstack.org/167782 need your opinion , also I will add normal tests
20:12:26 <stevebaker> kk
20:12:34 <skraynev_> stevebaker: thx
20:12:55 <asalkeld> pas-ha: $topic
20:13:04 <pas-ha> so the small idea was to decouple the tests a bit, at least give them their own requirements.txt and modify tox job to use it
20:13:25 <pas-ha> would decrease somewhat the tox env init
20:13:41 <pas-ha> and also make it easier for third parties to package it separately
20:13:42 <asalkeld> pas-ha: so the idea is to make it smaller/
20:13:50 <pas-ha> yes
20:14:07 <pas-ha> currently we need only clients and testtools+stuff
20:14:38 <pas-ha> ideally we could go as far as making it a git submodule :)
20:15:01 <asalkeld> i am quite enjoying it in tree
20:15:22 <stevebaker> being able to have a heat feature and the test in the same change series is nice
20:15:31 <pas-ha> well, with submodules it will still be, but as I said that's a long shot
20:15:55 <pas-ha> stevebaker, agree, strike submodule idea
20:15:55 <asalkeld> but i have no problem with a new tox target
20:16:08 <stevebaker> and having the attention of heat cores speeds reviews. Any repo which isn't heat is a bit of a ghetto
20:16:36 <stevebaker> pas-ha: but if it weren't for those two things I'd be totally for breaking it out
20:16:40 <pas-ha> stevebaker, tru, even the client suffers
20:17:29 <pas-ha> what if we also give it a setup.cfg, as for contrib plugins?
20:17:34 <asalkeld> pas-ha: so the main use case for this is validating a standalone installation?
20:17:56 <stevebaker> I'd like to see the tempest folk come up with some kind of story about how in-tree tests get brought together into a test suite. I was hoping tempest-lib will play a role here. We probably shouldn't do our own thing until there is a common solution <- mtreinish
20:17:57 <skraynev_> stevebaker: I suppose, that root cause was to add ability launch our integration tests against any installed Heat (i.e. have different package and avoid additional "test requirements")
20:18:29 <skraynev_> asalkeld: ^
20:18:33 <stevebaker> skraynev_: that seems reasonable. maybe a heat_integrationtests/requirements.txt
20:18:33 <asalkeld> ok
20:18:39 <pas-ha> not only, there is growing number of cloud validation projects, and they try collect every tools/test frameworks they find
20:18:52 <asalkeld> maybe a mailing list discussion on the best way forward
20:18:58 <skraynev_> stevebaker: +1
20:19:01 <pas-ha> ok, will do
20:19:10 <asalkeld> as stevebaker suggested we want to do this in a consistent way
20:19:32 <stevebaker> I've got a few testing topics to talk about
20:19:46 <asalkeld> #topic testing
20:20:01 <stevebaker> we're now using this image instead of pristine fedora. http://tarballs.openstack.org/heat-test-image/
20:20:09 <pas-ha> my smallest target was separate requirements seems we agree on that :)
20:20:23 <stevebaker> It gets rebuilt and uploaded every time a heat-templates change is merged. BUT...
20:20:33 <skraynev_> pas-ha: yeah. small victory
20:20:38 <skraynev_> :-)
20:21:26 <stevebaker> the upload is not atomic, so a CI job may download a corrupt image during an upload. I don't think it will happen often, its just something to keep in mind when doing a recheck
20:21:31 <pas-ha> stevebaker, on every commit or only on elements change?
20:21:49 <asalkeld> #action pas-ha send a message to mailing list to discuss way forward to do external functional tests
20:22:05 <stevebaker> pas-ha: every commit, because that queue doesn't have a file filter thingy
20:22:37 <pas-ha> strange, that should as easy as git-merge hook
20:22:54 <stevebaker> eventually we can switch to swift instead of tarballs.o.o. This will be atomic, and will likely be in a queue which does have a file filter
20:23:39 <asalkeld> stevebaker: so upload a small "lock" file busy.uploading
20:23:49 <asalkeld> and trash it after
20:23:51 <pas-ha> what exactly would be manifests of corrupted image?
20:24:26 <stevebaker> asalkeld: I was working on a solution for tarballs.o.o but was told to try swift
20:24:37 <pas-ha> i meant some specific failures we might elastic recheck on?
20:24:38 <asalkeld> ok
20:25:15 <stevebaker> pas-ha: failures on tests which boot image_ref I assume
20:26:18 <pas-ha> I mean the image would not boot or there might be deeper problems (like it boots but cloud-init/sc/sd not working etc)
20:26:23 <pas-ha> ?
20:26:36 <stevebaker> Also, we may need separate integration and functional jobs at some point. 60 minutes is long enough. The functional job should in theory run on a minimal devstack (heat+keystone)
20:27:04 <asalkeld> jogo: you about?
20:27:15 <pas-ha> right now there is one functional test that boots cirros
20:27:30 <stevebaker> pas-ha: hmm, we should fix that
20:27:42 <pas-ha> (id does not wait for completion though, just exits when stack is create_in_progress)
20:28:01 <asalkeld> stevebaker: jogo was talking about that in #heat a moment ago
20:28:02 <pas-ha> AFAIR it is "validation" test
20:28:14 <stevebaker> pas-ha: seems like a mock server nested stack would do
20:28:36 <pas-ha> stevebaker, probably
20:28:39 <stevebaker> asalkeld: I'll read the backscroll laster
20:28:42 <stevebaker> later
20:28:48 <jogo> asalkeld: o/
20:29:08 <asalkeld> jogo: we are mostly talking about what you suggested
20:29:16 <jogo> asalkeld: in short because heat is more 'on top' of the compute layer instead of in it. no reason to really run compute API tests on heat etc.
20:29:41 <asalkeld> jogo: we have 2 fairly distinct tests
20:29:51 <asalkeld> what we call "functional"
20:30:02 <asalkeld> could just run keystone and heat
20:30:04 <stevebaker> jogo: I think you're talking removing all heat tests from tempest, that is another thing which needs to happen
20:30:14 <asalkeld> then scenario that need all the things
20:30:22 <jogo> stevebaker: well short term, just moving around where the tempest heat tests get run
20:30:24 <jogo> long term yes
20:30:57 <jogo> stevebaker: but we can add a job tempest-dsvm-heat
20:31:05 <jogo> stevebaker: that runs a subset of tempest
20:31:13 <jogo> and stop running tempest-full on heat patches
20:31:25 <asalkeld> jogo: seems fine
20:31:27 <jogo> along with stop installing heat by default in all devstack-gate jobs
20:31:29 <stevebaker> yep, that would be nice
20:31:39 <pas-ha> +1
20:31:40 <jogo> (since we won't be calling it)
20:31:46 <asalkeld> jogo: makes sense
20:31:59 <jogo> cool, I'll start working on that, and include you on the reviews
20:32:07 <asalkeld> thanks
20:32:21 <jogo> thank you
20:32:28 <stevebaker> jogo: as an aside, I'd be tempted to replace the tempest heat API tests with gabbi tests
20:33:21 <asalkeld> stevebaker: those could be in-tree couldn't they?
20:33:28 <stevebaker> asalkeld: yes
20:33:31 <asalkeld> alongside our functional
20:33:33 <jogo> stevebaker: even better
20:33:35 <ryansb> stevebaker: that'd be pretty neat
20:33:56 <pas-ha> omg, yaml everywhere :)
20:34:15 <stevebaker> gabbi looks nice, but probably needs a couple of features to support IN_PROGRESS->COMPLETE state changes
20:34:28 <asalkeld> ok
20:34:41 <asalkeld> (i haven't looked into it)
20:35:18 <stevebaker> #link http://tarballs.openstack.org/heat-test-image/
20:35:21 <stevebaker> arg
20:35:28 <stevebaker> #link http://gabbi.readthedocs.org/en/latest/
20:35:28 <asalkeld> #topic open discussion
20:35:43 <asalkeld> jasond: you around
20:35:59 <jasond> asalkeld: hey
20:36:10 <asalkeld> inc0 was suggesting you *could* use glance to tag resource instances
20:36:19 <asalkeld> is that possible?
20:36:27 <asalkeld> or is that code still not in
20:36:46 <asalkeld> (the glance fancy tagging)
20:36:49 <jasond> hm, so propagate the heat tags to glance?
20:37:07 <asalkeld> well you just tag in glance
20:37:15 <asalkeld> and use them in heat
20:37:24 <asalkeld> so no need for tags api
20:37:27 <Tango|2> :q
20:37:33 <jasond> oh, instead of heat
20:37:46 <asalkeld> jasond: so i really have not looked into it
20:37:50 <asalkeld> so don't be alarmed
20:38:04 <asalkeld> just bringing up what he suggested
20:38:15 <pas-ha> not sure, I was under impression that those tags are for glance artifacts
20:38:29 <pas-ha> not "tags as a service"
20:38:43 <asalkeld> pas-ha: inc0 suggested you could tag an api instance
20:39:01 <asalkeld> maybe that's wrong, i honestly not sure
20:39:32 <jasond> asalkeld: will run it by randall
20:39:41 <asalkeld> jasond: i wouldn't stop what you are doing, just maybe ask someone
20:39:57 <asalkeld> jasond: thanks, nice to dispel that
20:41:12 <asalkeld> anything else?
20:42:21 <asalkeld> #endmeeting