| openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements: Updated from global requirements https://review.openstack.org/378900 | 00:11 |
|---|---|---|
| *** armax has joined #openstack-requirements | 01:46 | |
| openstackgerrit | Russell Bryant proposed openstack/requirements: Update ovs to 2.6.0. https://review.openstack.org/379067 | 01:51 |
| *** armax has quit IRC | 02:31 | |
| *** david-lyle has quit IRC | 03:04 | |
| *** armax has joined #openstack-requirements | 03:22 | |
| *** armax has quit IRC | 03:34 | |
| openstackgerrit | Merged openstack/requirements: Updated from global requirements https://review.openstack.org/378900 | 04:34 |
| *** coolsvap has joined #openstack-requirements | 04:42 | |
| openstackgerrit | Merged openstack/requirements: Update oslo.policy to >= 1.14.0 https://review.openstack.org/378946 | 04:45 |
| openstackgerrit | Merged openstack/requirements: Update ovs to 2.6.0. https://review.openstack.org/379067 | 04:45 |
| openstackgerrit | Tony Breeds proposed openstack/requirements: Remove non-existent lower bounds https://review.openstack.org/379158 | 05:55 |
| tonyb | dirk: nice one getting the uc-check "working" It now looks like we have at least one bindep issue | 06:35 |
| tonyb | dirk: we also need to backport the environment name change to stable/* http://logs.openstack.org/16/361116/2/check/gate-requirements-tox-py27-check-uc-ubuntu-trusty/c2d6a1d/console.html#_2016-09-29_05_29_47_291079 | 06:37 |
| dirk | tonyb: yep, realized that as well | 06:38 |
| tonyb | dirk: but we can do the rename in a single commit there as the infra stuff has landed already | 06:38 |
| dirk | Will do in a few min | 06:38 |
| dirk | tonyb: yeah, i'll Look into the bindep issue | 06:38 |
| tonyb | dirk: cool. I can +W it please make sure you mention the 2 master ChangeIDs | 06:39 |
| tonyb | dirk: http://logs.openstack.org/18/376218/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/0ac84b7/console.html#_2016-09-29_05_29_21_131170 (in case you hadn't seen it) | 06:40 |
| openstackgerrit | Tony Breeds proposed openstack/requirements: Quick wins for python3 support https://review.openstack.org/379193 | 06:49 |
| openstackgerrit | Dirk Mueller proposed openstack/requirements: DNM: Fixes for check-uc jenkins job https://review.openstack.org/379203 | 06:57 |
| dirk | tonyb: yay! | 07:08 |
| dirk | tonyb: meaningful errors.. | 07:08 |
| tonyb | woot! | 07:08 |
| dirk | ContextualVersionConflict: (Sphinx 1.3.6 (/data/dmueller/src/Cloud/requirements/.tox/py27-check-uc/lib/python2.7/site-packages), Requirement.parse('sphinx!=1.3b1,<1.3,>=1.2.1'), set(['openstack-doc-tools'])) | 07:09 |
| dirk | ContextualVersionConflict: (Sphinx 1.3.6 (/data/dmueller/src/Cloud/requirements/.tox/py27-check-uc/lib/python2.7/site-packages), Requirement.parse('sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2'), set(['os-api-ref'])) | 07:09 |
| dirk | ContextualVersionConflict: (pyparsing 2.1.9 (/data/dmueller/src/Cloud/requirements/.tox/py27-check-uc/lib/python2.7/site-packages), Requirement.parse('pyparsing<=1.9.9'), set(['pulp'])) | 07:09 |
| dirk | so openstack-doc-tools and os-api-ref is easy, we just need new releases there | 07:09 |
| tonyb | dirk: Awesome! | 07:09 |
| dirk | PuLP seems to be some external stuff | 07:09 |
| tonyb | dirk: Yeah, so our specification for pyparsing is more liberal that pulp's interesting | 07:10 |
| tonyb | dirk: is that all the problems or just a snippet? | 07:11 |
| dirk | tonyb: it is all | 07:15 |
| tonyb | dirk: Nice. | 07:17 |
| dirk | tonyb: hmm, we should add os-api-ref to the projects.txt | 07:17 |
| dirk | for openstack-doc-tools I requested a new releaes | 07:18 |
| tonyb | dirk: We can manually sync os-api-ref | 07:18 |
| dirk | tonyb: true.. done. when that merges, we can request a new release | 07:22 |
| tonyb | dirk: cool | 07:22 |
| dirk | pulp is the most painful it seems,b ut it is only used in congress | 07:23 |
| tonyb | Yeah that's going to be a bit of a pain. | 07:26 |
| tonyb | dirk: it looks like the next version of pulp will work as it reqires pyparsing>=2.0.1 | 07:29 |
| tonyb | dirk: so we might just need to fail until then | 07:29 |
| dirk | yeah, would be nice to have a kind of "blacklisting-until-new-release-is-there" capability | 07:30 |
| tonyb | dirk: Oh huh they only cap pyparsing on python2 | 07:30 |
| tonyb | Oh and dims fixed it | 07:30 |
| dirk | small world :) | 07:30 |
| tonyb | dirk: we could do something horrible like remove it from the venv before we run the check | 07:36 |
| tonyb | dirk: Or les gross just skip verifying PuLP | 07:37 |
| tonyb | dirk: soemthing like: http://paste.openstack.org/show/583418/ | 07:39 |
| tonyb | dirk: with comments etc | 07:39 |
| dirk | tonyb: right, I was thinking more about ignoring specific requirements from specific packages | 07:42 |
| dirk | so that it can error out when a particular problem isn't there | 07:42 |
| dirk | so rather than blacklisting before, blacklsting the error message | 07:42 |
| dirk | which is just making it easier to consume and then comparing it with a known-issues-uc.txt | 07:43 |
| dirk | basically this is XFAIL handling - we expect a fail, so we need to fail when the fail isn't there | 07:44 |
| dirk | I'll draft a patch for that when meeting madness has ended | 07:44 |
| *** tonyb_noSSH has joined #openstack-requirements | 07:48 | |
| tonyb | dirk: cool | 07:48 |
| tonyb | dirk: Sorry I went quiet my IRC connection dropped :( | 07:48 |
| *** strigazi_AFK is now known as strigazi | 08:29 | |
| *** jpena|off is now known as jpena | 08:57 | |
| openstackgerrit | gengchc2 proposed openstack/requirements: Use ConfigParser instead of SafeConfigParser https://review.openstack.org/375264 | 08:57 |
| openstackgerrit | Chris Dent proposed openstack/requirements: Bump gabbi to 1.26.1 https://review.openstack.org/379347 | 10:25 |
| openstackgerrit | Dirk Mueller proposed openstack/requirements: Fixes for check-uc jenkins job https://review.openstack.org/379203 | 10:45 |
| openstackgerrit | Chandan Kumar proposed openstack/requirements: Update os-testr to 0.8.0 https://review.openstack.org/379370 | 11:00 |
| *** openstackgerrit has quit IRC | 11:19 | |
| *** openstackgerrit has joined #openstack-requirements | 11:19 | |
| *** jpena is now known as jpena|lunch | 11:43 | |
| dims | dirk : you need this quickly? https://review.openstack.org/#/c/379216/ | 12:25 |
| number80 | dims: I assume that yes, if suse ships newer sphinx (and they do if I remember correctly) | 12:25 |
| dims | number80: i see | 12:27 |
| number80 | I haven't done that update in CentOS because of that issue | 12:27 |
| dims | number80 : gotcha, talking to dhellmann on #openstack-release | 12:29 |
| openstackgerrit | caoyuan proposed openstack/requirements: Remove the unnecessary "# BSD" https://review.openstack.org/379420 | 12:29 |
| number80 | dims: thank you :) | 12:29 |
| openstackgerrit | caoyuan proposed openstack/requirements: Remove the unnecessary "# BSD" https://review.openstack.org/379420 | 12:45 |
| *** david-lyle has joined #openstack-requirements | 12:57 | |
| *** jpena|lunch is now known as jpena | 12:59 | |
| dirk | dims: I don't realy need it quickly, but it would be nice to clean this up | 13:20 |
| openstackgerrit | Merged openstack/requirements: Remove now unused py27-with-upper-constraints env https://review.openstack.org/378734 | 13:21 |
| *** breton has joined #openstack-requirements | 13:22 | |
| breton | hi | 13:22 |
| dims | hey breton : what's up? | 13:23 |
| breton | we have bug 1628883 in keystone, which happened because of too low lower-constraint in requirements.txt | 13:23 |
| openstack | bug 1628883 in keystone (Ubuntu) "Minimum requirements too low on oslo.log for keystone" [Undecided,Triaged] https://launchpad.net/bugs/1628883 - Assigned to Corey Bryant (corey.bryant) | 13:23 |
| breton | is it safe to just bump it like https://review.openstack.org/379451 or we need to do something else in openstack/requirements? | 13:23 |
| dims | breton : we won't touch stable/newton requirements as its too late | 13:25 |
| dims | breton : i'd advocate a bump in requirements master branch if that's not done yet | 13:27 |
| breton | dims: that's already done | 13:27 |
| dims | perfect | 13:27 |
| dims | breton : if we bump g-r for stable/newton then we will have to cut releases *all* projects. so we have to avoid that | 13:28 |
| dims | breton : the guidance to packagers is to make sure they are as close to upper-constraints as possible, so that will minimize impact | 13:29 |
| breton | dims: cool, thanks. | 13:30 |
| dims | dirk : if you patch the version #, we can roll it out https://review.openstack.org/#/c/379216/ | 13:33 |
| dirk | dims: yep, sorry, I just read the backlog on this | 13:34 |
| dirk | dims: let me quickly check with aj and I'll do that in a min | 13:34 |
| anteaya | dirk: why do you +1 an incorrect defintion on the mailing list? | 13:39 |
| anteaya | it is hard enough to help folks as it is, encouraging them to use incorrect terms doesn't help | 13:40 |
| dirk | anteaya: hmm, I guess i am confused then as well | 13:40 |
| anteaya | that is fine if you would like some clarification | 13:41 |
| anteaya | I'm happy to assist | 13:41 |
| anteaya | but encouraging folks to use slang and incorrect terms just ensures they get little assistance in infra | 13:41 |
| dirk | anteaya: argh, my bad, I think I quoted the wrong thing :( | 13:42 |
| anteaya | it is exhausting to have to spend a good chunk of every request for help educating the querant on what their actually asking about | 13:42 |
| dirk | anteaya: I see what you mean.. I wanted to +1 the "promote..to.voting" part | 13:42 |
| anteaya | dirk: if you could be so kind as to take some time when you have some space and clarify it would mean a lot to me | 13:42 |
| anteaya | just take your time | 13:42 |
| anteaya | and thank you | 13:42 |
| anteaya | and so that you and I are clear | 13:43 |
| anteaya | gate is a pipeline of which we have many | 13:43 |
| anteaya | the name of the pipeline is at the top of every queue: http://status.openstack.org/zuul/ | 13:44 |
| anteaya | check, gate, post and so on | 13:44 |
| anteaya | jobs return results, success or failure | 13:44 |
| anteaya | verified +1, -1, +2 or -2 are recorded on a per job basis depending on the outcome of the job | 13:45 |
| anteaya | permissions on what can leave verified votes is set in gerrit | 13:45 |
| anteaya | third party ci systems can not leave verified +2 or -2 on patches | 13:45 |
| anteaya | as that would prevent patches from mergeing based on third party ci sytem job results and we don't allow that in our system | 13:46 |
| anteaya | only infra's ci results may leave verified +2 or -1 on our patches | 13:46 |
| anteaya | and thanks | 13:46 |
| dirk | anteaya: sec, just trying to wrap up the meeting in openstack-meetings-alt, brb | 13:47 |
| anteaya | sorry to disturb | 13:48 |
| anteaya | only infra's ci results may leave verified +2 or -2 on our patches* | 14:05 |
| dirk | anteaya: ok, am back | 14:05 |
| anteaya | third party ci systems may leave verified +1 or -1 on a repo's patches, if the repo team allows them | 14:05 |
| anteaya | dirk: welcome back | 14:06 |
| anteaya | just fixed a typo I made above | 14:06 |
| dirk | anteaya: so basically what we want is that the two 3rd party gates can do a "jenkins -1" on a PR check | 14:06 |
| dirk | so I guess the proper thing would be "allow them to vote on a check gate" | 14:06 |
| dirk | right? | 14:06 |
| dirk | or is that the check-job in the gate? | 14:06 |
| * dirk needs a picture :) | 14:06 | |
| anteaya | two third party jobs, not gates | 14:08 |
| dirk | third party ci's that have third party jobs, yes | 14:08 |
| anteaya | I don't want anything personally, but the email is about allowing third party ci to leave verified +1 or -1 on patches, is my hunch | 14:08 |
| anteaya | there is no such thing as a check gate | 14:08 |
| anteaya | there is a check job and a gate job | 14:09 |
| anteaya | jobs can run in check, they can run in gate, they can run in post | 14:09 |
| dirk | well, above you said "gate is a pipeline of which we have many" | 14:09 |
| anteaya | jobs run in pipelines | 14:09 |
| anteaya | yes | 14:09 |
| dirk | so we have a check pipeline, and a gate pipeline | 14:09 |
| anteaya | we do so | 14:09 |
| dirk | and we talk about the check pipeline | 14:10 |
| anteaya | we do, we also talk about other pipelines to | 14:10 |
| dirk | so for me gate and pipeline is interchangeable | 14:10 |
| anteaya | that can work until it doesn't | 14:11 |
| dirk | right, ther eis a gate gate :) | 14:11 |
| anteaya | pipeline is defined here: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n4 | 14:11 |
| dirk | that makes it quite difficult | 14:11 |
| anteaya | what makes what difficult | 14:11 |
| dirk | e.g. "check pipeline" and "gate pipeline" is easier for me to understand than | 14:11 |
| dirk | "check gate" and "gate gate" | 14:12 |
| anteaya | I'm glad the correct way is also easiest to understand | 14:12 |
| dirk | :-) | 14:12 |
| anteaya | pipelines tell our tooling which set of jobs to run | 14:12 |
| anteaya | we run the jobs considered check jobs in the check pipeline | 14:13 |
| anteaya | gate jobs in the gate pipleline | 14:13 |
| anteaya | post jobs in the post pipeline | 14:13 |
| anteaya | check and gate are closely related | 14:13 |
| anteaya | in that all the jobs that run on a patch in the gate pipeline have to have run and passed in the check pipeline | 14:13 |
| anteaya | also we want all jobs that vote in check also vote in the gate pipeline | 14:14 |
| dirk | aha! | 14:15 |
| dirk | thats an important piece of info | 14:15 |
| dirk | I was wondering about that as well | 14:15 |
| anteaya | I'm so glad we are having this conversation | 14:16 |
| dirk | anteaya: hmm, so basically we can not have voting 3rd party hosted checks ? | 14:16 |
| anteaya | are things starting to make sense? | 14:16 |
| dirk | yes | 14:16 |
| anteaya | great | 14:16 |
| anteaya | well third party ci is separate from our infra discussion | 14:16 |
| anteaya | so it appears we share an understanding of the names of things in the infra workflow, yes? | 14:17 |
| dirk | yes | 14:17 |
| dirk | to be honest the result of our discussion should be long in the z uul reference manual | 14:17 |
| dirk | I was scratching my head over that one already several times | 14:17 |
| dirk | I am aware of the issue with not relying on 3rd party jobs in the gate/post pipeline | 14:19 |
| dirk | that makes sense to me | 14:19 |
| anteaya | great | 14:19 |
| dirk | the part I'm lacking on is why there should be a strong relationship between what is voting as a check and voting as a gate job | 14:19 |
| dirk | why can't there be more voting checks than gate jobs ? | 14:20 |
| anteaya | now if a given project wishes to allow third party ci to leave a verified +1 or -1 on a patch, a project can do so | 14:20 |
| anteaya | this is the neutron-ci group: https://review.openstack.org/#/admin/groups/510,members | 14:21 |
| dirk | basically what we want is "if any of the 3rd party ci jobs fail, the overall jenkins vote should be a -1, so that it is dead easy to see on the gerrit listing that this review is no good" | 14:21 |
| anteaya | this gerrit group is administered by the neutron team | 14:21 |
| anteaya | this group gives permissions to those ci accounts listed to leave verified +1 or -1 on neutron patches | 14:21 |
| dirk | but we don't require them to be added to the gate pipeline *yet*. there is an independent effort to rebuild the 3rd party cis on the openstack hosted infra, and then they can be voting on the gate pipeline | 14:21 |
| anteaya | when you say basically what we want is, who is we? | 14:22 |
| anteaya | I don't want that myself | 14:22 |
| anteaya | let's deal with one question at a time | 14:22 |
| dirk | heh, we == rpm packaging core group, e.g. number80 (PTL) and me (ex-PTL) | 14:22 |
| anteaya | there are a number I have yet to answer | 14:22 |
| anteaya | then the rpm packaging core group can have a rpm-ci gerrit group and recieve verified +1 or -1 on its patches from whatever third party ci systems it wants | 14:23 |
| anteaya | let's address why should there be a strong relationship between voting check jobs and voting gate jobs | 14:24 |
| anteaya | the check pipeline runs all the jobs in isolation, each patch is tested individually | 14:24 |
| anteaya | the gate pipeline runs all the jobs together, each patch (in a pipeline group) is tested serially | 14:25 |
| anteaya | so all the jobs that vote have to pass in check for it to get into the gate | 14:25 |
| anteaya | then all the same jobs that vote have to run and vote again in the gate queue | 14:25 |
| anteaya | now for projects that don't share a pipeline, folks might not see much difference except for race conditions | 14:26 |
| anteaya | but for projects tested together it makes a big difference | 14:26 |
| anteaya | does that make sense? | 14:26 |
| anteaya | I have to make myself some food now | 14:27 |
| anteaya | we can continue | 14:27 |
| dirk | anteaya: hmm, ok, I see | 14:28 |
| dirk | so basically it is a real problem, albeit not a very relevant one for packaging itself | 14:28 |
| * dirk would love to find some time to put all of that into the zuul documentation | 14:28 | |
| anteaya | it is a real problem, what is a real problem? | 14:30 |
| anteaya | well it is more likely to go into the infra manual | 14:31 |
| dirk | it is a real problem when voting check jobs are not also voting in the gate pipeline | 14:31 |
| anteaya | which is the manual for developers to use our tooling | 14:31 |
| dirk | and that makes a lot of sense for interdependent changes. but rpm-packaging doesn't have those very often | 14:31 |
| anteaya | hopefully the project-config reviewers catch that and get projects to fix it | 14:31 |
| dirk | at least not right now | 14:31 |
| dirk | we do want to get to that point though , but that is the rebuild-the-ci-in-upstream-infra task | 14:32 |
| anteaya | project config reviewers review to ensure voting check jobs are also voting gate jobs | 14:32 |
| anteaya | http://docs.openstack.org/infra/manual/ | 14:32 |
| anteaya | when you say the rebuild the ci in upstream infra task, do you mean tripleo? | 14:32 |
| dirk | no this is unrelated to tripleo | 14:33 |
| anteaya | then I don't know this task | 14:34 |
| dirk | basically what was discussed in austin iirc was to have both the deb and the rpm packaging eventually produce binary packages of each git commit, e.g. a post job on the merge of a git commit | 14:34 |
| anteaya | okay | 14:34 |
| dirk | this was achieved (mostly) for deb according to zigos mail recently | 14:34 |
| dirk | but not even started for rpm | 14:34 |
| anteaya | okay | 14:34 |
| dirk | right now we have 3rd party ci's that are testing the packaging changes in the particular downstreams build environment | 14:34 |
| dirk | which also serves a purpose but a different one than a voting job in the gate pipeline would do | 14:35 |
| anteaya | the particular downstreams build environment, the enviroment for the third party ci? | 14:35 |
| anteaya | third party cis don't vote | 14:35 |
| anteaya | they can leave verfied +1 or -1 on patches | 14:36 |
| anteaya | that isn't voting | 14:36 |
| anteaya | please don't say third party cis vote | 14:36 |
| dirk | aha, see I learn a new thing | 14:36 |
| anteaya | that would cause me no end of issues | 14:36 |
| dirk | (one more) | 14:36 |
| dirk | so what is voting and what is verified? | 14:36 |
| anteaya | reviewers vote | 14:37 |
| anteaya | human reviewers | 14:37 |
| anteaya | automated systems verify | 14:37 |
| anteaya | now we do accept the words that the infra system votes | 14:37 |
| anteaya | with voting and non voting jobs | 14:38 |
| anteaya | however | 14:38 |
| anteaya | if third party operators heard that a system was voting | 14:38 |
| anteaya | they all would want to be able to leave verified +2 or -2 on patches | 14:38 |
| anteaya | which no system other than infras will be able to do | 14:38 |
| anteaya | voting third party ci is a politically charged phrase | 14:39 |
| anteaya | let's talk about third party cis leaving verfied +1 or -1 on patches | 14:39 |
| anteaya | since that is accurate, though a mouthful | 14:39 |
| anteaya | verifying patches also should be fine | 14:40 |
| anteaya | since it is so far a little used phrase | 14:40 |
| anteaya | i know it is confusing | 14:41 |
| anteaya | third party ci systems is a challenging topic | 14:41 |
| anteaya | and unfortunately it doesn't get much easier with increased exposure | 14:41 |
| anteaya | there are too many competing interests in the space | 14:42 |
| anteaya | and despite time and effort alignment doens't happen | 14:43 |
| anteaya | at best is is kind of a constant tension | 14:43 |
| anteaya | that is the best case scenario | 14:43 |
| anteaya | i feel I've lost you | 14:44 |
| anteaya | I'm going to make another attempt at food, my first attempt was lackluster | 14:45 |
| dirk | I'm trying to understand what a verified +2/-2 means in the check pipeline | 14:46 |
| dirk | +2/-2 means a workflow -1 right ? | 14:46 |
| anteaya | you won't get verified +2 or -2 in the check pipeline | 14:46 |
| anteaya | in the check pipeline you will get a verified +1 or -1 from infra's system | 14:47 |
| anteaya | in the gate pipeline you will get +2 (a green check mark, I think) or a -2 from infra's system | 14:47 |
| anteaya | and in the gate pipeline you can also get verified +1 or -1 from third party ci systems that that project has allowed to verify | 14:47 |
| anteaya | in this view I see a green check mark beside jenkins: https://review.openstack.org/#/q/project:openstack/neutron+status:merged | 14:48 |
| anteaya | in this view I see jenkins leaving a green +2: https://review.openstack.org/#/c/374914/ | 14:49 |
| anteaya | also microsoft hyperv ci has left a +1 under verified | 14:50 |
| dirk | anteaya: so the verified in there comes from check pipeline or from gate pipeline? | 14:50 |
| anteaya | in the check pipeline if the infra system jobs all report success jenkins leaves a +1 verified | 14:51 |
| anteaya | https://review.openstack.org/#/c/358845/ | 14:51 |
| anteaya | if one voting job fails in the check pipeline jenkins leaves a -1 in verified | 14:52 |
| anteaya | in the gate pipeline if the infra system jobs all report success jenkins leaves a +2 verified (and the patch should merge) | 14:53 |
| anteaya | in the gate pipeline if one of the infra system jobs fails jenkins leaves a -2 in verified | 14:53 |
| anteaya | automated systems can only report in the verified area of the gui for gerrit | 14:54 |
| dirk | anteaya: aha! | 14:54 |
| dirk | anteaya: https://review.openstack.org/#/c/379454/ | 14:54 |
| anteaya | I hear a lightbulb | 14:54 |
| dirk | anteaya: so basically here the mos check should have left a verified -1 ? | 14:54 |
| anteaya | what is the mos check? | 14:54 |
| dirk | (mos check == Fuel Packaging CI) | 14:54 |
| anteaya | yeah lets call that fuel packaging ci | 14:55 |
| anteaya | I can't map mos to that and make it stick | 14:55 |
| openstackgerrit | Paul Hummer proposed openstack/requirements: Bump pylxd global-requirements to 2.1.1 https://review.openstack.org/379522 | 14:55 |
| anteaya | fuel packaging ci has an internal problem | 14:55 |
| anteaya | it is reporting success and verified +1 on job failures | 14:56 |
| anteaya | that is something to follow up on with the fuel packaging ci folks | 14:56 |
| anteaya | and if they don't fix it to remove verification permissions from that ci account on your repo | 14:57 |
| anteaya | that is the other thing with third party ci systems | 14:57 |
| anteaya | they require a lot of maintenance and follow up | 14:57 |
| anteaya | just having them have permissions doesn't mean they are using them properly | 14:57 |
| anteaya | s/just having them/just granting them | 14:58 |
| dirk | anteaya: I happen to have some insights into the zuul configuration ;) | 14:59 |
| anteaya | great | 14:59 |
| anteaya | do you have what you need? | 14:59 |
| anteaya | we have monopolized the requirements channel for some time | 15:00 |
| anteaya | and happy to help clarify things | 15:00 |
| anteaya | but I don't want to prevent requirements work from happening | 15:00 |
| dirk | whops, sorry, I thought this is a query | 15:01 |
| openstackgerrit | Paul Hummer proposed openstack/requirements: Bump pylxd global-requirements to 2.1.1 https://review.openstack.org/379522 | 15:01 |
| anteaya | dirk: what was a query? | 15:01 |
| dirk | anteaya: our discussion was in a query | 15:01 |
| anteaya | oh I'm not saying we shouldn't discuss this, happy to do so | 15:02 |
| anteaya | I didn't know you didn't know what you didn't know | 15:02 |
| anteaya | so happy to help | 15:02 |
| anteaya | just apologizing to any folks who are waiting to discuss requirments things | 15:02 |
| anteaya | dirk: have we more to discuss? | 15:04 |
| dirk | anteaya: -> query | 15:15 |
| anteaya | I'm sorry i am missing what you are trying to convey | 15:15 |
| *** coolsvap has quit IRC | 15:22 | |
| *** openstackgerrit has quit IRC | 15:49 | |
| *** openstackgerrit has joined #openstack-requirements | 15:50 | |
| *** jpena is now known as jpena|off | 17:23 | |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements: Add sphinx-testing to g-r https://review.openstack.org/379635 | 18:07 |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements: Add os-api-ref to projects.txt https://review.openstack.org/379636 | 18:07 |
| *** AJaeger has joined #openstack-requirements | 18:11 | |
| AJaeger | dirk: I pushed all the changs for os-api-ref now. | 18:12 |
| AJaeger | Do you want to do a new release of it as well? | 18:12 |
| AJaeger | dirk: https://review.openstack.org/379644 is the release - I espect we need it... | 18:17 |
| dirk | AJaeger: cool, thanks for pushing this | 18:20 |
| dirk | AJaeger: we could add to the projects.txt change then also the removal from the xfail list | 18:22 |
| AJaeger | dirk, where is the xfail list? | 18:25 |
| dirk | AJaeger: https://review.openstack.org/379203 :-) | 18:26 |
| AJaeger | dirk: so, once os-api-ref is released, then let's update 379203. | 18:29 |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements: Add os-api-ref to projects.txt https://review.openstack.org/379636 | 18:32 |
| openstackgerrit | Dirk Mueller proposed openstack/requirements: Fixes for check-uc jenkins job https://review.openstack.org/379203 | 18:33 |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements: Add sphinx-testing to g-r https://review.openstack.org/379635 | 18:42 |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements: Add os-api-ref to projects.txt https://review.openstack.org/379636 | 18:42 |
| openstackgerrit | Andreas Jaeger proposed openstack/requirements: Raise constraints for os-api-ref and openstack-doc-tools https://review.openstack.org/379707 | 18:44 |
| AJaeger | dirk, is the above needed? ^ | 18:44 |
| AJaeger | hope that's all ready now... | 18:44 |
| dirk | AJaeger: that last change should land automatically | 18:45 |
| dirk | AJaeger: as part of the release process with the release-review in releases/ we get a new review posted that raises upper constraints | 18:45 |
| AJaeger | dirk - ah, ok. Then I'll abandon... | 18:46 |
| *** dolphm has left #openstack-requirements | 18:59 | |
| *** toabctl_ has joined #openstack-requirements | 19:46 | |
| *** toabctl has quit IRC | 19:50 | |
| *** AJaeger has quit IRC | 19:50 | |
| *** toabctl_ is now known as toabctl | 19:50 | |
| *** AJaeger has joined #openstack-requirements | 20:14 | |
| *** jpena|off has quit IRC | 21:00 | |
| *** jpena|off has joined #openstack-requirements | 21:02 | |
| *** anteaya has quit IRC | 21:05 | |
| *** anteaya has joined #openstack-requirements | 21:29 | |
| openstackgerrit | Merged openstack/requirements: Bump gabbi to 1.26.1 https://review.openstack.org/379347 | 22:24 |
| prometheanfire | whoa, people are talking | 22:30 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!