Friday, 2019-01-11

*** e0ne has joined #openstack-loci06:24
*** e0ne has quit IRC06:36
*** e0ne has joined #openstack-loci06:45
*** e0ne has quit IRC07:27
*** e0ne has joined #openstack-loci07:36
*** e0ne has quit IRC07:36
*** e0ne has joined #openstack-loci08:01
*** e0ne has quit IRC08:10
*** e0ne has joined #openstack-loci08:20
*** e0ne has quit IRC08:21
*** e0ne has joined #openstack-loci10:01
*** dims has quit IRC11:21
*** hrw has quit IRC11:29
*** hrw has joined #openstack-loci11:29
*** dims has joined #openstack-loci13:01
*** dims has quit IRC13:07
*** dims has joined #openstack-loci13:07
evrardjpo/13:39
evrardjphrw: more details about the "dumb-init"? It seems you're familiar with it :)13:40
hrwevrardjp: kolla uses it13:40
hrwand release is only for amd64 and ppc64le so we need to build it for arm6413:41
hrwanyway abandoned13:41
hrwif someone will try to add it then I suggest grabbing binary package from Debian and reuse13:42
hrwmore archs supported13:42
hrwhttps://github.com/Yelp/dumb-init/issues/13813:43
evrardjpyeah I have seen it was used in kolla, and partially in osh14:50
evrardjpnot really suire what it does14:50
evrardjpsure14:59
evrardjp*14:59
hogepodge#startmeeting loci15:00
openstackMeeting started Fri Jan 11 15:00:47 2019 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
*** openstack changes topic to " (Meeting topic: loci)"15:00
openstackThe meeting name has been set to 'loci'15:00
hogepodge#link https://etherpad.openstack.org/p/loci-meeting agenda15:01
evrardjpo/15:01
hogepodgeHooray! We've increased our attendance by 100%!15:02
*** lemko has joined #openstack-loci15:02
evrardjphaha15:02
evrardjphope you had nice holidays :)15:02
evrardjpdo you have a link handy for last meeting(s)' action points? It's too far I can't remember :p15:03
hogepodgeYou too. I got very sick, with was a downside. But on the upside it forced me to take a lot of time to rest and I enjoyed the time doing nothing.15:03
evrardjphogepodge: that's good :)15:03
hogepodgeSame link. I don't think we worked on any of the items from that list.15:03
hogepodgeI have been working on possible AIO deployment to use for gate testing.15:04
hogepodgeportdirect: you around?15:04
hogepodgeAnyone else planning on joining?15:04
hogepodgeok, let's start off and we can chat about the topics on hand15:06
evrardjpI hope there will be more people indeed15:06
evrardjpsounds good15:06
hogepodge#topic stable release15:06
*** openstack changes topic to "stable release (Meeting topic: loci)"15:06
hogepodgeOk, so a big issue I've run into over the last month is building images from stable branches15:07
hrwo/15:07
hogepodgeHi hrw! 200% increase from last week :-)15:07
hrw;)15:07
evrardjphogepodge: look at you getting big numbers! :p15:07
hogepodgeevrardjp: I like to look at the optimistic side of things15:08
evrardjphogepodge: so my concern there, is that there are many failing already, that's how I caught up a newton issue.15:08
hogepodgeWhen distributions update packages, they frequently go outside the bounds of requirements repository, and the build will break.15:08
evrardjpso if we bring more branches into loci pipelines, we should make sure it's slowly phased, maybe non voting15:08
evrardjphogepodge: sorry for the interruption15:09
hogepodgeI believe that if we want to do branches, we need to run integration tests to guarantee that updates to requirements works for all major distros, then we can propose changes to openstack/requirements that guarantees a fix will work15:10
hogepodgeBuild tests aren't sufficient, because they don't tell you if a requirement update functionally breaks a service15:10
evrardjpfair15:11
evrardjpbut isn't that the scope of a deployment project?15:11
evrardjpcan we leverage the existing, to prevent re-inventing the wheel?15:12
hogepodgeI'm working on a simple loci-based installer that we might want to use, but it's pretty basic and might not be robust enough. https://github.com/hogepodge/locistack15:12
evrardjp(maybe continuing pbourke work on kolla-ansible? )15:12
hogepodgeThat, or OpenStack Helm could be solutions.15:12
evrardjpI'd say that openstackhelm needs k8s and all that jazz, which is a bigger series of moving parts.15:14
evrardjpNot that I am pro or against15:14
hogepodgeYeah, I'd like to keep things as simple as possible. The solution I'm writing requires docker-compose, which is much smaller15:14
evrardjpI am currently working on the image building of OSH, and yeah, I hope we'll do functional testing of loci images15:15
evrardjpI am currently working on the image building of OSH, and yeah, I hope we'll do functional testing of loci images15:15
evrardjpsorry for my flaky bouncer there15:15
hogepodgeIn general though, if we have any solution that uses loci and does stable branch integrated builds for multiple distros we can use it as a signal to requirements to do joint-gating and bump as needed15:16
evrardjpI like the idea of functional testing of loci images, not really linked to the issue of "out of requirements bounds"15:16
hogepodgeno problem :-)15:16
evrardjphogepodge: I am curious if that happens a lot. Because OSA is using upper constraints in venv for ages, and we never really had an issue, with any distro15:17
evrardjpso I am really deeply curious of the root cuase15:17
evrardjpcause*15:17
hogepodgeevrardjp: it's happened twice to me, once with Centos and once with Leap. Both were eventually corrected.15:17
hogepodgeThe root cause is distros update packages to new versions and the values exceed the largest allowable version of a dependency.15:18
hrwif you want to be sane then venv15:19
evrardjpI am probably too young in this project to really judge. I like the idea of functional testing though, as expressed earlier15:19
hogepodgeSo it's typically a one line fix, but the requirements maintainers won't bump a version to fix one distro without evidence it doesn't break other distros15:19
hogepodgeSo it's typically something like libvirt (which isn't pip built but is from the distro) is updated which forces the pip-version (which tightly tracks libvirt) to break15:20
hogepodge(when I say pip-version I mean python-libvirt)15:20
evrardjplet me check if I understand correctly and compare with osa: in osa, at some point we are building all wheels for a distro,so the minimum pip package version is the minimum taking consideration the packages/other pip packages, so that's why we seem to never break (compared to bare minimum). Here we build the wheels for upper constraints, but then we are pip installing which could means lower version, is that right?15:22
evrardjphogepodge: ok so for that I think you might have a different solution15:22
evrardjpinstead of lowering/increasing the minimum base version of a package, you could ensure the building of the wheel is taking the appropriate c binding for said version15:23
evrardjp(in other words, building where libvirt is installed would produce a different result)15:24
evrardjpomg my english is bad15:24
evrardjpI will check some things in code15:24
hogepodgeTwo things are happening. On a distro if I install libvirt, I may get version x. Upper constraints may limit python-libvirt to version x-1, which will cause the build to break.15:24
evrardjpin the meantime, I think it's great you're working on a functional testing :)15:24
hogepodgeI need an environment I can stand up quickly and repeatedly. :-) The functional testing will be a nice side effect. I also like to do little manual installs to check on the progress and health of individual projects and how they're evolving.15:25
hogepodgeIt's time consuming though and I hope it's the last time I'll take on such a task.15:26
evrardjpyup... deploy projects are like that :)15:27
hogepodgeI have all sorts of feedback to individual projects, which I'm not sure if it would be welcomed or not (for example, all api projects should have consistent ways to launch as a wsgi app, currently Neutron stands out as an odd duck in that field)15:28
portdirectOn the functional testing front, I 100% support a docker-compose approach15:28
hogepodgeUp to 300%! This is truly a blockbuster meeting. Hi portdirect!15:28
portdirectSam and I spun wheels on that for a bit, but it makes sense - apart from anything it's fast.15:28
hrwhogepodge: libvirt has stable api so you do not have to keep libvirt and python-libvirt in sync15:28
hogepodgeIf you try to build python-libvirt x against libvirt x+1 the build will fall over.15:29
hrwhttp://obs.linaro.org/ERP:/18.06/Debian_9/ - libvirt 4.3 libvirt-python 4.015:30
hrwkolla images work fine15:30
hogepodgekolla source or kolla packages?15:30
hrwsource15:30
hogepodgeit was libvirt that was breaking for me on my centos build15:31
hrwDebian libvirt maintainers do not keep both in sync15:31
hogepodge I use breaking lightly, because a bump in upper constraints would fix it15:31
portdirectIn kolla, for source does it not still deploy the distro package for python-libvirt through?15:31
portdirectI'm pretty sure it used to15:32
hogepodgeI don't know how kolla handles python dependencies.15:32
evrardjpportdirect: you probably have too?15:32
evrardjpor maybe there is some kind of libvirt-libs or something15:32
evrardjpgod the package names is something I hate15:33
hrwportdirect: python-libvirt is from binary package15:33
portdirecthrw: which is why you won't hit this issue in kolla15:33
hogepodgedistro packes will be self-consistent15:33
hogepodgepackages15:33
evrardjpanyway, for individual issues we can talk about that later? :p I think we get the gist of the idea :)15:33
hogepodgeYes, we can move on I think.15:34
hrwportdirect: and those are binary packages I built. python-libvirt 4.0 against libvirt 4.315:34
hrwmove on15:34
hogepodge#topic testing15:34
*** openstack changes topic to "testing (Meeting topic: loci)"15:34
hogepodgeI wanted us to think about how we could rework our testing to be a bit more robust. It's similar to the last topic so maybe doesn't need much discussion, but if anyone has ideas I'd love to hear them.15:35
hogepodgeRight now our testing is that we build a bunch of project for a bunch of distros.15:35
evrardjpon the previous topic: good luck hogepodge.15:35
hogepodgeThere's no functional or integration testing.15:35
hogepodgeevrardjp: thanks, it's actually almost to the stage of booting VMs, once I'm there I can iterate with tempest15:36
evrardjpgreat :)15:36
evrardjphogepodge: so for the testing I thought of two things15:36
evrardjphave something like goss , or have real functional testing15:37
portdirectGoss?15:38
evrardjpwith your work of the precedent topic, we could maybe have minimum functional testing?15:38
evrardjplike serverspec15:38
evrardjpportdirect: ^15:38
evrardjphttps://github.com/aelsabbahy/goss15:38
portdirectI'd be a propoent of real functional testing off the bat15:39
evrardjpok15:40
evrardjpsounds better and less work15:40
portdirectAs checking that apis are running only scratch the surface15:40
portdirectYup15:40
evrardjpafk15:40
hogepodgeWe could do a simple run of project specific tests on each build15:41
hogepodgesomeone started work on this in the keystone tree, but I don't think it's gone anywhere15:41
portdirectThat as a starting point, and then eveolving toward something like tempest smoke would be awesome15:42
portdirectThat was gagehugo15:42
portdirectI think I could twist his arm into giving it new life15:42
hogepodgecool :-)15:42
hogepodgeuse that as a starting point? I want to be careful about work I assign for myself so I don't over-promise and under-deliver.15:43
portdirectMaybe, though it was osh based15:43
portdirectBeing selfish, that's great for us15:43
portdirectBut may be a bit heavy15:44
portdirectThe flip side being, I think there would be some traction from osh people, who would be able to help15:44
portdirectWhereas another approach may be a bit hard to get outside interest in for things other than gating15:45
hogepodgeif a job exists somewhere that uses loci containers (regardless of deployment tooling) we can trigger it on loci patches15:45
portdirectYup15:45
hogepodgethen if something simpler comes along we can switch to that, so leveraging existing and cross project work is always better, especially if it means more hands on deck (to use airship terminology)15:46
portdirectThe idea we punted around with Sam ages ago, was some very lightweight testing in tree, and then cross gating with osh/openstack-projects15:46
hogepodgeportdirect: I'll let you pursue that, and we can check back in. Sound good?15:47
portdirectWhich leaves the door open for non osh deployment projects being 1st class citizens15:47
portdirectSure, I'll follow this up15:48
hogepodgegreat, thanks!15:48
hogepodgeevrardjp: hrw: any other actions or input?15:48
hogepodgeMoving along then.15:49
hogepodge#topic cycle development15:49
*** openstack changes topic to "cycle development (Meeting topic: loci)"15:49
hogepodgeWe can start with some open reviews15:49
hogepodge#link https://review.openstack.org/#/c/624396/ Remove python-qpid-proton 0.14.0 build15:50
hogepodgeWe can start with this one, which has an open request for meeting time.15:50
hogepodgeevrardjp: portdirect: I think you both had this action15:50
hogepodgeThe context is coming up with a pattern to remove stale requirements from upper-constraints15:52
hogepodge(which hey, might solve my other problem from earlier)15:52
hogepodgeWe could add yet another environment variable that iterates over a set of packages and removes them at build time, which seems like a maintainable solution.15:53
hogepodgeFeedback on that? I'll leave a comment to that effect in the review, and maybe we can iterate one more patch to implement it.15:55
hogepodgeOk, hearing nothing more, I think we can close the meeting and revisit more cycle priority topics for next week. with testing I think we have a lot on our plate already.15:57
hogepodgeThanks everyone!15:57
hogepodgeLast comments? I'll leave the floor open for three more minutes.15:57
hogepodgeThanks everybody!15:59
hogepodge#endmeeting15:59
*** openstack changes topic to "Build image -- `docker build https://github.com/openstack/loci.git --build-arg PROJECT=keystone` || Review patches -- https://review.openstack.org/#/q/projects:openstack/loci+status:open"15:59
openstackMeeting ended Fri Jan 11 15:59:37 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/loci/2019/loci.2019-01-11-15.00.html15:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/loci/2019/loci.2019-01-11-15.00.txt15:59
openstackLog:            http://eavesdrop.openstack.org/meetings/loci/2019/loci.2019-01-11-15.00.log.html15:59
*** e0ne has quit IRC16:00
evrardjpthx hogepodge16:05
*** e0ne has joined #openstack-loci16:08
*** evrardjp has quit IRC16:10
*** evrardjp has joined #openstack-loci16:11
*** e0ne has quit IRC16:24
*** e0ne has joined #openstack-loci16:24
*** e0ne has quit IRC16:39
*** lemko has quit IRC18:22
*** openstackstatus has quit IRC19:43
*** openstackstatus has joined #openstack-loci19:44
*** ChanServ sets mode: +v openstackstatus19:44
*** kmalloc has joined #openstack-loci19:50
*** kmalloc has quit IRC19:51
*** openstack has joined #openstack-loci20:14
*** ChanServ sets mode: +o openstack20:14
*** e0ne has joined #openstack-loci20:26
*** gagehugo has quit IRC22:15
*** gagehugo has joined #openstack-loci22:17
*** e0ne has quit IRC22:19
*** e0ne has joined #openstack-loci22:45
*** e0ne has quit IRC22:51

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!