15:08:26 <apevec> #startmeeting RDO packaging meeting (2015-04-29)
15:08:26 <zodbot> Meeting started Wed Apr 29 15:08:26 2015 UTC.  The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:33 <apevec> #chair jruzicka aortega number80 rbowen
15:08:33 <zodbot> Current chairs: aortega apevec jruzicka number80 rbowen
15:08:39 <apevec> #topic roll call
15:08:42 <apevec> o/
15:08:44 <rbowen> .oO( Present )
15:08:46 <eggmaster> o/
15:08:50 <chandankumar> o/
15:09:22 <jruzicka> o/
15:09:26 <number80> apevec: o/
15:10:18 <apevec> #topic test day
15:10:29 * kashyap waves
15:10:34 <apevec> so we have dates, May 5-6 next week
15:10:45 <apevec> trello card tracking prep is https://trello.com/c/w1UkNChb/55-test-day-kilo-rc-ga
15:11:01 <apevec> we'll have rdo-management too
15:11:27 <apevec> and I should have properly signed RDO Kilo "core" repo by then
15:11:53 <number80> could we get doc few days ahead so we could help with rdo-management testing effectively ?
15:12:00 <apevec> I've most CBS builds done, now checking dep updatets, repoclosure etc.
15:12:20 <apevec> number80, I think rbowen got promised that
15:12:26 <apevec> rbowen, do we have a link?
15:12:30 <rbowen> The RDO-manager docs are being actively worked on. hewbrocca is on that.
15:12:47 <rbowen> https://www.rdoproject.org/RDO_test_day_Kilo is the test day doc. I don't have a link to the rdo-manager docs yet, but it will be linked from that page soon.
15:12:52 <apevec> rbowen, I think they also wanted subdomain under rdoproject.org
15:13:07 <apevec> rbowen, jcoufal will probably ask you about it
15:13:11 <rbowen> Yes, I created docs.rdoproject.org which will have that content once there is some.
15:13:18 <apevec> cool
15:13:26 <rbowen> Although, the name is kind of generic, so I'm not sure how well that works.
15:13:27 <jcoufal> apevec: yup, already discussed
15:13:30 <jcoufal> rbowen: thanks!
15:13:35 <rbowen> But we'll figure it out. :)
15:14:19 <apevec> rbowen, right, site refactoring can part of site conversion to git
15:14:49 <rbowen> Yes. And that's scheduled for shortly after OpenStack Summit, when things are slightly quieter.
15:14:54 <apevec> ack
15:15:07 <apevec> back to test day prep: I propose to do quick big triage what was reported against RC2 snapshot
15:15:14 <jruzicka> rbowen, did you mean https://www.rdoproject.org/Docs ? :)
15:15:22 <jruzicka> very nice ;)
15:15:33 <apevec> I've copied summaries to the etherpad
15:15:54 <apevec> of what was reported on rdo-list
15:15:55 <rbowen> When I say "I created" I just mean I made a DNS record. It is pointing at the main site, so there's nothing different there than we've already had before.
15:16:35 <apevec> #topic RC2 bug triage
15:16:37 <apevec> #info "compute_nodes"  in nova database appeared to be empty up on completion
15:16:56 <apevec> ^ any Nova folks how can  comment?
15:17:09 <apevec> RC2 did pass CI so I'm not sure what happened
15:17:23 <apevec> CI (packstack installation + tempest smoke testsuite)
15:17:26 <kashyap> apevec: Bug URL for that?
15:17:44 <jruzicka> possibly ndipanov? ^
15:17:48 <apevec> kashyap, yeah, just noticed bz# is missing, it was only reported on rdo-list
15:17:53 <apevec> lemme find thread
15:17:56 * kashyap looks
15:18:53 <apevec> looks like compute doesn't get registered
15:19:03 <jcoufal> mmagr: where did you write me about the rdo-management github?
15:19:08 <jcoufal> I cannnot find your user
15:19:46 <mmagr> jcoufal, oh yes, sorry: paramite
15:19:54 <ndipanov> apevec, there was some refactoring around that so not impossible that it got borked
15:20:00 <ndipanov> got bz number?
15:20:29 <jcoufal> mmagr: try now
15:20:39 <apevec> kashyap, ndipanov - nope, all I have is https://www.redhat.com/archives/rdo-list/2015-April/msg00248.html
15:20:58 <apevec> kashyap, can you reply there asking for details/bz ?
15:21:00 <mmagr> jcoufal, nope, still not there: https://github.com/orgs/rdo-management/people
15:21:10 <kashyap> apevec: Will do.
15:21:33 <apevec> thanks
15:21:36 <apevec> next:
15:21:39 <apevec> #info Horizon permission denied error, old bug: https://bugzilla.redhat.com/show_bug.cgi?id=1150678   => mrunge cannot reproduce
15:21:41 <kashyap> ndipanov: I'll add you to CC to that bug. So you can take a look when you can.
15:21:49 <jcoufal> mmagr: try your e-mail
15:21:54 <apevec> mrunge, ^ still no news?
15:21:56 <jcoufal> mmagr: you might need to accept the invitation
15:21:58 <ndipanov> apevec, doesn't look good tbh
15:22:06 <mmagr> ah right
15:22:16 <ndipanov> and might actually be a legit issue
15:22:28 <apevec> ndipanov, this was rc2 - was there related fixes in rc3 ?
15:22:30 <ndipanov> the right person to look at it would be sylvain
15:22:37 <ndipanov> but he's not on this channel
15:22:54 <jcoufal> mmagr: you are there
15:22:54 <apevec> ndipanov, ok, we'll follow up in bz
15:23:08 <jcoufal> jruzicka: btw, any progress with the backport?
15:23:25 <ndipanov> apevec, bauzas is here
15:23:28 <mmagr> jcoufal, ok great, I'm there thanks, can you please create a team called 'puppet' for me with admin rights so I can create repos there?
15:23:34 <ndipanov> mind re-pasting the bug details
15:23:38 <bauzas> ndipanov: apevec: aloha
15:24:07 <apevec> bauzas, hi, sorry we don't have much details, it was only report on rdo-list https://www.redhat.com/archives/rdo-list/2015-April/msg00248.html
15:24:21 <jcoufal> mmagr: there are puppeteers
15:24:23 <jcoufal> can you be part of them?
15:24:38 <apevec> bauzas, kashyap will followup and ask for details in BZ
15:24:40 <bauzas> apevec: I'm missing contrext
15:24:48 <mmagr> jcoufal, sure if members will be able to create repos :)
15:25:07 <apevec> bauzas, with Kilo RC2, "compute_nodes"  in nova database appeared to be empty up on completion
15:25:12 <apevec> see that post
15:25:17 <apevec> that's all we have ATM
15:25:20 <bauzas> apevec: yeah that's what I'm reading
15:25:29 <jcoufal> mmagr: yup
15:25:41 <jcoufal> mmagr: you should ask EmilienM though
15:25:48 <jcoufal> he is lead of that group
15:26:07 <ndipanov> bauzas, seems like your disconeect the service from compute node could have caused this
15:26:13 <mmagr> jcoufal, ack
15:26:28 <apevec> bauzas, not sure details about their setup, we also know that RC2 passed CI so at least in some cases it does work...
15:26:36 <bauzas> ndipanov: yeah I'm just wondering why it breaks, because we fixed the bugs
15:26:56 <ndipanov> well that and paul's hack
15:27:06 <ndipanov> er refactoring
15:27:09 <ndipanov> looking at the RT code
15:27:21 <apevec> I'll refresh snapshot with RC3 once I get trunk.rdo unblocked
15:27:24 <ndipanov> if we can't find the service based on the compute node lookup
15:27:29 <apevec> derekh, ^ BTW no ssh again...
15:27:31 <ndipanov> we bail and never create the record
15:27:37 <ndipanov> how did that slip in :/
15:28:24 <derekh> apevec: ack, will ask dprince to see if he can find anything info on the console
15:28:30 <apevec> ndipanov, so RC3 won't help?
15:28:52 <bauzas> ndipanov: that just means the service is not found when looking at the database by the host name
15:29:03 <derekh> apevec: hmm, he isn't around, mailing
15:29:09 <ndipanov> apevec, actually it might not be a bug for everyone
15:29:29 <bauzas> ndipanov: but self.host is given by the hypervisor
15:29:35 <apevec> ndipanov, definitely the cases, as I said it work in CI setup
15:29:58 <bauzas> ndipanov: when the compute manager is starting
15:29:58 <ndipanov> yeah - so taht guy gets a different hostname from libvirt and python
15:30:07 <bauzas> ndipanov: that's my thoughtds
15:30:07 <apevec> man, much bad grammar
15:30:23 <ndipanov> there was a bug around this before
15:30:24 <bauzas> ndipanov: but that's strange
15:30:39 <bauzas> ndipanov: because 'compute1' is the name
15:31:05 <bauzas> ndipanov: so I'm looking into objects.Service.get_by_compute_host
15:31:13 <ndipanov> bauzas, that's the name Service gets
15:31:28 <apevec> ndipanov, bauzas, ok, let's take it to BZ which kashyap will create, need to move on to other reported bugs
15:31:40 <apevec> #info openstack-nova-novncproxy service fails to start: https://bugzilla.redhat.com/show_bug.cgi?id=1200701 => RDO Juno updated, Nova spec needs versioned dep
15:32:03 <bauzas> ndipanov: there is no reason that the DB shouldn't find the entry
15:32:06 <kashyap> apevec: I asked Boris to file one on the list, since he seems to have the env.
15:32:14 <apevec> kashyap, thanks
15:32:26 <ndipanov> bauzas, CONF.host is what it gets defaulted to
15:32:40 <ndipanov> so if compute service gets something else - it can happen
15:33:14 <bauzas> ndipanov: mmm, it explicitely checks self.host, and the log says it's "compute1"
15:33:15 <apevec> so websockify is updated in hte repo, we just need versioned dep in openstack-nova to ensure upgrade
15:33:30 <apevec> last one:
15:33:33 <apevec> # neutron-lbaas-agent  fails to start
15:33:38 <apevec> #info neutron-lbaas-agent  fails to start
15:33:40 <jcoufal> jruzicka: somewhere around?
15:33:48 <apevec> #info fixed in Neutron RC3
15:34:11 <apevec> that's all I've found reported on the list, was there anything else I missed?
15:34:15 <apevec> itzikb, ^
15:34:43 <jruzicka> jcoufal, yeah but now is meeting. Unless it's relating to current topic, please wait till it's over.
15:34:53 <jcoufal> jruzicka: ah, sorry
15:35:29 <itzikb> apevec: sorry was in a meeting
15:35:30 <apevec> I think we're done with bug triage here, to be continued in BZ or later on irc
15:35:56 <apevec> itzikb, np, just asking if there was more issues reported against RC2 after your post?
15:36:09 <itzikb> apevec: I need to send and update
15:36:14 <apevec> itzikb, I summarized rdo-list reports inhttps://etherpad.openstack.org/p/RDO-Packaging
15:36:18 <ndipanov> bauzas, yeah
15:36:23 <ndipanov> seems like it should work
15:36:29 <apevec> itzikb, ok, reply on your post
15:36:39 <bauzas> ndipanov: agreed, because the object is calling the conductor which checks DB
15:36:42 <apevec> let's move to the next topic
15:36:42 <itzikb> apevec: ok will do
15:36:50 <apevec> #topic distrepos @ rdoinfo
15:36:55 <ndipanov> and the self.host is passed in my the service
15:37:00 <ndipanov> so it's the same value
15:37:04 <bauzas> ndipanov: because RT runs on the compute side
15:37:07 <apevec> jruzicka, ^ floor is yours, please explain yourself :)
15:37:17 <bauzas> ndipanov: but it passes the correct value
15:37:29 <apevec> #link https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml#L29
15:38:01 <apevec> jruzicka, what's the question about distrepos?
15:38:11 <bauzas> ndipanov: so the only way that is can't work is that db.sqla.service_get_by_compute_host() doesn't get a row
15:39:09 <apevec> jruzicka, there?
15:40:40 <jruzicka> oh, back
15:40:41 <jruzicka> sorry
15:41:16 <apevec> jruzicka, current info in rdo.yml looks good to me, is there some concern?
15:41:25 <jruzicka> yeah so I need us to fill the distrepos
15:41:28 <jruzicka> in RDO info
15:41:42 <jruzicka> that defines what we assume is available in supported distros
15:41:50 <jruzicka> and what will be tested in CI eventually
15:41:56 <apevec> ah for Kilo?
15:42:09 <jruzicka> that is all repos available on a system where ($dist,$release) RDO is installed
15:42:21 <jruzicka> for all the the combinations :)
15:42:30 <jruzicka> I figured out Fedora 20 hopefully
15:42:39 <jruzicka> but then is fedore.next and I got confused
15:42:47 <jruzicka> respectively lazy with centos :)
15:43:24 <apevec> jruzicka, is it still the issue that you cannot use mirror url?
15:43:30 <jruzicka> Just sayting that needs to be done in order for querying requirements.txt
15:43:56 <apevec> dl.fedoraproject.org is probably not the fastest mirror for everybody
15:43:56 <jruzicka> issue is I need to identify sets of repos for each supported (dist,release)
15:44:05 <jruzicka> And fill rdoinfo with that information
15:44:05 <itzikb> apevec: I sent an email to the list
15:44:09 <apevec> itzikb, thanks
15:44:18 <jruzicka> apevec, and that problem with mirrorlist not working, yes
15:44:20 <jruzicka> :-/
15:44:51 <social> mrunge: http://v3.sk/~social/evince/
15:45:06 <social> mrunge: no promises except it should not crash right away
15:45:25 <apevec> jruzicka, ok, I'll take action to update distrepos
15:45:40 <apevec> #action apevec to update distrepos in rdoinfo
15:45:55 <jruzicka> best way I'm aware of would be to install the distros... and I don't have time for the new VM setup on lab machine now
15:45:56 <apevec> jruzicka, where is limitation w/ mirrorlist is coming from?
15:46:02 <jruzicka> I bet you can do it in like 1/10 of time
15:46:13 <jruzicka> repoquery doesn't support it
15:46:16 <apevec> jruzicka, no, it should be possible to query yum repos
15:46:22 <jruzicka> dnf repoqeuery as well
15:46:30 <jruzicka> yes, but explicit repos
15:46:31 <apevec> hm, repoquery - shame on you
15:46:41 <jruzicka> doesn't support the metalink
15:46:48 <jruzicka> old and new one
15:47:02 <jruzicka> I didn't figure that one out got closed in the box :)
15:47:23 <apevec> jruzicka, but that's strange, isn't repoquery using yum backend?
15:47:33 <apevec> and mirrors do work with yum...
15:47:38 <apevec> or dnf
15:47:46 <jruzicka> that's what I thought
15:48:38 <jruzicka> well, if it can do it, I'm not worthy enough to figure out
15:48:39 <number80> apevec, jruzicka: dnf repoquery uses the same code as dnf, repoquery and yum share some code but not everything
15:49:11 <jruzicka> yeah, but I didn't find a correct string that would make either of them do what I want.
15:49:33 <jruzicka> ancients strings of power, forgotten in the sands of code
15:49:37 <jruzicka> maybe they're just a legent
15:49:40 <jruzicka> *legend
15:49:51 <jruzicka> anyway, that's it for distrepos
15:49:55 <jruzicka> we can look at it later
15:50:01 <apevec> number80, jruzicka - ok, we can look at that later
15:50:08 <apevec> moving on
15:50:14 <apevec> #info rdopkg reqcheck available to help with requirements.txt management in rdopkg-0.27
15:50:23 <apevec> jruzicka, ^ thanks!
15:50:28 <apevec> I need to try it out
15:50:32 <jruzicka> please do
15:50:42 <apevec> re. borken with new milestone tags (ugh), use #patches_base=$TAG if needed
15:50:42 <jruzicka> I found it uberusful even
15:50:48 <jruzicka> with the dubmest possible reqs matching
15:50:54 <jruzicka> (string comparison, huehuehue)
15:50:57 <apevec> is that rpm-master merges I did, like http://pkgs.fedoraproject.org/cgit/openstack-heat.git/diff/openstack-heat.spec?id=b4f6dc65ec5bf62aa369e7f5af1666a2ea8a7e7b
15:50:58 <apevec> ?
15:51:04 <apevec> +Release:        0.1%{?milestone}%{?dist}
15:51:12 <jruzicka> apevec, should work OK with that
15:51:13 <apevec> why is that a problem?
15:51:18 <jruzicka> no that's ok
15:51:26 <jruzicka> problem is Version: not being string
15:51:28 <jruzicka> but macro
15:51:29 <apevec> which one is not?
15:51:40 <jruzicka> rdopkg needs to figure out the git tag
15:51:40 <apevec> ah, we're not going to do that
15:51:42 <jruzicka> or all is lost
15:51:53 <apevec> only in Delorean we'll have Version: XXX
15:51:58 <jruzicka> it goes #patches_base (not used anymore) > Version:
15:51:59 <apevec> because it's over-written
15:52:05 <jruzicka> it detects XXX
15:52:14 <jruzicka> and then uses ../$PROJECT/requirements.txt
15:52:18 <jruzicka> so you can use it in delorean spec
15:52:22 <apevec> also Delorean spec should not have any patches
15:52:29 <jruzicka> as long as you add upstream repo
15:52:53 <apevec> it must be "upstream" git remote ?
15:53:02 <jruzicka> preferably
15:53:13 <apevec> there's rdopkg RFE to set all that up automagically, right?
15:53:16 <jruzicka> yes
15:53:24 <jruzicka> many RFEs lately as people started using it ;)
15:53:40 <jruzicka> it's gonna only get better with time ;)
15:53:47 <jruzicka> anyway
15:53:54 <jruzicka> if you hit incorrect requirement
15:53:58 <apevec> jruzicka, ok, so openstack-keystone master is problematic, I'll fix  it
15:54:17 <jruzicka> I.E. something that didn't got translated wrong reqs.txt to package name
15:54:43 <jruzicka> just fix rdopkg/actionmods/pymod2pkg.py or let me know
15:54:50 <apevec> yep, send a patch!
15:54:58 <jruzicka> apevec, so is neutron I think... I can also do this
15:55:08 <jruzicka> if Version doesn't correspond to a git tag
15:55:17 <jruzicka> try parse %upstream_version fro mspec
15:55:19 <apevec> jruzicka, ok, I messed up with neutron too, will look at it
15:55:20 <jruzicka> *from .spec
15:55:33 <jruzicka> I can do that, but it seems like unnecessary automagic
15:55:49 <jruzicka> well, you tell me, it can be done
15:55:56 <apevec> yeah, too much automagic is not good
15:56:04 <apevec> ok, we have only few minutes left, let's move on
15:56:07 <number80> jruzicka: rpm -P (rpm > 4.9) will expand the macro (could be useful)
15:56:08 <jruzicka> also: grep Version *.spec
15:56:14 <jruzicka> will actually give you version
15:56:17 <jruzicka> the little things
15:56:24 <apevec> #topic Packaging tests packages for openstack-components
15:56:25 <jruzicka> like not needing to use librpm
15:57:01 <apevec> -tests subpackages will be our next goal, for L-cycle
15:57:11 <chandankumar> apevec, can we package test packages which are under txt-requirements.txt ?
15:57:14 <apevec> it needs some thoughts how to do it properly,
15:57:25 <apevec> project now include both unit and functional tests
15:57:46 <apevec> chandankumar, sure, that's the requisite, to have all test deps available in buildroot
15:57:52 <number80> +1
15:57:53 <apevec> so we run _unit_ tests in %check
15:57:55 <jruzicka> nice
15:58:08 <chandankumar> apevec, i will list all the test packages and package it.
15:58:11 <apevec> b/c I don't think buildroot is the right env to run functional tests
15:58:23 <apevec> chandankumar, excellent here comes your action
15:58:26 <number80> apevec: exactely
15:58:39 <apevec> #action  chandankumar  will list all the test packages and package it
15:58:46 <chandankumar> Thanks :)
15:58:49 <apevec> chandankumar, please post the list to rdo-list when you have it
15:58:49 <jruzicka> looking forward to the soothing feeling of passed tests
15:59:06 <chandankumar> apevec, sure :)
15:59:30 <apevec> jruzicka, well could actually be misleading :) http://pythontesting.net/strategy/why-most-unit-testing-is-waste/
15:59:41 <apevec> but let's not go there now
16:00:06 <jruzicka> misleading but soothing nonetheless :-p
16:00:14 <apevec> next
16:00:21 <apevec> #info selinux enforcing jobs enabled for kilo
16:00:27 <apevec> brace for AVCs!
16:00:48 <apevec> plan is to collect them all and update openstack-selinux for Kilo
16:01:16 <apevec> another CI update:
16:01:20 <apevec> #info trystack is down atm w/ floating ip issues, public ci down
16:01:25 <apevec> weshay, aortega ^ any hope?
16:01:52 <weshay> ggilles and kosh are looking at it
16:02:01 <apevec> ok, thanks for the update
16:02:21 <aortega> Graeme made pretty good progress yesterday, and wfoster and kosh have taken over
16:02:30 <apevec> #topic juno el6 in CBS
16:02:35 <alphacc> #info Enabling cloud6-openstack-juno-candidate and cloud6-openstack-common-candidate CBS repositories on CentOS 6 (No EPEL) you will be able to "yum install openstrack-nova openstack-ceilometer-*".
16:02:52 <number80> :)
16:02:54 <alphacc> Now how can we handle CI for Juno el6 ? (/me didn't follow any CI discussion so is clueless / Yesterday the team upgraded 3200 production nodes from ice6 -> juno6 so I have ongoing "validation tests"  :)
16:02:55 <apevec> excellent
16:03:23 <apevec> alphacc, we can't beat that with our CI :)
16:03:47 <apevec> alphacc, so you're upgraded only computes to EL6 Juno?
16:03:50 <alphacc> apevec: I wish I had found some issues in advances I could have still kept some hair.
16:03:58 <apevec> alphacc, what were issues?
16:04:12 <alphacc> apevec: mainly python-* updates
16:04:13 <apevec> alphacc, and which setup should we test in CI?
16:04:26 <apevec> EL6 compute nodes + controller EL7 ?
16:04:32 <apevec> weshay, ^ could we do that?
16:04:35 <alphacc> apevec: yes
16:04:36 <apevec> weshay, it's RDO Juno
16:05:01 <weshay> yes.. that is possible
16:05:17 <weshay> rdo-juno w/ el6 compute and el7 for controllers
16:05:17 <apevec> weshay, do we have any such job as an example?
16:05:20 <weshay> no
16:06:01 <apevec> weshay, do we have enough info/pointers for alphacc to add such job?
16:06:29 <apevec> weshay, also do we have khaleesi-settings open up for external contributions?
16:07:24 <alphacc> anyway, ping me when I can help.
16:07:25 <weshay> atm.. our up stream / downstream story for khaleesi-settings sucks..
16:07:46 <weshay> it would be available on any slave we use, but the github account lags
16:08:10 <apevec> alphacc, number80 - BTW https://trello.com/c/L0X5bU5s/25-el6-juno-packages has Juno/EL6 neutron in the checklist
16:08:17 <weshay> the change would I think only be for the settings/installer/packstack/topology
16:08:25 <weshay> the os is mapped to each node
16:08:30 <apevec> alphacc, are you actually interested in that? b/c EL6 and neutron might not be best match
16:08:44 <apevec> alphacc, you're still on nova-net right?
16:08:45 <alphacc> apevec: yes neutron is coming tomorrow ;)
16:08:59 <weshay> apevec, btw.. we have a new platform ci guy and he'll be taking some of this on hopefully
16:09:00 <apevec> alphacc, so you migrated?
16:09:05 <alphacc> apevec: yes modified nova-net
16:09:12 <alphacc> apevec: no
16:09:27 <alphacc> packages are coming we are still putting a plan together
16:09:40 <apevec> ok, so who actually would want EL6 Neuron?
16:10:17 <apevec> alphacc, number80 - could we can say EL6 Juno is "done" with Nova + Ceilo + clients?
16:10:26 <alphacc> apevec: We likely need it for our upgrade path nova-net -> neutron el6/el7
16:11:35 <alphacc> apevec: I'll publish some neutron stuff anf let see if there is some interest from the community; I should send soemthing to the list
16:12:19 <apevec> alphacc, ack
16:13:03 <apevec> #action alphacc to post about EL6 neutron status on rdo-list, to gauge interest
16:13:17 <apevec> number80, do you have anything for EL6 ?
16:13:46 <apevec> ok, we're already over time
16:13:49 <number80> apevec: as for myself, we're providing an upgrade path
16:13:51 <apevec> #topic open floor
16:13:59 <DrBacchus> alphacc: Would also be useful to have a doc for the RDO docs wiki, but perhaps that'll come out of that thread.
16:14:29 <apevec> rbowen, yeah, let's not put too much new stuff into wiki before migration
16:14:54 <alphacc> rbowen: sure when we have the final repos I'll add it
16:15:03 <rbowen> The migration process is all scripted, and converts all content. Takes about 5 minutes, last time we tested. But, sure, before or after is fine.
16:15:43 <apevec> rbowen, best part IMHO is that content updates will have proper history and reviews
16:15:48 <rbowen> +1
16:15:54 <rbowen> Very true
16:16:04 <rbowen> I'll make a list of people to bug post-update. :-)
16:16:12 <apevec> rbowen, btw would we prefer to use gerrithub or github PRs for updates?
16:16:41 <alphacc> ok thanks all, I need to run.
16:16:43 <apevec> not sure what folks writing docs prefer
16:16:46 <apevec> alphacc, thanks you
16:16:46 <rbowen> I'm not sure. We should perhaps discuss that on the list. I'll get more details from Garrett on how this all works.
16:16:57 <apevec> ok
16:17:17 <rbowen> So far, the oVirt guys have said that they don't want to use Gerrit for it, but that's just one opinion among many.
16:17:32 <apevec> yeah
16:17:38 <apevec> ok, if no other topics, I'll end meeting in 3
16:17:45 <apevec> 2
16:18:02 <apevec> 1 - thanks everyone!
16:18:06 <apevec> #endmeeting