15:04:12 <apevec> #startmeeting RDO packaging meeting (2015-08-05)
15:04:12 <zodbot> Meeting started Wed Aug  5 15:04:12 2015 UTC.  The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:17 <apevec> #chair number80
15:04:17 <zodbot> Current chairs: apevec number80
15:04:22 <apevec> #topic roll call
15:04:26 <apevec> o/
15:04:26 <number80> o/
15:04:44 <mburned> o/ (somewhat)
15:04:49 <eggmaster> o/
15:04:56 <rbowen> o/
15:05:03 <number80> #chair mburned eggmaster rbowen
15:05:03 <zodbot> Current chairs: apevec eggmaster mburned number80 rbowen
15:05:09 <apevec> jruzicka, is that you adding rdopkg on agenda?
15:05:42 <jruzicka> just an information I'm not sure about is very useful to anyone yet worth noting ;)
15:05:53 <eggmaster> apevec: we could discuss plans/theories for rdopkg ci a bit.
15:05:56 <eggmaster> idk.
15:06:16 <apevec> eggmaster, ack, please add to agenda
15:06:34 <number80> jruzicka: check the pymodpkg review ;)
15:06:47 <apevec> #chair jruzicka
15:06:47 <zodbot> Current chairs: apevec eggmaster jruzicka mburned number80 rbowen
15:06:49 <xaeth> 0/
15:06:56 <social> o/
15:06:58 <dtantsur> o/
15:07:09 <number80> #chair xaeth social dtantsur
15:07:09 <zodbot> Current chairs: apevec dtantsur eggmaster jruzicka mburned number80 rbowen social xaeth
15:07:21 <apevec> hehe, as soon as I announced it will be quick one, lots of folks showed up :)
15:07:34 <apevec> alright, quorum reached
15:07:42 <apevec> #topic python3 clients
15:07:48 <apevec> number80, ^ all yours
15:08:03 <apevec> #info hguemar started working on python3 clients packaging (fixing dependencies and remaining oslo libs)
15:08:08 <number80> basically dtantsur remembered me that was a goal for liberty
15:08:15 <apevec> ack
15:08:27 <apevec> so is next agenda item (test deps) :)
15:08:30 <number80> I have to fixed low-level deps first but we should have keystoneclient soon
15:08:39 <dtantsur> yeah, I got asked about openstackclient on review for ironic-inspector-client
15:08:49 <apevec> #info we should have python3-keystoneclient soon!
15:09:21 <apevec> number80, question: this is all Fedora only right?
15:09:44 <apevec> EL7 doesn't have python3 and SCL would lots of work afaict
15:10:01 <apevec> s/would/would be/
15:10:06 <number80> apevec: atm, yes, but I'll check the new python34 package in EPEL7
15:10:42 <apevec> oh I missed that: http://koji.fedoraproject.org/koji/buildinfo?buildID=663483
15:11:00 <number80> but python3 clients on EL7 is ultra-low priority for liberty
15:11:03 <apevec> #info EPEL7 now has python34 base package ^
15:11:08 <apevec> number80, ack
15:11:26 <apevec> number80, I suspect lots of python34-* are missing in EPEL7
15:11:31 <number80> exactly
15:12:05 <number80> but I'll consider this for mitaka or liberty post-release
15:12:36 <apevec> ok, anything else on py3? Do we have/need trello card to track it?
15:13:12 <number80> #action hguemar set up a trello card to track python3 client progress
15:13:16 <number80> eol
15:13:26 <apevec> thanks
15:13:28 <apevec> next
15:13:31 <apevec> #topic chandankumar rebooted the weekly bug report mailing
15:13:45 <apevec> chandankumar++ thanks for taking this over from larsks
15:13:45 <zodbot> apevec: Karma for chandankumar changed to 2:  https://badges.fedoraproject.org/tags/cookie/any
15:13:52 <jruzicka> chandankumar++
15:13:52 <zodbot> jruzicka: Karma for chandankumar changed to 3:  https://badges.fedoraproject.org/tags/cookie/any
15:14:23 <apevec> also related on agenda:
15:14:27 <apevec> #info Starting again Bug Triage Day in the last week of every month
15:14:39 <rbowen> Excellent
15:15:11 <apevec> also spearheaded by chandankumar
15:15:34 <number80> chandankumar++
15:15:44 <apevec> he can't join today but ofered to lead this meeting next week
15:15:57 <apevec> which I'd like to be rotating among us
15:16:08 <number80> *nods*
15:16:13 <apevec> as discussed few meetings back
15:16:37 <apevec> #topic test deps
15:16:45 <apevec> also from Chandankumar: will be packaging all the test-packages by next week
15:16:57 <apevec> we're running out of ++ for him :)
15:17:22 <number80> #action chandankumar to link new reviews to this tracker => https://bugzilla.redhat.com/show_bug.cgi?id=1243533
15:17:22 <apevec> #info Chandankumar will be packaging test deps
15:17:52 <apevec> ack, we need to track those
15:17:53 <number80> there'll be likely a lot, so people are expected to help with reviews :)
15:18:06 <number80> (informal reviews work too)
15:18:13 <apevec> yep
15:18:39 <apevec> #action everybody help with package reviews, see  	RDO-LIBERTY-REVIEWS  tracker BZ
15:18:50 <apevec> #topic rdo-update CI
15:19:02 <eggmaster> ohai.
15:19:09 <apevec> eggmaster, ^ can you summarize what we mumbled on IRC about?
15:19:29 <eggmaster> apevec: so I was thinking about this before meeting and (sadly?) I think it may be too soon to start dancing on the grave of jruzicka 's rdopkg update yml
15:20:04 <eggmaster> What apevec and I were discussing was using tagging in CBS for rdopkg ci,
15:20:06 <eggmaster> i.e.
15:20:07 <apevec> we can keep it but it would feed into scripts tagging into -testing CBS tags
15:20:18 <eggmaster> > <eggs> 1) tag as -testing  [13:40]
15:20:19 <eggmaster> > <eggs> 2) testing pass/fail
15:20:19 <eggmaster> > <eggs> 3) collect list of -testing with pass
15:20:19 <eggmaster> > <eggs> 4) tag as -release, includes magic to sign pkgs in -release repo
15:20:34 <apevec> right
15:20:55 <eggmaster> What I had hoped was that it would be easy to create the ci jobs by just pointing at CBS yum repo based off -testing tag
15:21:08 <eggmaster> the problem, I think, is concurrency, e.g.
15:21:14 <eggmaster> pkgrA tags pkg-foo with -testing
15:21:14 <eggmaster> CI runs against -testing repo, passes, \o/
15:21:14 <eggmaster> pkgrB tags pkg-bar with -testing
15:21:14 <eggmaster> pkgrA tags all projects in -testing to -release based on CI run
15:21:17 <eggmaster> OOPS
15:21:20 <eggmaster> 
15:21:27 <eggmaster> So it might not be as simple as I'd hoped.
15:21:52 <apevec> so as a quickfix we could make tagging sequential
15:22:01 <apevec> since it's only few of us who have privs
15:22:07 <apevec> me number80 and jruzicka
15:22:38 <number80> apevec: we can request an account for RDO CI for tagging
15:22:38 <eggmaster> yeah, with limited # of gatekeepers ^^ might not be a big problem.
15:22:39 <apevec> i.e. we tag all in update yml and wait for CI result
15:22:51 <apevec> then move to next update yml
15:23:09 <apevec> number80, how does Bodhi handle updates testing?
15:23:21 <apevec> iirc there's some autoqa reporting on Bodhi updates?
15:23:58 <number80> apevec: yes, you can add test case in a wiki page
15:24:25 <apevec> ahh, it's called taskotron  now?
15:24:38 <number80> yes, but pretty much the same thing
15:24:39 <apevec> e.g. in https://admin.fedoraproject.org/updates/FEDORA-2015-10711/openstack-keystone-2014.1.5-1.fc21
15:26:11 <number80> honestly, if we get RDO CI more reliable, it'll be simpler than deploying bodhi
15:26:15 <apevec> eggmaster, ok, let's assume sequential updates testing for now
15:26:35 <eggmaster> apevec: ok, but I'm not sure that solves the other problem I thought of :)
15:26:35 <apevec> number80, yeah, I didn't mean to imply adopting Bodhi!
15:26:39 <number80> ack
15:26:41 <apevec> just as a source of ideas
15:26:56 <apevec> eggmaster, what's the other one?
15:27:21 <eggmaster> Which is, let's say we tag pkgA,B,C as -testing. CI runs and fails. Which caused fail? A,B or C?
15:27:46 <eggmaster> i.e. we may need the isolation that rdopkg update provides.
15:27:51 <apevec> that's why I suggested above procesing update by update
15:27:59 <apevec> i.e. we keep update.yml as-is
15:28:01 <eggmaster> ok, I wasn't clear on that.
15:28:05 <number80> +1
15:28:11 <apevec> but use it to feed into -testing tag script
15:28:17 <jruzicka> Hmm, what is actually the reason for the joy of dancing on the grave of the update yml? I mean what does it suck at most?
15:28:21 <eggmaster> I thought you meant we'd put a bunch in together.
15:28:33 <eggmaster> jruzicka: bad metaphor, disregard
15:28:35 <number80> jruzicka: we're saving its neck actually ;)
15:28:50 <eggmaster> jruzicka: it would be a slow, mournful dance
15:28:54 <jruzicka> yeah but what is the better alternative?
15:28:56 <apevec> eggmaster, I probably did, but that's why we're discussing details now :)
15:29:15 <apevec> jruzicka, it turns out, there isn't :)
15:29:30 <jruzicka> OK now I'm confused :D Never mind.
15:29:38 <eggmaster> jruzicka: I don't think we found a better alternative; I think what we're talking about is how to sort the packages using tags in CBS
15:29:48 <eggmaster> based on results we get using rdopkg update
15:29:51 <jruzicka> ah, that's the answer
15:29:53 <jruzicka> you want tagging
15:30:32 <apevec> yes, we'll tag NVRs from update yml in -testing CBS tag
15:30:33 <jruzicka> isn't that just next piece that connects where the update file funkyness ends?
15:30:36 <apevec> which will trigger CI
15:30:48 <eggmaster> apevec: The thing I thought tags would buy me (as the person to implement ci jobs) would be the ability to just add a yum repo to a job and automagically get packages,
15:31:05 <apevec> eggmaster, yes, it will
15:31:06 <eggmaster> as opposed to what I have to do now which is download builds using rdoupdate download
15:31:16 <jruzicka> oh I see
15:31:37 <number80> well, koji generated repo are not reliable, metadata takes some time to be regenerated
15:31:50 <apevec> eggmaster, update CI will use the same trigger as current https://ci.centos.org/job/cloud-sig-validate-packstack-rdo-kilo-testing_tag/
15:32:15 <apevec> https://ci.centos.org/job/cloud-sig-validate-packstack-rdo-kilo-testing_tag/urltriggerPollLog/
15:32:16 <number80> ie: build A has been added to the -testing repo, then comes in the middle build B and your metadata are not available because koji is crunching them
15:32:33 <apevec> number80, that's why we'll serialized tagging into -testing
15:32:38 <number80> +2
15:33:13 <jruzicka> single thread should be enough for everyone. :-p
15:33:50 <apevec> yep
15:34:10 <apevec> rate of updates is not in MHz ;)
15:34:32 <jruzicka> ...yet.
15:35:22 <apevec> well, for trunk chasing we have separate system, Delorean
15:35:34 <jruzicka> RDO - we package software faster than it's created (TM)
15:35:40 <apevec> but even there, it's not even 1 Hz :)
15:35:53 <jruzicka> right, I think it's very reasonable
15:36:15 <jruzicka> always better to have a scalar instead of vector ;)
15:36:43 <ayoung> slagle, perhaps I should have asked that here:
15:36:54 <apevec> eggmaster, so with those asumptions, you should be good to continue work on ci.centos ?
15:37:03 <eggmaster> So the missing piece for any scenario is running packstack aio ci.centos jobs. I am working on that.
15:37:04 <ayoung> slagle,  Lets say we want to kill Packstack.  What is keeping us from using director in an "undercloud only, non ironic mode"  from a technical perspective?  I'm looking at things like demos, presentations, and development work, not production deployments here.
15:37:14 <apevec> eggmaster, cool
15:37:55 <apevec> #action eggmaster to continue working on running packstack aio ci.centos jobs
15:38:01 <apevec> #topic open floor
15:38:20 <apevec> #info ayoung wants to kill Packstack
15:38:24 <apevec> :)
15:38:38 <apevec> anything else?
15:38:41 <jruzicka> #info everyone wants to kill packstack, but noone dares
15:38:48 <rbowen> hehe
15:38:56 <ayoung> I really don't care
15:39:00 <jruzicka> and that
15:39:07 <ayoung> I just need something to use, and it looks like the effort is going into director
15:39:20 <ayoung> but I can't use director, because I don't have bare metal
15:39:41 <ayoung> so...could director just subsume packstack instead?
15:39:52 <apevec> yeah, packstack covers all-in-one proof-of-concept setups that rdo-manager doesn't support
15:40:02 <apevec> ayoung, it cannot by design afaict
15:40:12 <jruzicka> ayoung, question is whether it's as stable and simple as packstack which although not being the best software ever written, is quite stable and tested
15:40:14 <apevec> mburned, ^ ?
15:40:24 <rbowen> The place that packstack fills - first time all-in-one proof of concept - needs to be filled by something.
15:40:30 <slagle> ayoung: i assume you mean using the undercloud installer as an all in one without ironic?
15:40:32 <rbowen> The "Quick Start" is already not particularly quick.
15:40:39 <ayoung> jruzicka, that is not really a reason. All newe software needs to be shaken out
15:41:03 <ayoung> jruzicka, the "two different installers" story has been a problem for a while.  Well, more than two....
15:41:05 <social> rbowen: still it would be nice to have simple all-in-one to multinode which atm only packstack does
15:41:06 <jruzicka> ayoung, ah, it wasn't related to CI... never mind.
15:41:11 <rbowen> It's important to be able to give people a good first experience - somethign that works without a great deal of fiddling around.
15:41:16 <rbowen> social: Yes, exactly.
15:41:35 <ayoung> but, it seems like with manager, we finally have something that can handle a CLI driven workflow like Packstack..but that needs the full CI covereage itsle,f too
15:41:37 <lon> in general, unattended deployment.
15:41:43 <social> and it would be nice to make choice either kill it or revive it and let it develop further
15:41:43 <rbowen> And whatever it is that fills that space is fine with me. This is something that people rave about at every event - how easy it was to get started with RDO.
15:41:52 <social> state packstack is in now sucks
15:41:52 <lon> and allinone
15:41:56 <jruzicka> I thought we agreed that whatever the new installer is, it will have packstack-like simple CLI frontend.
15:42:09 <ayoung> jruzicka, I think that is the case, but it does...too much
15:42:13 <number80> did someone say new khaleesi?
15:42:22 <ayoung> it assumes Ironic will be used to deploy the overcloud
15:42:51 <ayoung> we need to beat on rdo-manager to get it stable
15:43:55 <ayoung> I'm focused on Keystone, and I need to integrate my work more closely with RDO.  That means tying in with the installer.  I'd rather deal with the "real" installer if that is possible
15:43:59 <jruzicka> ayoung, stable and simple in the minimal case.
15:44:34 <jruzicka> ayoung, oh well, RDO is just a bunch of packages really. The more ways you use/test them, the better, no?
15:44:42 <ayoung> jruzicka, so...the question is if there is any reason that rdo-manager can't be "stable and simple in the minimal case" right?
15:45:12 <ayoung> jruzicka, RDO is more than that, just as Fedora is more than just a bunch of packages
15:45:21 <apevec> ayoung, integration starts with puppet modules, both packstack and rdo-mgr use them, so I guess you need to start there?
15:45:25 <jruzicka> ayoung, haha, tricky question. It is unquestionably possible as such. The implementation, however... I don't know much about but it all sounds too comlex to me.
15:45:34 <ayoung> apevec, we do work at that level
15:45:34 <number80> ayoung: merely tripleo architecture
15:46:40 <apevec> social, what is upstream puppet CI using to test puppet modules themselves?
15:46:58 <apevec> they do integration testing with real openstack install I assume?
15:46:58 <jruzicka> ayoung, while packstack isn't "real" installer, it can really install the packages as advertised in most cases
15:46:59 <social> apevec: another own set of puppet
15:47:32 <apevec> pop? puppet-on-puppet :)
15:47:49 <ayoung> jruzicka, its just that it is a different code base than we are telling people to use for production deployments, and splitting the effort is making it difficult for me and people like me that need to do end state configurations:  LDAP, Federation, Kerberos, and SAML
15:47:53 <social> apevec: no, you have puppet modules that need to be tested to you just use them
15:48:00 <social> apevec: look at it as another composition layer
15:48:14 <mburned> apevec: the question from ayoung?
15:48:20 <apevec> mburned, yes
15:48:21 <social> apevec: as packstack uses puppet modules differently compared to tripleo so does the upstream ci
15:48:54 <social> and I do agree with ayoung that we need one at least composition layer ,)
15:48:55 <mburned> apevec: yeah, i'd defer to slagle on that
15:48:59 <apevec> yeah, packstack is supposed to be light-weight compsition layer
15:49:03 <ayoung> mburned, yeah, so I need to do a development setup, and right now, I have to use packstack, because I don;t have baremetal, and will not get baremetal.  I need to deploy openstack on VMs to test Keystone type stuff.
15:49:28 <mburned> in general, the undercloud is not as configurable as you could get with packstack
15:49:37 <ayoung> But ideally, what I am working on top of would be the "real" deployer.  Is there some reason we can't make rdo-director work in a scaled down mode?
15:49:41 <mburned> ayoung: you can do a director deployment completely in vms
15:49:51 <ayoung> mburned, just undercloud?
15:49:53 <mburned> but it's a much more heavyweight solution than packstack
15:49:59 <slagle> the undercloud installer is not meant to be merely as flexible as packstack, by design
15:50:04 <mburned> ayoung: both under and overcloud
15:50:09 <apevec> social, is that upstream composition layer reusable i.e. could it be used to reimplement packstack?
15:50:19 <slagle> so it is significantly limited in terms of what you can configure vs packstack
15:50:28 <social> apevec: all packstack needs is to get out of undef state
15:50:55 <jruzicka> mburned, is there CI for the VMs only deoployment or is it more like a special case?
15:51:03 <social> apevec: a) kill it and write something new (we are actually working on this) or b) continue normal development, improve and change things (consume the new project we have)
15:51:13 <slagle> that said, we are exploring a new undercloud installer that uses a minimal Heat container to deploy an all in one openstack (in containers) all to the same node
15:51:16 <social> or c) kill it and all is director
15:51:30 <ayoung> slagle, I understand that.  I just think that we should focus on making a single tool to solve the use cases, instead of having two.  So, could rdo-manager assume the use cases currently handled by packstack?
15:51:47 <apevec> pmyers, aortega ^ see from social :)
15:51:55 <slagle> ayoung: right now, no. as packstack's use case is "all in one" aiui
15:52:06 <jruzicka> social, c) is only an option once director covers the packstack use cases. Does it?
15:52:07 <slagle> and that is expressly *not* the purpose of rdo-manager
15:52:12 <apevec> social, where is a) happening?
15:52:24 <jruzicka> Can I run a single command and get AIO openstackz on that machine?
15:52:28 <social> apevec: nonwork related side project
15:52:42 <slagle> now, we can deploy an overcloud in vm's all on one node. but that's a quite different all in one vs packstacks
15:52:53 <ayoung> slagle, can I use rdo-manager and only get the undercloud, and no-ironic?  Really, I just need Keystone and Nova.
15:52:57 <slagle> is more meant for using rdo-manager vs openstack
15:52:58 <ayoung> maybe glance
15:53:07 <slagle> ayoung: no. not without significant code changes
15:53:17 <mburned> jruzicka: yes, CI runs vm deployments
15:53:20 <apevec> social, where where? You're hiding it :) https://github.com/social?tab=repositories
15:53:34 <jruzicka> OK so it's possible just heavyweight. Hmm.
15:53:35 <mburned> jruzicka: it's not allinone, though
15:53:57 <mburned> jruzicka: minimum is 3 vms, 1 undercloud, 1 overcloud controller, 1 overcloud compute
15:54:30 <social> it's simple as that you want 1..n installer, packstack could do that even with scaling to HA wif it got the development, director won't be able to do that
15:54:42 <jruzicka> yeah so that vector instead of scalar :)
15:54:45 <social> solution for that could be to use at least same puppet composition layer
15:54:58 <social> and keep both in worst case
15:55:15 <ayoung> what is installed on the undercloud controller?
15:56:45 <ayoung> is it just nova, with not Keystone?
15:56:49 <slagle> ayoung: pretty much all of openstack
15:56:53 <slagle> with ironic
15:57:02 <slagle> keystone is there
15:57:06 <apevec> looks like we won't have conclusion on this topic, so I'll close the meeting, please continue talking :)
15:57:15 <apevec> #endmeeting