17:00:17 <mtreinish> #startmeeting qa
17:00:17 <openstack> Meeting started Thu Mar 12 17:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:21 <openstack> The meeting name has been set to 'qa'
17:00:31 <mtreinish> hi, who's here today?
17:00:44 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_March_12th_2015_.281700_UTC.29
17:00:44 <dkranz> o/
17:00:49 <mtreinish> ^^^ Today's agenda
17:00:51 <cdent> o/
17:00:54 <riwinters> hi
17:01:18 <dtroyer> o/
17:01:48 <dstanek> hi
17:02:00 <mtreinish> andreaf, afazekas, sdague, jogo: courtesy ping
17:02:14 <sdague> o/
17:02:21 <afazekas> o/
17:02:24 <andreaf> o/
17:02:26 <mtreinish> ok let's get started
17:02:31 <mtreinish> #topic Specs Reviews
17:02:43 <mtreinish> are there any qa specs reviews to bring up this week?
17:03:52 <mtreinish> heh, I guess not
17:04:03 <mtreinish> ok then let's move on
17:04:16 <mtreinish> #topic Blueprints
17:04:18 <jogo> o/
17:04:23 <jlanoux> o/
17:04:35 <mtreinish> are there any blueprints open that someone would like to discuss?
17:05:33 <mtreinish> well I guess I'll mention the test accounts continued bp
17:05:51 <mtreinish> we've landed the first part of that, which is roles support for the accounts.yaml file
17:06:12 <mtreinish> now all 3 cred_providers can provide accounts with arbitrary roles (including admin)
17:06:49 <mtreinish> the only big piece left for that bp is the network part, so we'll be able to express which network should be used w/ tenants
17:07:24 <mtreinish> are there any other bps to bring up?
17:07:27 <mtreinish> andreaf: ^^^ ?
17:07:32 <andreaf> perhaps a couple of updates
17:07:37 <andreaf> #link https://blueprints.launchpad.net/tempest/+spec/multi-keystone-api-version-tests
17:07:49 <andreaf> I prepared all patches needed to complete that
17:08:26 <andreaf> https://review.openstack.org/#/q/topic:+bp/multi-keystone-api-version-tests+status:open,n,z
17:08:41 <andreaf> once those three are merged we should be able to close the bp
17:09:29 <mtreinish> andreaf: the bp also lists the v3 in the stress tests has that been taken care of too?
17:10:00 <andreaf> mtreinish: yes it does
17:10:31 <afazekas> #NOTE: we need to handle token skopes in-order to pass with  etc/policy.v3cloudsample.json
17:11:27 <andreaf> afazekas: I don't think that is part of the bp - I would consider it as an extra
17:11:33 <andreaf> afazekas: else that bp will never end
17:11:41 <afazekas> :)
17:12:39 <andreaf> The other bp is tempest-lib migration - there as well we're almost ready to move token clients and auth to tempest-lib
17:13:12 <mtreinish> andreaf: are there any reviews needed to help push that around? Or is just the act of doing the migration left?
17:14:30 <andreaf> only the migration
17:14:35 <mtreinish> ok
17:14:47 <andreaf> afazekas: do you think supporting the v3 policy will require changes to auth.py?
17:15:33 <andreaf> afazekas, mtreinish: I think auth should be general enough so that it should work just by making changes in tests and base classes / tenant isolation
17:16:24 <mtreinish> andreaf: yeah I think since jamielennox add support for the domain scopes it should be good to go
17:16:27 <afazekas> andreaf: I am unsure  about this , looks like Jamie Lennox has more idea about this
17:16:57 <andreaf> ok I will check with jamielennox if he's happy, and prepare the migration in parallel
17:17:13 <mtreinish> andreaf: even if there are future changes needed after we make the lib migration we can do them. We just have to worry about backwards compat
17:17:37 <andreaf> sure
17:18:08 <mtreinish> ok, are there any other bps to bring up? Otherwise let's move on
17:18:12 <andreaf> regarding the resource-cleanup bp, it's amost done, there are a few patches outstanding only
17:18:27 <mtreinish> andreaf: just some last split patches?
17:18:55 <andreaf> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/resource-cleanup,n,z
17:19:47 <andreaf> mtreinish: my patches in that list however still need a bit more work
17:20:10 <andreaf> mtreinish: there're more about optimizing things once the split is complete
17:20:17 <andreaf> s/there/they
17:20:41 <mtreinish> andreaf: ok
17:21:08 <mtreinish> ok, in the interest of time let's move on
17:21:09 <andreaf> mtreinish: the ssh-auth-strategy is still WIP, but getting close
17:21:14 <mtreinish> andreaf: ok cool
17:21:25 <mtreinish> let me know if any assistance is needed on that one
17:21:53 <andreaf> mtreinish: yes we will need reviews once the first set of patches is ready
17:22:11 <mtreinish> #topic Devstack
17:22:20 <mtreinish> dtroyer: still around?
17:22:25 <dtroyer> yup
17:23:19 <dtroyer> I've refreshed the venv patches and added a global USE_VENV control, series starts with https://review.openstack.org/162783
17:23:36 <sdague> ok, cool. Need to take a lot on that series
17:23:37 <dtroyer> it's passing with it turned off, running now with it turned on
17:23:57 <sdague> btw, the operator meetup put a different spin on this
17:24:08 <sdague> as they apparently largely want the global requirements sync
17:24:09 <dtroyer> I've forgotten if we have taled about how to run this ongoing…do we need a new job template?
17:24:18 <dtroyer> heh, nice
17:24:33 <sdague> yeh, we should make another job I think
17:24:49 <mtreinish> dtroyer: yeah it makes sense to have it as a separate job, even if just running on devstack
17:25:00 <afazekas> dtroyer: Are you planning to support to use just single venv with allowed site-packages ?
17:25:08 <dtroyer> ok, lets work through that later, I'm a lost boy in project-config repo
17:25:23 <mtreinish> dtroyer: sure I can give you a hand with that
17:25:32 <dtroyer> afazekas: it's totally configurable.  right now it's a per-project venv, but can easily be changed from local.conf
17:26:46 <mtreinish> the other thing I have to add on the venvs is my patch to cache them in nodepool landed
17:26:49 <afazekas> dtroyer: I am ok  with the currently proposed patches, but I would like to have a simple single opt for this, instead of configuring it per project
17:27:01 <mtreinish> still waiting on jogo's d-g patch to use it:
17:27:08 <mtreinish> #link https://review.openstack.org/#/c/160933/
17:27:12 <dtroyer> mtreinish: right, thanks.  have images with that enabled been used yet?
17:27:16 <dtroyer> ok
17:27:42 <mtreinish> dtroyer: build_wheels is being called according to the nodepool logs so it should be on the images
17:27:50 <mtreinish> we're just not using it yet
17:28:16 <dtroyer> afazekas: looks like we're going to need to talk about what the defaults will be still…it's much better to develop it this way though as it has exposed a lot of interesting little assumptions
17:28:58 <jogo> sdague: you have +2 on that repo right?
17:29:07 <sdague> yeh, I'll look
17:29:08 <dtroyer> also, I've planned to wait to start backporting until master is going…is that still a good plan?
17:29:21 <sdague> dtroyer: yes, lets get master sorted first
17:29:29 <dtroyer> ok
17:30:13 <afazekas> dtroyer, I comment what is my vision here https://review.openstack.org/#/c/161161/ , a single venv with use site packages is very close to that
17:30:42 <dtroyer> afazekas: heh, use-site-packages isn't in our plans atm…I'll go read that though
17:31:16 <mtreinish> ok, is there anything else to discuss on devstack?
17:31:25 <dtroyer> getting away from the packages is actually the current direction…
17:31:30 <dtroyer> that's all from me
17:32:16 <mtreinish> ok, then let's move on
17:32:28 <mtreinish> #topic Grenade
17:32:48 <mtreinish> is there anything to talk about in the world of grenade this week?
17:32:54 * mtreinish looks at jogo
17:33:01 * andreaf has to drop off now
17:33:36 <sdague> I think EmilienM had grenade questions
17:33:43 <sdague> sorry javelin questions
17:33:47 <EmilienM> I'm doing floating ip in javelin2: https://review.openstack.org/#/c/163622/
17:33:55 <mtreinish> #link https://review.openstack.org/#/c/163622
17:34:03 <EmilienM> maybe my patch is not correct, I would love some feedbacks
17:34:07 <jogo> mtreinish: also https://review.openstack.org/163773
17:34:16 <mtreinish> EmilienM: ok I'll take a look after the meeting
17:34:18 <jogo> will try to look at both later today
17:34:21 <EmilienM> we may want to be able to run javelin in multi node env
17:34:27 <EmilienM> mtreinish: awesome, thx.
17:34:38 <mtreinish> EmilienM: is it just a patch to use floating ip for ssh when needed?
17:34:49 <EmilienM> mtreinish: for ping
17:34:56 <EmilienM> but I use the ssh flag
17:35:08 <mtreinish> ah ok
17:35:22 <EmilienM> in a multi node env, you can't reach namespace
17:35:29 <EmilienM> so I implemented floating IP
17:35:33 <EmilienM> so you can test the ping
17:35:50 <mtreinish> EmilienM: ooh, you're using javelin in a multinode env?
17:35:55 <EmilienM> and I do it of the use_floatingip_for_ssh flag is a true
17:36:04 <EmilienM> mtreinish: yes
17:36:08 <EmilienM> we use it for QA
17:37:15 <mtreinish> EmilienM: interesting, I'll probably ping you at some point for more details, because I'm curious :)
17:37:22 <mtreinish> #link https://review.openstack.org/#/c/163773/
17:37:24 <EmilienM> mtreinish: anytime
17:37:35 <mtreinish> ok is there anything else to discuss on grenade?
17:38:48 <mtreinish> #topic Neutron shared network testing
17:39:01 <mtreinish> this topic has been deferred from the past 2 meetings
17:39:12 <mtreinish> I'm not sure who put it on the agenda though
17:39:25 <mtreinish> afazekas: for some reason I thought it was you? :)
17:39:27 <afazekas> me
17:39:37 <mtreinish> heh, ok go ahead
17:40:14 <afazekas> So at the moment looks like I had to -2 this change https://review.openstack.org/#/c/124998/
17:40:29 <afazekas> because testing shared networks in tempest is not safe
17:40:56 <afazekas> Looks like the only way to make it safe is ALWAYS specifying a network at nova boot
17:41:10 <afazekas> Does anyone has any objections against it or better solution ?
17:41:20 <mtreinish> afazekas: sigh, yeah that's been a big long standing bug
17:41:40 <mtreinish> hogepodge was hitting it earlier this week just against an existing deployment
17:41:47 <afazekas> It is 3th proposed patch for shared net test if I am counting correctly..
17:42:13 <mtreinish> there is a patch up somewhere which starts to address this as a short term fix (by adding the network id to each of the create server helpers)
17:42:49 <mtreinish> the long term solution is the test accounts bp and the ssh auth improvements one
17:42:59 <afazekas> mtreinish: AFAIK not yet, we need to fix at least in 3 places: api,scenario,boto
17:43:24 <afazekas> probbaly we also need to specify network for the tests where we omited it and we boot the vms without network
17:43:47 <afazekas> unless we cen specify the `No NETWORK` explicitly on the api
17:43:54 <marun> long term, this kind of scenario testing should be done in the project tree in a test-controlled environment imho
17:44:30 <mtreinish> marun: maybe for testing the shared networks explicitly, but we also have this issue running a tempest test against an env with a share network
17:44:39 <mtreinish> so it needs to be fixed anyway
17:45:02 <afazekas> marun, can you support shared net testing in neutron in similar way as tempest without this issue ?
17:45:19 <mtreinish> afazekas: yeah IIRC that was what the patch was trying to do just adding the network id everywhere to prevent this
17:45:21 <marun> I'm just saying that not all testing is best done without control of the env
17:45:42 <mtreinish> I think it might have been from bnemec, but I can seem to find it
17:46:03 <bnemec> Oh, the multiple networks thing?
17:46:05 <mtreinish> yeah
17:46:23 <bnemec> Yeah, I ran out of steam on that. :-(
17:46:23 <afazekas> mtreinish, So adding net id everywhere is an agreed and good solution ? (yes/no)
17:46:48 <marun> tempest's mission to do just that suggest that this kind of testing doesn't belong there
17:47:11 <marun> afazekas: definitely
17:47:43 <mtreinish> afazekas: yeah it'll be the short term fix. Long term we should consolidate the create server helpers and just do it there
17:47:48 <mtreinish> bnemec: do you have the link?
17:48:03 <bnemec> I'm looking, but I didn't own the original change so it's a little tricky to find.
17:48:53 <mtreinish> bnemec: no worries, yeah I had trouble finding it too
17:49:11 <mtreinish> ok, is there anything else on this topic?
17:49:48 <bnemec> mtreinish: https://review.openstack.org/#/c/61037/
17:49:57 <mtreinish> #link https://review.openstack.org/#/c/61037/
17:49:59 <mtreinish> great thanks
17:50:03 <bnemec> np
17:50:14 <dkranz> mtreinish: can we make sure we have time for the last two topics?
17:50:28 <mtreinish> dkranz: yes I was going to do those next
17:50:39 <afazekas> If nova not able to do it already, probbaly I will ask for an API option to allow to specify booting vm without network..
17:51:21 <mtreinish> #topic Can we freeze development of Neutron api tests? (marun)
17:51:41 <mtreinish> afazekas: heh, I thought you could do that, but I dunno
17:51:48 <marun> So, we have a snapshot of the api tests running as part of the neutron api job.
17:52:31 <afazekas> mtreinish: now we do it implicitly in tempest , the tenant has zero network in some cases
17:52:46 <marun> My intention is to update from tempest regularly until we can designate a point to freeze development in tempest (not remove, just move development focus to neutron tree).
17:53:13 <marun> mtreinish: What needs to happen to freeze work in tempest and move the focus to neutron?
17:53:24 <mtreinish> marun: are you talking about freezing new tests or all changes in api.network?
17:53:40 <marun> mtreinish: The latter.
17:53:57 <marun> mtreinish: maybe 'manual changes in api.network' is a more apt description
17:54:10 <marun> mtreinish: until the tests are removed we may need to maintain in tempest
17:54:21 <marun> mtreinish: but I'd like to see manual changes take place in neutron first
17:54:35 <marun> mtreinish: make sense?
17:54:36 <mtreinish> that might get tricky because there are a number of in flight refactors going on right now and I'm sure they'll probably touch it
17:54:49 <marun> mtreinish: when will those refactors be done then?
17:55:01 <marun> mtreinish: I'm not asking for an immediate freeze, but I do want to set a timeline
17:55:18 <afazekas> Do we want to enforce the tempest api tests should not be changed at the same time (change), when the code also changed in-order to enforce api compatibility ?
17:55:23 <mtreinish> the 2 big bps I'm thinking of probably not until right up until the release
17:55:44 <marun> afazekas: we intend to enforce that in the neutron repo, yes.
17:56:23 <mtreinish> marun: what I'd really like to say is we can freeze everything when all the pieces you need are in the lib
17:56:29 <afazekas> marun, imho it is sufficient
17:56:36 <mtreinish> but we can freeze new test dev sooner
17:56:44 <dkranz> marun: +1
17:56:52 <marun> mtreinish: How long would we be freezing test dev for though?
17:57:32 <marun> mtreinish: I think we have new features landing this cycle that need new tests before release.
17:57:48 <marun> mtreinish: To clarify, the bp's in question are about moving functioanlity to tempest-lib?
17:58:06 <mtreinish> marun: no they're refactors needed before we can consider doing that
17:58:22 <mtreinish> for things like the cred_providers and ssh/guest verification
17:58:31 <marun> mtreinish: is there a reason that couldn't be done external to test freeze?
17:58:48 <marun> mtreinish: we're talking api tests only
17:58:56 <marun> so ssh/guest doesn't seem applicable
17:59:09 <marun> cred_providers, I'm also not sure why tests would be affected
17:59:13 <mtreinish> marun: that's what I was saying it could be a staged thing we stop adding new api tests and do them in neutron, then everything in that dir, then go through the deletion procedure
17:59:15 <marun> test infrastructure, sure
17:59:30 <marun> mtreinish: ah, ok.
17:59:33 <mtreinish> marun: they both will change how servers and other resources will be created
17:59:49 <mtreinish> at least to a certain extent
18:00:01 <marun> mtreinish: so the refactor work would mainly be about keeping the tempest-maintained tests running rather than modifying their logic
18:00:12 <mtreinish> marun: yeah
18:00:30 <marun> mtreinish: so we should be able to take over responsibility for maintanance ahead of the refactor being completed?
18:00:35 <afazekas> Are we planning to migrate the test ids ?
18:00:35 <mtreinish> anyway we're at time, I'll add this and the other topic to the agenda for next week
18:00:41 <mtreinish> afazekas: we'll have to
18:00:48 <mtreinish> that migration to tempest-lib should happen soon
18:00:55 <mtreinish> thanks everyone
18:00:59 <dkranz> mtreinish: have a few minutes in #qa?
18:01:01 <mtreinish> #endmeeting