15:00:33 <apevec> #startmeeting RDO meeting (2015-11-11)
15:00:33 <zodbot> Meeting started Wed Nov 11 15:00:33 2015 UTC.  The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:34 <elmiko> \o/
15:00:45 <apevec> #chair number80 elmiko trown
15:00:45 <zodbot> Current chairs: apevec elmiko number80 trown
15:00:50 <apevec> #topic roll call
15:00:52 <number80> o/
15:00:59 <elmiko> hi
15:01:03 <apevec> #info agenda https://etherpad.openstack.org/p/RDO-Packaging
15:01:19 <dmsimard> \i
15:02:05 <trown> o/
15:03:26 <apevec> #chair dmsimard
15:03:26 <zodbot> Current chairs: apevec dmsimard elmiko number80 trown
15:03:40 <apevec> #topic client separate target/repo in CBS?
15:03:43 <apevec> number80, ^
15:04:02 <apevec> we had considered that in the paste, is the time right now?
15:04:06 <number80> long-running topic but since it came back, I'd like to have a separate repo for clients
15:04:18 <number80> so that we can update them independently from servers
15:04:20 <apevec> looks like upstream clients will be taking backward compat seriously now?
15:04:47 <number80> yeah, but I wouldn't bet on this :)
15:04:59 <apevec> no bets, but CI :)
15:05:37 <number80> so should I drop this item from the todo?
15:05:38 <apevec> number80, so this would be for mitaka
15:06:03 <apevec> number80, let's explore it first
15:06:10 <number80> ok
15:06:42 <apevec> number80, they should be compatible for client use but unclear about client usage in service2service
15:06:51 <number80> #action number80 setup separate repo for clients (CBS)
15:07:16 <dmsimard> so I have a question
15:07:24 <number80> dmsimard: go ahead :)
15:07:25 <dmsimard> how does this work for "servers" since they require the clients ?
15:07:28 <apevec> number80, so TBD will that new target be inherited by mitaka build target?
15:07:33 <dmsimard> aka nova will need python-novaclient
15:07:39 <apevec> dmsimard, yeah, that's my TBD :)
15:07:56 <dmsimard> I'm trying to understand what's the point
15:07:59 <apevec> I guess we leave it as is for liberty
15:08:05 <number80> dmsimard: people deploying services shouldn't enable clients repo
15:08:10 <apevec> and inherit in mitaka
15:08:17 <apevec> number80, hold on
15:08:24 <jruzicka> o/
15:08:25 <number80> #undo
15:08:25 <zodbot> Removing item from minutes: ACTION by number80 at 15:06:51 : number80 setup separate repo for clients (CBS)
15:08:26 <apevec> services do need clients
15:08:40 <number80> apevec: yes, we'll keep compatible version in the service repo
15:08:59 <dmsimard> Why manage two repos ? Sounds like more work, what's the incentive ?
15:09:04 <apevec> IMHO what we want is to allow newer clients for end-user workstation
15:09:16 <number80> dmsimard: people complaining that we ship old clients :)
15:09:20 <apevec> with upstream backward compat that should work
15:09:31 <dmsimard> number80: they can install from pip for all I care
15:09:37 <dmsimard> this is what I did on Ubuntu
15:09:46 <dmsimard> Ubuntu ships old clients
15:09:46 <apevec> well, we want that w/o pip :)
15:10:02 <apevec> so we can be better than Ubuntu
15:10:09 <jruzicka> dmsimard, great, so one more thing we're better at then ubuntu ;)
15:10:14 <jruzicka> *than
15:10:15 <number80> so the plan is to have latest clients in rawhide + separate mitaka target in CBS?
15:10:20 <number80> (am I right?)
15:10:25 <dmsimard> I get your point but it just doesn't seem worth the work to me
15:10:26 <apevec> number80, that sounds right
15:10:26 <jruzicka> Hmm, that does make sense
15:10:47 <number80> good, we were converging on that topic
15:10:50 <dmsimard> Seeing as we're already struggling to keep up with just what we have right now
15:10:51 <apevec> number80, with TODO decide if we could just inherit clients in mitaga services target
15:11:25 <jruzicka> dmsimard, yeah, so let's make the struggle worth it and do it well ;)
15:11:43 <apevec> #chair jruzicka
15:11:43 <zodbot> Current chairs: apevec dmsimard elmiko jruzicka number80 trown
15:11:46 <jruzicka> doesn't sound like too much work to me
15:11:49 <number80> apevec: that's tricky, but I agree that CI should be the one deciding this
15:12:08 <jruzicka> plus extra benefit of having the client packages ready when they're really needed in the services repo
15:12:15 <dmsimard> I'm not a packaging/mirror guru, you guys are the experts
15:12:31 <jruzicka> good questions, I'm trying to give answers ;)
15:13:30 <number80> dmsimard: you'll learn ;)
15:13:33 <dmsimard> Let's just do it right and not make it confusing, we already discussed the delorean vs delorean-deps repo - this will add another :p
15:13:35 <jruzicka> dmsimard, if we integrate the two correctly, it should be a little overhead but great value for end users
15:14:29 <number80> #agreed have latest clients in rawhide + separate mitaka target in CBS
15:15:02 <number80> #info TODO: inheritance of the mitaka clients target by mitaka target
15:15:18 <number80> (log trimming)
15:15:19 <jruzicka> bad thing is that if someone will put clients repo alongside the service repo, it will explode, no?
15:15:36 <jruzicka> or implode
15:16:01 <jruzicka> or desintegrate in some other funny way cause we don't specify the client versions too closely
15:16:18 <number80> jruzicka: latter is packaging issue, we can fix this
15:16:35 <apevec> that's under TODO item to explore
15:16:43 <jruzicka> number80, yes, just noting that.
15:16:55 <number80> jruzicka: and you're right, sir!
15:17:28 <jruzicka> stuff is getting so fancy I'll need a second monocle soon.
15:17:52 <number80> :)
15:18:13 <elmiko> lol
15:18:34 <number80> then, I suggest that we move to the next item and continue investigating that next week
15:19:28 <apevec> oh we got more on the agenda!
15:19:33 <dmsimard> OH
15:19:41 <apevec> #topic Mitaka test days suggestion
15:19:41 <trown> sneaky
15:19:51 <rbowen> See the list of dates on rdo-list
15:19:57 <apevec> #link https://www.redhat.com/archives/rdo-list/2015-November/msg00096.html
15:19:57 <rbowen> They're all roughly one week after a milestone
15:20:19 <rbowen> We want to test mitaka stuff, but also provide a place for folks to install stable packages with some handholding
15:20:30 <rbowen> And, docs, at the same time.
15:20:32 <apevec> rbowen, yep that would be general target I proposed, we moar automation and working CI we should be able to keep it
15:20:37 <rbowen> As per discussion in Tokyo
15:20:39 <dmsimard> +1, I want a current-passed-ci mitaka repo before the first test day target
15:20:48 <rbowen> There is no proposed date in November.
15:20:56 <number80> rbowen: good for me but january 27, 28 is nearby RDO mid-cycle/devconf
15:21:01 <rbowen> This gives us a month to get test plans together, and figure out related stuff.
15:21:13 <apevec> yeah, too much in flux, early Dec should work
15:21:21 <rbowen> number80: Ok, that's good to know. Perhaps propose another date for that milestone?
15:21:48 <apevec> rbowen, number80, Jan28 is rdo meetup before fosdem
15:21:54 <apevec> so why not,
15:21:59 <apevec> testday live!
15:22:00 <rbowen> Anyways, I'll start working on documentation, for the test day, rather than leaving it to the last minute like I did last time.
15:22:11 <number80> rbowen, apevec: why not :)
15:22:12 <rbowen> Oh, of course, I forgot about FOSDEM. Which is weird.
15:22:24 <apevec> hehe, next topic!
15:22:29 <rbowen> 29th is FOSDEM RDO day.
15:22:34 <apevec> #topic FOSDEM RDO Day
15:22:46 <apevec> ah ye Friday
15:22:47 * kashyap is lurking
15:22:52 <rbowen> We have a CFP at http://goo.gl/forms/oDjI2BpCtm
15:23:05 <apevec> any proposal yet?
15:23:07 <rbowen> Filling out the CFP doesn't mean "I will present", it means "we should discuss"
15:23:10 <rbowen> No, we have nothing yet.
15:23:16 <rbowen> Of course, if you want to present, that's fine, too.
15:23:28 <apevec> hmm, we need more marketing
15:23:31 <number80> #action number80 submit a delorean hands-on for RDO meetup
15:23:32 <jruzicka> I don't plan to go to FOSDEM this year since I hate Brussel, who's gonna be there?
15:23:34 <kashyap> rbowen: Assume you plan to announce on the mailing lits?
15:23:37 <kashyap> s/lits/list/
15:23:39 <jruzicka> I might reconsider
15:23:40 <rbowen> Yes. Marketing is important, once we have a topic or two.
15:23:49 <rbowen> Yes, I will announce on various lists.
15:23:58 <apevec> rbowen, I mean, sending CFP around...
15:24:05 <rbowen> I hate Brussels too, but I'll be there.
15:24:13 <rbowen> apevec: Will do it right after this meeting. Thanks.
15:24:15 <apevec> jruzicka, bunch of us
15:24:19 <elmiko> number80: any chance that delorean hands-on will be recorded or something?
15:24:20 <number80> jruzicka: I am every year in Brussels for FOSDEM, that's the only one truth.
15:24:45 <rbowen> The room we have confirmed seats 45, apparently, so not a huge space, but probably big enough.
15:24:47 <dmsimard> lol what's up with Brussels that you guys hate it ?
15:24:57 <number80> elmiko: it could, we just need to ensure that we have the hardware for that
15:24:59 <dmsimard> sorry for offtopic
15:25:04 <rbowen> Actually, it's more the date. It's cold and miserable there that time of year.
15:25:10 <rbowen> Brussels itself isn't awful.
15:25:24 <elmiko> number80: i would be interested, i'm very curious about the hands-on, but no chance i'll make the meetup =(
15:25:31 <number80> dmsimard: don't let them get to you, FOSDEM is awesome
15:25:33 <rbowen> Anyways, there's also an IaaS devroom, that people might consider submitting to. Link also in the etherpad.
15:25:36 <apevec> #topic FOSDEM IaaS devroom CFP
15:25:46 <apevec> #link http://community.redhat.com/blog/2015/10/call-for-proposals-fosdem16-virtualization-iaas-devroom/
15:25:57 <rbowen> Although some folks mentioned that the Distro devroom might be appropriate for certain types of RDO talks.
15:26:17 <rbowen> It would be nice to have a strong presence in one or both of those rooms.
15:26:28 <apevec> yeah, I still doubt that distro devroom but whatever
15:26:29 <kashyap> rbowen: Yeah, number80 did a talk there last year, as mrunge pointed out on the list
15:26:32 <rbowen> Not sure of deadlines, but I expect it's soon.
15:26:57 <rbowen> The deadline for the RDO meetup day is "when the schedule is full".
15:27:03 <rbowen> That's all I've got. Questions?
15:27:04 <apevec> Submission deadline: 1 December 2015
15:27:10 <apevec> for virt devroom
15:27:40 <apevec> no question, moving on
15:27:57 <apevec> somehting I just noticed:
15:28:04 <apevec> #topic loads of py3.5 FTBFS
15:28:08 <apevec> number80, ^ what's going on?
15:28:31 <trown> FTBFS?
15:28:41 <number80> apevec: buildroot issues, some packages were not built in the right order
15:28:41 <apevec> fails to build from source
15:28:47 <apevec> phew
15:28:48 <number80> I'm of the opinion to wait releng to finish
15:28:49 <apevec> number80, thanks
15:29:19 <apevec> #info wait releng to finish py3.5 mass rebuild
15:29:22 <apevec> #link https://fedoraproject.org/wiki/Fails_to_build_from_source
15:29:25 <apevec> trown, ^
15:29:47 <apevec> #topic open floor
15:30:05 <apevec> anything else not on agenda?
15:30:36 <apevec> FYI we have red CI due to khaleesi changes, fixes are under review
15:30:44 <number80> ok
15:31:00 <apevec> weshay_xchat and dmsimard are on top of it
15:31:20 <trown> I got the greenlight to store images on artifacts.centos which is the same infra as the CI so DL will be super fast
15:31:39 <apevec> 1Gb fast
15:31:52 <dmsimard> Also I'm going to double down on migrating stuff to ci.centos, this should allow us to have 100% smoke test coverage for liberty
15:32:35 <trown> ya I think I was getting 200k earlier this week from fedorapeople, so 1G will be a huge improvement
15:34:22 <apevec> ok, thanks folks!
15:34:28 <apevec> #endmeeting