Thursday, 2017-04-20

*** hoangcx has joined #openstack-requirements00:40
*** udesale has joined #openstack-requirements05:06
*** kornicameister has joined #openstack-requirements06:16
*** florianf has joined #openstack-requirements06:26
*** hoangcx_ has joined #openstack-requirements06:56
*** hoangcx has quit IRC06:59
*** jpich has joined #openstack-requirements07:00
*** jhesketh has quit IRC07:14
*** jhesketh has joined #openstack-requirements07:44
*** florianf has quit IRC08:27
*** florianf has joined #openstack-requirements08:29
*** hoangcx has joined #openstack-requirements08:30
*** hoangcx_ has quit IRC08:31
openstackgerritNicola Peditto proposed openstack/requirements master: Added the IoTronic projects: - iotronic - iotronic-lightning-rod - python-iotronicclient  https://review.openstack.org/45538509:12
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for cliff to new release 2.6.0  https://review.openstack.org/45842210:02
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for ovsdbapp to new release 0.3.0  https://review.openstack.org/45842310:03
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for osc-lib to new release 1.4.0  https://review.openstack.org/45842410:03
*** sdague has joined #openstack-requirements10:21
*** hoangcx has quit IRC10:55
*** openstackgerrit has quit IRC11:32
*** openstackgerrit has joined #openstack-requirements13:11
openstackgerritEric Fried proposed openstack/requirements master: Update pypowervm to 1.1.2  https://review.openstack.org/45825913:11
*** jpich has quit IRC13:57
*** jpich has joined #openstack-requirements14:09
*** jpich has quit IRC14:18
*** Jeffrey4l has quit IRC14:19
*** jpich has joined #openstack-requirements14:19
openstackgerritEric Fried proposed openstack/requirements master: Allow pypowervm 1.1.2  https://review.openstack.org/45825914:44
openstackgerritLee Yarwood proposed openstack/requirements master: Require os-brick>=1.11.0  https://review.openstack.org/45854515:09
*** udesale has quit IRC15:11
*** hongbin has joined #openstack-requirements15:13
*** Jeffrey4l has joined #openstack-requirements15:31
openstackgerritStephen Finucane proposed openstack/requirements master: Bump cliff to 2.6.0  https://review.openstack.org/45855815:42
fungidhellmann: so the idea you mentioned in #openstack-infra about problems arising from pinning pbr and some other setup_requires was to add them to http://git.openstack.org/cgit/openstack/requirements/tree/blacklist.txt15:51
dhellmannyeah, I'm not 100% clear of exactly what that file does (maybe more than we want in this case?)15:52
fungione thing it's used for is to avoid complaining when people pin specific versions of those things in their project-specific requirements files15:53
dhellmannthat sounds like something we wouldn't want here. we don't want the pins, and should complain if people use them15:53
fungiit's also used to skip entries when generating upper-constraints.txt, looks like15:54
dhellmannthat part we do want15:54
dhellmannI think?15:54
dhellmanndirk, prometheanfire : ^^15:54
fungimaybe... i mean constraints is a pip-specific concept and we're talking about things that will get installed by setuptools outside of pip's control15:55
dhellmannhmm, probably true15:55
fungilooking at relevant hits from http://git.openstack.org/cgit/openstack/requirements/tree/blacklist.txt it looks like we only use it for skipping entries during constraints validation and omitting entries when generating constraints lists15:56
fungier, i mean http://codesearch.openstack.org/?q=blacklist.txt&i=nope&files=&repos=15:57
dhellmannso this probably needs to be a new file, to apply new rules15:57
mordredyah - I think we mostly want something that fails when anyone proposes changes to global-requirements.txt that touch setuptools, pbr or the other ones15:57
mordredyah15:57
dhellmanndoes someone have time to work on that?15:58
fungior do we only care to check for addition of <, <= and !=?15:58
fungiand <~ is a thing too, i think?15:58
dhellmannminimums seem ok, but nothing else?15:58
dhellmann> and >= are good, everything else should fail?15:58
fungii guess minimums are a problem only if they're higher than the available released versions15:58
dhellmannthat would fail for another reason, already being checked15:59
fungiand that's probably a pathological situation anyway, right15:59
dhellmannwe do try to install everything15:59
dhellmannso we want to allow the item in global-requirements.txt, but the rules there should only include > and >= operators15:59
funginoting we already have blacklisted a ton of setuptools releases in global-requirements.txt because devstack at least can take advantage of those when explicitly calling pip install setuptools16:00
dhellmannnotes going into https://etherpad.openstack.org/p/handling-setup-requires-in-gr16:00
fungiappdirs and six only have minimums declared (in master, and more recently in stable branches too i think)16:01
fungiwhat was the other setuptools setup_requires?16:01
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for pbr to new release 3.0.0  https://review.openstack.org/45857216:02
fungiaha, right, packaging16:02
fungihttps://github.com/pypa/setuptools/blob/master/setup.py#L16616:02
fungiand we similarly only declare a minimum for that in global-reqs16:02
dirkmordred: fungi : I don't think we want a separate file16:02
*** newmember has joined #openstack-requirements16:03
dirkis there a way to check if the setup.py template and the global requirements are in some conflict?16:03
dirke.g. trigger the actual error we currently have? that might be more useful16:03
fungidirk: for the pbr case, you actually need to try importing a consuming module which has the exclusion in its install_requires after setup_requires ahve already been satisfied16:04
mordreddirk: well, it's not just being in conflict, it's that because of how pbr and setuptools are installed _any_ constraint on them actually both doens't work and can lead to errors16:04
dhellmannwe need to apply a validation rule to avoid allowing any of our packages to introduce that conflict16:05
fungii mean, one slightly less draconian option is to check whether we're excluding the most recent available release for any of the problem packages16:05
mordredso it's one of those cases where it can seem like a good idea to express a constraint, but edge-cases in python packaging make it more of a footgun than anything else16:05
mordredfungi: ++16:05
fungioh, except in the case of maximum caps, we can't predict that future state16:05
dhellmannthat seems more complicated to code16:05
dhellmannalso that16:05
mordredI don't think we can put maximum caps into our things either - because hte install tools can't fulfull them - so as constraints they're lies16:06
dirkmordred: fungi : so basically https://git.openstack.org/cgit/openstack/requirements/tree/openstack_requirements/cmds/update.py#n66 and global-requirements.txt need to be identical?16:06
mordredlike, setuptools and pbr could break us in some way in the future ... but we cannot protect ourselves from it with requirements maximum caps16:06
dirkor do we also need to ensure that it is not capping?16:06
mordreddirk: I would argue that we need to ensure it's not capping16:07
fungidirk: that's far from sufficient because transitive dependencies are satisfied by setuptools/easy_install as well16:07
dirkright but we want that neither the one place nor the other one is capping16:07
dirkwe want them to be identical16:07
dirkso yes, we should develop a check for that.16:08
mordredyes. we want to ensure in both places that neither cap16:08
fungiso anything listed in the package's setup_requires, but also anything those setup_requires declare setup_requires on (as well as setuptools and the same for its setup_requires, both direct and transitive)16:08
mordredI _started_ to look in to developing a check for it, but then I wasn't fully sure where the right place would be16:08
mordredfungi: I thinkn to start with just a list of packages that should be validated to not have caps would get us somewhere, right?16:08
dhellmannmordred : https://etherpad.openstack.org/p/handling-setup-requires-in-gr16:09
fungiyeah, a static list is probably far easier than needing to recursively parse the ast for setup.py on an unguessable number of packages16:09
dhellmannoh, yes, please let's not do that16:09
fungiit will need to evolve over time, but i'm worried that automating the thorough solution would be more complex and buggy than occasionally having to add or remove something from the list16:10
dhellmannright16:10
openstackgerritMerged openstack/requirements master: update constraint for ovsdbapp to new release 0.3.0  https://review.openstack.org/45842316:11
dhellmannso, do one of you want to work on that change or should I ask on the ML for some help?16:11
fungishould we consider adding setuptools to the list? it's sort of a grey area (though its setup_requires are obviously a problem)16:12
fungii'm on the fence about setuptools mainly because devstack does actually do something like `pip -c upper-constraints.txt install setuptools` as part of its environment setup16:13
mordredfungi: it does- but that's for the gate - listing that constrained version in the actual requirements.txt can hose consumers who install things from pip16:13
fungiso excluding latest setuptools versions in global-requirements.txt does solve a class of setuptools-induced job breakages16:14
mordredit does - but software consumers can't count on the tools providing them with that version if we express it in g-r16:14
fungibut it's far from a complete solution in those cases and i'm always uneasy when i see that used to fix devstack while leaving the larger issue unsolved16:14
mordredyah16:14
mordredif a current setuptools is broken, us pinning it in the gate is merely a temporary thing so that the gate can move while we work with upstream to fix it16:15
mordredbut during that time our consumers are effectively broken and there is no mechanism we can use to unbreak them automatically16:15
mordredwhich is why fixing it upstream in setuptools is essential at that point16:15
fungiwondering if we just need a different solution for that which won't propagate to individual projects16:15
openstackgerritMerged openstack/requirements master: update constraint for osc-lib to new release 1.4.0  https://review.openstack.org/45842416:16
mordredwell - I think it's fine to cap it in upper-constraints16:16
mordredsince that does not get written to metadata in the package install and therefore subsequently read by pkg_resources16:16
mordredit's the stuff winding up in the packages's install_requires in the egg_info that borks us16:16
fungigood point, we can propose/aprove a hand-edited upper-constraints.txt change which lowers teh setuptools version and attempt to avoid approving bumps back to the known broken version (for those cases where the issue doesn't cause requirements changes to fail jobs anyway)16:17
mordredyah16:17
mordrednow - iirc, we actually have to do extra work in pbr to add the things from requirements into the egg-info metadata16:17
mordredso we _could_ also consider just removing that from pbr and not having out things express those constraints in the metadata so that pkg_resources doesn't ever try to validate it16:18
dhellmannfungi, mordred : maybe instead of building this, we should build the thing I proposed to stop syncing requirements16:18
dhellmannI don't think it's *that* much more complicated16:18
dhellmannhttps://etherpad.openstack.org/p/ocata-requirements-notes16:18
mordreddhellmann: I am not against that idea16:19
*** jpich has quit IRC16:20
mordredoh- ok - my idea about removing the injection of install_requires from pbr will not work16:21
mordredwe _used_ to not inject into install_requires, but that was also when we had pbr itself call out to pip during installation to install the contents of requirements.txt16:21
mordredwe moved from doing that to adding them to install_requires so that pip could just handle the whole thing itself16:21
mordredwhich overall is better16:21
mordredso I withdraw my suggestion about removing that bit from pbr16:22
*** newmember has quit IRC16:22
openstackgerritTerry Wilson proposed openstack/requirements master: Update ovsdbapp requirement to 0.3.0  https://review.openstack.org/45858116:23
*** newmember has joined #openstack-requirements16:23
mordreddhellmann: I believe I could work on a check to block constraints on a list of packages - I do not believe I have bandwidth this week or next to work on your sync-less proposal, although I'd be happy to _help_ on that16:23
fungiyeah, i'm far too underwater myself to write it right now, but as long as we track it as a thing we want hopefully we'll get around to it before the next time this happens (and also ask requirements reviewers in the meantime to be on the lookout for changes adding exclusions or caps to any of those 5 known problem packages?)16:26
mordredfungi: ++16:27
fungiif we do move forward with an automated check, we'll need to remove the exclusions lists from pbr and setuptools in global-requirements.txt too16:28
fungi(not only in master, but also in stable branches i suppose)16:31
openstackgerritMerged openstack/requirements master: Add Nemesis to requirements projects list.  https://review.openstack.org/45821216:53
openstackgerritMerged openstack/requirements master: update constraint for cliff to new release 2.6.0  https://review.openstack.org/45842216:53
openstackgerritStephen Finucane proposed openstack/requirements master: Bump cliff to 2.6.0  https://review.openstack.org/45855816:55
*** newmember has quit IRC16:56
*** IgorYozhikov has quit IRC17:14
*** IgorYozhikov has joined #openstack-requirements17:19
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for os-brick to new release 1.12.0  https://review.openstack.org/45861118:41
openstackgerritOpenStack Proposal Bot proposed openstack/requirements master: update constraint for os-win to new release 2.0.1  https://review.openstack.org/45861418:46
openstackgerritMerged openstack/requirements master: update constraint for monasca-common to new release 2.0.0  https://review.openstack.org/45798618:50
*** newmember has joined #openstack-requirements19:23
*** newmember has quit IRC19:27
*** newmember has joined #openstack-requirements19:28
*** newmember has quit IRC19:34
*** newmember has joined #openstack-requirements19:35
*** florianf has quit IRC20:21
*** sdague has quit IRC21:23
openstackgerritMerged openstack/requirements master: Allow pypowervm 1.1.2  https://review.openstack.org/45825922:43
*** sdague has joined #openstack-requirements23:06
openstackgerritchristopher.uhler proposed openstack/requirements master: Update os-brick version for Veritas volume driver  https://review.openstack.org/45868823:52

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