15:00:44 <chandankumar> #startmeeting RDO meeting - 2016-09-31
15:00:44 <zodbot> Meeting started Wed Aug 31 15:00:44 2016 UTC.  The chair is chandankumar. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:44 <zodbot> The meeting name has been set to 'rdo_meeting_-_2016-09-31'
15:00:45 <openstack> Meeting started Wed Aug 31 15:00:44 2016 UTC and is due to finish in 60 minutes.  The chair is chandankumar. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:49 <openstack> The meeting name has been set to 'rdo_meeting___2016_09_31'
15:00:59 <chandankumar> #topic roll call
15:01:02 <chandankumar> \o/
15:01:04 <trown> o/
15:01:07 <jruzicka> o/
15:01:07 <hrybacki> o/
15:01:10 <jpena> o/
15:01:15 <leifmadsen> \o
15:01:15 <apuimedo> \o/
15:01:21 <number80> o/ (nitpick we're still in august so 08-31)
15:01:37 <myoung> o/
15:01:41 <rbowen> o/
15:01:50 <pabelanger> hello
15:01:55 <leifmadsen> and there aren't 31 days in September either :)
15:02:04 <chandankumar> #chair trown number80 jruzicka jpena leifmadsen number80 myoung rbowen pabelanger
15:02:04 <zodbot> Current chairs: chandankumar jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown
15:02:33 <chandankumar> #chair hrybacki
15:02:33 <zodbot> Current chairs: chandankumar hrybacki jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown
15:02:46 <apevec> /o/
15:02:53 <rbowen> #chair apevec
15:02:53 <zodbot> Current chairs: apevec chandankumar hrybacki jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown
15:02:53 <chandankumar> #chair apevec
15:02:53 <zodbot> Current chairs: apevec chandankumar hrybacki jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown
15:02:56 <rbowen> :)
15:02:59 <chandankumar> dmellado: around?
15:03:02 <weshay> o/
15:03:09 <chandankumar> #chair weshay
15:03:09 <zodbot> Current chairs: apevec chandankumar hrybacki jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown weshay
15:03:18 <eggmaster> o/
15:03:25 <chandankumar> #chair eggmaster
15:03:25 <zodbot> Current chairs: apevec chandankumar eggmaster hrybacki jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown weshay
15:03:43 <chandankumar> wow! so many people!
15:03:53 <chandankumar> so starting with first topic.
15:04:03 <chandankumar> #topic tempest packaging
15:04:12 <apevec> that was for dmellado ^
15:04:28 <apevec> but there's also thread on rdo-list with the info
15:04:35 <chandankumar> dmellado: is in another meeting i think.
15:04:46 <dmellado> apevec: I'm not done with the meeting, sorry,
15:04:51 <dmellado> but I'll try to read around
15:04:53 <apevec> I think we definitely need to move -tests deps to new tempest-all as suggested
15:05:04 <number80> +1 to that personally
15:05:06 <apevec> ok, chandankumar can you summarize ?
15:05:08 <jpena> +1
15:05:12 <chandankumar> dmellado: has dropped a nice summary of current RDO packaging problems and solutions
15:05:23 <chandankumar> https://www.redhat.com/archives/rdo-list/2016-August/msg00240.html
15:05:27 <chandankumar> apevec: sure
15:05:29 <apevec> but I liked stevebaker's hack as workaround for in-tree plugins
15:05:40 <dmellado|mtg> +1
15:05:45 <apevec> we just need to make it simpler (put in rdo-rpm-macors?)
15:06:06 <number80> *nods*
15:06:18 <apevec> and also continue to push upstream project to move tempest plugins to separate git,
15:06:22 <apevec> even when they say NO :)
15:06:35 <Duck> quack o/
15:06:35 <chandankumar> In current tempest packaging, tempest install all the test plugins.
15:06:36 <apevec> dmellado|mtg, ^ would that be too rude :)
15:06:49 <rdogerrit> Merged rdoinfo: Enable magnum and mistral horizon plugins  http://review.rdoproject.org/r/1991
15:06:54 <chandankumar> There are some solutions proposed to handle plugins issues:
15:06:56 <apevec> chandankumar, yep, and that's bad, b/c tempest is now also a library
15:07:07 <apevec> tempest-lib is deprecated
15:07:17 <chandankumar> Integrate back the -test packages for entry plugins
15:07:37 <apevec> that would be only -tests-tempest, if decided
15:07:45 <apevec> but not needed w/ stevebaker's hack
15:07:51 <chandankumar> yes
15:08:08 <chandankumar> Another solution is removing tempest as a requirements for out of tree plugins
15:08:09 <dmellado|mtg> how would you track int-tree
15:08:13 <dmellado|mtg> in-tree plugins
15:08:26 <number80> No, unless it
15:08:30 <number80> 's temporary
15:08:49 <imcsk8_> o/
15:08:52 <chandankumar> currently we have i think 3 out of tree plugins : sahara horizon and designate i think
15:08:57 <chandankumar> #chair imcsk8_
15:08:57 <zodbot> Current chairs: apevec chandankumar eggmaster hrybacki imcsk8_ jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown weshay
15:08:57 <apevec> tempest can't be removed as a req
15:09:06 <apevec> it's also a library
15:09:09 <trown> #chair Duck
15:09:09 <zodbot> Current chairs: Duck apevec chandankumar eggmaster hrybacki imcsk8_ jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown weshay
15:09:17 <coolsvap> o/
15:09:20 <apevec> trown is back! welcome!
15:09:26 <trown> thanks :)
15:09:30 <chandankumar> #chair coolsvap
15:09:30 <zodbot> Current chairs: Duck apevec chandankumar coolsvap eggmaster hrybacki imcsk8_ jpena jruzicka leifmadsen myoung number80 pabelanger rbowen trown weshay
15:09:33 * Duck :-)
15:09:35 <jpena> apevec: at least, it could be removed as a runtime requirement, couldn't it?
15:09:52 <apevec> not really, plugins import parts of tempest
15:10:06 <number80> jpena: if we do that, there's no value to package them, just use plain git install
15:10:08 <apevec> that was previously tempest-lib but it has been integrated back into tempest
15:10:27 <apevec> workaround is to tempest-all subpackage
15:10:38 <chandankumar> apevec: yes that was the third proposal
15:10:40 <jpena> mmm ok, if we move the dependencies to tempest-all it would still be ok
15:10:40 <apevec> but that needs CI jobs change
15:10:52 <apevec> or we subpackge python-tempest
15:11:13 <apevec> leaving main tempest meta package pulling all -tests as it is now ?
15:11:23 <apevec> then tempest plugins depend on python-tempest
15:11:42 <number80> both works for me, we just need to agree and stick to one roadmap
15:11:51 <apevec> still need to think about upgrade path
15:11:57 <apevec> number80, ack
15:12:20 <jpena> that last option (using python-tempest) looks like a better idea
15:12:24 <number80> apevec: it will require fixing CI tools anyway, so I'd rather let CI folks choose their preferred method
15:12:51 <chandankumar> i think weshay has a better answer on CI side.
15:12:55 <jpena> number80: if we keep openstack-tempest as a metapackage, there's no change required in CI I think
15:13:05 <apevec> jpena, yeah, thinking more, I agree with that
15:13:11 <apevec> jpena, yep
15:13:24 <apevec> and upgrade path is fine, we just need coordinated update of -tests-tempest
15:13:27 <number80> jpena: they still need to fix their tooling, as they don't use tempest from package but install it with pip ...
15:13:31 <dmellado|mtg> +1 on metapackage
15:13:48 <apevec> number80, yep but that's separate
15:14:05 <weshay> ya.. both ways are avail to ci.. pkg or pip
15:14:49 <apevec> what we're fixing is that installing single -tests-tempest you end up with all tempest plugins you didn't want, via openstack-tempest dep :)
15:15:16 <apevec> alright, actions/info time?
15:15:35 <apevec> chandankumar, can you look at python-tempest change?
15:15:41 <chandankumar> apevec: sure
15:16:10 <apevec> I'll take action to review and try to simplify stevebaker hack
15:16:14 <jschlueter> o/
15:16:24 <number80> ack
15:16:24 <chandankumar> #chair jschlueter
15:16:24 <zodbot> Current chairs: Duck apevec chandankumar coolsvap eggmaster hrybacki imcsk8_ jpena jruzicka jschlueter leifmadsen myoung number80 pabelanger rbowen trown weshay
15:16:31 <chandankumar> action items here?
15:16:34 <apevec> #action apevec  review and try to simplify egg-info mangling for -tests-tempest
15:16:42 <apevec> chandankumar, add one for yourself :)
15:17:05 <chandankumar> #chair chandankumar to take a look at python-tempest changes
15:17:05 <zodbot> Current chairs: Duck a apevec at chandankumar changes coolsvap eggmaster hrybacki imcsk8_ jpena jruzicka jschlueter leifmadsen look myoung number80 pabelanger python-tempest rbowen take to trown weshay
15:17:16 <chandankumar> #undo
15:17:16 <zodbot> Removing item from minutes: ACTION by apevec at 15:16:34 : apevec  review and try to simplify egg-info mangling for -tests-tempest
15:17:19 <jpena> lol
15:17:23 <apevec> oops
15:17:33 <apevec> can't undo chairs :)
15:17:36 <apevec> #action apevec  review and try to simplify egg-info mangling for -tests-tempest
15:17:51 <chandankumar> #action chandankumar to take a look at python-tempest changes
15:17:52 <dmellado|mtg> apevec: count me on for there to review
15:17:52 <number80> #unchair a at changes take to
15:17:52 <zodbot> Current chairs: Duck apevec chandankumar coolsvap eggmaster hrybacki imcsk8_ jpena jruzicka jschlueter leifmadsen look myoung number80 pabelanger python-tempest rbowen trown weshay
15:18:06 <number80> #unchair python-tempest look
15:18:07 <zodbot> Current chairs: Duck apevec chandankumar coolsvap eggmaster hrybacki imcsk8_ jpena jruzicka jschlueter leifmadsen myoung number80 pabelanger rbowen trown weshay
15:18:30 <chandankumar> we need to discuss about tempest config tool.
15:18:37 <dmellado|mtg> about the tempest config tool
15:18:42 <dmellado|mtg> I do propose to have it in its own repo
15:18:49 <apevec> yes! please!
15:18:50 <dmellado|mtg> so it could be decoupled form downstream tempest
15:18:59 <dmellado|mtg> and we could get rid of that
15:19:01 <apevec> and no tempest fork anymore
15:19:05 <dmellado|mtg> +1
15:19:08 <chandankumar> +1
15:19:09 <apevec> thank you thank you thank you
15:19:10 <dmellado|mtg> will keep it for now as deprecated
15:19:40 <apevec> can we do this for newton?
15:19:50 <dmellado|mtg> apevec: there's no time for OSP10, tbh
15:19:50 <chandankumar> dmellado|mtg: does decoupling the tempest config tool change the user experience who are consuming the forked tempest rpm?
15:19:53 <dmellado|mtg> but for OSP11 yep
15:19:55 <apevec> (get rid of tempest fork)
15:20:00 <dmellado|mtg> I mean, ocata
15:20:04 <apevec> RDO Newton  you mean
15:20:18 <dmellado|mtg> RDO Newton, yep
15:20:18 <eggmaster> apevec: the midstream repo would still be needed for the RHOS support window use case, iykwim
15:20:24 <dmellado|mtg> there's a feature freeze this week
15:20:32 <dmellado|mtg> and in order to avoid having issues with the plugins later
15:20:36 <apevec> eggmaster, please don't mention "midstream" :)
15:20:38 <dmellado|mtg> I'll be feature freezing the downstream
15:20:41 <dmellado|mtg> to get rid of it asap
15:20:51 <eggmaster> apevec: mea culpa
15:20:54 <dmellado|mtg> but I wouldn't count on it for newton
15:21:06 <apevec> also community doesn't care about downstream support windows
15:21:13 <apevec> we follow upstream lifecycle
15:21:39 <dmellado|mtg> apevec: also, the tempest config tool, I'm trying for it to be integrated later on to refstack
15:21:48 <eggmaster> apevec: I'm done mentioning it but I thought it should be mentioned.
15:21:49 <dmellado|mtg> the 1st step is to decouple it
15:22:18 <apevec> dmellado|mtg, agreed, repo at redhat-openstack should be temporary
15:22:21 <eggmaster> b/c that (in addition to the config script) was one of the reasons we have redhat-openstacl/tempest
15:23:03 <apevec> chandankumar, can you put summary as #info re. config tool?
15:23:20 <dmellado|mtg> yep, hold on
15:24:44 <chandankumar> #info config tool can be decoupled from redhat-openstack/tempest in ocata release cycle,
15:25:03 <jruzicka> \o/
15:26:17 <chandankumar> #info decoupling tempest config tool will help to consume in refstack in future.
15:26:26 <chandankumar> apevec: that will work?
15:26:36 <apevec> dmellado|mtg, ^ will tell
15:26:49 <apevec> not sure about refstack
15:27:06 <apevec> iiuc, refstack will be eventual home for tempest config ?
15:27:44 <apevec> dmellado|mtg, ^ please ack or undo
15:27:54 * chandankumar waits.
15:27:57 <apevec> anything else left on this topic? we need to  move on
15:28:11 <chandankumar> apevec: nothing we can move to different topic
15:28:17 <dmellado|mtg> apevec: ack
15:28:21 <dmellado|mtg> but it'll take some time
15:28:26 <dmellado|mtg> so we need to get those steps before
15:28:37 <apevec> ack
15:28:41 <apevec> next topic!
15:28:42 <chandankumar> #topic shade distribution
15:29:12 <chandankumar> Here is the rdo thread about python-shade in RDO https://www.redhat.com/archives/rdo-list/2016-August/msg00213.html
15:29:34 <chandankumar> number80: you can go ahead.
15:30:00 <apevec> oh no -1 for "RDO Common" which I liked :)
15:30:43 <number80> apevec: conflicts with already existing -common tag
15:31:03 <jpena> would this repo be for clients+SDK only, or in general for projects without a stable lifecycle?
15:31:23 <apevec> for all which have master only imho
15:31:25 <number80> back to topic, we've had no way to ship SDK + latest clients and few more stuff like rally, tempest
15:31:47 <number80> so we need a separate repo for such use-cases
15:31:54 <chandankumar> Proposal: ship latest openstack clients + SDK in a separate repository (proposed name: rdo-extras)
15:32:10 <chandankumar> number80: has proposed it.
15:32:33 <number80> -1 to extras name as Grame had legit reasons against it
15:32:34 <apevec> it was pointed out "extras" might be bad name, so naming (hard!) suggestions are welcome
15:32:56 <apevec> what about "RDO Tools" ?
15:33:08 <number80> wfm
15:33:21 <leifmadsen> +1
15:33:24 <chandankumar> +1
15:33:27 * jruzicka thinking
15:33:35 <leifmadsen> or... contrib?
15:33:51 <trown> rdo-independent?
15:33:57 <jruzicka> if the criteria is "anything with master only", then not sure Tools cuts it
15:33:57 <leifmadsen> rdo-potpourri
15:34:01 <apevec> rdo-July4th
15:34:03 <dmellado> rdo_tools
15:34:05 <dmellado> +1
15:34:06 <imcsk8_> XD
15:34:10 <number80> leifmadsen: same as extras, it gives the impression of being a second-class citizen repo
15:34:16 <trown> rdo-release-agnostic
15:34:27 <leifmadsen> rdo-allthethings_butnotthosethings
15:34:38 * leifmadsen isn't helping...
15:34:39 <chandankumar> leifmadsen: too long name!
15:34:40 * number80 notes that clients are not release agnostic but they will be tagged into it
15:34:53 <imcsk8_> rdo-naming-this-is-hard
15:34:55 <jruzicka> I got nothing better then tools
15:34:56 <myoung> rdo-morsels
15:34:57 <leifmadsen> rdo-extended ?
15:35:15 <dmellado> lol
15:35:33 <jruzicka> rdo-mastery
15:35:35 <jruzicka> :D
15:35:38 <imcsk8_> hehe
15:35:43 <leifmadsen> rdo-shedpaint
15:35:43 <jpena> rdo-userland
15:35:43 <rbowen> Could spend all day on picking names, though.
15:35:44 <chandankumar> what about asking for naming suggestions on ML and then go for voting?
15:35:44 * number80 fine with anything that doesn't give off the wrong impession this is a second-class repo
15:35:50 <jruzicka> all right, all right
15:35:52 <leifmadsen> chandankumar: +1
15:36:13 <myoung> that sounds rational.  +1
15:36:14 <jruzicka> let's default to rdo-tools onless someone figures out something better until next meeting
15:36:24 <number80> +1
15:36:25 <apevec> +1
15:36:27 <imcsk8_> +1
15:36:28 <trown> rdo-tools wfm
15:36:31 <leifmadsen> +1
15:36:33 <leifmadsen> NEXT!
15:36:33 <dmellado> +1
15:36:53 <chandankumar> action items here?
15:37:27 <leifmadsen> running to the dentist... bai! :)
15:37:41 <imcsk8_> good luck!
15:37:42 <jruzicka> oh bai
15:37:47 <leifmadsen> just a cleaning luckily
15:38:45 <chandankumar> apevec: do we need to take it to ML?
15:39:50 <apevec> I can update the thread with the summary
15:40:18 <jruzicka> let's move on
15:40:20 <apevec> #action apevec to update rdo-list thread about rdo-tools
15:40:27 <chandankumar> apevec: Thanks :-)
15:40:32 <chandankumar> moving to next topic
15:40:43 <chandankumar> #topic python3 support
15:40:57 <chandankumar> apuimedo: you can go ahead.
15:41:06 <apuimedo> chandankumar: thanks!
15:41:08 <rdogerrit> rdo-trunk created openstack/swift-distgit: openstack-swift: failed to build dd30b9e  http://review.rdoproject.org/r/1994
15:41:32 <apuimedo> As part of OpenStack Kuryr's integration with Kubernetes, we have one component that is python3 only
15:41:47 <apuimedo> I'm currently working on its packaging for rdo
15:42:16 <apevec> which component is py3 only?
15:42:19 <apuimedo> it is my current understanding that on Fedora 24 RDO can use python 3.5 to build packages
15:42:23 <apuimedo> apevec: the Kuryr watcher
15:42:26 <apuimedo> it is asyncio based
15:42:48 <apuimedo> it connects to the RDO API server and gets chunked data transfers
15:43:00 <apuimedo> and translates them to Neutron commands
15:43:07 <rdogerrit> rdo-trunk created openstack/nova-distgit: openstack-nova: failed to build b32f3d2  http://review.rdoproject.org/r/1995
15:44:18 <apuimedo> so I would like to know what are the plans for rdo on centos
15:44:18 <apevec> hmm, but we don't have py3 on EL7
15:44:21 <apuimedo> for python 3.5
15:44:37 <apuimedo> :/
15:44:46 <apevec> so that watch will need to use py3.5 SCL
15:44:52 <apevec> watcher
15:45:00 <apuimedo> I know, that's why I'm asking if there is some way that the packaging for #rdo can use SCL
15:45:01 <apevec> number80, fun ^
15:45:14 <apuimedo> or it needs to be distributed separately
15:45:15 <apevec> it could, there's SCL SIG
15:45:34 <apevec> but we'll need to setup new CBS target I think
15:46:07 <apuimedo> apevec: I assume there is no precedent, is there?
15:46:31 <apuimedo> and that would probably mean do the legwork for oslo and neutron deps as well
15:46:32 <rdobot> [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-newton-current @ http://tinyurl.com/gud2vup |#| Build failure on centos7-master/current: swift: http://trunk.rdoproject.org/centos7-master/report.html
15:46:43 <apevec> apuimedo, what are deps of watcher ?
15:47:00 <apevec> you need to have them all rebuilt in SCL
15:47:32 <apuimedo> oslo.{concurrency,log,config}, python-neutronclient
15:47:39 <number80> problem with SCL, is that we need to enable it in the build system ...
15:47:40 <apuimedo> and kuryr-lib
15:48:12 <apuimedo> number80: apevec: Is it completely out of the question to finally bring python3 to EL7?
15:48:16 <apevec> number80, as separate build target right?
15:48:26 <number80> apevec: yes ...
15:48:27 <apuimedo> or just out of our ruling?
15:48:40 <apevec> apuimedo, it is, that's baseOS decision which won't happen in minor update
15:48:40 <number80> apuimedo: it's just difficult topic to solve
15:48:54 <apuimedo> I know
15:49:06 <number80> quickest way would be to add python35 build but there are pros and cons
15:49:06 <apevec> SCL is "recommended" way
15:49:07 <apuimedo> I tried to investigate a bit
15:49:13 <apevec> number80, nope for RDO
15:49:36 <number80> then, it's SCL and separate build target
15:49:57 <apuimedo> got it
15:50:01 <apevec> yeah... not fun, but no other way around it
15:50:07 <number80> (and fixing all spec files)
15:50:27 <apuimedo> when I get to it I'll have to ask around for quite a bit of help
15:50:41 <dmellado> apuimedo: feel free to ;)
15:50:42 <apuimedo> I didn't check SCL in two years
15:50:45 <number80> then I suggest that we postpone action to ocata cycle
15:50:46 <apuimedo> another question
15:51:09 * chandankumar reminds we have 10 mins left and we have 3 more topics.
15:51:16 <apuimedo> ok, last question
15:51:24 <apevec> the wrench: I see only sclo7-python33-rh-el7  in CBS :(
15:51:26 <apuimedo> do we have a container registry?
15:51:36 <apevec> need to work with SCL SIG to get python35
15:51:46 <apuimedo> that we can use to have rdo OSt services containerized?
15:51:53 <number80> http://cbs.centos.org/koji/packageinfo?packageID=2504 <- apevec
15:51:55 <apevec> apuimedo, we have not really touched containers in RDO, but we should
15:51:56 <apuimedo> apevec: very well
15:52:02 <number80> apuimedo: no
15:52:09 <dmellado> that'd come in handy for tempest too
15:52:10 <apuimedo> apevec: we're in the process of getting kolla support too
15:52:15 <apuimedo> so I was wondering...
15:52:17 <apevec> centos has docker registry afaik
15:52:30 <apuimedo> and I usually only want to run that python 3.5 watcher inside a container
15:52:44 <apuimedo> so it would go long ways towards giving us a temporary solution
15:52:45 <number80> apuimedo: build system support of containers is still very new, and out of our direct scope
15:52:57 <apuimedo> number80: ok
15:53:12 <dmellado> should we bring this to the ML
15:53:14 <apevec> number80, but there is working containers pipeline in centos?
15:53:15 <dmellado> we're out of time almost
15:53:18 <apuimedo> sorry for taking up so much time from the meeting chandankumar
15:53:27 <apuimedo> that was all
15:53:35 <chandankumar> Any action items here?
15:53:48 <number80> apevec: there are bits, but some are not yet there, that needs concertation w/ kbsingh and bstinson
15:53:48 <apevec> to be continued on the rdo-list
15:53:54 <apuimedo> chandankumar: I guess talk to the scl sig
15:54:03 <apuimedo> and check the centos container registry
15:54:19 <apevec> apuimedo, yes, python35 scl is a blocker, let's check with scl folks that first
15:54:29 <chandankumar> #action apuimedo to talk to SCL sig for python35
15:54:29 <apuimedo> thanks apevec!
15:54:34 <number80> python35 scl is built
15:54:49 <apuimedo> yes, not a lot of packages, but it is built
15:55:03 <apevec> number80, ok, but no build target ?
15:55:04 <number80> and we need to build all that is in common ...
15:55:21 <number80> apevec: we have to request them with custom buildroot to add scl bits
15:55:53 <apevec> ah it's -rh-release - what does that mean?
15:56:00 * chandankumar reminds we have 5 mins left!
15:56:09 <apevec> ok, let's move on
15:56:19 <rbowen> chandankumar: my items do not require discussion.
15:56:19 <chandankumar> moving to next topic
15:56:24 <number80> yeah ...
15:56:33 <rbowen> Newton milestone 3 is this week, and so test day is next week, pending promotions: https://www.rdoproject.org/testday/newton/milestone3/
15:56:33 <rbowen> If you will be at OpenStack Summit, and wish to give a demo: https://etherpad.openstack.org/p/rdo-barcelona-summit-booth
15:56:37 <rbowen> That's the whole story.
15:56:51 <rbowen> So feel free to skip to the next
15:57:01 <chandankumar> rbowen: Thanks :-)
15:57:06 <chandankumar> #topic oooq images
15:57:26 <chandankumar> There is a query dropped on "Does the RDO community want oooq images created and stored w/ a delorean hash that has not been validated by the tripleo periodic jobs?"
15:58:03 <apevec> myoung, ^ is that yours?
15:58:34 <apevec> (see at the top of etherpad Note: Please add your IRC nick against your meeting agenda :)
15:58:38 <trown> I guess that is related to https://review.gerrithub.io/289662
15:58:45 <trown> weshay: ^
15:59:19 <myoung> apevec: weshay, though I'm quite interested, and think we need a vote
15:59:33 <apevec> I'm missing background info
15:59:40 <weshay> it's mine
15:59:44 <apevec> can you explain?
16:00:08 * chandankumar reminds we are running out of time!
16:00:21 <weshay> skip it.. will ask on list
16:00:31 <apevec> ack
16:00:31 <weshay> I already have a review out to enable it.. not a big deal
16:00:36 <chandankumar> weshay: Thanks ;-)
16:00:55 <chandankumar> we are moving File server for RDO community being discussed to next meeting if it is ok?
16:00:55 <apevec> let's just pase rbowen's FYI items as #info
16:01:02 <apevec> paste
16:01:05 <weshay> ack
16:01:09 <rbowen> #info Newton milestone 3 is this week, and so test day is next week, pending promotions: https://www.rdoproject.org/testday/newton/milestone3/
16:01:15 <rbowen> #info If you will be at OpenStack Summit, and wish to give a demo: https://etherpad.openstack.org/p/rdo-barcelona-summit-booth
16:01:31 <apevec> thanks, so it ends up in meeting minutes :)_
16:01:38 <chandankumar> #topic chair for next meeting
16:01:58 <chandankumar> Anyone up for that?
16:02:06 <trown> I can take it
16:02:12 <chandankumar> #action trown to chair for next meeting
16:02:19 <chandankumar> #endmeeting