Monday, 2018-01-15

*** kumarmn has joined #openstack-tc00:03
*** kumarmn has quit IRC00:05
*** kumarmn has joined #openstack-tc00:05
*** superdan is now known as dansmith00:11
*** kumarmn has quit IRC00:15
*** kumarmn has joined #openstack-tc01:15
*** kumarmn has quit IRC01:21
*** liujiong has joined #openstack-tc01:39
openstackgerritzhurong proposed openstack/governance master: Update policy goal for solum
*** kumarmn has joined #openstack-tc03:10
*** liujiong has quit IRC03:11
*** liujiong has joined #openstack-tc03:15
*** kumarmn has quit IRC03:19
*** rosmaita has quit IRC03:27
*** liujiong has quit IRC03:35
*** liujiong has joined #openstack-tc03:36
*** liujiong has quit IRC03:41
*** kumarmn has joined #openstack-tc03:45
*** liujiong has joined #openstack-tc03:49
*** kumarmn has quit IRC04:42
-openstackstatus- NOTICE: The filesystem has been restored to full health. We are attempting to keep logs uploaded between the prior alert and this one, however if your job logs are missing please issue a recheck.04:50
*** ChanServ changes topic to "The filesystem has been restored to full health. We are attempting to keep logs uploaded between the prior alert and this one, however if your job logs are missing please issue a recheck."04:50
*** ChanServ changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | | channel logs"04:54
*** kumarmn has joined #openstack-tc05:43
*** kumarmn has quit IRC05:48
*** kumarmn has joined #openstack-tc06:44
*** kumarmn has quit IRC06:49
*** kumarmn has joined #openstack-tc07:45
*** kumarmn has quit IRC07:49
*** liujiong has quit IRC07:50
openstackgerritMasayuki Igawa proposed openstack/governance master: [WIP] Add Cold upgrades capabilities
*** masayukig has joined #openstack-tc08:16
*** kumarmn has joined #openstack-tc08:46
*** kumarmn has quit IRC08:50
*** jpich has joined #openstack-tc08:58
*** kumarmn has joined #openstack-tc09:46
*** kumarmn has quit IRC09:51
*** kumarmn has joined #openstack-tc10:47
*** cdent has joined #openstack-tc10:47
*** dtantsur is now known as dtantsur|bbl10:48
*** kumarmn has quit IRC10:53
*** cdent has quit IRC11:10
*** cdent has joined #openstack-tc11:11
*** cdent has quit IRC11:16
*** cdent has joined #openstack-tc11:17
*** kumarmn has joined #openstack-tc11:48
*** kumarmn has quit IRC11:53
*** kumarmn has joined #openstack-tc12:49
*** andreaf has quit IRC12:53
*** andreaf has joined #openstack-tc12:53
*** kumarmn has quit IRC12:54
*** dtantsur|bbl is now known as dtantsur13:01
*** openstackgerrit has quit IRC13:18
*** kumarmn has joined #openstack-tc13:50
*** kumarmn has quit IRC13:54
*** cdent has quit IRC14:28
*** kumarmn has joined #openstack-tc14:30
*** kumarmn_ has joined #openstack-tc14:30
*** kumarmn has quit IRC14:34
*** gcb has joined #openstack-tc14:44
*** cdent has joined #openstack-tc15:05
*** rosmaita has joined #openstack-tc15:12
*** hongbin has joined #openstack-tc15:29
*** gcb has quit IRC15:54
mnaserhow do we ideally want to handle massive patchsets doing things like bumping openstackdocstheme version bump16:32
mnaserpuppet has a lot of repos and we've gotten a large # of patchsets to bump it up..16:32
mnaser(i'm proposing drop the requirement version and rely on upper-constraints which will avoid this)16:32
*** jpich has quit IRC17:46
*** dtantsur is now known as dtantsur|afk18:16
*** kmalloc has joined #openstack-tc18:19
-openstackstatus- NOTICE: Zuul has been restarted and has lost queue contents; changes in progress will need to be rechecked.18:23
EmilienMmnaser: I would abandon them18:42
dhellmannmnaser , EmilienM : what's the problem with accepting them?19:10
EmilienMdhellmann: 1) the person haven't communicated with the team at all before19:11
EmilienMdhellmann: 2) the change doesn't fit with our needs19:11
EmilienMdhellmann: 3) we waste CI resources every time this things happen19:11
EmilienMlast time someone proposed a change in all modules for something we didn't want and it triggered hundred of CI jobs19:12
mnaserdhellmann: also, we've worked decided to dropping versions from requirements.txt and avoid pinning things and rely on upper constraints, however, we weren't able to coommunicate that was the change we wanted :<19:12
EmilienMso what I would do is 1) engage dialog with this person 2) explain why we reject this patch and what we would rather do 3) make sure the person understands how the community works19:12
dhellmannmnaser : you should talk to the requirements team before proceeding with that change. They are working on plans that will stop syncing requirements into project repos that may conflict with not having minimums set in-tree19:13
mnaseri am really torn about this because it could very much be someone who is trying to pick up low hanging fruit19:13
dhellmannEmilienM, mnaser : it would be good for you to talk to the docs team before just rejecting all of the patches. Some of the things we're doing with documentation publishing will require the latest versions of the theme library to work properly.19:14
EmilienMdhellmann: we haven't rejected them yet I think19:14
EmilienMI did nothing19:14
mnaserwe have not indeed19:14
EmilienMI just skipped reviewing themm19:14
dhellmannyeah, I'm just saying...19:14
mnaseri wanted to start a conversation around it19:14
dhellmannok. I'm suggesting some people you should include in that. :-)19:14
EmilienMto me, puppet-* modules shouldn't have pined versions of any python project19:15
EmilienMwe should rely on whatever is in requirements19:15
mnaseryeah we don't really depend on anything.  we just build docs .. actually, even less, we just build release notes19:15
dhellmannEmilienM : in the abstract, I agree. In the concrete world of our CI and doc publishing, we need to make sure everything is going to keep working as expected.19:15
dhellmannso you could potentially move those requirements into doc/requirement.txt instead of updating test-requirements.txt19:16
dhellmannperhaps melissaml would help with that19:16
mnaserthats a good idea, and with irrelevant-files we can drop running our entire suite of tests19:16
mnaserfor these type of changes19:16
dhellmanngood point19:16
EmilienMwe do already19:17
mnaserEmilienM: not for requirements.txt changes i think19:17
EmilienMwhat I'm saying is not specific to docs19:17
EmilienMlet me check19:17
EmilienMah, just for test-requirements.txt19:18
mnaseri honestly dont mind these small changes.  i believe they're all done in good faith, i just try to see how we can do better at avoiding wasting resources from donated infra and taking away valuable time from devs19:18
EmilienMI'll add requirements.txt19:18
mnaserno one likes to wait for the gate :>19:18
EmilienMmnaser: is ok?19:20
EmilienMI'm unsure if we touch the file it will actually trigger one job after that19:20
mnaserEmilienM: im looking at it looks like the build release notes job installs sphinx itself now19:21
dhellmannEmilienM, mnaser : 99cloud is a chinese company, iirc, so it may be challenging to find melissaml on IRC. Email is probably the best way to reach out.19:22
EmilienMmnaser: so we wouldn't need that file at all?19:23
EmilienMdhellmann: ok, thanks19:23
mnaserdhellmann: ack19:23
dhellmannmnaser , EmilienM : the release notes job should use doc/requirements.txt for anything extra you need, including the theme19:24
mnaserEmilienM: i have to double check the jobs and verify for infra, but for now, adding the requirements exception is probably ok... but i wonder indeed as you said no jobs will run19:24
mnaserso maybe ideally we should just have 'openstackdocstheme' in doc/requirements.txt and drop requirements.txt19:24
mnaserand the nice thing is by doing that we can skip doc/requirements.txt19:25
mnaserand we will still have 1 job run19:25
EmilienMwe don't have doc/ in puppet repos19:25
mnaseroh you're right we have releasenotes/19:26
mnaserdrop requirements.txt and "openstackdocstheme" in test-requirements.txt (with your patch to avoid running a ton of jobs when we drop it from requirements)19:26
mnaserEmilienM: +2 your patch and ill email melissaml to ask for them to drop the requirements.txt file and replace it by "openstackdocstheme" only in test-requirements.txt .. however ill contact after we can get this patch merged to avoid the churn19:28
persiawhile it is laudable to conserve resources, and the decision to contact to discuss is an excellent one, is there a metric that is in place to determine how overloaded the CI resources are, as a means of measuring CI impact?  My guess would be that if someone were to submit patches at 4:00 UTC they would generally find the system fairly unloaded.19:53
*** dansmith has quit IRC20:22
*** openstackgerrit has joined #openstack-tc20:32
openstackgerritMohammed Naser proposed openstack/governance master: Add gating to verify project access levels in Gerrit
openstackgerritMohammed Naser proposed openstack/governance master: Add gating to verify project access levels in Gerrit
*** Guest49522 has joined #openstack-tc20:36
*** Guest49522 is now known as dansmith20:40
openstackgerritMohammed Naser proposed openstack/governance master: Add gating to verify project access levels in Gerrit
*** flwang has quit IRC21:11
*** flwang has joined #openstack-tc21:25
fungipersia: closest metric we have is probably the "Zuul Job Queue" graph at (when "Waiting" is at or near 0, there is no appreciable backlog)21:39
*** zaneb has quit IRC22:03
*** zaneb has joined #openstack-tc22:17
persiaThat one works, but perhaps the nature of my day caused me to express myself badly: I don't believe it to be a waste of resources to submit even 1000 parallel minor patches that call CI, so long as "Waiting" remains near zero at the time any more pressing change is submitted to gerrit.  While I am in support of dialog to understand motivation, and redirect people who are causing excess effort to other people based on a misunderstanding of how to23:03
persiahelp, I don't believe it is useful to claim "waste of CI resources" as part of the justification for why not to do things.23:03
persiaThat is, unless we can usefully demonstrate that having done so actually blocked someone else: while I'm not absolutely confident, I have doubts that adding several thousand more nodes to the CI pools would actually help the social problem that was mentioned before, but claiming a shortage of CI resources could result in a reaction of infrastructure donation if large organisations thought it would help them meet their goals of having more23:04
persia(not that more CI nodes is a bad thing: it isn't: this is more about solving the right problem)23:05
*** cdent has quit IRC23:17
*** kumarmn_ has quit IRC23:17
*** kumarmn has joined #openstack-tc23:18
*** kumarmn has quit IRC23:22
*** hongbin has quit IRC23:28
*** kumarmn has joined #openstack-tc23:35
*** kumarmn has quit IRC23:40

Generated by 2.15.3 by Marius Gedminas - find it at!