| *** jamesd has quit IRC | 02:27 | |
| *** jamesd has joined #openstack-requirements | 02:29 | |
| *** stevemar_ is now known as stevemar | 02:49 | |
| *** armax has quit IRC | 04:29 | |
| *** armax has joined #openstack-requirements | 05:15 | |
| *** coreycb has quit IRC | 05:15 | |
| *** mordred has quit IRC | 05:16 | |
| *** mordred has joined #openstack-requirements | 05:21 | |
| *** armax has quit IRC | 05:45 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements: Updated from generate-constraints https://review.openstack.org/364762 | 07:37 |
|---|---|---|
| *** jpena|off is now known as jpena | 07:42 | |
| *** coolsvap_ is now known as coolsvap | 09:09 | |
| *** jpena is now known as jpena|lunch | 11:17 | |
| *** openstackgerrit has quit IRC | 11:34 | |
| *** openstackgerrit has joined #openstack-requirements | 11:35 | |
| prometheanfire | tonyb, sigmavirus, prometheanfire, number80, dirk, coolsvap, toabctl - requirements meeting in 5 | 11:55 |
| coolsvap | prometheanfire: ack | 11:56 |
| prometheanfire | tonyb, sigmavirus, prometheanfire, number80, dirk, coolsvap, toabctl - requirements meeting in openstack-meeting in 1 min | 11:59 |
| * number80 is sick today | 12:04 | |
| number80 | have a good meeting! | 12:04 |
| coolsvap | number80: tc, gws | 12:05 |
| tonyb | Thanks all | 12:37 |
| * tonyb -> bed | 12:37 | |
| prometheanfire | nn :D | 12:39 |
| *** jpena|lunch is now known as jpena | 12:55 | |
| openstackgerrit | Sean Dague proposed openstack/requirements: block oslo.db 4.13.3 as it causes test races https://review.openstack.org/370115 | 13:27 |
| prometheanfire | lolol | 13:30 |
| *** zhugaoxiao has quit IRC | 13:35 | |
| *** armax has joined #openstack-requirements | 15:12 | |
| dhellmann | tonyb, prometheanfire : if we're going to support projects having diverging requirements settings, their minimums may be different. so anything we do to test lower constraints needs to compute the constraints per-project. maybe we should just keep a list in each repo, instead of a global list? then if we set up a unit test job to use the local lower constraint file, it's easy for a project to update that when | 15:33 |
| dhellmann | they realize something is causing them to need a new version. | 15:33 |
| dhellmann | tonyb , prometheanfire : and then we can have a periodic job that compares the mins across all repos and proposes changes to the global list when nothing supports the min version in the global list | 15:34 |
| dhellmann | tonyb, prometheanfire : all of that assumes we use unit tests to manage lower constraints, and not a dsvm job, but maybe that's sufficient? | 15:35 |
| prometheanfire | dhellmann: well, we are suposed to have global lowers, but if we don't then each project would have to have their own, yes | 15:35 |
| dhellmann | prometheanfire : right, in order to support the overlapping but different requirements ranges between projects we can't have a global lower | 15:35 |
| prometheanfire | having the global min be mostly unsupported isn't useful | 15:35 |
| prometheanfire | ya | 15:36 |
| dhellmann | right, the periodic job would watch for projects that gradually shift up | 15:36 |
| prometheanfire | not sure what's sufficient testing wise, more testing is always nice, but also a headache | 15:36 |
| prometheanfire | resource wise | 15:36 |
| prometheanfire | the global min should be the maximum minimum found in the projects using/testing lower-constraints | 15:37 |
| dhellmann | right, I think the unit tests are less expensive than dsvm, and they're decoupled from everything else so we wouldn't get a constraint in project A causing project B to work even when it probably doesn't have the right lower bound set | 15:37 |
| prometheanfire | that'd be a useful thing | 15:37 |
| dhellmann | prometheanfire : right, that's what the periodic job I mentioned would compute | 15:37 |
| prometheanfire | that's true | 15:37 |
| prometheanfire | ah | 15:37 |
| prometheanfire | I read that as global would be the minimum munimum | 15:38 |
| prometheanfire | not the max min | 15:38 |
| dhellmann | prometheanfire : oh, no, min min, I misread what you said | 15:38 |
| prometheanfire | min min isn't useful in a global setting | 15:38 |
| dhellmann | in order for a project's requirements to overlap with the g-r list we have to keep g-r set to the min-min | 15:38 |
| dhellmann | but each project could have its own min that is higher | 15:38 |
| dhellmann | distros should still package u-c, but someone deploying a project on their own could optionally use the lower ranges in each project | 15:39 |
| prometheanfire | I'd suggest renaming gloabl-requirements to lower-requirements in that case | 15:39 |
| dhellmann | well, it also includes exclusions | 15:39 |
| prometheanfire | use that to sync | 15:39 |
| prometheanfire | and then global requiremetns would track the max min across projects | 15:40 |
| prometheanfire | that'd be useful to distros at least | 15:40 |
| dhellmann | if we track the max min, we can't have diverging requirements between projects. | 15:40 |
| prometheanfire | track, not push to the projects | 15:40 |
| dhellmann | ah | 15:40 |
| dhellmann | that might be useful to track separately | 15:40 |
| dhellmann | g-r should be min min, we can add a max-min file, and u-c is the fully tested version | 15:41 |
| prometheanfire | yep | 15:41 |
| prometheanfire | the max-min version could be fully tested as uc as well | 15:41 |
| dhellmann | and I guess we don't sync at all, just have a job in each project testing that their requirements and lower-constraints are compatible with the global list | 15:42 |
| prometheanfire | that would be the openstack-wide min version testing | 15:42 |
| prometheanfire | yep | 15:42 |
| prometheanfire | every project would have at least one new test, probably 2 (py3) | 15:42 |
| dhellmann | we could only do this for py3, to cut down the number of jobs | 15:42 |
| prometheanfire | so that sucks, but if only unit it should be alright | 15:42 |
| prometheanfire | true | 15:42 |
| prometheanfire | everyone should be using py3 by now, right :P | 15:43 |
| dhellmann | "you get to have divergent requirements when you have a py3 unit test job running" | 15:43 |
| prometheanfire | that's a good incentive | 15:43 |
| prometheanfire | especially to people like swift :P | 15:43 |
| prometheanfire | well, not people, swift is a nice guy | 15:44 |
| prometheanfire | swift the project | 15:44 |
| prometheanfire | talking about swift to swift is always a fun situation | 15:44 |
| dhellmann | I wasn't thinking of any project in particular | 15:44 |
| prometheanfire | right | 15:44 |
| dhellmann | just that it's a way to minimize the number of jobs | 15:44 |
| dhellmann | and be looking ahead | 15:45 |
| *** coreycb has joined #openstack-requirements | 15:45 | |
| prometheanfire | yep | 15:45 |
| prometheanfire | this should go in a bug as a precursor to a blueprint | 15:45 |
| dhellmann | prometheanfire : good idea | 15:46 |
| prometheanfire | dhellmann: this works for updates that change the min, but I think updates that add != still need to be done in gr | 15:55 |
| prometheanfire | as far as divergent reqs go | 15:55 |
| prometheanfire | dhellmann: https://bugs.launchpad.net/openstack-requirements/+bug/1623571 | 15:57 |
| openstack | Launchpad bug 1623571 in OpenStack Global Requirements "lower-constraints blueprint idea dumping ground" [Undecided,New] | 15:57 |
| prometheanfire | how do we get the bot to post in here when a new bug is submitted? | 15:57 |
| dhellmann | prometheanfire : well, maybe. if a bug in a lib doesn't impact a project, do we need that project to exclude it? | 16:01 |
| prometheanfire | it's harder to track | 16:01 |
| dhellmann | true | 16:01 |
| dhellmann | maybe to start we just stop syncing the mins | 16:02 |
| prometheanfire | we'd still need to sync the min mins to projects that are not divergent | 16:03 |
| *** jpena is now known as jpena|off | 16:11 | |
| dhellmann | prometheanfire, tonyb : I had another thought. We had talked about how it might be complicated to ensure that changes to the requirements ranges in divergent projects are checked against the global list. I don't think we need to check the whole range, though. We only need to verify that the u-c value for a dependency is compatible with the specification for that dependency in the project's requirements list. | 17:31 |
| dhellmann | The u-c value is already compatible with g-r, and already known to be a real package, so we can get commutative compatibility verification. | 17:31 |
| dhellmann | prometheanfire : regarding syncing min mins, how long do you see that as something we'd need to do? | 17:32 |
| dhellmann | prometheanfire : could we just say we're going to sync everything like we do now until the project is ready to stop, and then stop? no middle ground where we only sync mins? | 17:33 |
| dhellmann | or would that break what we said about syncing exclusions | 17:33 |
| prometheanfire | dhellmann: I'm not sure, for as long as divergent and non-divergent need to be co-installable | 17:33 |
| prometheanfire | I don't think there needs to be a middle ground | 17:33 |
| dhellmann | divergent are still going to have to work with u-c, so we'll always have co-installability | 17:33 |
| prometheanfire | true | 17:34 |
| dhellmann | prometheanfire, tonyb : I've tried to write this up more clearly in https://etherpad.openstack.org/p/ocata-requirements-notes | 18:01 |
| prometheanfire | cool | 18:10 |
| * dhellmann is seeing venn diagrams | 18:12 | |
| prometheanfire | lol | 18:31 |
| prometheanfire | dhellmann: congratulations, you've just invented another level of hell | 18:32 |
| openstackgerrit | Sergey Slipushenko proposed openstack/requirements: Add murano-pkg-check 0.1.0 https://review.openstack.org/370293 | 18:52 |
| dhellmann | prometheanfire : heh | 19:22 |
| *** coolsvap has quit IRC | 20:52 | |
| tonyb | dhellmann: I think that just checking u-c isn't enough. I think we want $projects requirement on foo to be a strict superset of that in g-r | 21:09 |
| prometheanfire | tonyb: moin :D | 21:09 |
| tonyb | dhellmann: Havign played around with the tools bother are pretty easy to validate so we can try both and see how they look | 21:09 |
| tonyb | prometheanfire: howdy. | 21:10 |
| tonyb | prometheanfire: just a quick IRC check while the kids get out of bed | 21:10 |
| dhellmann | tonyb : why a superset? that doesn't give us the flexibility to say that project A needs a newer version of a lib than project B, does it? | 21:10 |
| dhellmann | tonyb : IOW, I think an intersection is sufficient to maintain co-installability | 21:11 |
| prometheanfire | yep | 21:11 |
| prometheanfire | dhellmann: I think that as long as uc.txt work among all projects we maintain co-installability | 21:12 |
| tonyb | dhellmann: Hmm when I thought about it I thought that'd mean that we could have differing intersections for set(nove & g-r) & set(glance & g-r) | 21:15 |
| tonyb | dhellmann: but I could be wrong | 21:15 |
| dhellmann | tonyb : if gr is >=0.1 and nova is >=0.2 and glance is >=0.3 then nova and glance are not supersets of gr, they're subsets. | 21:16 |
| dhellmann | however, they're all still compatible | 21:16 |
| tonyb | dhellmann: picking u-c may work for an instance but when u-c shifts it'd be invalid | 21:16 |
| dhellmann | not if we don't cap | 21:17 |
| tonyb | dhellmann: true | 21:17 |
| tonyb | ... kids are dressed gotta go be a dad .... | 21:18 |
| dhellmann | tonyb : think about it, let's discuss via the etherpad | 21:18 |
| prometheanfire | ya, this assumes no caps | 21:19 |
| dhellmann | yeah, I added that to the etherpad | 21:19 |
| dhellmann | it at least assumes the caps move at the same pace across all projects, so maybe we do still need to sync those | 21:20 |
| dhellmann | I see 23 dependencies with caps | 21:20 |
| dhellmann | er, my grep is wrong, hang on | 21:21 |
| dhellmann | 21 | 21:21 |
| dhellmann | 2 are rules for python_version<3.0 | 21:21 |
| prometheanfire | yep | 21:23 |
| prometheanfire | updated the etherpad with minor notes | 22:24 |
| openstackgerrit | Jerry Zhao proposed openstack/requirements: add fortiosclient library for networking-fortinet https://review.openstack.org/370478 | 23:27 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!