15:00:18 <number80> #startmeeting RDO meeting - 2016-08-24
15:00:19 <zodbot> Meeting started Wed Aug 24 15:00:18 2016 UTC.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:19 <zodbot> The meeting name has been set to 'rdo_meeting_-_2016-08-24'
15:00:19 <openstack> Meeting started Wed Aug 24 15:00:18 2016 UTC and is due to finish in 60 minutes.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <openstack> The meeting name has been set to 'rdo_meeting___2016_08_24'
15:00:26 <number80> #topic roll call
15:00:33 <number80> who's around?
15:00:34 <jpena> o/
15:00:35 <dmsimard> o/
15:00:35 <imcsk8> \o/
15:00:36 <tosky> o/
15:00:37 <dmellado> o/
15:00:49 <weshay> o/
15:00:52 <hrybacki|appt> o/
15:00:59 <hrybacki> o/
15:01:21 <number80> #chair jpena dmellado imcsk8 tosky dmellado weshay hrybacki
15:01:21 <zodbot> Current chairs: dmellado hrybacki imcsk8 jpena number80 tosky weshay
15:01:24 <mvc> Hi all! I'm using latest stable version of mitaka's packstack installer from github stable/mitaka. I'm getting an error on 10.99.200.50_aodh.pp: Error: Execution of '/usr/bin/yum -d 0 -e 0 -y list python-aodhclient' returned 1: Error: No matching Packages to list.
15:01:35 <rdogerrit> Javier Peña proposed DLRN: Add run_project_tests.sh script to test upstream commits  http://review.rdoproject.org/r/1933
15:01:40 <number80> mvc: please wait that we finish our meeting
15:01:47 <Duck> quack o/
15:01:51 <number80> agenda is here: https://etherpad.openstack.org/p/RDO-Meeting
15:02:00 <number80> #chair Duck
15:02:00 <zodbot> Current chairs: Duck dmellado hrybacki imcsk8 jpena number80 tosky weshay
15:02:12 <number80> ok let's start
15:02:14 <chandankumar> \o/
15:02:21 <number80> #topic making qemu-kvm-ev (qemu-kvm >=2.3.0) a hard requirement in openstack-nova
15:02:24 <number80> #chair chandankumar
15:02:24 <zodbot> Current chairs: Duck chandankumar dmellado hrybacki imcsk8 jpena number80 tosky weshay
15:02:39 <number80> that comes from https://bugzilla.redhat.com/show_bug.cgi?id=1367696
15:03:01 <number80> so we have 4 options
15:03:05 <Duck> thanks number80 :-)
15:03:26 <jruzicka> o/
15:03:29 <jschlueter> o/
15:03:37 <number80> so we have to make sure that we install qemu-kvm-ev with RDO
15:03:41 <number80> #chair jruzicka jschlueter
15:03:41 <zodbot> Current chairs: Duck chandankumar dmellado hrybacki imcsk8 jpena jruzicka jschlueter number80 tosky weshay
15:03:49 <dmsimard> let me see if we can get a hold of danpb
15:03:53 <number80> so we have 4 options listed in the agenda
15:04:34 <number80> 1. add a rdo-release script to configure repositories
15:04:56 <number80> 2. force the use of virt-SIG in rdo-release (that does not contain non-RDO repository as of today)
15:05:09 <number80> 3. ship qemu-kvm-ev in RDO repositories
15:05:25 <number80> 4. multiple rdo-releases according your config
15:05:53 <jjoyce> 0/
15:05:58 <jpena> I have a question here: is qemu-kvm completely unusable for nova, or just some functionality is missing?
15:06:02 <number80> IMHO: 4 is too complex, 3 is a bad idea as virt SIG does a better job maintaining qemu-kvm-ev
15:06:07 <number80> #chair jjoyce
15:06:07 <zodbot> Current chairs: Duck chandankumar dmellado hrybacki imcsk8 jjoyce jpena jruzicka jschlueter number80 tosky weshay
15:06:25 <number80> jpena: likely the latter
15:06:33 <dmsimard> jpena: "it lacks key functionality that Nova expects"
15:06:46 <dmsimard> I think something that comes back is around snapshots
15:07:03 <number80> dmsimard: in the past, compute folks had a very broad definition of key functionality ...
15:07:19 <dmsimard> qemu-kvm is usable with nova or we'd have done the switch much earlier
15:07:22 <jpena> dmsimard: yep, so that's my question. For general "release" cases, i.e. using centos-openstack-release-mitaka, we are already covered
15:07:56 <imcsk8> is there a list of funcionalities that are needed bit qemu-kvm don't deliver?
15:08:18 <jpena> we can make sure the rdo-release rpm includes it as well, so any supported RDO installation method will get qemu-kvm-ev anyway
15:08:29 <alphacc> (I think rbd support is disable too)
15:08:37 <dmsimard> jpena: well the idea is that really what we need is >= 2.3, not necessarily -ev
15:08:39 <number80> imcsk8: good question, there's no documentation on what qemu-kvm-ev provides
15:08:40 <dmsimard> fedora has >= 2.3
15:08:48 <dmsimard> centos and rhel does not, and thus needs an extra repo or channel
15:08:52 <number80> dmsimard: in practice, that's the same ...
15:09:13 <dmsimard> number80: but you're not going to add the virt sig repo on fedora, are you 6
15:09:15 <dmsimard> ?
15:09:21 <dmsimard> same with rhel
15:09:27 <number80> dmsimard: it wouldn't work
15:09:34 <dmsimard> right.
15:09:37 <number80> and Fedora has newer qemu-kvm
15:09:53 <dmsimard> so on fedora we don't do anything, centos we add the virt sig repo and on rhel we add a channel (?)
15:10:02 * dmsimard not very familiar with rhel
15:10:21 <jpena> dmsimard: that's it
15:10:59 <dmsimard> jpena: so my question - how does dlrn test the install ?
15:11:02 <jpena> my only concern is the centos case. If we use option 1 (rdo-release script) then update the openstack-nova spec, we need to make sure every RDO consumer (including Trunk) uses the rdo-release script
15:11:07 <number80> yes, Alan preferred that we just install Virt SIG repo everywhere as we should assume that RHEL has neither RHEV nor OSP channels available
15:11:09 <dmsimard> jpena: does the virt sig repo need to be installed ?
15:11:29 <adarazs> o/
15:11:34 <jpena> dmsimard: not now, but it would need to be installed if we go ahead
15:11:35 <number80> #chair adarazs
15:11:35 <zodbot> Current chairs: Duck adarazs chandankumar dmellado hrybacki imcsk8 jjoyce jpena jruzicka jschlueter number80 tosky weshay
15:11:36 <jschlueter> dmsimard: for RHEL qemu-kvm-rhev is available from the OSP channels
15:12:10 <dmsimard> jschlueter: that's so vague to me, because the bug cites that it is possible to get qemu-kvm (not rhev) when installing osp
15:12:16 <number80> jschlueter: one good point is that if you use RDO, you're likely not having OSP channels enabled
15:12:17 <dmsimard> is it in an extra channel or something ?
15:12:31 <weshay> jschlueter, that doesn't help RDO
15:13:04 <number80> the only case where it can be annoying is RHEL + RHEV channels enabled (as they're providing qemu-kvm-rhev)
15:13:05 <jpena> so RHEL+RDO would require enabling the CentOS virt SIG repo
15:13:11 <number80> yes
15:13:19 <weshay> jpena+
15:13:27 <dmsimard> right now the docs for rdo on rhel mention yum install rdo-release.rpm
15:13:39 <jjoyce> any security concerns on the RHEL side if you do that?
15:13:42 * jschlueter nods
15:13:56 <number80> I have a review ready for this => https://github.com/redhat-openstack/rdo-release/pull/6 (overlook the mitaka part, I have a newton version ready)
15:14:04 <dmsimard> jjoyce: well I don't think it'd be supported by Red Hat anyway, right ? only osp ?
15:14:14 <dmsimard> The /OS/ would be, but not the deployment ?
15:14:31 <jjoyce> dmsimard: ack
15:14:41 <jpena> dmsimard: that would be expected, after all you're installing RDO not OSP
15:14:41 <number80> jjoyce: considering that virt SIG folks are quite involved in qemu-kvm upstream, I think it's safe
15:15:11 <jjoyce> number80: That is good to know.
15:15:16 <number80> rationale is that we should leave that component being maintained by their experts
15:15:35 <dmsimard> my other concern was that I think we should do the switch for >= newton only, not mitaka due to the implications involved in (potentially) upgrading qemu 1.x to 2.x -- it goes a bit against the definition of a "stable" release
15:16:01 <number80> dmsimard: I'm fine for having it as a newton-only change
15:16:22 <jpena> +1
15:16:37 <Duck> +1
15:16:38 <jjoyce> +1
15:16:41 <number80> I did it on Mitaka to test if there were any issue like conflict with centos-release-*
15:16:50 <number80> +1 (too)
15:17:08 <dmsimard> We're +1'ing what, here ?
15:17:20 <number80> ok, let's start
15:17:33 <number80> Proposal: enable virt SIG repo in RDO Newton+
15:17:49 <dmsimard> For fedora, centos & rhel ?
15:18:13 <number80> dmsimard: in pratice, that's just centOS and RHEL, we're not supporting Fedora
15:18:30 <number80> Fedora is master only
15:18:50 <dmsimard> number80: yeah but I mean, someone can do yum install rdo-release on fedora
15:18:55 <dmsimard> :)
15:19:12 <number80> dmsimard: well, they'll be using RPM built on EL7 and it won't work
15:19:27 <number80> pretty much all crypto libs will be screaming for sure
15:19:48 <jpena> +rabbit, mariadb...
15:19:53 <dmsimard> ok, how about this formal proposal question then -- "Enable virt SIG repo in rdo-release for Newton+"
15:20:35 <number80> that's the same question
15:20:55 <dmsimard> it's a nit to include rdo-release :P
15:21:02 <jruzicka> in nice form
15:21:15 <number80> nm, let's continue
15:21:41 <number80> so let's restart the ovte
15:22:05 <number80> Proposal: enable virt SIG repo in rdo-release for Newton+
15:22:34 <dmsimard> +1
15:23:26 <jpena> +1
15:23:31 <chandankumar> +1
15:23:43 <imcsk8> +1
15:23:53 <dmsimard> need more votes, folks vote please :)
15:24:13 <hrybacki> +1
15:24:16 <adarazs> +1
15:24:30 <tosky> uhm, I don't know how much I'm qualified, but it looks like a sane decision
15:24:32 <tosky> +1
15:24:37 <number80> weshay, jjoyce, jschlueter, jruzicka ?
15:24:44 <weshay> +1
15:24:50 <jjoyce> +1
15:24:55 <jschlueter> +1
15:25:08 <jruzicka> +1
15:25:19 <number80> #agreed Enable virt SIG repo in rdo-release for Newton+ (+1: 12, 0: 0, -1: 0)
15:25:19 <jruzicka> I'm not aware about a reason not to, that is
15:25:41 <number80> ok, I'll push a new review for rdo-release newton
15:25:57 <jjoyce> Does rdo-release have any support from RHEL? If someone tries and install and they have issues can they call support?
15:26:07 <number80> #action number80 send a review to update rdo-release newton+
15:26:08 <dmsimard> jjoyce: not afaik.
15:26:25 <dmsimard> jjoyce: but it /should/ work
15:26:27 <number80> jjoyce: only community support
15:26:31 <jpena> #action jpena to update dlrn-deps.repo in dlrn newton workers to include virt SIG repo
15:26:40 <number80> jpena: good catch
15:26:47 <jpena> I just realized we need ^^ to have any chance of building stuff
15:26:56 <jpena> + it will solve the CI use case
15:27:07 <jjoyce> dmsimard number80: ack was curious
15:27:14 <dmsimard> jpena: more or less, I had a patch in flight to enable the repo
15:27:20 <dmsimard> jpena: but adding it to dlrn-deps makes sense too
15:27:20 <number80> jpena: then -W the nova review and remove -W when you're ok
15:28:04 <number80> ok, then next
15:28:19 <number80> #topic python-heat-agent review
15:28:25 <number80> https://review.rdoproject.org/r/#/c/1909
15:29:12 <number80> stevebaker has been working on refreshing heat packaging, and he has started a discussion on the list
15:29:31 <number80> https://www.redhat.com/archives/rdo-list/2016-August/msg00189.html
15:29:49 <dmsimard> I'm not very familiar with heat but my first thought when looking at that was that it seemed very tripleo-opinionated ?
15:30:22 <dmsimard> I can be proven wrong very easily, I'm just not knowledgeable -- it's just what it looked like to me at first glance
15:31:32 <number80> I think it's generic-enough to suit most needs
15:31:44 <number80> at least, I confirmed that it should not break existing scenarios
15:32:47 <number80> If people are not inspired, may I suggest that we set a deadline?
15:33:01 <number80> If there's no feedback, let's merge this next week
15:33:03 <jpena> it's just a new subpkg, isn't it? Worst thing that could happen is that the name is not 100% accurate
15:33:59 <number80> packaging-wise, it's low risk, I agree
15:34:09 <number80> ok
15:34:50 <number80> A. merge it  B. give it one more week for discussion
15:35:24 <number80> I don't think we should wait too much
15:35:25 <jpena> I'm pro-A
15:35:37 <number80> A > B
15:35:44 <jruzicka> so why consider B? :)
15:35:55 <chandankumar> changes looks good, i am not sure about the permissions.
15:36:09 <number80> jruzicka: for people who has valid concerns, but people are remaining mute over that topic
15:36:43 <dmellado> I'm pro-A as well, it can be always be modified later
15:36:57 <jruzicka> it's another package, is there something special about it in comparison to all the other ones?
15:37:12 * chandankumar goes for A.
15:37:39 <number80> nobody for B, last call?
15:38:16 <imcsk8> A
15:38:55 * tosky abstains this time
15:39:40 <number80> ok
15:39:46 <number80> let's merge this
15:39:50 <number80> #agreed merge stevebaker python-heat-agent change (+1: 6, 0: 1, -1: 1)
15:40:03 <number80> #action number80 work with stevebaker to merge his changes
15:40:19 <number80> #topic rdopkg new release
15:40:50 <number80> jruzicka: have you seen rdopiera request to ship a new rdopkg release with milestones support?
15:41:08 <jruzicka> oh yeah
15:41:10 <jruzicka> on that topic
15:41:17 <jruzicka> I'll release this one by hand
15:41:27 <number80> jruzicka: great :)
15:41:28 <jruzicka> (by a script that uses rdopkg to release rdopkg, whoooo)
15:41:43 <number80> rdopkg inception
15:41:48 <jruzicka> but I wonder what exactly needs to be done to have automatic releases
15:41:58 <number80> #action jruzicka to release a new version of rdopkg
15:42:04 <jruzicka> that involves changing rpmfactory project-config
15:42:20 <jruzicka> number80, then you mentioned something about CBS support
15:42:44 <number80> jruzicka: can you remind me what it was about?
15:43:18 <jruzicka> I don't remember myself :D
15:43:33 <number80> well, nm, if it is important, we'll remember later :)
15:43:41 <jruzicka> #action jruzicka to investigate rdopkg auto-releases using rpmfactory
15:44:18 <jruzicka> and that's it, rdopkg-0.39 hitting repos soonish :)
15:44:43 <number80> rdopiera: ^
15:44:46 <number80> great
15:45:50 <number80> #topic open discussion
15:45:57 <number80> any topic, you want to bring?
15:46:11 <number80> (you may have noticed that rbowen is at linuxcon this week)
15:46:16 <jpena> I have a quick question about tripleo-ui
15:46:17 <chandankumar> number80: chair call.
15:46:18 <dmsimard> jruzicka: random rdoinfo rambling
15:46:24 <number80> chandankumar: after that
15:46:35 <number80> jpena: yes?
15:46:39 <dmsimard> jruzicka: I wish this was less awkward https://github.com/openstack-packages/DLRN/blob/master/scripts/map-project-name
15:46:51 <jpena> is there a tripleo-ui-deps package or subpackage anywhere?
15:47:02 <jpena> I can't find it :?
15:47:21 <number80> jpena: yes, it is here => http://cbs.centos.org/koji/packageinfo?packageID=4136
15:47:44 * jruzicka looking
15:47:49 <jpena> ahhh ok, so we're not building it in dlrn
15:47:54 <number80> jpena: you need it in testing?
15:48:20 <jruzicka> dmsimard, you want easier project -> package mapping?
15:48:21 <number80> yes, it would mean hacking DLRN to have pre-configuration steps before building a package
15:48:22 <jpena> it's required by https://github.com/rdo-packages/tripleo-ui-distgit/blob/rpm-master/openstack-tripleo-ui.spec#L18, but for some reason dlrn can't find it
15:48:29 <jschlueter> when might an initial build of tripleo-ui rpm be available?
15:48:50 <jpena> jschlueter: as soon as we get https://review.rdoproject.org/r/1934 fixed
15:48:51 <dmsimard> jruzicka: yeah, it's harder than it should be to take whatever project name and get the rdoinfo name back
15:49:04 <number80> jpena: let me check DLRN mock config
15:49:09 <jpena> I mean https://review.rdoproject.org/r/1935, sorry
15:49:11 <jschlueter> jpena: cool
15:49:46 <dmsimard> jruzicka: we just had to create a new script that's almost the same thing but for non-distgit projects https://review.rdoproject.org/r/#/c/1933/
15:49:53 <jruzicka> #action jruzicka to provide nicer interface to rdoinfo in coordination with dmsimard
15:50:11 <jruzicka> dmsimard, yeah, it's ugly. I wasn't even sure rdoinfo will be used with all the changes
15:50:14 <jpena> number80: the tripleo-ui-deps package needs some tags, it's not in openstack-newton right now
15:50:53 <number80> jpena: yes, I checked that mock config only looks at tagged stuff
15:51:14 <jruzicka> since rdoinfo seems to be serving its purpose (human editable metadata), I'll gladly improve it in any way needed
15:51:20 * number80 tagged it in newton-testing
15:51:25 <jruzicka> dmsimard, so let's talk about this post-meeting in detail
15:51:33 <dmsimard> jruzicka: sure
15:51:43 <number80> jpena: the mistake was as it's a build dependency only, we shouldn't ship it but yeah, there's DLRN
15:51:55 <jpena> number80: ack, understood
15:52:11 <number80> ok, no other topic?
15:52:24 <number80> #topic next week chair
15:52:28 <number80> who wants it?
15:52:47 * chandankumar 
15:52:59 <number80> #info chandankumar is chairing next week meeting
15:53:01 <tosky> ehm, before we close
15:53:09 <tosky> quick update on openstack-sahara-tests,
15:53:10 <number80> tosky: go ahead
15:53:16 <tosky> which is https://bugzilla.redhat.com/show_bug.cgi?id=1318765 - the origin of jar files is mostly tracked, working on removing the one with questionable license; the trello card has a link to an etherpad with the progress
15:53:36 <number80> #topic openstack-sahara-tests update
15:53:53 <tosky> ups, should I retype the above?
15:53:54 <number80> https://bugzilla.redhat.com/show_bug.cgi?id=1318765
15:54:02 <number80> tosky: nope, it's fine continue
15:54:31 <number80> #info tosky is working on tracking jar files origin and removing the one with questionable licensing
15:54:55 <tosky> I think it's all; when the jar file above is fixed, and two sources are added, the sources of the others are all in place or in known locations
15:55:17 <number80> ok, ping us or put it in the agenda to move forward
15:55:19 <number80> tosk++
15:55:23 <number80> tosky++
15:55:44 <number80> Well, we're done
15:55:47 <chandankumar> number80: please have a look https://bugzilla.redhat.com/show_bug.cgi?id=1361581#c9
15:55:54 <number80> ack
15:56:00 <number80> #endmeeting