Wednesday, 2018-03-07

*** lbragstad has quit IRC01:27
openstackgerritPaul Belanger proposed openstack/requirements master: [WIP] test wheel builds on bionic  https://review.openstack.org/55025401:40
openstackgerritPaul Belanger proposed openstack/requirements master: [WIP] test wheel builds on bionic  https://review.openstack.org/55025401:42
openstackgerritPaul Belanger proposed openstack/requirements master: Begin testing wheel builds with ubuntu-bionic  https://review.openstack.org/55025301:45
openstackgerritPaul Belanger proposed openstack/requirements master: [WIP] test wheel builds on bionic  https://review.openstack.org/55025401:45
*** edmondsw has quit IRC02:21
*** edmondsw has joined #openstack-requirements02:22
*** edmondsw has quit IRC02:26
*** andreas_s has joined #openstack-requirements02:43
*** andreas_s has quit IRC02:48
openstackgerritPaul Belanger proposed openstack/requirements master: Update bindep.txt for ubuntu-bionic  https://review.openstack.org/55025403:04
*** edmondsw has joined #openstack-requirements05:09
*** udesale has joined #openstack-requirements05:10
*** edmondsw has quit IRC05:14
*** prometheanfire has quit IRC06:56
*** edmondsw has joined #openstack-requirements06:58
*** coolsvap has joined #openstack-requirements07:00
tonybAre we doing a thing?07:02
*** edmondsw has quit IRC07:03
coolsvapI dont see prometheanfire07:03
dirko/07:03
dirkmaybe he fell asleep07:04
tonyb#startmeeting requirements07:04
openstackMeeting started Wed Mar  7 07:04:09 2018 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.07:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.07:04
*** openstack changes topic to " (Meeting topic: requirements)"07:04
openstackThe meeting name has been set to 'requirements'07:04
dirko/07:04
tonybThe queue .... https://review.openstack.org/#/q/status:open+project:openstack/requirements07:04
tonybhas anyone looked at it in the last 48 hours?07:05
coolsvapo/07:05
* coolsvap looking at it now07:05
dirka bit yeah, I don't think there is anything controversial atm07:06
dirkactually it seems people are still on PTG-travel or other post activitie07:06
tonybThe good news is tripleo has branched, so we just need to verify that kolla and OSA have and then we can really-really thaw07:06
dirkthe interesting thing is the switch to py36 testing (add bionic support)07:06
dirktripleo was the last project07:07
dirkand we already started merging uc over the weekend07:07
tonybdirk: Yeah, we have easy access to wheel builders now and can add similat for tox-py36 when we're ready07:07
tonybOh cool07:07
* tonyb will fix up constraints generation and add py36 tomorrow if y'all don't beat me to it07:08
dirk#action tonyb  fix up constraints generation and add py36 tomorrow07:09
dirkhappy to defer it to you :-)07:09
* dirk is pretty busy today07:09
tonyb;P07:10
dirkI might look at adding tumbleweed testing somewhere, but I don't see a *lot* of value in there07:10
*** pfire has joined #openstack-requirements07:10
pfireinternet is down07:10
coolsvappfire: o/07:10
tonybdirk: Havign new stuff would be good but it would mostly be a duplicate job07:11
dirkor asking it differently: would it make sense to run a devstack-integration on more than ubuntu on constraints changes? I don't see a good reason atm07:11
tonybdirk: if we were using distro packages then it make a lot of sense but as we're just pulling most stuff from pypi we don't gain a lot IMO07:11
dirktonyb: agreed07:12
tonyb#topic ptg07:13
*** openstack changes topic to "ptg (Meeting topic: requirements)"07:13
dirkone thing I haven't been following - does anyone want to look at getting rid of outdated/unused deps?07:13
tonybAnything we need to follow up on from the PTG07:13
pfiretalked to Doug earlier today07:14
tonybpfire: Yeah I read it07:15
dirkyeah, there was some proposal from doug, I haven't fully read the backlog yet07:15
pfireI think we are on close to the same page...07:15
tonybI think we're going to struggle to get everyon in the same discussion :(07:15
pfireya07:15
pfireif you can talk to him don't wait for me07:16
tonybpfire: I'm not 100% certain I agree with that, and dhellmann's proposal will make the lower-constraints work harder07:16
tonybI get thet dhellmann isn't signing up for oding that which is fine but we still want to do it07:16
dirkmaybe all that we need to agree on is the first step, as thats the one we've been not doing so far07:16
pfireby decoupling the carrot and stick?07:17
tonyb?07:17
pfirecarrot, per project reqs07:17
pfirestick lc testing07:17
tonybI still don't follow07:17
pfirewe can talk later, when I'm not on the phone07:18
tonybokay07:18
tonybAnthing else from the PTG?07:19
dirkwas there any discussion on the pycrypto thing?07:19
dirkor is the transition to cryptography settled?07:20
pfirejust to remind them more often, offering to help when needed07:20
tonybdirk: No I think we need to push for that to be an 'S' goal07:21
pfirealso pycrypyodome is the emergency fallback, kinda07:21
*** andreas_s has joined #openstack-requirements07:21
pfirewhy s?07:21
tonybpfire: becaus the goals for R are settled already aren't they?07:22
dirkearlier would be better though07:22
dirkit started to hurt about last cycle07:22
dirkI don't think its that big of a mess to be an official goal07:23
pfireyes, though I started bugging people about it before the ptg07:23
tonybdirk: Sure, we can work on it without a goal and it can be done ad-hoc but if it's still an issue in 4 months we shoudl push for a goal to get the work complete07:23
dirkbut I guess dependency-cleanliness is not a priority anymore with containerization07:23
pfiretony: cross project goal or reqs goal?07:24
tonybpfire: community wide goal07:24
tonybI agree it's apoor candidate but it's the only tool we have so ....07:25
pfireok, didn't know that was needed07:25
dirktonyb: wfm. Or maybe draft a generic goal of reducing overlapping dependencies07:25
pfireya07:25
tonybWe could perhaps aim for a couple of items on our problem list07:25
tonybSure07:25
pfireit does also fall under that overlap07:25
tonybI just think we've been asking for 2 years now so we need to try somethign else07:26
pfireI agree, cross project seems like a good idea07:26
dirkI tried to look at deps that haven't released a new version for 2+ years07:26
dirkAs those might not be a good dependency07:27
dirkThat gives quite a list of candidate07:27
tonybdirk: Wow that's a big chunk of work. ;P07:27
dirkWell, we don't need to eliminate all of them07:28
dirkBut the problematic ones07:28
pfirefor now I think we should limit our focus, but that's good for next cycle07:28
dirkA crypto library without updates sounds smelly07:28
tonybsure07:29
tonybokay aything else?07:30
tonyb#topic open discussion07:31
*** openstack changes topic to "open discussion (Meeting topic: requirements)"07:31
tonybcoolsvap: which city are you in again?07:31
pfireok, gonna leave for now then07:31
pfirecell phone and all07:31
tonybpfire: okay07:32
*** pfire has quit IRC07:32
dirktonyb: the other obvious candidate for dropping is tempest-lib07:32
coolsvaptonyb: Pune India07:33
dirkah we moved on already, sorry07:33
tonybdirk: Yeah I guess if tempest is the right thin to use there we shoudl do that07:33
dirkwell, any change to tempest-lib is -2'ed so its unmaintainable per excellence :-) but still there seems to be things depending on it07:33
tonybdirk: no biggie the topic is very fluid07:34
tonybdirk: Okay I'll reach out to thr QA team for help on that one07:34
tonyb.... So meeting times, its the bi-annual veryone moves clock thing over the next few weeks07:34
tonybwhen that's done this meeing looks like: https://www.worldtimebuddy.com/?qm=1&lid=2147714,12,6,1259229&h=2147714&date=2018-4-4&sln=17.5-1807:35
openstackgerritDirk Mueller proposed openstack/requirements master: Drop tempest-lib from g-r  https://review.openstack.org/55037507:35
tonybwhich is a bit silly for prometheanfire, dhellman and dims07:35
tonybso we shoudl probably look at what times are do able for us as a group07:36
dirkyeah, its getting late for prometheanfire07:36
tonyb... Or give up and switch to alternatine meetins and rely on in channel comms to keep us in sync07:36
tonybthoughts?07:37
dirktonyb: the question is if you want to do a meeting at 11pm+ :-)07:37
tonybdirk: I do not ;P07:37
tonybhttps://www.worldtimebuddy.com/?qm=1&lid=2147714,12,6,1259229&h=2147714&date=2018-4-4&sln=21.5-22.5 isn't too bad07:38
tonybbut I don't think prometheafire is a early riser07:38
dirk630 am might be tough for pfire07:38
tonybanyway start thinking and and we can disccuss it in channel or on the mailing list07:38
* tonyb really dislikes moving meetings every 6 months07:39
dirkso I think we used to have the slot at noon07:39
dirke.g. 8pm sydney 5am central07:39
dirkbut at this point its mostly prometheanfirew who needs to decide when he wants to be awake :-)07:40
tonybYup07:40
dirkthe alternative is something like 6am european07:40
dirkwhich is however still 11pm central - so probably not good for dims etc07:41
tonybYeah.07:41
tonybIt's a massive pain :(07:41
dirktonyb: so 9pm would be good for you?07:42
dirk6am central might be acceptable for some07:42
tonybAnyway I think we shoudl endmeeting as we're not going to decide now but we have a starting point for conversation07:42
dirkagreed07:42
tonybdirk: good? no, but I can do it ;P07:42
tonybThanks everyone07:43
tonyb#endmeeting07:43
*** openstack changes topic to "OpenStack Requirements - IRC meetngs on Wednesdays @ 07:00 UTC in here in #openstack-requirements - See agenda @ http://tinyurl.com/h44ryuw - IRC channel is *LOGGED* @ http://tinyurl.com/j38rk24"07:43
openstackMeeting ended Wed Mar  7 07:43:40 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)07:43
openstackMinutes:        http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-03-07-07.04.html07:43
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-03-07-07.04.txt07:43
openstackLog:            http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-03-07-07.04.log.html07:43
dirkI'd be willing to experiment with asynchronous meeting tbh07:44
dirkwith some discipline I have made good experiences with an etherpad-discussion over the course of a day07:45
dirkbecause things can be commented on in place, but without the need for time synchroniticity07:45
dirkas a food for thought ;-)07:46
tonybdirk: Yeah07:53
*** florianf has joined #openstack-requirements08:41
openstackgerritMerged openstack/requirements master: update constraint for openstackdocstheme to new release 1.19.0  https://review.openstack.org/54999808:44
openstackgerritMerged openstack/requirements master: update constraint for openstacksdk to new release 0.12.0  https://review.openstack.org/54998308:44
openstackgerritMerged openstack/requirements master: Adds castellan-ui  https://review.openstack.org/55026208:44
openstackgerritMerged openstack/requirements master: update monasca-common min 2.7.0  https://review.openstack.org/54341508:44
openstackgerritMerged openstack/requirements master: Begin testing wheel builds with ubuntu-bionic  https://review.openstack.org/55025308:44
*** edmondsw has joined #openstack-requirements08:46
*** ralonsoh has joined #openstack-requirements08:48
*** ralonsoh_ has joined #openstack-requirements08:48
*** edmondsw has quit IRC08:50
openstackgerritMerged openstack/requirements master: Update bindep.txt for ubuntu-bionic  https://review.openstack.org/55025409:10
openstackgerritMerged openstack/requirements master: Add documentation for lower-constraints.txt  https://review.openstack.org/54959309:26
openstackgerritDirk Mueller proposed openstack/requirements master: Drop tempest-lib from g-r  https://review.openstack.org/55037509:52
*** ralonsoh_ has quit IRC10:17
*** edmondsw has joined #openstack-requirements10:34
*** edmondsw has quit IRC10:38
*** coolsvap has quit IRC10:49
*** udesale_ has joined #openstack-requirements11:19
*** udesale has quit IRC11:21
*** udesale has joined #openstack-requirements11:21
*** udesale_ has quit IRC11:24
*** udesale has quit IRC11:36
*** vpickard_ is now known as vpickard12:19
*** mattoliverau has quit IRC12:21
*** mattoliverau has joined #openstack-requirements12:22
*** udesale has joined #openstack-requirements12:39
*** lbragstad has joined #openstack-requirements12:39
*** ameeda has joined #openstack-requirements12:59
*** ameeda has left #openstack-requirements13:13
*** prometheanfire has joined #openstack-requirements13:20
*** edmondsw_ has joined #openstack-requirements13:25
openstackgerritMonty Taylor proposed openstack/requirements master: Add neutron and horizon to global requirements  https://review.openstack.org/55047513:55
*** lbragstad has quit IRC14:15
*** lbragstad has joined #openstack-requirements14:21
*** pabelanger has quit IRC15:04
*** migi has quit IRC15:04
*** edmondsw_ is now known as edmondsw15:13
*** pabelanger has joined #openstack-requirements15:18
*** udesale has quit IRC15:45
openstackgerritMerged openstack/requirements master: Limit construct lib to before 2.9  https://review.openstack.org/54986615:46
*** andreas_s has quit IRC16:14
*** andreas_s has joined #openstack-requirements16:19
*** andreas_s has quit IRC16:28
*** andreas_s has joined #openstack-requirements16:33
*** andreas_s has quit IRC16:47
*** andreas_s has joined #openstack-requirements16:49
*** andreas_s has quit IRC16:58
*** florianf has quit IRC17:21
*** andreas_s has joined #openstack-requirements17:22
*** andreas_s has quit IRC17:41
*** andreas_s has joined #openstack-requirements17:44
*** andreas_s has quit IRC17:57
*** andreas_s has joined #openstack-requirements18:02
*** ralonsoh has quit IRC18:14
*** andreas_s has quit IRC18:16
dhellmanndirk : ++18:20
dhellmann(for more async communication)18:21
*** andreas_s has joined #openstack-requirements18:22
*** andreas_s has quit IRC18:36
*** andreas_s has joined #openstack-requirements18:41
*** sdake has joined #openstack-requirements18:59
*** sdake has quit IRC18:59
*** sdake has joined #openstack-requirements18:59
*** andreas_s has quit IRC18:59
prometheanfireugh, looks like gentoo was still using the old msgpack19:34
openstackgerritEmmet Hikory proposed openstack/requirements master: Begin testing wheel builds with Ubuntu Xenial ARM64  https://review.openstack.org/55057819:40
pabelangeris there a plan to delete stable/newton branch on requirements? I only ask because we are still building wheels, and unsure if jobs are still using that branch19:46
openstackgerritEmmet Hikory proposed openstack/requirements master: Begin testing wheel builds with Ubuntu Xenial ARM64  https://review.openstack.org/55057819:48
prometheanfirepabelanger: no20:28
dhellmannprometheanfire, dirk, tonyb : do you all feel that the notes I drew up yesterday are ready to be turned into a plan and published on the -dev list for feedback?20:42
prometheanfireI'd like a final review of the email, but generally yes I think20:43
prometheanfiretony had problems but I don't know what they were (I was offline due to cable company)20:44
dhellmannprometheanfire : oh, well, the idea is I would write the email as a "this is what I plan to do" thing and you'd comment there and we'd come to agreement. We don't have a specs repo, or I'd just use that.20:47
prometheanfireI'd like to at least wait til tony acks20:48
dhellmannsure20:49
dhellmannis tonyb's comment the one in purple on line 88?20:50
dhellmannoh, no, I see it in the meeting log scrollback20:51
prometheanfireI don't have that, I should look at irclogs20:51
dhellmanntonyb : I'm not sure I see how the lower constraints work becomes harder. That has to be per-repo anyway, so whatever tool we have to produce the list would need to work with requirements files input from a repo and produce the lower constraints.20:52
prometheanfiretonyb: ya, that time isn't too bad (around noon UTC)20:52
dhellmannI guess the global list was going to fill in minimum values for things we don't have listed explicitly in a given requirements file, but we can always get the old version of the file to do that. Or we could delay removing the minimum settings.20:52
prometheanfiredhellmann: removing minimum settings was on the table?20:54
dhellmannI suppose one way to do that would be to build a constraints file using the minimum values from the g-r list, then install the packages in the requirements files, then run pip freeze to see what packages were actually installed and use that list as the starting point for lower-constraints.txt for that repo.20:54
dhellmannprometheanfire : yes, step 3 on line 11320:54
prometheanfireline 113 of?20:54
dhellmannwe don't want to imply that those global minimums are correct20:54
dhellmannhttps://etherpad.openstack.org/p/ocata-requirements-notes20:54
prometheanfireah20:55
prometheanfirein the last cycle we went through and added the mins so that we could do min based testing20:55
prometheanfireyou'll probably see dirks name a bunch in git blame for that20:55
dhellmannwe've always had mins in g-r. maybe not for every single line?20:55
prometheanfireya, wasn't for every single one20:56
dhellmannok20:56
prometheanfireit is now and is enforced20:56
dhellmannI guess with that existing lower-constraints.txt file we can just use that to build a per-project constraints file20:57
prometheanfireyep20:57
prometheanfirethat was the idea20:57
dhellmannand what's the plan for defining the test job? python 3 only I hope? and in the repo via the local zuul config?21:00
prometheanfirewell, we'd like to see at least py3, but given swift is the poster boy...21:01
prometheanfirethe plan was for at least unit tests to be run with the project's lower constraints21:01
dhellmannprometheanfire : like this? https://review.openstack.org/55060321:04
prometheanfireya, looks about right21:06
dhellmannhow many repos do we think this is going to apply to?21:08
prometheanfireit's opt-in, so whoever wanted to be independent21:09
dhellmann"independent"?21:09
prometheanfireper-project21:09
prometheanfirewanted to stop syncing21:09
dhellmannoh. Well, I think we want all projects to stop syncing. Why would we not?21:09
prometheanfirethen all projects I guess, would be best case21:10
dhellmannok21:10
dhellmannthat's a lot of patches21:10
prometheanfireit is21:10
dhellmannI suppose it lets us define the job one time, though21:10
dhellmanninstead of in each repo21:10
dhellmannalthough that requires us to land all of the tox settings changes before we can turn the job on21:11
prometheanfirehow do you mean? you mean in project-config?21:11
dhellmannyeah21:11
prometheanfireya21:11
dhellmannI don't think we want that21:11
dhellmannat least not to start21:11
dhellmannit would delay getting things working21:11
dhellmannyay, the job is running against that patch21:12
dhellmanndo we need that in the gate queue, too?21:12
dhellmannif all the changes we need are in the project repo, it's probably scriptable. The question is whether we actually want all projects to have these tests, I guess.21:15
*** andreas_s has joined #openstack-requirements21:15
dhellmannI mean, sure, we do. But is it a requirement or is it a desire?21:16
prometheanfirethe cost of testing should be relatively low, gate allows us to test as it appears after merge, I think21:16
prometheanfireif it's not a requirement I'm not sure it's going to happen21:16
dhellmannyeah, I'm more worried about adding 200+ new test definitions than I am about running the extra check and gate job on each patch.21:16
prometheanfireyou mean the work in getting it merged into all the repos?21:17
dhellmannright21:17
dhellmannI don't want to block the rest of the syncing changes on that21:17
dhellmannprojects.txt has 324 lines21:17
prometheanfireya, that part is going to suck, but don't we do the same thing for tox.ini changes?21:18
dhellmannfor the constraints URL?21:18
prometheanfireand we can do it slowly, I get the impression you think it has to all merge at once21:18
prometheanfireya, like the constraints url (stable branch) updates21:18
dhellmannwell, you had been saying this was a prerequisite for stoping syncing21:19
dhellmannthose patches are proposed by a bot now21:19
dhellmannbut yeah, I guess since this looks pretty scriptable I can add it to the work I would be doing21:19
dhellmannassuming folks agree with the rest of the general plan and the way I've prepared the sample for oslo.config makes sense21:20
prometheanfirethe sync could check for the job definition of the lower check/gate and if found skip21:20
*** andreas_s has quit IRC21:20
prometheanfirewe'd still have to do cleanup and remove from projects.txt, but at least then they'd be desync'd21:21
prometheanfireI think that's what you are looking for?21:21
prometheanfireI think I'm happy with this, would be good to get the others view to be sure21:21
prometheanfirewe'd like the check/gate to be voting as well, but that should hopefully go without saying :D21:22
dhellmannso you're saying change the sync job to skip the repo if it has the lower-constraints tox environment?21:23
dhellmannI still don't like coupling these 2 things together21:24
dhellmannaccording to fungi  in -infra if we propose too many zuul config changes at one time it will break zuul21:24
dhellmannso we have to batch them21:24
prometheanfirethat's fine21:24
prometheanfirehow do you mean coupling them together?21:24
dhellmannadding the l-c test and stopping the sync job21:25
fungiconcurrent configuration changes running tests21:25
prometheanfireoh, ya21:25
prometheanfirefungi: what's a good number?21:25
dhellmannwe thought ~10 at a time would be safe21:26
fungi10 at a time is probably safe if you let most of them finish testing before you push more21:26
dhellmannoh! they can be up for review, just not running tests all at once?21:26
dhellmannwell, that's a bit better21:26
dhellmannI figured we needed to land the batch before proposing more21:26
fungifor every proposed zuul configuration change, it assembles a speculative future configuration state and our configuration is pretty huge already21:26
fungiit needs to hold all those prospective configuration states in memory while it's running jobs against them21:27
dhellmannwe could define the job in project-config and make it non-voting, but then every project team would have to make it voting with a separate patch to project-config so I'm not sure we gain that much that way21:28
dhellmannway more review bandwidth needed from the infra team, for example21:28
fungiwe've seen pushing ~50 in parallel basically max out the 30gb of ram we have on that system21:28
prometheanfiredhellmann: so make it voting by default or...?21:29
dhellmannprometheanfire : if we define the job centrally and add it to every repo voting then we have to already have the tox settings in place in all 324 repos before we turn on the job21:29
dhellmannif we define it centrally non-voting, then project teams can turn it to be voting as they get it working, but that's potentially 324 more patches for infra to have to review21:30
prometheanfireya21:30
dhellmannif we define it in tree, then we don't need infra to review anything and project teams can each review 1 patch per repo21:30
prometheanfireI think defining it in tox before we start with project-config21:30
prometheanfirethe problem with that is that once the job is added stuff will fail til the project teams fix it21:31
dhellmannthe safest way to do it is to add the job in-tree first; then after they all work we can replace the per-repo job with a centrally defined job21:32
dhellmannthen remove the per-repo job21:32
prometheanfireya, that would be the safest, a bunch of tracking though, but safer21:32
dhellmannI'm extending the etherpad with these notes21:33
dhellmannyay, the job passed for oslo.config21:35
prometheanfireya, looks good to me21:37
prometheanfirereading from 116 on21:38
prometheanfireI don't see an update for the pass yet :P21:38
dhellmann'update for the pass'21:40
dhellmann?21:40
prometheanfirethe test results listed https://review.openstack.org/#/c/55060321:44
dhellmannoh, it's still running a dsvm job21:48
dhellmannsee http://zuul.openstack.org21:48
prometheanfireah21:49
openstackgerritDirk Mueller proposed openstack/requirements master: Drop tempest-lib from g-r  https://review.openstack.org/55037521:50
dhellmannugh, I just realized with all of the variations for how to configure zuul the script to add the job may not be trivial21:50
dhellmannlots of projects have .zuul.yaml or .zuul.d or zuul.d21:51
prometheanfireya :| forgot about that21:51
prometheanfiredhellmann: I see you are around :P21:51
dhellmannwe at least have some conventions in place so the latter 2 cases are the same21:51
prometheanfireya21:52
dhellmannauto-editing existing yaml files can be messy21:53
tonybdhellmann: In general I think we're on  the same page.  I need to think through how indepenant that lets projects be and if that's a problem or not.  Also while I get that you're not signing up for the lower-constratints work I think that removing minimums from g-r makes that work really hard so I'm inclined to leave it there22:10
tonybdhellmann: which job are we adding?22:11
dhellmannhttps://review.openstack.org/#/c/550603/422:12
dhellmanntonyb : there is now a lower-constraints.txt file in the requirements repo as well, but as soon as we stop syncing both sets of mins will be lies22:12
*** openstackstatus has quit IRC22:13
*** openstack has joined #openstack-requirements22:15
*** ChanServ sets mode: +o openstack22:15
prometheanfiredhellmann: like swift :P22:15
tonybdhellmann: Oh the plan was to work with infra to provide a varient of the tox jobs that would do that for us22:15
dhellmanntonyb : do the py35 jobs not run within tox now? I can't remember the state of that.22:16
dhellmannbut see also the logic in the etherpad about why we don't want to do a central job first22:17
tonybdhellmann: the plan we had in Denver was that the check tool wouldn't allow a project to up a minium above what's in g-r, without first upping it there.  In much the same was as today so that mimimum in gor- could be used to regernate the lower-constraints.txt in requirements22:17
tonybdhellmann: No they're runnign in tox.22:17
dhellmanntonyb : ok, that violates the whole point of doing this work22:18
dhellmannthe point is we don't want projects to have to have the same minimums as anyone at all22:18
prometheanfireif a project could raise the min, the effective min/max would both be as defined as whatever is in UC22:18
tonybdhellmann: we discussed a series of chnages to make the lower-constratints) gateing a little better22:18
tonybdhellmann: No the same, just we track the highest minimum in g-r22:18
dhellmannI don't really see the point to doing that extra work22:20
prometheanfiretonyb: so if a project raised their min we'd just raise our min (via a bot that checks all projects?)22:20
tonyb$project a can have a no minimum, project b can have >=1.0.0 pand projects{n..m} can have any they like ... with the proviso that the highest minimum across all of openstack is tracked in g-r22:20
dhellmannI'm trying to simplify all of this22:20
tonybprometheanfire: Sure we could do it that way but that isn't what we discuessed22:20
tonybprometheanfire: and someone need to write it22:20
prometheanfiretonyb: sure, was just thinking how it'd end up working, doesn't have to be that way22:20
prometheanfirebut automation is nice22:21
dhellmannwe want projects to express valid minimums. In the absence of "valid" we want something. We don't care that any 2 projects have the same value, because the only time the minimum should ever come into play is if someone is installing a project via pip independently of all other projects and using old versions of packages for some reason.22:21
prometheanfireinstalling without -U22:21
dhellmannI want us to stop having bots proposing patches to keep things in sync that we don't need to be in sync.22:21
tonybdhellmann: I agree with all of that.22:22
prometheanfirewe should ask the question of if we should track mins at all in gr (and != too)22:22
dhellmannprometheanfire : I think I've consistently been saying "no" to that question22:22
prometheanfireif everything is independant I don't think we need to22:23
dhellmannright22:23
dhellmanneverything is independent22:23
prometheanfiredhellmann: you have, and I think I'm coming around22:23
dhellmannwe need 1 proven set of co-installable versions, and that's our u-c list22:23
tonybdhellmann: as a team we decided that we wanted to be able to do *global* lower constraints, and as a team we decided the only way we could do that was with the approach I described22:23
prometheanfirethe way we've been thinking of it is that only a few would be independant22:23
dhellmannwe could add other sets if we want to in the future, but we need to keep at least one for now22:23
dhellmanntonyb : ok. I wasn't present for that conversation so I'm sorry for arguing it all again.22:24
tonybdhellmann: I'm not placing a value on *if* we need to do that only sayin that your plan makes that work harder22:24
dhellmannI would like to understand why you think that's a useful set of numbers to have22:24
prometheanfireI was never a strong 'yes' on tracking global mins other than to help with getting per project stuff started22:25
tonybdhellmann: I'm really happy to revisit the initial premise, and for now I don't consider it a blocker in anyway ... if we can track the miniumums untl we make a call22:25
prometheanfireafter it's done the only reason would be to allow new projects to be added easilly22:25
dhellmanntonyb : that's fine with me. Removing the mins was the last step in the process anyway.22:25
tonybdhellmann: Because some dirstos are very reluctant to up a packaged version of $thing and will only do so if it can be domonstrated as needed22:26
prometheanfiregr would stop sending out updates and instead gather them from projects22:26
dhellmannprometheanfire : new projects could also assume that their lower bounds are the current upper-bounds, no?22:26
prometheanfireit'd be descriptive instead of perscriptive22:26
prometheanfiredhellmann: they can, if they are ok with that, sure22:26
tonybthis was the lever we came up with to validate it / provide the lever the distros need22:26
tonybIn general I'd really like to be able to test the lower bounds to find a rash of bugs we know we have22:27
tonybzigo, used to do that but always too late to be haelpful22:27
dhellmanntonyb : I understand that to be true. I also think it's not necessarily the community's responsibility to do the product-level testing for all of the distros by maintaining those lists.22:27
dhellmannif we have a $foo-distro-constraints.txt file that someone wants to maintain, I would support variants of test jobs on the platform using those versions.22:27
dhellmannbut I suspect those distros are already running their own tests using their packages instead, so I'm not sure there's community value in doing the tests upstream.22:28
dhellmanntesting per-project lower-bounds makes sense to me if we say we want projects to be run on their own, but I think that's a different case from what you're sayimng22:29
dhellmannsaying22:29
zigotonyb: I never really tested lower bounds, I just happened to use the intersection of what's in Debian stable with what's in requirements.22:29
zigoAnd sometimes, I found issues.22:29
dhellmannright, just like we do in rdo22:29
zigodhellmann: BTW, I'm done with packaging Queens, tomorrow, I'm starting functional testing, all with py3.22:30
dhellmannzigo : \o/22:30
zigoSo far, it went all quite well, appart from manila-ui which is not py3 compliant at all.22:30
dhellmannit's time for me to make dinner, so I need to drop off22:31
prometheanfireI just upgraded my home cluster to queens, smootest yet22:31
zigo(and of course, I'm not talking about swift)22:31
* prometheanfire knocks on wood22:31
zigodhellmann: Bon appetit ! :)22:31
tonybdhellmann: rdo tracks u-c aggressively22:31
prometheanfireya, I'm about to relocate22:31
prometheanfireOSA tracks it too22:31
zigoprometheanfire: Relocate to where?22:32
prometheanfirehome22:32
prometheanfireat work now22:32
zigo:P22:32
prometheanfire2018-03-07 22:31:33.313 21152 WARNING oslo_config.cfg [req-b83b8861-7e71-457b-9e5f-a28ee80dc041 - - - - -] Option "auth_uri" from group "keystone_authtoken" is deprecated. Use option "www_authenticate_uri" from group "keystone_authtoken".22:32
prometheanfireI'm tired of these values changing all the time btw22:32
tonybdhellmann: I more or less agree with everything you've said22:32
zigoyeah.22:32
zigoUseless...22:32
zigoI also agree with dhellmann about not synching minimums, though I'm afraid I don't trust it's going to work because projects will not do a good job at it.22:34
tonybdhellmann: the question with the per distro constraints file (which we agreed to try but the driver didn't do the work) is how to manage the interxection with packages and pypi ... but that's another issue22:34
dhellmanntonyb : yeah, the files would have to list versions on pypi for our normal test jobs to work properly22:34
zigoAnd the minimums will be just wrong.22:34
dhellmannzigo : I suspect so, too. jobs like https://review.openstack.org/#/c/550603/4 would help but applying those to all of the repos will be a lot of work.22:35
prometheanfireif we gather update into gr.txt (from the set that the projects update/test) instead of push updates from it we'd get what might be valid results22:35
zigoIt'd be really awesome to have it though !22:36
prometheanfireanyway, i'm walking to my car now22:36
prometheanfirebe back in a bit22:36
* zigo goes to sleep22:36
tonybdhellmann: Yup.22:36
zigo23:30 here22:36
dhellmannso I think I'll write up this plan as a long email tomorrow and start circulating it on the -dev list for broader feedback. is that ok with everyone?22:36
zigoGot to get up at 6:00 to go to $work ...22:36
prometheanfireearly22:36
dhellmannnot as a "this is what we will do" but "this is what we want to do" proposal22:37
* zigo nods22:37
*** edmondsw has quit IRC22:38
*** edmondsw has joined #openstack-requirements22:39
tonybdhellmann: Good plan22:41
*** openstackstatus has quit IRC22:42
*** openstack has joined #openstack-requirements22:44
*** ChanServ sets mode: +o openstack22:44
*** openstackstatus has joined #openstack-requirements22:44
*** ChanServ sets mode: +v openstackstatus22:44
*** vpickard is now known as vpickard_23:46

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