| adam_g | morganfainberg, IIRC the discussion a while back around the original patch (to neutron or nova?) that did the same was that it'd be an okay exception if the new config values default to the existing behavior | 00:01 |
|---|---|---|
| morganfainberg | adam_g: will 2x check and press go if it mirrors current behavior | 00:02 |
| morganfainberg | adam_g: thanks | 00:02 |
| morganfainberg | (it looks like it does) | 00:02 |
| *** david-lyle has quit IRC | 00:20 | |
| Daviey | morganfainberg: Adding config options is really not as bad as is feared, providing the path of least suprise is followed. Ie, keeping the current default behaviour (unless security is a reason, then things change) | 00:30 |
| morganfainberg | Daviey: good to know | 00:58 |
| *** jamielennox|away is now known as jamielennox | 01:23 | |
| *** david-lyle has joined #openstack-stable | 01:35 | |
| *** pixelb has quit IRC | 02:09 | |
| *** david-lyle has quit IRC | 02:33 | |
| *** david-lyle has joined #openstack-stable | 03:11 | |
| *** gnuoy has quit IRC | 04:05 | |
| *** jamespage has quit IRC | 04:05 | |
| *** gnuoy has joined #openstack-stable | 04:06 | |
| *** jamespage has joined #openstack-stable | 04:06 | |
| *** e0ne has joined #openstack-stable | 06:01 | |
| *** e0ne has quit IRC | 06:11 | |
| *** e0ne has joined #openstack-stable | 08:15 | |
| *** e0ne has quit IRC | 08:19 | |
| *** pixelb has joined #openstack-stable | 08:29 | |
| *** ihrachyshka has joined #openstack-stable | 08:58 | |
| *** e0ne has joined #openstack-stable | 09:23 | |
| *** e0ne is now known as e0ne_ | 09:23 | |
| *** e0ne_ is now known as e0ne | 09:31 | |
| *** derekh has joined #openstack-stable | 09:37 | |
| *** e0ne is now known as e0ne_ | 11:26 | |
| *** openstack has joined #openstack-stable | 11:38 | |
| *** e0ne is now known as e0ne_ | 12:09 | |
| *** e0ne_ is now known as e0ne | 12:14 | |
| *** eharney has quit IRC | 12:40 | |
| *** mrunge has joined #openstack-stable | 12:44 | |
| *** mrunge_ has joined #openstack-stable | 12:44 | |
| *** mrunge has quit IRC | 12:45 | |
| *** mrunge_ has quit IRC | 12:45 | |
| *** mrunge has joined #openstack-stable | 12:45 | |
| *** bknudson has joined #openstack-stable | 13:06 | |
| *** mriedem_away is now known as mriedem | 13:17 | |
| *** eharney has joined #openstack-stable | 13:30 | |
| number80 | zigo++ | 13:54 |
| number80 | (I read your packaging proposal, still processing this :) ) | 13:55 |
| ihrachyshka | number80, delorean could lead the way since all the workflow is already set for that, the "only" thing that we would need is switching to stackforge and u/s infra | 13:56 |
| number80 | ihrachyshka: yes, that's what I've been thinking, and I don't mind moving Delorean upstream | 13:57 |
| number80 | but I'm not the only one to be convinced to do that switch :) | 13:57 |
| number80 | adding debian/ubuntu support in Delorean is a small task | 13:58 |
| *** apevec has joined #openstack-stable | 13:59 | |
| *** apevec has joined #openstack-stable | 13:59 | |
| ihrachyshka | number80, yes, we need deb-master ;) | 13:59 |
| ihrachyshka | honestly, I wouldn't even mind if debian packages are maintained in the same branch, to boost collaboration, but gerrit ACLs are not tree based, and allowing fedora guys to merge stuff for debian and vice versa is probably silly (but we could rely on trust and not ACLs) | 14:01 |
| number80 | +2 | 14:01 |
| number80 | I don't mind having cross-collaboration between packaging "groups" | 14:02 |
| zigo | number80: Why would we use something else than sbuild? | 14:02 |
| zigo | number80: ihrachyshka: As I wrote, the issue is that we don't use the same package names, on top of that. | 14:03 |
| number80 | zigo: Delorean pattern is to run build tools in a container for isolation purpose, so you'd still use sbuild | 14:04 |
| zigo | Not sure what you guys would do, but I would try to keep things consistent in this regard. | 14:04 |
| ihrachyshka | zigo, spec contents is what defines artificats naming, not repo name, right? | 14:04 |
| ihrachyshka | *artifacts | 14:04 |
| zigo | number80: Well, sbuild already uses LVM snapshots for the chroots, so I don't see why we would need containers. | 14:04 |
| zigo | A chroot is more than enough for building. | 14:04 |
| zigo | No need to use docker and such. | 14:04 |
| ihrachyshka | artificats... meow | 14:05 |
| zigo | I know docker is trendy, but it itsn't the answer to everything. | 14:05 |
| ihrachyshka | zigo, well, I guess we could extend delorean to use other tools for other platforms. the point is to have common UI. | 14:05 |
| number80 | zigo: we do have sbuild-like tool (mock) but in rare cases, it's not enough (as far fedora is involved, our builders are in VMs) | 14:05 |
| zigo | number80: Interesting! In which cases? | 14:06 |
| ihrachyshka | number80, an example of when it's not enough would be appreciated | 14:06 |
| number80 | (just for the record, I'm trying to understand and see how we could converge!) | 14:06 |
| zigo | The thing is, sbuild is already used in the Debian buildd network, so I wouldn't want to use anything else. Canonical guys expressed the same opinion. | 14:06 |
| ihrachyshka | zigo, what is buildd network? | 14:07 |
| zigo | If we do, we may have bad surprises with fail-to-build issues. | 14:07 |
| ihrachyshka | ah, it's koji :) | 14:07 |
| zigo | ihrachyshka: In Debian, we build packages which are non arch: all through a network of machines with different arch. | 14:07 |
| zigo | ihrachyshka: Everything is built on a machine running the target arch. | 14:08 |
| number80 | zigo, ihrachyshka: in some cases, you may have malicious code that tries to get out of the chroot (in the rare cases, where fedora infra has been compromised, some people did try malicious builds) | 14:08 |
| ihrachyshka | zigo, so you would build a package in debian infra for openstack needs? | 14:08 |
| zigo | For example, we have arm64 machines in Cambridge ... | 14:08 |
| zigo | ihrachyshka: Only on amd64. | 14:08 |
| zigo | Which is where uploading to distributions makes more sense, as it adds more arch. | 14:09 |
| ihrachyshka | zigo, but still, you would bomb debian infra with irrelevant requests. | 14:09 |
| number80 | anyway, we could probably not enforce using docker | 14:09 |
| zigo | ihrachyshka: What? Sorry, I didn't get that one. | 14:09 |
| ihrachyshka | zigo, if CI is in place, and a patch for debian packaging is uploaded, where would the package be built? in debian infra or openstack one? | 14:09 |
| zigo | My proposal is *not* to use the Debian buildd network, but to use the same system in OpenStack infra, just to be on the safe side. | 14:10 |
| zigo | So that if we build a package on OpenStack infra, we know it will build the same way as in the Debian buildd network when we upload it there. | 14:11 |
| ihrachyshka | zigo, aha. so you would run 'buildd' like node there for packaging? | 14:11 |
| zigo | Which leads to: we can't use anything else than sbuild. | 14:11 |
| zigo | ihrachyshka: No, just sbuild. | 14:11 |
| zigo | I don't think we have any reason to build for anything else than amd64. | 14:11 |
| number80 | zigo: got that | 14:11 |
| ihrachyshka | ok, so sbuild is debian way to do delorean. | 14:11 |
| zigo | LOL ! :) | 14:11 |
| zigo | ihrachyshka: delorean is new, no? | 14:12 |
| zigo | sbuild is like over a decade old. | 14:12 |
| ihrachyshka | zigo, yes, at least most (all?) packages are noarch in any case | 14:12 |
| number80 | zigo: no, we used it for at least 2 or 3 releases (it's our Continuous Delivery platform, we even have some reporting) | 14:12 |
| zigo | Also, in Debian, we have some crazy guys that are rebuilding all of the Debian archive using AWS. | 14:12 |
| ihrachyshka | zigo, well, I don't think I'm interested in deciding whose history is older, I just try to understand whether there is any common ground | 14:12 |
| number80 | I was just mentioning this to bootstrap the conversation, as I wasn't at summit | 14:12 |
| zigo | These tests are using sbuild too. | 14:13 |
| zigo | ihrachyshka: Sure, I'm just reacting to the "sbuild is debian way to do delorean"... | 14:13 |
| number80 | getting rid of delorean is an option | 14:13 |
| number80 | but at least, I'd like to share as much infrastructure (especially reporting) | 14:13 |
| zigo | number80: I'm sure that RPM world tests will be different. | 14:15 |
| zigo | Like, we use lintian, piuparts, adequate ... | 14:15 |
| ihrachyshka | the problem with having two different tools is that openstack-infra would need to maintain separate jobs for both. not that it's a huge waste of resources (I just don't know), but if we would be able to come with some common UI, that would be better I guess. sbuild could still be under the hood for debian package updates. | 14:16 |
| number80 | zigo: not much | 14:16 |
| number80 | (I do have some experience in Debian packaging and we have common issues) | 14:16 |
| zigo | If we can share some tools, then great, but I just don't think it's going to be the case. | 14:16 |
| number80 | ok | 14:16 |
| ihrachyshka | number80, do we even run QE on package updates on every upload? I don't think so, the only time I saw those tools involved was initial package review process | 14:16 |
| number80 | zigo: then, it's even a lower barrier for everyone to jump in | 14:17 |
| zigo | So, if I understand well, Fedora uses delorean and VMs to build packages by default? | 14:17 |
| number80 | ihrachyshka: for RDO, we run CI over every update and even have now repo-level (basic) CI | 14:17 |
| ihrachyshka | number80, yeah, but do we run e.g. rpmlint? | 14:18 |
| zigo | It's my strong feeling that it'd be better to use what the distributions are using in Fedora's case too, but I'll let others to decide for anything non-debianish. | 14:18 |
| ihrachyshka | zigo, there may be no Fedora packages whatsoever, just RDO | 14:18 |
| number80 | ihrachyshka: no, too much false positives | 14:18 |
| zigo | ihrachyshka: As you like! :) | 14:18 |
| zigo | I never really understood the barrier between RDO and Fedora. | 14:19 |
| ihrachyshka | number80, and I guess zigo meant that they run similar tools on upload | 14:19 |
| zigo | Isn't it the same packages? | 14:19 |
| ihrachyshka | zigo, Fedora packages are just broken versions of RDO :D | 14:19 |
| zigo | LOL ! :) | 14:19 |
| zigo | .oO(Note for later: use RDO, not Fedora...) | 14:19 |
| number80 | zigo: off course, we have to reuse build system and guidelines from downstream (+2) | 14:19 |
| ihrachyshka | zigo, they are the same, but they don't get timely updates in most cases, so it's better to discourage people from even trying them | 14:19 |
| zigo | Got you. | 14:19 |
| zigo | ihrachyshka: FYI, it's also often painful for me to do updates in Debian in a timely maner. | 14:20 |
| ihrachyshka | zigo, and that's why there are ideas floating around to just drop them not to show ourselves in bad shape for no reason. | 14:20 |
| apevec | catching up (btw aren't we off-topic here? :) .... re. builders in infra, I'm looking at https://etherpad.openstack.org/p/YVR-infra-meetup-packaging and https://review.openstack.org/#/c/179713/2/specs/build_distribution_packages.rst | 14:20 |
| zigo | Unless there's an friendly FTP master looking over it, that is (which I have, but he's often busy doing something else...). | 14:20 |
| apevec | IIUC infra will just give us bare VMs and we can run whatever tools inside we like | 14:21 |
| apevec | i.e. deb => sbuild | 14:21 |
| ihrachyshka | zigo, there is no big deal in fedora per se, it's just that people are bad at handling packaging for multiple sources (fedora + rdo of multiple platforms), and since everyone is busy with upstream stuff, fedora packages lag | 14:21 |
| zigo | Oh, I didn't see the HP stuff. | 14:21 |
| * zigo is reading... | 14:21 | |
| apevec | rpm => mock or delorean | 14:21 |
| number80 | and use gerrit for packages reviews (which is exactly how we work for delorean packaging) | 14:21 |
| * number80 has to leave | 14:22 | |
| number80 | I will read my logs, and this is a very interesting discussion and we should definitively try to reach agreement and full understanding asap | 14:22 |
| zigo | "Currently, OpenStack is at the mercy of upstream distributions with respect to what we can easily install on our build infrastructure." <--- Seriously, HP did absolutely ZERO contribution back to Debian, it's not serious to write such a thing. | 14:23 |
| ihrachyshka | btw if we somehow decide to keep packaging for all platform in a single repo, then we would need to make sure the proper jobs are executed only (so that no debian job is run on rpm update). it's doable with file filters in project-config | 14:23 |
| number80 | zigo: anyway, doers will do as they wish, let the others bark | 14:24 |
| apevec | zigo, yeah, but spec is out there, so we need to provide feedback... | 14:24 |
| *** jokke_ has quit IRC | 14:24 | |
| *** jokke_ has joined #openstack-stable | 14:24 | |
| apevec | ihrachyshka, I think separate repos are better, and if single repo, it would be separate branches... | 14:25 |
| apevec | depends on ACLs, that's discussed in zigo's proposal | 14:25 |
| ihrachyshka | apevec, gerrit is dumb, it can't give ACLs per directory :( | 14:26 |
| ihrachyshka | that limitation hits openstack hard | 14:26 |
| ihrachyshka | neutron started to split partly because of that | 14:26 |
| apevec | yeah, so must be per branch or separate repo | 14:26 |
| ihrachyshka | apevec, unless we trust :) | 14:26 |
| apevec | trust but verify! | 14:26 |
| apevec | i.e. ACL is must :) | 14:27 |
| ihrachyshka | AND I DON'T TRUST zigo !!! | 14:27 |
| ihrachyshka | :) | 14:27 |
| number80 | ihrachyshka: I know where he lives, I don't need to trust him :) | 14:27 |
| ihrachyshka | that's what I meant my trusting - actual sharing of everyone's home addresses | 14:28 |
| ihrachyshka | my -> by | 14:28 |
| Daviey | The other solution is to have a branch per packaging type, and maybe even a derived branch per distro? | 14:30 |
| number80 | :) | 14:30 |
| Daviey | kilo_deb -> kilo_debian | kilo_ubuntu , kilo_rpm, kilo_rdo | kilo_suse ? | 14:31 |
| ihrachyshka | Daviey, I think in delorean, that was an idea behind renaming f20-master branch into rpm-master. like 'what if one day we get other package types?' | 14:31 |
| Daviey | ihrachyshka: nice | 14:31 |
| ihrachyshka | if there is suse in the game, rpm in the branch name would be too vague though | 14:32 |
| Daviey | ihrachyshka: Does RDO and SUSE not share any commonality with the packages? | 14:33 |
| ihrachyshka | Daviey, I would be amused to realize that's the case since I don't even know who packages it. | 14:33 |
| Daviey | ihrachyshka: that is probably sader than the debian/ubuntu relationship then! | 14:33 |
| ihrachyshka | Daviey, though yeah, we could try to diverge. it will depend whether there are actual differences in contents though (like whether config files and log files are in the same locations) | 14:34 |
| Daviey | ihrachyshka: Well, i was suggesting that there is a top level for the packaging type maybe, and derived from that for each distro | 14:34 |
| ihrachyshka | Daviey, also, RDO is systemd heavy, not sure what suse does these days. so obviously we should try to have common specs, but it can be touch | 14:34 |
| ihrachyshka | *tough | 14:34 |
| Daviey | ihrachyshka: That is mostly the issues that Ubuntu and Debian had failed to deal with | 14:35 |
| Daviey | systemd vs upstart co-exist in packaging | 14:36 |
| Daviey | and interactive installing (asking questions) vs sideband configuring | 14:36 |
| ihrachyshka | Daviey, in rpm specs, we can conditionalize based on platform though | 14:36 |
| ihrachyshka | Daviey, you mean debconf not used by ubuntu? | 14:36 |
| Daviey | ihrachyshka: yeah, ubuntu doesnt really use debconf for packaging openstack | 14:37 |
| Daviey | ihrachyshka: and it can also be conditional, but rather than each distro integrating both formats it turned into both badly supporting both | 14:37 |
| Daviey | ihrachyshka: The mindset of ubuntu is that anyone doing openstack seriously is using something like juju, puppet, chef, ansible or saltstack and really.. debconf just gets in the way for that. | 14:38 |
| zigo | ihrachyshka: It can't have ACLs per directory, but it can per branch. | 14:38 |
| Daviey | ^^ that is what i was suggesting | 14:39 |
| zigo | Anyway, I'm for separated repository. | 14:39 |
| zigo | Daviey: As for Debian & Ubuntu, the goal is to *not* have separate packaging branches. | 14:39 |
| zigo | So we can work together. | 14:39 |
| zigo | When unavoidable, we will, but we will try not. | 14:40 |
| Daviey | zigo: Totally, but having common ancestory is a pretty good start towards that | 14:40 |
| zigo | ihrachyshka: Isn't the solution to support multiple init systems, like I did for Debian, and which Ubuntu adopted (in openstack-pkg-tools)? | 14:41 |
| *** eharney has quit IRC | 14:42 | |
| zigo | Daviey: You're wrong about about the fact we didn't deal with multiple init systems, see above. | 14:42 |
| zigo | Daviey: Ubuntu adopted my openstack-pkg-tools for this very reason: so they could support all 3 init systems at once. | 14:42 |
| Daviey | zigo: I'm sorry, but i am really not wrong about this... the .upstart was partially added to debian packages and the same in reverse | 14:43 |
| zigo | Daviey: What we never agreed on, is the use of Debconf for configuring packages. | 14:43 |
| Daviey | it was totally broken in both distros | 14:43 |
| zigo | Daviey: Which is why I wrote stuff in openstack-pkg-tools: to make sure that all init scripts, for all 3 systems, are consistent. | 14:44 |
| zigo | Daviey: The issue was more that it is painful to maintain more than 70 daemons ... | 14:44 |
| Daviey | Indeed.. So it was badly done in both distros | 14:45 |
| ihrachyshka | zigo, for redhat, there is no other rc system. | 14:45 |
| zigo | Let's say you realise something is wrong, then you need to edit 70 init scripts * 3 init systems. | 14:45 |
| ihrachyshka | zigo, if suse has one and wants to collaborate, surely we can add it | 14:45 |
| Daviey | ihrachyshka: RHEL6 disgarees with you :) | 14:45 |
| ihrachyshka | Daviey, we don't build Juno+ for el6 | 14:45 |
| zigo | ihrachyshka: I'd suggest that you write some kind of helper to bring consistency (if that is possible...). | 14:45 |
| ihrachyshka | sure. if there is an issue to solve, we'll do smth about it :) | 14:46 |
| Daviey | ihrachyshka: True | 14:46 |
| Daviey | zigo: Anyway, now we have all agreed that the one true direction is SystemD, life becomes somewhat easier.. right? :) | 14:47 |
| bknudson | https://review.openstack.org/#/c/175519/ is a security fix in keystone that hasn't been +W yet for some reason | 14:47 |
| Daviey | zigo: BTW, i wish i saw the packaging meetup advertised.. i'd have been there. | 14:47 |
| zigo | Daviey: I am not sure if we "all agreed", but that's currently the state of things, so let's just try to use what we have ! :) | 14:48 |
| zigo | I've always been on the side of "let's support as much as we can", though of course one them has to be the default. | 14:49 |
| zigo | Systemd as issues, but sysv-rc too ... | 14:49 |
| Daviey | zigo: That is my view aswell.. better to have agreed on something than have 100 perfect implementations | 14:49 |
| zigo | Right. | 14:49 |
| ihrachyshka | speaking of converging... do we want to see systemd units in upstream projects? ;) | 14:50 |
| zigo | Oh, BTW, I'm the package maintainer of OpenRC in Debian ! :) | 14:50 |
| zigo | ihrachyshka: I don't want them there, no. | 14:50 |
| zigo | ihrachyshka: This has to be distribution specific. In Debian, it's not even stored anywhere, it's generated ... | 14:50 |
| ihrachyshka | zigo, right. we could think of templates to use for generation (?) | 14:51 |
| zigo | ihrachyshka: http://thomas.goirand.fr/blog/?p=212 | 14:51 |
| zigo | ihrachyshka: I'd be *very* happy to share this with Fedora people. | 14:51 |
| zigo | tl;dr: I'm using the begining of a sysv-rc init script as a template. | 14:52 |
| * ihrachyshka adds the link to things-to-read | 14:52 | |
| zigo | FYI, there's been some scripting improvements since. | 14:52 |
| zigo | But the main idea of this blog post remains. | 14:53 |
| zigo | (and is currently implemented in both Debian & Ubuntu packages for OpenStack) | 14:53 |
| zigo | .oO( I thought this channel was always idle... ) | 14:54 |
| ihrachyshka | zigo, you started fire with your email | 14:55 |
| Daviey | Actually... systemd being in upstream isn't as crazy as it sounds. | 14:55 |
| Daviey | Before Systemd won the war, i'd have disagreed.. but why does it now not make sense? | 14:55 |
| ihrachyshka | Daviey, afaik systemd upstream claims that's the way to do it since systemd is platform independent | 14:56 |
| Daviey | exactly | 14:56 |
| Daviey | The thiner the packaging is, the better - surely? | 14:57 |
| *** jamespage_ has joined #openstack-stable | 15:02 | |
| zigo | Daviey: Because we wont use it, since we generate the .service files in Debian & Ubuntu. | 15:06 |
| zigo | Daviey: So only RDO would use it, therefore, it doesn't make sense. | 15:06 |
| ihrachyshka | zigo, but if you have templates, wouldn't you use them? | 15:06 |
| zigo | ihrachyshka: I wouldn't, because I want to keep the fact that things like log path are hard-wired in templates. | 15:07 |
| Daviey | zigo: ] | 15:07 |
| zigo | Having too much things written in the .service files means that it's hard to do change in all packages. | 15:07 |
| Daviey | zigo: erm, that is a pretty poor reason for rejecting collaborative work | 15:07 |
| zigo | Daviey: I've proposed to others to use the same generation of .service files as we do... | 15:08 |
| zigo | I'm all for more collaboration. | 15:08 |
| ihrachyshka | zigo, why not provide log file name for substitution? | 15:08 |
| zigo | ihrachyshka: What do you mean? | 15:09 |
| Daviey | zigo: well, you blew out the entire idea without any consideration.. that isn't collaboration! :) | 15:09 |
| Daviey | zigo: Does systemd not support variable substitution of values? | 15:09 |
| ihrachyshka | whatever, I'm not that interested in systemd. we can consider it later if/once we see any convergence. | 15:09 |
| zigo | Daviey: I've given points of argumentations, it's not like it I just blew it without reasons. | 15:09 |
| zigo | ihrachyshka: What do you use then? sysv-rc or upstart? | 15:10 |
| zigo | If you use any of the 3, then you're still interested in having things generated. | 15:10 |
| zigo | The burden of maintenance is too high otherwise. | 15:10 |
| Daviey | zigo: I would suggest a collaborative way would be, it can work for us if... rather than, we can't use it because...! | 15:10 |
| ihrachyshka | zigo, we use systemd, we don't generate those (at least not in neutron), though we want to look into it in liberty. | 15:11 |
| zigo | ihrachyshka: FYI, for the OVS agent daemon, we don't use generated .service, that's in fact the only exception ! :) | 15:11 |
| ihrachyshka | zigo, if we would be able to execute some externally managed tool passing some args to generate results, that would be better for us than copying your generator around branches | 15:11 |
| zigo | ihrachyshka: Another thing we got to remember is that having consistency accros distribution makes life easier for documentation people. | 15:12 |
| zigo | Things like log file path and so on, it's easy to make it consistent. | 15:13 |
| *** e0ne is now known as e0ne_ | 15:13 | |
| ihrachyshka | zigo, it should be consistent across distros, not just in single distro. otherwise puppet guys swear in our direction. | 15:13 |
| ihrachyshka | (and docs too, right) | 15:13 |
| zigo | Exactly right! | 15:13 |
| zigo | Puppet guys also want us to be consistent. | 15:14 |
| zigo | Thanks for the reminder... :) | 15:14 |
| ihrachyshka | zigo, we have neutron/RDO bashed once in a while for not following (bad) example of ubuntu that passes ml2_conf.ini to ovs agent | 15:14 |
| ihrachyshka | it's even documented as an RDO bug in official docs (while it's not and is intentional) | 15:14 |
| zigo | ihrachyshka: I've also been pointed finger at for the same reason. | 15:15 |
| ihrachyshka | zigo, so you don't pass plugin.ini there? | 15:15 |
| ihrachyshka | cool! | 15:15 |
| zigo | ihrachyshka: IMO, the issue here is that the install-guide is ubuntu centric. | 15:15 |
| zigo | ihrachyshka: I do ! :) | 15:15 |
| ihrachyshka | oh, if you pass it, that's incorrect :) | 15:15 |
| ihrachyshka | because plugin.ini is controller side | 15:15 |
| zigo | ihrachyshka: What I do is looking at the core_plugin directive, and conveniently pass the corresponding .ini file to the OVS agent. | 15:15 |
| ihrachyshka | ovs agent should only read ovs_neutron_plugin.ini (yes, the name is wrong for historical reasons) | 15:16 |
| zigo | ihrachyshka: http://anonscm.debian.org/cgit/openstack/neutron.git/tree/debian/plugin_guess_func | 15:17 |
| ihrachyshka | zigo, even if core_plugin is ml2, you still should pass ovs_neutron_plugin.ini to ovs agent, not ml2_conf.ini | 15:18 |
| zigo | ihrachyshka: There's an ovs_neutron_plugin.ini file and an ml2_conf.ini with directives there on upstream etc folder. | 15:18 |
| zigo | Why not using what upstream provides? | 15:18 |
| zigo | The day upstream git repo present things differently, then I'll change my mind. | 15:18 |
| zigo | In the mean while, my package will use what upstream provides. | 15:19 |
| zigo | What to fix things? Do that upstream first... | 15:19 |
| ihrachyshka | zigo, what do you mean? upstream provides ovs_neutron_plugin.ini for ovs agent | 15:19 |
| zigo | Yeah, and I use that + the ml2_conf.ini. | 15:19 |
| ihrachyshka | as I said, the name is unfortunate but it's for valid historical reasons | 15:20 |
| zigo | Since there's important directives which the plugin use in both files. | 15:20 |
| zigo | ihrachyshka: Fix this upstream then ! | 15:20 |
| ihrachyshka | you should not pass ml2_conf.ini since there is no option relevant for ovs agent there | 15:20 |
| *** xaeth_afk is now known as xaeth | 15:20 | |
| zigo | ihrachyshka: Really ? | 15:20 |
| zigo | ihrachyshka: So, passing the ml2_conf.ini like I do in my package has no effect? | 15:20 |
| zigo | Interesting ... | 15:21 |
| zigo | Anyway, the solution is that Neutron upstream rethinks this from zero, then we can make it consistent accross distros. | 15:21 |
| mriedem | looks like we have a new grenade breakage in stable/kilo | 15:22 |
| mriedem | http://logs.openstack.org/56/183656/4/check/check-grenade-dsvm/3acba73/logs/old/screen-s-proxy.txt.gz | 15:22 |
| ihrachyshka | I agree there is at least rename to do | 15:22 |
| mriedem | since this is the 'old' side it'd be a problem in stable/juno requirements | 15:22 |
| mriedem | bknudson: mtreinish: ^ | 15:22 |
| mriedem | adam_g: ^ | 15:22 |
| *** e0ne_ is now known as e0ne | 15:22 | |
| bknudson | kazoo and zake? | 15:22 |
| mriedem | heavy hitters right | 15:22 |
| zigo | ihrachyshka: There's also the fact that the Neutron files can't be parsed with a reasonable script. | 15:23 |
| mriedem | zake 0.2.2 released today https://pypi.python.org/pypi/zake/0.2.2 | 15:23 |
| bknudson | zake uploaded on 05-27 | 15:23 |
| mtreinish | mriedem: what are with these weird package names? I have no idea what those things do | 15:23 |
| ihrachyshka | zigo, what do you mean by parsing? | 15:23 |
| bknudson | A python package that works to provide a nice set of testing utilities for the kazoo library. | 15:23 |
| bknudson | zake ^ | 15:23 |
| zigo | ihrachyshka: I mean this: | 15:24 |
| mtreinish | mriedem: oh that would explain it. Yell at harlowja | 15:24 |
| zigo | # cat etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini | grep integration_bridge | 15:24 |
| zigo | # integration_bridge = br-int | 15:24 |
| zigo | # integration_bridge = br-int | 15:24 |
| zigo | # integration_bridge = br-int | 15:24 |
| zigo | # integration_bridge = br-int | 15:24 |
| zigo | That's a nonsense !!! | 15:24 |
| zigo | Directives should be there *once*. | 15:24 |
| zigo | Examples shouldn't start with commented-out directive names. | 15:24 |
| zigo | There should be a way at least, to differentiate directives and examples. | 15:25 |
| bknudson | zake is capped http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable%2Fjuno#n230 | 15:25 |
| bknudson | zake>=0.1,<=0.1.7 | 15:25 |
| bknudson | as is kazoo>=1.3.1,<=2.0 | 15:25 |
| ihrachyshka | zigo, yeah, those are not auto-generated, that's why | 15:27 |
| mriedem | bknudson: i think tooz is pulling something in | 15:27 |
| ihrachyshka | zigo, there is a plan to make them autogenerated in L | 15:27 |
| mriedem | Collecting kazoo>=1.3.1 (from tooz<=0.12,>=0.3->ceilometer==2014.2.4.dev4) | 15:27 |
| bknudson | Requirement.parse('kazoo!=2.1,>=1.3.1'), set(['zake'])) -- from that it looks like zake is not a fan of kazoo 2.1 | 15:28 |
| bknudson | but that's the current release of kazoo | 15:29 |
| mriedem | Collecting zake>=0.1 (from tooz<=0.12,>=0.3->ceilometer==2014.2.4.dev4) | 15:29 |
| mriedem | tooz has an uncapped requirement on zake | 15:29 |
| bknudson | what's tooz? | 15:29 |
| bknudson | Coordination library for distributed systems. | 15:29 |
| mriedem | bingo https://github.com/openstack/tooz/blob/0.12/requirements.txt#L8 | 15:30 |
| bknudson | it would be interesting to know why zake thinks kazoo 2.1 is such a problem. | 15:30 |
| mriedem | tooz 0.12 has uncapped requirement on zake | 15:30 |
| bknudson | and if a new release of kazoo is expected | 15:30 |
| zigo | ihrachyshka: There's been such a plan for like years ... :) | 15:30 |
| mriedem | bknudson: let's go to the oslo channel and ask harlowja | 15:30 |
| bknudson | y, let's pile on | 15:31 |
| ihrachyshka | zigo, this time it will be different!!! | 15:31 |
| ihrachyshka | nah, it won't, just kiddin' | 15:31 |
| zigo | :) | 15:31 |
| ihrachyshka | but I heard it that time from a doc guy who felt pain doing manual updates for official docs | 15:31 |
| bknudson | mriedem: mtreinish: s-proxy is really good at catching these things, unlike every other server | 15:31 |
| ihrachyshka | so maybe pain will remain for some time until the solution is there | 15:32 |
| *** eharney has joined #openstack-stable | 15:32 | |
| bknudson | so either s-proxy is doing something right and everyone else is wrong or s-proxy is wrong. | 15:32 |
| bknudson | seems like it's s-proxy that's helping out here | 15:32 |
| mtreinish | bknudson: it's first | 15:33 |
| mtreinish | well the first that pulls in a lot of libs | 15:34 |
| Daviey | Is stable/kilo gate working properly now? | 15:36 |
| mriedem | Daviey: no ^ | 15:38 |
| mriedem | it was, for about an hour | 15:38 |
| mriedem | yesterday | 15:38 |
| Daviey | mriedem: Is there a summary of the current issues? | 15:39 |
| mriedem | Daviey: not really | 15:40 |
| mriedem | Daviey: https://pypi.python.org/pypi/zake/0.2.2 released today | 15:40 |
| ihrachyshka | in case someone comes up with details, please use https://etherpad.openstack.org/p/stable-tracker | 15:40 |
| mriedem | which breaks here http://logs.openstack.org/56/183656/4/check/check-grenade-dsvm/3acba73/logs/old/screen-s-proxy.txt.gz | 15:40 |
| mriedem | ihrachyshka: i'll probably bring it up in the ML first | 15:40 |
| mriedem | once i map out all of these gd dependencies | 15:40 |
| mriedem | with 'z' in the name of the library | 15:40 |
| ihrachyshka | thanks | 15:41 |
| mriedem | bknudson: is there an outstanding g-r sync for ceilometer in stable/juno? | 15:43 |
| Daviey | mriedem: I'm looking at zuul, but i can't find a stable/kilo job that is busted... Do you have an example review that is blocked? | 15:44 |
| mriedem | Daviey: the link above ^ | 15:44 |
| mriedem | https://review.openstack.org/#/c/183656/ | 15:44 |
| Daviey | doh | 15:44 |
| bknudson | mriedem: https://review.openstack.org/#/c/173117/ | 15:44 |
| mriedem | stable/kilo is blocked on grenade b/c stable/juno (old side of grenade for stable/kilo changes) is f'ed | 15:44 |
| mriedem | bknudson: ok, i'm not sure if that helps, but we might as well get it in: https://review.openstack.org/#/c/173117/ | 15:45 |
| mriedem | mtreinish: ^ | 15:45 |
| mriedem | since it's passing tests | 15:45 |
| bknudson | mriedem: we needed to get https://review.openstack.org/#/c/183656/ in during that one golden hour. | 15:45 |
| mriedem | heh | 15:46 |
| mriedem | i was disconnected due to terribleness from yesterday | 15:46 |
| bknudson | mriedem: yesterday was pretty bad, but that's what you get for being away for a week | 15:47 |
| Daviey | damn, i thought everything would be rosie after the keystone issue | 15:47 |
| mriedem | bknudson: being away or not, it doesn't matter | 15:47 |
| mriedem | every day stable is broken by some other transitive dependency somewhere down the change | 15:47 |
| mriedem | *chain | 15:47 |
| mtreinish | mriedem: +A, but on dsvm job that shouldn't change anything | 15:48 |
| mriedem | mtreinish: bknudson: Daviey: so ceilometer pulls in tooz 0.12 and tooz 0.12 has uncapped zake which pulls in zake 0.2.2 (released today) which has a block on kazoo 2.1 | 15:48 |
| mriedem | that's where we fail | 15:48 |
| mriedem | however, g-r on stable/juno also caps kazoo<=2.0 | 15:49 |
| mriedem | Collecting kazoo>=1.3.1 (from tooz<=0.12,>=0.3->ceilometer==2014.2.4.dev4) | 15:49 |
| mtreinish | is tooz g-r synced on juno? | 15:49 |
| mriedem | no | 15:49 |
| mriedem | tooz does not have a stable/juno branch | 15:49 |
| mriedem | ah yes | 15:50 |
| mriedem | https://github.com/openstack/tooz/blob/0.12/requirements.txt#L6 | 15:50 |
| mriedem | tooz 0.12 also has an uncapped requirement on kazoo | 15:50 |
| mriedem | so it's pulling in kazoo 2.1 which breaks with zake 0.2.2 b/c that can't have kazoo 2.1 | 15:50 |
| mtreinish | yep, that explains it | 15:50 |
| mriedem | so, we need a stable/juno branch for tooz | 15:51 |
| *** ihrachyshka has quit IRC | 15:51 | |
| mriedem | and a sync from g-r for stable/juno on that | 15:51 |
| bknudson | then we'll also need a release of tooz | 15:51 |
| mriedem | i don't really know wtf you'd version that as for tooz though since it's already like microversioned | 15:51 |
| mriedem | we also need harlowja to wake up | 15:51 |
| bknudson | I think our best bet is to get a release of kazoo that doesn't have whatever the bug is | 15:52 |
| mtreinish | mriedem: surely someone else should have the acl to push a release | 15:52 |
| mriedem | alternatively, we might be able to order requirements such that capped kazoo is installed before tooz | 15:52 |
| mriedem | ceilometer->tooz->kazoo | 15:53 |
| mtreinish | mriedem: heh, let's build an even taller house of cards | 15:53 |
| Daviey | mriedem, bknudson: You know, i really think we need better tooling to determine the dep chain | 15:53 |
| mriedem | i agree with that | 15:53 |
| mriedem | i just use the tox logs | 15:54 |
| mriedem | and then walk it back via github tags in each repo | 15:54 |
| *** jamespage_ has quit IRC | 15:54 | |
| mriedem | which blows | 15:54 |
| mriedem | brb | 15:54 |
| *** jamespage_ has joined #openstack-stable | 15:54 | |
| Daviey | mriedem: What tags do you mean? | 15:54 |
| mriedem | git tags | 15:55 |
| *** jamespage_ has quit IRC | 15:59 | |
| mriedem | here is the bug for tracking https://bugs.launchpad.net/python-tooz/+bug/1459322 | 16:00 |
| openstack | Launchpad bug 1459322 in tooz "stable/juno broken with zake 0.2.2 release" [Undecided,New] | 16:00 |
| mriedem | i'll get an e-r query up | 16:00 |
| mriedem | i have had it with these mothertrucking dependencies on this mothertrucking plane | 16:01 |
| *** xaeth is now known as xaeth_afk | 16:12 | |
| Daviey | mriedem: I knew that, i mean.. of which project? | 16:19 |
| mriedem | Daviey: updated https://etherpad.openstack.org/p/stable-tracker | 16:20 |
| mriedem | Daviey: all of them? | 16:20 |
| Daviey | mriedem: Thought as much.. :/ | 16:21 |
| *** derekh_ has joined #openstack-stable | 16:21 | |
| Daviey | mriedem: you are on fire! | 16:21 |
| mriedem | we should just have one gigantic monolithic 'openstack' package with like 300 libraries in it | 16:21 |
| mriedem | that would fix everything i'm pretty sure :P | 16:22 |
| Daviey | That sounds like a good fit with Vish's opinion that perhaps openstack should have been written in java | 16:22 |
| mriedem | yeah i liked that | 16:23 |
| mriedem | especially after going to oracle | 16:23 |
| *** derekh has quit IRC | 16:25 | |
| *** akrivoka has joined #openstack-stable | 16:29 | |
| Daviey | mriedem: failed. | 16:33 |
| Daviey | Oh bugger.. WARNING: urllib3.connectionpool HttpConnectionPool is full, discarding connection: 127.0.0.1 | 16:49 |
| Daviey | I really hope that is not related to keystone recent issue | 16:49 |
| bknudson | Daviey: I think we get those warnings all over the place and it doesn't cause tests to fail | 16:51 |
| adam_g | ya those are typical | 16:51 |
| Daviey | bknudson: indeed, https://bugs.launchpad.net/glance/+bug/1402747 | 16:51 |
| openstack | Launchpad bug 1402747 in OpenStack Object Storage (swift) "setuptools 8 breaks multi-range version checks" [Undecided,Invalid] | 16:51 |
| bknudson | invalid | 16:52 |
| bknudson | the bug is marked invalid for whatever reason | 16:52 |
| *** xaeth_afk is now known as xaeth | 16:53 | |
| mriedem | you'll see "WARNING: urllib3.connectionpool HttpConnectionPool is full, discarding connection: 127.0.0.1" all over swift and glance api stuff | 17:14 |
| mriedem | b/c of gets on large artifacts | 17:14 |
| mriedem | timing out the pools | 17:14 |
| *** e0ne is now known as e0ne_ | 17:16 | |
| *** e0ne_ is now known as e0ne | 17:20 | |
| *** e0ne has quit IRC | 17:25 | |
| *** mrunge has quit IRC | 17:27 | |
| *** apevec has quit IRC | 18:05 | |
| *** e0ne has joined #openstack-stable | 18:06 | |
| *** e0ne is now known as e0ne_ | 18:06 | |
| *** e0ne_ is now known as e0ne | 18:07 | |
| *** e0ne has quit IRC | 18:59 | |
| *** eharney has quit IRC | 19:08 | |
| *** eharney has joined #openstack-stable | 19:15 | |
| mriedem | https://review.openstack.org/#/c/186065/ is in the gate | 20:05 |
| *** akrivoka has quit IRC | 20:35 | |
| mriedem | ^ is merged | 20:53 |
| mriedem | keep an eye out for ceilometer reqs update sync on stable/juno | 20:53 |
| mriedem | here is the stable/juno ceilometer reqs sync https://review.openstack.org/#/c/173117/ | 21:10 |
| mriedem | that will get updated at some point for tooz | 21:11 |
| mriedem | https://review.openstack.org/#/c/173117/ has the tooz update now | 21:15 |
| mriedem | no idea if tests will pass | 21:15 |
| mriedem | mtreinish: devstack actually installed on this https://review.openstack.org/#/c/173117/ | 21:33 |
| mriedem | tempest is running | 21:33 |
| mriedem | i think i might pull a george w. here and say mission accomplished | 21:34 |
| mtreinish | mriedem: yeah that's a good sign | 21:35 |
| *** mriedem has quit IRC | 21:51 | |
| *** lifeless has joined #openstack-stable | 21:53 | |
| lifeless | omganotherchannel | 21:53 |
| lifeless | is the stable requirements wedge fixed? | 21:53 |
| *** xaeth is now known as xaeth_afk | 21:54 | |
| *** mriedem has joined #openstack-stable | 22:03 | |
| *** xaeth_afk is now known as xaeth | 22:04 | |
| *** bknudson has quit IRC | 22:06 | |
| Daviey | lifeless: looks like it is.. pending last merge | 22:12 |
| Daviey | lifeless: of https://review.openstack.org/#/c/173117/ | 22:13 |
| Daviey | (thanks mostly to the heroic effort of mriedem) | 22:13 |
| mriedem | that's nearly done in the gate queue | 22:14 |
| mriedem | then stable juno and kilo should be 'ok' | 22:14 |
| *** xaeth is now known as xaeth_afk | 22:16 | |
| mriedem | Daviey: you didn't need to recheck https://review.openstack.org/#/c/173117/ it was already in the gate qeuue | 22:19 |
| mriedem | s/was/is/ | 22:19 |
| mriedem | Daviey: you can track that stuff by going to http://zuul.openstack.org/ and plug the gerrit id (173117) into the Filters box | 22:20 |
| Daviey | mriedem: yeah, i saw that after i pressed submit | 22:20 |
| Daviey | mriedem: yeah, i know that! I was responding to the failed check previously. | 22:20 |
| mriedem | ah ok | 22:20 |
| mriedem | https://review.openstack.org/#/c/173117/ is merged | 22:40 |
| mriedem | hurray! approve and recheck everything!!! | 22:40 |
| mriedem | s/hurray/hurry/ | 22:40 |
| *** derekh_ has quit IRC | 22:42 | |
| mriedem | plug for this backport to stable/kilo in nova - has a +2 from me https://review.openstack.org/#/c/176396/ | 22:44 |
| mriedem | and this one https://review.openstack.org/#/c/184240/ | 22:47 |
| mriedem | ^ fixes live migrate for libvirt driver on s390x | 22:47 |
| *** mriedem has quit IRC | 23:04 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!