Tuesday, 2018-03-06

*** andreas_s has joined #openstack-requirements00:37
*** andreas_s has quit IRC00:41
rm_workCan someone refresh my memory -- do projects need to match EXACTLY the line from global-requirements for every package, or does it just have to be mostly matching?00:42
prometheanfirerm_work: what do you mean?00:46
prometheanfirewe are working on per project requirements https://bugs.launchpad.net/openstack-requirements/+bug/171900900:47
openstackLaunchpad bug 1719009 in OpenStack Global Requirements "per project requirements" [High,New]00:47
rm_workprometheanfire: like gr here https://github.com/openstack/requirements/blob/master/global-requirements.txt#L8400:48
rm_workcan we have a slightly different line?00:48
rm_workas long as it doesn't violate u-c00:48
prometheanfirewhat do you want it to be?00:48
rm_work>=2.1000:48
prometheanfire(and why)00:48
rm_workbecause that's what we require00:48
rm_workour project literally breaks on lower00:48
prometheanfireif that's what your project requires then update GR00:50
rm_workk00:50
rm_workcan we backport g-r?00:50
prometheanfire(and lower)00:50
rm_workto queens00:50
prometheanfireno, the biggest thing we allow for stable branches is disallowing something00:50
rm_work:/00:51
rm_workk00:51
prometheanfireya00:51
*** oanson has quit IRC00:56
rm_workit SHOULD be fine but apparently RDO doesn't use upper-constraints and like ... just grabbed the lowest version of jinja2 that is valid (2.8.1) which doesn't work00:56
rm_workand i can't argue that technically our requirements are wrong since we imply 2.8.1 would work00:57
*** oanson has joined #openstack-requirements01:03
prometheanfireso you are not using upper-constraints?01:05
prometheanfirethat seems like asking for trouble01:05
openstackgerritAdam Harwell proposed openstack/requirements master: Bump jinja2 minimum to 2.10 (required by Octavia)  https://review.openstack.org/54991301:40
rm_workprometheanfire: it's not me, it's the RDO packagers01:41
rm_workand I told them as much :P01:41
rm_workprometheanfire: ^^ feel free to ask why they aren't using u-c on that patch, lol01:47
prometheanfirelol01:47
prometheanfireour UC is still good, we can accept a gr block on something if it breaks something, but so far it looks like this is all RDO packagers' fault01:48
*** ying_zuo_ is now known as ying_zuo03:51
*** andreas_s has joined #openstack-requirements04:06
*** andreas_s has quit IRC04:11
*** udesale has joined #openstack-requirements04:44
*** andreas_s has joined #openstack-requirements06:48
*** andreas_s has quit IRC06:53
*** andreas_s has joined #openstack-requirements07:25
*** florianf has joined #openstack-requirements08:31
*** oanson has quit IRC08:41
*** ralonsoh has joined #openstack-requirements08:49
*** oanson has joined #openstack-requirements08:50
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for openstacksdk to new release 0.12.0  https://review.openstack.org/54998309:11
*** dims has quit IRC09:45
*** dims has joined #openstack-requirements09:49
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for openstackdocstheme to new release 1.19.0  https://review.openstack.org/54999810:11
*** ralonsoh_ has joined #openstack-requirements10:28
*** ralonsoh has quit IRC10:32
*** ralonsoh_ is now known as ralonsoh10:33
openstackgerritMerged openstack/requirements master: Bump jinja2 minimum to 2.10 (required by Octavia)  https://review.openstack.org/54991312:30
*** edmondsw has joined #openstack-requirements13:27
*** udesale has quit IRC13:29
*** udesale_ has joined #openstack-requirements13:29
*** florianf has quit IRC14:38
*** florianf has joined #openstack-requirements14:39
*** andreas_s has quit IRC16:23
*** andreas_s has joined #openstack-requirements16:28
prometheanfiredhellmann: when would you like to go over the per project requirements?16:30
dhellmannprometheanfire : I'm free now. Do you want to schedule a time when dirk and/or tonyb can be included?16:31
prometheanfiredhellmann: yes, so probably ~5 hours I think16:40
dhellmannthat seems late for dirk, but I don't know his work schedule16:40
prometheanfiredhellmann: our normal meeting time is 1AM Central16:41
dhellmannah16:41
prometheanfirewhich is tonight16:41
prometheanfireactually16:41
*** andreas_s has quit IRC16:42
dhellmannok, I can be available to discuss it then16:44
prometheanfiredhellmann: ok, thanks, depending on when people are around we may be able to do it beforehand]16:47
dhellmannok16:47
*** udesale_ has quit IRC16:53
*** ralonsoh has quit IRC18:09
*** florianf has quit IRC18:30
*** florianf has joined #openstack-requirements18:45
*** florianf has quit IRC20:00
openstackgerritPaul Belanger proposed openstack/requirements master: Begin testing wheel builds with ubuntu-bionic  https://review.openstack.org/55025320:49
openstackgerritPaul Belanger proposed openstack/requirements master: [WIP] test wheel builds on bionic  https://review.openstack.org/55025420:49
*** prometheanfire has quit IRC21:10
openstackgerritBrianna Poulos proposed openstack/requirements master: Adds castellan-ui  https://review.openstack.org/55026221:18
-openstackstatus- NOTICE: The infrastructure team is aware of replication issues between review.openstack.org and github.com repositories. We're planning a maintenance to try and address the issue. We recommend using our official supported mirrors instead located at https://git.openstack.org.21:18
*** prometheanfire has joined #openstack-requirements21:28
*** vpickard is now known as vpickard_21:54
dhellmannprometheanfire , tonyb, dirk : I have added some notes about an implementation plan to the bottom of https://etherpad.openstack.org/p/ocata-requirements-notes22:09
dhellmannI would appreciate it if you could confirm that I'm interpreting the test behaviors correctly and that I have thought through the sequence of steps correctly22:10
dhellmannonce we agree in general, I can write up a more detailed plan to send to the -dev list22:10
prometheanfiredhellmann: https://bugs.launchpad.net/openstack-requirements/+bug/1719009 is our rough draft22:23
openstackLaunchpad bug 1719009 in OpenStack Global Requirements "per project requirements" [High,New]22:23
dhellmannprometheanfire : I'm still confused by all of the stuff about global lower requirements in that bug :-(22:30
prometheanfiredhellmann: I think that's lower-constraints now22:31
dhellmannit feels like some completely different project; like we're working on different things22:31
prometheanfirethe end goal is to allow projects to disable their reqs sync22:31
dhellmannprometheanfire : I'm also not personally interested in setting up gate jobs for projects to test their lower bounds, so I've left that part out.22:31
prometheanfirein order to do so they need to test their minimums22:31
dhellmannah, no, see, I don't consider that testing to be a prerequisite22:32
dhellmannbecause we're not testing it now22:32
prometheanfiretrue, but does that mean that the projects can just stop requirements updates?22:32
dhellmannadding testing for lower bounds is orthogonal to what I want, which is to stop having a bot keep the requirements.txt entries in order22:32
dhellmannyes, after we adjust the test that verifies that their requirements files have "valid" entries we can just delete the job that does the sync22:33
dhellmannat least I think so, based on the notes I dropped into that etherpad22:33
dhellmannand fwiw, I'm trying to come up with steps to let us just turn it off completely, not turn it off one project at a time22:34
prometheanfireI'm not sure I think projects will actually update their requirements files22:34
prometheanfirewhat happens if everyone just opts out?22:34
dhellmannwhat ensures that anyone updates the minimums in g-r today?22:34
prometheanfirehow is this diferent than projects just not syncing at all?22:34
prometheanfirenothing22:35
dhellmannso we're no worse off22:35
dhellmannthis is different from not syncing at all because projects still ensure that all of their deps are in g-r and that they work with the u-c version22:35
prometheanfiretrue22:35
dhellmannso we still maintain the co-installability feature22:35
prometheanfirejust seems like a step back22:35
dhellmannwhich was one of the main purposes of the g-r list in the first place22:36
prometheanfiresure22:36
dhellmannhow is it a "step back"22:36
dhellmann?22:36
dhellmannthat feels like you see a negative outcome that I may not be seeing22:37
prometheanfireI'm not sure I actually do22:37
prometheanfires/seems/feels22:37
dhellmannit definitely loosens the reins22:38
dhellmannbut we have the same benefit because we still have that constraints list22:38
dhellmannsyncing made sense before we had constraints, but now that pip supports constraints we don't need to be so tightly in sync22:38
prometheanfireone of the things I wanted before marking a project as 'self managed' is that they have something to ensure that they are looking at their requirements and updating them as needed22:39
prometheanfireI get that we don't really lose anything22:39
prometheanfiresure22:39
dhellmannI agree having something like that would be nice.22:39
prometheanfirethat's what the lower-constraints testing was meant to do22:40
dhellmannsure, that was per-project though22:40
prometheanfireyep22:40
*** andreas_s has joined #openstack-requirements22:41
prometheanfirethey only use of the global lower constraints is to fill in the blanks of what gets generated per project (since deps of requirements are not tracked)22:41
prometheanfireit could be fully self managed as well though, as dirk is doing/did for the requirements project22:42
dhellmannah, so the global list will be used to produce the per-project lists?22:42
dhellmannat least the initial versions?22:43
prometheanfirefill in the blanks22:43
prometheanfireprojects would have their first pass be is defined in their requirements file22:43
dhellmannI guess I'm lazy, I was just going to populate it with the lower bounds listed in their requirements files and let people add older versions of other things as they felt the need22:43
prometheanfirethat's probably better, allows projects to self manage/override as well22:44
prometheanfireand self document22:44
dhellmannbut again, I'm way less interested in that lower bounds testing22:44
dhellmannnot all projects need to do it22:44
prometheanfireyep, I was only wanting it for projects self managing reqs22:44
dhellmannbecause we already tell distributors to look at the u-c list22:44
dhellmannso only projects that want to be installable via pip on their own will actually benefit from it22:44
dhellmannor projects that are being packaged on their own somehow outside of the major os vendors22:45
dhellmannand that list of projects is pretty small22:45
prometheanfireaparently rdo doesn't follow uc, not sure lc would help though22:45
prometheanfiretrue22:45
dhellmannyeah, if they're not following it they're going to have to do their own testing anyway22:45
prometheanfireyep22:45
dhellmannby "projects self managing reqs" do you mean that are not validating against g-r at all?22:46
dirkdhellmann: not sure it is actually true that vendors follow uc. they use it as inspiration, but it isn't always followed 100$22:46
dirk100%22:46
*** andreas_s has quit IRC22:46
prometheanfireno, I mean they still validate22:46
* prometheanfire needs to find a term for this inbetween22:46
dhellmanndirk : true, but we *tell* them to look at that list. We give them 1 set of versions we know works. If they don't like those versions, testing is up to them.22:46
dirkdhellmann: I think upstream could be more collaborative than "either this way or the high way"22:47
dhellmannprometheanfire : my goal is to have projects that validate against g-r and u-c, and projects that ignore the requirements repo entirely22:47
dirkdhellmann: did you intentionally add the rocky plan to the ocata etherpad? feels weird22:47
*** jrist has quit IRC22:47
* prometheanfire wasn't going to say anything22:48
dhellmanndirk : sure. I'm not saying we won't. I'm just saying I'm not personally interested in implementing all of that because I think the gain is very small. So if someone else wants to implement it, I support them doing that work.22:48
*** jrist has joined #openstack-requirements22:48
prometheanfiredhellmann: yes, that is the min neede to get this working22:48
dhellmannyeah, I was trying to keep all of the notes in one place22:48
dirkprometheanfire: sorry, I'm not good at knowing when to shut up ;-)22:48
prometheanfiredhellmann: I wanted to tie it to lower bounds testing because I just don't trust projects to self manage I guess :P22:49
dhellmannI shouldn't have named that etherpad with "ocata" in the title to begin with22:49
prometheanfiredhellmann: we had a separate etherpad for this, but that was moved into the bug22:49
dhellmannprometheanfire : like I said, they have nothing in place to cause them to do it now.22:49
prometheanfiretrue22:49
dirkdhellmann: I would actually say that the uc-working-for-all-projects-at-any-point-in-time is actually a myth more than reality to some extend22:49
prometheanfireit's prefrence to want to move to something tighter than to the same22:50
dhellmanndirk : why? because our test coverage isn't high enough?22:50
prometheanfireit's a weaker prefrence than an hour ago though22:50
dirkdhellmann: its only really tested by the "devstack integration" job, and that one uses pip for many deps (aka releases aka snapshots of a project from the past)22:50
prometheanfiredirk: that's what the freeze period is for though22:50
dirkat any point in time there are always some projects gating job broken by some uc chnage samewhere, and some things already more ahead and some more behind22:50
dhellmannisn't that pip call using the constraints list, though? isn't that exactly the point of having that list?22:50
dhellmannah22:51
dirkdhellmann: sure, but the factor is time: releases happen in the past, uc is independent of that22:51
dirkit is a bit synced via a freeze period as prometheanfire mentioned, and it certainly is not a big issue, but to some extend there is always a slight mismatch22:51
dhellmannyes, I see what you mean, there is some slack in the system22:52
prometheanfiretechnically constraints/reqs support defining git urls, but we shouldn't do that22:52
dirkdhellmann: it certainly would become better if the "coinstallable set" is more towards the lower bounds than the upper bounds like it is now22:53
dirkespecially if there is some testing on the project-minimums being "correct"22:54
dhellmanndirk : I can't imagine us saying that we need to maintain coinstallability for anything other than the upper-bounds of our own releases, though22:54
dhellmannwe're not going to say that projects need to work with old versions of oslo libraries that do not include the features they need22:54
dhellmannwe could technically have a different constraint list for every distro if we wanted to22:55
dhellmannwhere the distros specified the versions of the non-openstack packages they ship and we keep it up to date with the versions of the things we're releasing22:55
dhellmannthe problem is we can't gate on that, because we try to use the requirements list to push distros to adopt the new versions of non-openstack things that we require for new features22:56
prometheanfireboil the oceans22:56
dhellmannand as soon as we gate on something they won't change, we stop being able to advance22:56
dhellmannI'm just trying to fill a tea kettle over here22:57
dirkdhellmann: not saying that projects should do anything other than now. if they use a feature of an oslo library, they should jus trequire it22:58
prometheanfireI think I'll have some tea tomorrow for my fix22:58
* prometheanfire likes rusts dep model22:58
dirkdhellmann: I certainly don't want to encourage to remain on old stuff, I just want to have lower bounds be correct in the sense of reflecting what the project actually requires (and yes that can be newer and older than what it could get via g-r)22:59
* dirk needs to get some sleep before the meeting tomorrow though :)22:59
dhellmanndirk : I do support having testing for lower bounds, just not enough to implement it myself. :-)22:59
dirkI'll try to check the etherpad tomorrow morning, but I'll likely not be able before the meeting starts22:59
dirkdhellmann: fine ;)22:59
dirkI actually carea bout that part quite a bit, so we can collaborate23:00
dirkanyway, not today anymore.23:00
dirkafk23:00
prometheanfirecya23:00
prometheanfirenn23:00
* dhellmann should sign off for the evening, too23:00
prometheanfiredhellmann: not at meeting tonight (just want to know if we should wait if you are not around)23:01
dhellmannwhat time was that agin?23:01
prometheanfire1am23:01
prometheanfirecentral23:01
dhellmannwhat tz?23:01
prometheanfire-623:01
dhellmannok, that's 2am here in EST? I think I'm very unlikely to be coherent at that time tonight given my day. :-(23:02
prometheanfirek23:02
prometheanfirenp, catch you later23:02

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