| *** e0ne has joined #openstack-loci | 06:24 | |
| *** e0ne has quit IRC | 06:36 | |
| *** e0ne has joined #openstack-loci | 06:45 | |
| *** e0ne has quit IRC | 07:27 | |
| *** e0ne has joined #openstack-loci | 07:36 | |
| *** e0ne has quit IRC | 07:36 | |
| *** e0ne has joined #openstack-loci | 08:01 | |
| *** e0ne has quit IRC | 08:10 | |
| *** e0ne has joined #openstack-loci | 08:20 | |
| *** e0ne has quit IRC | 08:21 | |
| *** e0ne has joined #openstack-loci | 10:01 | |
| *** dims has quit IRC | 11:21 | |
| *** hrw has quit IRC | 11:29 | |
| *** hrw has joined #openstack-loci | 11:29 | |
| *** dims has joined #openstack-loci | 13:01 | |
| *** dims has quit IRC | 13:07 | |
| *** dims has joined #openstack-loci | 13:07 | |
| evrardjp | o/ | 13:39 |
|---|---|---|
| evrardjp | hrw: more details about the "dumb-init"? It seems you're familiar with it :) | 13:40 |
| hrw | evrardjp: kolla uses it | 13:40 |
| hrw | and release is only for amd64 and ppc64le so we need to build it for arm64 | 13:41 |
| hrw | anyway abandoned | 13:41 |
| hrw | if someone will try to add it then I suggest grabbing binary package from Debian and reuse | 13:42 |
| hrw | more archs supported | 13:42 |
| hrw | https://github.com/Yelp/dumb-init/issues/138 | 13:43 |
| evrardjp | yeah I have seen it was used in kolla, and partially in osh | 14:50 |
| evrardjp | not really suire what it does | 14:50 |
| evrardjp | sure | 14:59 |
| evrardjp | * | 14:59 |
| hogepodge | #startmeeting loci | 15:00 |
| openstack | Meeting 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| *** openstack changes topic to " (Meeting topic: loci)" | 15:00 | |
| openstack | The meeting name has been set to 'loci' | 15:00 |
| hogepodge | #link https://etherpad.openstack.org/p/loci-meeting agenda | 15:01 |
| evrardjp | o/ | 15:01 |
| hogepodge | Hooray! We've increased our attendance by 100%! | 15:02 |
| *** lemko has joined #openstack-loci | 15:02 | |
| evrardjp | haha | 15:02 |
| evrardjp | hope you had nice holidays :) | 15:02 |
| evrardjp | do you have a link handy for last meeting(s)' action points? It's too far I can't remember :p | 15:03 |
| hogepodge | You 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 |
| evrardjp | hogepodge: that's good :) | 15:03 |
| hogepodge | Same link. I don't think we worked on any of the items from that list. | 15:03 |
| hogepodge | I have been working on possible AIO deployment to use for gate testing. | 15:04 |
| hogepodge | portdirect: you around? | 15:04 |
| hogepodge | Anyone else planning on joining? | 15:04 |
| hogepodge | ok, let's start off and we can chat about the topics on hand | 15:06 |
| evrardjp | I hope there will be more people indeed | 15:06 |
| evrardjp | sounds good | 15:06 |
| hogepodge | #topic stable release | 15:06 |
| *** openstack changes topic to "stable release (Meeting topic: loci)" | 15:06 | |
| hogepodge | Ok, so a big issue I've run into over the last month is building images from stable branches | 15:07 |
| hrw | o/ | 15:07 |
| hogepodge | Hi hrw! 200% increase from last week :-) | 15:07 |
| hrw | ;) | 15:07 |
| evrardjp | hogepodge: look at you getting big numbers! :p | 15:07 |
| hogepodge | evrardjp: I like to look at the optimistic side of things | 15:08 |
| evrardjp | hogepodge: so my concern there, is that there are many failing already, that's how I caught up a newton issue. | 15:08 |
| hogepodge | When distributions update packages, they frequently go outside the bounds of requirements repository, and the build will break. | 15:08 |
| evrardjp | so if we bring more branches into loci pipelines, we should make sure it's slowly phased, maybe non voting | 15:08 |
| evrardjp | hogepodge: sorry for the interruption | 15:09 |
| hogepodge | I 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 work | 15:10 |
| hogepodge | Build tests aren't sufficient, because they don't tell you if a requirement update functionally breaks a service | 15:10 |
| evrardjp | fair | 15:11 |
| evrardjp | but isn't that the scope of a deployment project? | 15:11 |
| evrardjp | can we leverage the existing, to prevent re-inventing the wheel? | 15:12 |
| hogepodge | I'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/locistack | 15:12 |
| evrardjp | (maybe continuing pbourke work on kolla-ansible? ) | 15:12 |
| hogepodge | That, or OpenStack Helm could be solutions. | 15:12 |
| evrardjp | I'd say that openstackhelm needs k8s and all that jazz, which is a bigger series of moving parts. | 15:14 |
| evrardjp | Not that I am pro or against | 15:14 |
| hogepodge | Yeah, I'd like to keep things as simple as possible. The solution I'm writing requires docker-compose, which is much smaller | 15:14 |
| evrardjp | I am currently working on the image building of OSH, and yeah, I hope we'll do functional testing of loci images | 15:15 |
| evrardjp | I am currently working on the image building of OSH, and yeah, I hope we'll do functional testing of loci images | 15:15 |
| evrardjp | sorry for my flaky bouncer there | 15:15 |
| hogepodge | In 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 needed | 15:16 |
| evrardjp | I like the idea of functional testing of loci images, not really linked to the issue of "out of requirements bounds" | 15:16 |
| hogepodge | no problem :-) | 15:16 |
| evrardjp | hogepodge: 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 distro | 15:17 |
| evrardjp | so I am really deeply curious of the root cuase | 15:17 |
| evrardjp | cause* | 15:17 |
| hogepodge | evrardjp: it's happened twice to me, once with Centos and once with Leap. Both were eventually corrected. | 15:17 |
| hogepodge | The root cause is distros update packages to new versions and the values exceed the largest allowable version of a dependency. | 15:18 |
| hrw | if you want to be sane then venv | 15:19 |
| evrardjp | I am probably too young in this project to really judge. I like the idea of functional testing though, as expressed earlier | 15:19 |
| hogepodge | So 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 distros | 15:19 |
| hogepodge | So 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 break | 15:20 |
| hogepodge | (when I say pip-version I mean python-libvirt) | 15:20 |
| evrardjp | let 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 |
| evrardjp | hogepodge: ok so for that I think you might have a different solution | 15:22 |
| evrardjp | instead 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 version | 15:23 |
| evrardjp | (in other words, building where libvirt is installed would produce a different result) | 15:24 |
| evrardjp | omg my english is bad | 15:24 |
| evrardjp | I will check some things in code | 15:24 |
| hogepodge | Two 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 |
| evrardjp | in the meantime, I think it's great you're working on a functional testing :) | 15:24 |
| hogepodge | I 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 |
| hogepodge | It's time consuming though and I hope it's the last time I'll take on such a task. | 15:26 |
| evrardjp | yup... deploy projects are like that :) | 15:27 |
| hogepodge | I 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 |
| portdirect | On the functional testing front, I 100% support a docker-compose approach | 15:28 |
| hogepodge | Up to 300%! This is truly a blockbuster meeting. Hi portdirect! | 15:28 |
| portdirect | Sam and I spun wheels on that for a bit, but it makes sense - apart from anything it's fast. | 15:28 |
| hrw | hogepodge: libvirt has stable api so you do not have to keep libvirt and python-libvirt in sync | 15:28 |
| hogepodge | If you try to build python-libvirt x against libvirt x+1 the build will fall over. | 15:29 |
| hrw | http://obs.linaro.org/ERP:/18.06/Debian_9/ - libvirt 4.3 libvirt-python 4.0 | 15:30 |
| hrw | kolla images work fine | 15:30 |
| hogepodge | kolla source or kolla packages? | 15:30 |
| hrw | source | 15:30 |
| hogepodge | it was libvirt that was breaking for me on my centos build | 15:31 |
| hrw | Debian libvirt maintainers do not keep both in sync | 15:31 |
| hogepodge | I use breaking lightly, because a bump in upper constraints would fix it | 15:31 |
| portdirect | In kolla, for source does it not still deploy the distro package for python-libvirt through? | 15:31 |
| portdirect | I'm pretty sure it used to | 15:32 |
| hogepodge | I don't know how kolla handles python dependencies. | 15:32 |
| evrardjp | portdirect: you probably have too? | 15:32 |
| evrardjp | or maybe there is some kind of libvirt-libs or something | 15:32 |
| evrardjp | god the package names is something I hate | 15:33 |
| hrw | portdirect: python-libvirt is from binary package | 15:33 |
| portdirect | hrw: which is why you won't hit this issue in kolla | 15:33 |
| hogepodge | distro packes will be self-consistent | 15:33 |
| hogepodge | packages | 15:33 |
| evrardjp | anyway, for individual issues we can talk about that later? :p I think we get the gist of the idea :) | 15:33 |
| hogepodge | Yes, we can move on I think. | 15:34 |
| hrw | portdirect: and those are binary packages I built. python-libvirt 4.0 against libvirt 4.3 | 15:34 |
| hrw | move on | 15:34 |
| hogepodge | #topic testing | 15:34 |
| *** openstack changes topic to "testing (Meeting topic: loci)" | 15:34 | |
| hogepodge | I 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 |
| hogepodge | Right now our testing is that we build a bunch of project for a bunch of distros. | 15:35 |
| evrardjp | on the previous topic: good luck hogepodge. | 15:35 |
| hogepodge | There's no functional or integration testing. | 15:35 |
| hogepodge | evrardjp: thanks, it's actually almost to the stage of booting VMs, once I'm there I can iterate with tempest | 15:36 |
| evrardjp | great :) | 15:36 |
| evrardjp | hogepodge: so for the testing I thought of two things | 15:36 |
| evrardjp | have something like goss , or have real functional testing | 15:37 |
| portdirect | Goss? | 15:38 |
| evrardjp | with your work of the precedent topic, we could maybe have minimum functional testing? | 15:38 |
| evrardjp | like serverspec | 15:38 |
| evrardjp | portdirect: ^ | 15:38 |
| evrardjp | https://github.com/aelsabbahy/goss | 15:38 |
| portdirect | I'd be a propoent of real functional testing off the bat | 15:39 |
| evrardjp | ok | 15:40 |
| evrardjp | sounds better and less work | 15:40 |
| portdirect | As checking that apis are running only scratch the surface | 15:40 |
| portdirect | Yup | 15:40 |
| evrardjp | afk | 15:40 |
| hogepodge | We could do a simple run of project specific tests on each build | 15:41 |
| hogepodge | someone started work on this in the keystone tree, but I don't think it's gone anywhere | 15:41 |
| portdirect | That as a starting point, and then eveolving toward something like tempest smoke would be awesome | 15:42 |
| portdirect | That was gagehugo | 15:42 |
| portdirect | I think I could twist his arm into giving it new life | 15:42 |
| hogepodge | cool :-) | 15:42 |
| hogepodge | use 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 |
| portdirect | Maybe, though it was osh based | 15:43 |
| portdirect | Being selfish, that's great for us | 15:43 |
| portdirect | But may be a bit heavy | 15:44 |
| portdirect | The flip side being, I think there would be some traction from osh people, who would be able to help | 15:44 |
| portdirect | Whereas another approach may be a bit hard to get outside interest in for things other than gating | 15:45 |
| hogepodge | if a job exists somewhere that uses loci containers (regardless of deployment tooling) we can trigger it on loci patches | 15:45 |
| portdirect | Yup | 15:45 |
| hogepodge | then 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 |
| portdirect | The idea we punted around with Sam ages ago, was some very lightweight testing in tree, and then cross gating with osh/openstack-projects | 15:46 |
| hogepodge | portdirect: I'll let you pursue that, and we can check back in. Sound good? | 15:47 |
| portdirect | Which leaves the door open for non osh deployment projects being 1st class citizens | 15:47 |
| portdirect | Sure, I'll follow this up | 15:48 |
| hogepodge | great, thanks! | 15:48 |
| hogepodge | evrardjp: hrw: any other actions or input? | 15:48 |
| hogepodge | Moving along then. | 15:49 |
| hogepodge | #topic cycle development | 15:49 |
| *** openstack changes topic to "cycle development (Meeting topic: loci)" | 15:49 | |
| hogepodge | We can start with some open reviews | 15:49 |
| hogepodge | #link https://review.openstack.org/#/c/624396/ Remove python-qpid-proton 0.14.0 build | 15:50 |
| hogepodge | We can start with this one, which has an open request for meeting time. | 15:50 |
| hogepodge | evrardjp: portdirect: I think you both had this action | 15:50 |
| hogepodge | The context is coming up with a pattern to remove stale requirements from upper-constraints | 15:52 |
| hogepodge | (which hey, might solve my other problem from earlier) | 15:52 |
| hogepodge | We 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 |
| hogepodge | Feedback 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 |
| hogepodge | Ok, 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 |
| hogepodge | Thanks everyone! | 15:57 |
| hogepodge | Last comments? I'll leave the floor open for three more minutes. | 15:57 |
| hogepodge | Thanks everybody! | 15:59 |
| hogepodge | #endmeeting | 15: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 | |
| openstack | Meeting ended Fri Jan 11 15:59:37 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/loci/2019/loci.2019-01-11-15.00.html | 15:59 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/loci/2019/loci.2019-01-11-15.00.txt | 15:59 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/loci/2019/loci.2019-01-11-15.00.log.html | 15:59 |
| *** e0ne has quit IRC | 16:00 | |
| evrardjp | thx hogepodge | 16:05 |
| *** e0ne has joined #openstack-loci | 16:08 | |
| *** evrardjp has quit IRC | 16:10 | |
| *** evrardjp has joined #openstack-loci | 16:11 | |
| *** e0ne has quit IRC | 16:24 | |
| *** e0ne has joined #openstack-loci | 16:24 | |
| *** e0ne has quit IRC | 16:39 | |
| *** lemko has quit IRC | 18:22 | |
| *** openstackstatus has quit IRC | 19:43 | |
| *** openstackstatus has joined #openstack-loci | 19:44 | |
| *** ChanServ sets mode: +v openstackstatus | 19:44 | |
| *** kmalloc has joined #openstack-loci | 19:50 | |
| *** kmalloc has quit IRC | 19:51 | |
| *** openstack has joined #openstack-loci | 20:14 | |
| *** ChanServ sets mode: +o openstack | 20:14 | |
| *** e0ne has joined #openstack-loci | 20:26 | |
| *** gagehugo has quit IRC | 22:15 | |
| *** gagehugo has joined #openstack-loci | 22:17 | |
| *** e0ne has quit IRC | 22:19 | |
| *** e0ne has joined #openstack-loci | 22:45 | |
| *** e0ne has quit IRC | 22:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!