rdo_meeting_-_2016-08-10
LOGS
15:02:05 <number80> #startmeeting RDO meeting - 2016-08-10
15:02:05 <zodbot> Meeting started Wed Aug 10 15:02:05 2016 UTC.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:05 <zodbot> The meeting name has been set to 'rdo_meeting_-_2016-08-10'
15:02:34 <number80> #topic roll call
15:02:36 <chandankumar> number80, https://meetbot.fedoraproject.org/sresults/?group_id=rdo&type=channel i think number80 is the chair
15:02:44 <chandankumar> \o/
15:02:46 <number80> agenda is here: https://etherpad.openstack.org/p/RDO-Meeting
15:02:48 <rbowen> According to the agenda, yes. :-)
15:02:50 <rbowen> o/
15:02:58 <number80> completely forgot :)
15:03:00 <jpena> o/
15:03:11 <jruzicka> o/
15:03:16 <amoralej> o/
15:03:24 <coolsvap> o/
15:03:27 <number80> dmsimard: around?
15:04:04 <rbowen> He just said he had to leave.
15:04:26 <rbowen> well, 20 minutes ago.
15:04:37 <number80> ok
15:04:48 <number80> #chair chandankumar rbowen jpena jruzicka amoralej coolsvap
15:04:48 <zodbot> Current chairs: amoralej chandankumar coolsvap jpena jruzicka number80 rbowen
15:04:50 <jschlueter> o/
15:04:52 <number80> let's start
15:04:54 <number80> #chair jschlueter
15:04:54 <zodbot> Current chairs: amoralej chandankumar coolsvap jpena jruzicka jschlueter number80 rbowen
15:05:09 <number80> #topic Add vanilla tempest package
15:05:12 <chandankumar> tosky, EmilienM RDO meeting.
15:05:21 <tosky> hi
15:05:33 <number80> we had a request to ship a vanilla tempest package
15:05:52 <chandankumar> #chair tosky
15:05:52 <zodbot> Current chairs: amoralej chandankumar coolsvap jpena jruzicka jschlueter number80 rbowen tosky
15:06:14 <number80> considering that part of our CI and test teams are using the heavily modified current package, it's not possible to replace it
15:06:46 <number80> so workaround is to ship both and make sure that they co-exists in our repository without breaking current use cases
15:06:47 <flepied> o/
15:06:52 <number80> #chair flepied
15:06:52 <zodbot> Current chairs: amoralej chandankumar coolsvap flepied jpena jruzicka jschlueter number80 rbowen tosky
15:07:12 <amoralej> i think dmellado was working in a better solution for tempest package
15:07:21 <amoralej> but he's on PTO now
15:07:55 <chandankumar> so we need a small gap solution for tempest
15:08:00 <number80> yes, he'll be back around M3 so we're now trying to find a workaround to work for everyone
15:08:12 <number80> s/to/that/
15:09:00 <number80> proposal: ship openstack-tempest-vanilla, and have both openstack-tempest{,-vanilla} provides tempest
15:09:18 <amoralej> who will use the new vanilla package?
15:09:19 <number80> and dependencies should require tempest instead of the package directly
15:09:29 <number80> amoralej: I had requests from dmsimard and EmilienM
15:09:56 <EmilienM> number80: you always has requests from us.
15:10:12 <number80> EmilienM: this one is reasonable, just not good timing :)
15:10:13 <jpena> which tempest would win if we install a package that depends on it? Would the Epoch in openstack-tempest prevail?
15:10:38 <jpena> let's say we install python-designate-tests-tempest without any tempest package installed
15:10:48 <number80> jpena: not necessarily, hence the Provides: tempest (note that it's unversioned)
15:11:37 <number80> both packages will conflicts, but yum will likely prefer the existing one (due to epoch)
15:11:54 <chandankumar> so basically we have two tempest package one from upstream and another from rh-openstack/tempest which will provide tempest, am i right?
15:12:01 <number80> but, if you use the package name, the one installed will prevail
15:12:12 <number80> chandankumar: just one, the latter
15:12:33 <amoralej> what about dependencies, we'll keep them as they are? tempest-vanilla will depend on all -tests packages?
15:12:43 <amoralej> as openstack-tempest?
15:12:52 <number80> EmilienM: would installing explicitly openstack-tempest-vanilla would work for you? until we fix openstack-tempest?
15:13:07 <number80> amoralej: actually, it won't matter
15:13:11 <jpena> actually, if we do this, I'd do dependencies right (-test packages depend on tempest, not the other way around)
15:13:16 <number80> tempest-vanilla can depends on all -tests
15:13:37 <number80> and -tests should requires: tempest (not openstack-tempest)
15:13:41 <number80> so won't break
15:14:01 <EmilienM> number80: yes
15:14:20 <amoralej> i don't like the idea of tempest requiring -tests, but chinging that would require other changes probably
15:14:42 <number80> jpena: we can do that, that's relatively easy to do
15:15:13 <jpena> number80. Ack. Would it impact CIs relying on -test packages? I'd assume no, but just in case, EmilienM?
15:15:23 <EmilienM> no
15:15:33 <EmilienM> I see a problem though
15:15:42 <number80> jpena: existing downstream CI should not be affected
15:15:44 <EmilienM> Tempest CI is currently running our puppet jobs
15:15:49 <EmilienM> and for that, we use zuul-cloner
15:16:04 <EmilienM> so using a packaging in RDO would not help us, since we need tempest from source in that case
15:16:37 <EmilienM> look https://review.openstack.org/#/c/349124/
15:16:42 <EmilienM> and see puppet jobs (non voting)
15:17:02 <EmilienM> it's possible thanks to https://github.com/openstack/puppet-openstack-integration/blob/master/run_tests.sh#L73-L74
15:17:21 <EmilienM> if we stop doing ^ and we deploy the new package, the jobs in tempest gate would be useless
15:17:31 <jpena> EmilienM: ok, I see.
15:17:32 <EmilienM> and we like tempest testing our jobs
15:17:42 <EmilienM> because we avoid them to inject regressions
15:17:44 <number80> EmilienM: so why using plugins packages?
15:17:51 <EmilienM> number80: good question
15:18:10 <number80> I don't mind that we use git or RPM, but mixing them is not a good idea
15:18:13 <EmilienM> iirc, it was introduced because regular packages didn't have the tests
15:18:19 <EmilienM> so we started to package them
15:18:47 <number80> not all packages have yet -tests subpackages
15:19:16 <tosky> it's still a work in progress (and more and more Tempest tests will be in plugins)
15:19:24 <number80> I suggest that we remove tempest deps from all -tests subpackages
15:19:35 <chandankumar> number80, i think all the openstack services has test subpackages
15:19:38 <EmilienM> +1
15:19:57 <chandankumar> https://github.com/openstack/puppet-tempest/blob/master/manifests/params.pp#L15
15:20:04 <number80> chandankumar: not all of them, I came accross few ones that don't
15:20:40 <number80> let's vote about removing tempest as dependency to -tests packages
15:20:41 <chandankumar> number80, please let me know we can create the test sub packages.
15:20:42 <number80> +1
15:20:48 <amoralej> number80
15:20:49 <number80> ack
15:20:56 <number80> amoralej: yes?
15:21:08 <amoralej> but what's the purpose of removing the dev?
15:21:13 <amoralej> dependency?
15:21:29 <number80> amoralej: if upstream CI uses tempest from git, it may conflict
15:21:53 <number80> mixing git/pip installed modules with RPM packages may bring unwanted side-effect
15:22:15 <EmilienM> i'll give a try (later this week maybe) to setup plugins from source in puppet ci
15:22:20 <amoralej> ok, we should understand that mixing plugins as rpm + tempest from source is a requirement, right?
15:22:29 <number80> it also means that the whole topic of having vanilla tempest may be delayed up to dmellado return
15:22:30 <jruzicka> +1
15:22:56 <amoralej> yes, then we are in the point we were yesterday with dmsimard :)
15:23:04 <number80> amoralej: well, I wouldn't support that configuration.
15:23:23 <tosky> number80: upstream CI uses tempest from git and it installs it in its own virtualenv, so if it the virtualenv is isolated it can't access system-installed plugins
15:23:26 <number80> at least tempest + its plugins should be installed from same sources
15:23:50 <amoralej> i think the point is that some projects have tempest plugin in main git repo
15:23:52 <number80> tosky: we had a review to allow mixing tempests plugins packages w/ git-installed tempests
15:23:52 <EmilienM> the problem is afik puppet ci doesnt deploy tempest in vevn
15:23:54 <EmilienM> venv*
15:23:55 <amoralej> with service code
15:24:07 <amoralej> so it's not that easy to install the plugin from source, maybe
15:24:30 <tosky> number80: if tempest is installed systemd-wide (so at the same level of the plugins, or with visibility to the plugins) than it's fine
15:24:30 <amoralej> when it has it's own project is probably much easier
15:24:44 <tosky> number80: they just need to be in the same... installation environment
15:25:17 <number80> tosky: the thing is, we should not allow people installing stuff in system site-packages
15:25:32 <tosky> number80: correct as well
15:25:57 <weshay> hrybacki, any resolution to the missing overcloud rst's?
15:26:00 <tosky> number80: but I think that tempest with a venv with --system-site-packages should work
15:26:03 <tosky> just for the record
15:26:14 <number80> tosky: that would be a good workaround
15:26:23 * number80 suggests to move out to the mailing-list
15:26:37 <number80> one topic ate 1/3 of the allocated time :)
15:26:51 <hrybacki> weshay: gate is calling roles-deploy.sh, not quickstart.yml, so it's using tripleo-overcloud (which doesn't have the changes) instead of the native role to deploy the overcloud
15:26:54 <hrybacki> so nothing is broken
15:27:24 <number80> please wait, meeting is running
15:27:43 <number80> #topic Volunteers wanted to talk about what you're doing in Newton, for RDO podcast
15:27:43 <amoralej> +1 to remove tempest dependency from -tests so far and wait for dmellado feedback before creating the vanilla package
15:27:45 <rbowen> The kids have gone back to school, so my office is quiet again. Over the coming weeks, I'd like to do podcasts with members of various OpenStack projects about what's coming in Newton. I'm looking for volunteers.
15:27:56 <number80> amoralej: ack
15:28:07 <rbowen> I'm looking for 10-15 minutes, talking about what you're working on, what you're excited about in Newton, that sort of thing.
15:28:16 <number80> #info rbowen is looking for volunteers for RDO Newton release podcasts
15:28:20 <weshay> hrybacki, meh.. just flip it to quickstart then
15:28:22 <rbowen> See https://dmsimard.com/2016/05/15/what-did-everyone-do-for-the-mitaka-release-of-openstack/ for examples of what we did last time.
15:28:38 <rbowen> </end of topic>
15:28:43 <number80> thanks
15:28:58 <number80> #topic Cleanup old commits from former centos7-master in DLRN instance
15:29:00 <number80> jpena: ?
15:29:22 <jpena> we're still using quite a lot of space in the old centos7-master (now centos7-master-head)
15:29:50 <jpena> now that we've moved jobs to the new worker (using upper-constraints) it would be a good time to purge it
15:30:03 <amoralej> my only concern is that i remember from migration to ci.centos that specific hash repos where hardcoded in some places
15:30:15 <amoralej> i remember tripleo ci i.e.
15:30:29 <amoralej> so, purging may remove those olds repos, right?
15:30:36 <jpena> amoralej: not anymore. We copied hardcoded hashed repos to the new centos-newton worker
15:30:56 <jpena> so if there was something wrong, it should have failed by now, the old worker has a different url
15:31:29 <amoralej> sorry, you are talking only about the old server
15:31:32 <amoralej> right?
15:32:05 <jpena> amoralej: no, the new server at ci.centos.org, but the centos-master worker (now published at trunk/centos7-master-head)
15:32:30 <amoralej> ok, i got it now
15:32:54 <number80> that looks good, please add action or info for the logs
15:32:54 <rdogerrit> Eric Harney created openstack/taskflow-distgit: Remove dependency on python3-futures  http://review.rdoproject.org/r/1829
15:33:09 <jpena> since the NFS share is quite slow, the whole process could take long (maybe a couple days), during the which the old worker will be stopped
15:33:14 <jpena> just fyi
15:33:27 <jpena> #action jpena to purge old commits from centos-master
15:33:44 <number80> thank you :)
15:34:11 <number80> #topic chair for next week meeting
15:34:14 <number80> who wants it?
15:34:24 <jpena> I can take it, it's been a while since I last did it
15:34:36 <number80> #info jpena to chair next week meeting
15:34:48 <number80> #topic open floor
15:34:52 <chandankumar> number80, Any action item from vanilla tempest discussion or we wait till dmellado returns?
15:35:23 <number80> chandankumar: except starting a discussion on the rdo-list and removing tempest as dependency in all -tests packages, none
15:35:55 <chandankumar> i will do that
15:36:23 <number80> solution may be simple, but the topic is tricky, that's why we need all the input before touching the packages
15:36:37 <amoralej> i think the only one is the designate-tempest-test package
15:36:38 <number80> or we'd just keep changing things and breaking everyone
15:36:56 <number80> amoralej: yes, there may be some others though
15:37:18 <number80> not satisfactory, but we can't do better
15:37:34 <number80> any other topic someone wants to throw?
15:37:49 <chandankumar> horizon-tempest also requires tempest-horizon https://github.com/openstack/tempest-horizon/blob/master/requirements.txt#L11
15:37:58 <chandankumar> *tempest
15:38:35 <chandankumar> tempest-horizon also requires tempest https://github.com/openstack/tempest-horizon/blob/master/requirements.txt#L11
15:40:55 <chandankumar> number80, not from my side
15:41:59 <number80> ok
15:42:06 <number80> I'm closing soon
15:42:08 <number80> 3
15:42:11 <number80> 2
15:42:15 <number80> 1
15:42:17 <chandankumar> 0
15:42:19 <number80> ignition
15:42:23 <number80> #endmeeting