Monday, 2014-03-17

*** jepoy has quit IRC00:09
*** thuc_ has quit IRC00:09
*** jepoy has joined #openstack-infra00:09
*** thuc has joined #openstack-infra00:10
*** matsuhashi has joined #openstack-infra00:12
*** resker has quit IRC00:13
*** VijayTripathi has joined #openstack-infra00:13
*** jepoy has quit IRC00:14
*** thuc has quit IRC00:14
*** cyeoh is now known as Guest2027100:18
*** sarob_ has joined #openstack-infra00:18
*** mwagner_lap has quit IRC00:19
*** sarob_ has quit IRC00:23
*** yamahata has quit IRC00:24
*** matsuhashi has quit IRC00:31
*** esker has joined #openstack-infra00:33
*** esker has quit IRC00:38
*** rdwrer is now known as marktraceur00:43
*** marktraceur is now known as rdwrer00:43
mordredlifeless, dstufft: I'd use build tags if there were available - I like the concept of those - but what fungi says is right on00:44
mordredthe problem we're trying to solve is to ensure we're expressing the uniqueness of a commit00:45
mordredand although there are circumstances, such as what fungi says, where it can fall down and is non-perfect00:45
*** Sukhdev has quit IRC00:45
mordredit should DTRT if you are following openstack trunk yourself by making packages automatically from every commit and instaling those00:46
mordredwhile at the same time it shoudl be abundantly clear to anyone who gets a tarball that's autogenerated from this that it's autogenerated and not a release00:46
mordredI'm happy to tweak areas where we've gotten a pep440 and semver inspired view of that wrong00:47
lifelessmordred: so, semver says 1.0.0.a1, pep440 says 1.0.0a100:47
lifelessmordred: I don't care which we do, but I'd like to make what I do consistent within pbr's own docs :)00:48
mordredlifeless: is 1.0.0.a1 actually a violation of pep440? I raed it to be able to go either way00:48
*** thuc has joined #openstack-infra00:49
lifelessmordred: the reason my tests failed tempest etc was that oslo.config has a version X.Y.Za000:50
lifelessmordred: dstufft said that 1.0.0a1 is what PEP440 would expect00:50
*** bearhands is now known as comstud00:51
mordredhrm. you're right. that's an ugly problem00:52
lifelessmordred: dstufft: I don't want to be caught in the middle here :). I just need to know if oslo's latest tag is invalid (its not consistent with pbr semver) or if semver.rst is wrong.00:52
*** matsuhashi has joined #openstack-infra00:52
mordredwhat is oslo's latest tag?00:52
lifelessmordred: *secondly* I need to figure out what to issue as a version number for 'first commit after a tag that has an alpha/beta/tc marker'00:52
*** thuc has quit IRC00:53
lifeless1.3.0a000:53
lifelessoslo.config specifically00:53
*** thuc has joined #openstack-infra00:53
lifelessmordred: *thirdly* I need to knwo if I should file a bug about setup.py sdist ignoring local content and only including git committed content00:54
mordredlifeless: do you mean files that have not been git added?00:54
mordredthat are also not things that would normally be in sdist/00:54
mordred?00:54
mordred(can you give me an example?)00:55
lifelessmordred: I mean if I edit pbr/core.py; run setup.py sdist; pip install the resulting tarball; the edits will not be present in whats installed.00:56
mordredI would consider that a bug, yes. although I'm not fully sure I grok how that would be accomplished, pbr does not do any thing other than auto-edit manifests00:56
dstufftmordred: I filed an issue for making build tags be a thing in PEP44000:57
mordreddstufft: cool00:57
lifelessmordred: does it suck in setuptools-git or something braindamaged like that?00:57
mordredlifeless: no00:57
dstufftI think that's where the git sha information belongs00:57
mordredbut00:57
dstufftin a PEP440 view of the world00:57
mordredit does its own thing00:57
mordreddstufft: does that wind up in the tarball name/00:57
mordred?00:57
dstufftmordred: well it doesn't exist at all yet, but it would yes00:57
mordredok. then I'm on board with it. :)00:57
dstufftProbably ideally pip and such would ignore it, unless you specify it00:58
mordred++00:58
dstufftso you could do pip install oslo.config==1.0a1+thinger00:58
mordreddo you think there is any chance to get pep440 to accept .a1?00:58
mordredor should I consider that in-stone and to be dealt with/00:59
lifelesshttps://bugs.launchpad.net/pbr needs triage love01:00
*** esker has joined #openstack-infra01:00
mordredI'm sure it does.01:00
mordredoh good. I get to go answer not-a-bug to things01:01
*** rdwrer is now known as marktraceur01:02
*** marktraceur is now known as rdwrer01:02
dstufftMaybe? Feels like it's just making an already complicated spec more complicated than it needs to be, is there a reasoning for it?01:02
mordredwell, it makes the argument for integrating with semver simpler01:02
dstufftFWIW the reason that a/b/c/rc don't have a period and .dev and .post do is so you can do dev releases of an a/b/c/rc or post releases01:03
dstufftbecause there are projects that do that :/01:03
mordredsemer says X.Y.Z-stuff and really only cares about the content of X.Y.Z01:03
dstuffte.g. 1.0a0.dev0 is valid01:03
mordredbut - is kinda evil in a version because debian01:03
openstackgerritlifeless proposed a change to openstack-dev/pbr: Allow examining parsing exceptions.  https://review.openstack.org/8085601:04
openstackgerritlifeless proposed a change to openstack-dev/pbr: Permit pre-release versions with git metadata  https://review.openstack.org/8085701:04
openstackgerritlifeless proposed a change to openstack-dev/pbr: Teach pbr about post versioned dev versions.  https://review.openstack.org/8044901:04
openstackgerritlifeless proposed a change to openstack-dev/pbr: Add a converter to version_tuples.  https://review.openstack.org/8045701:04
mordredso my compromise was to replace the - as a version/other demarcation with a .01:04
mordredand then things become simple from a semver perspective - is it beyond the 3rd chunk? it's additional info01:04
dstufftmordred: I would raise an issue here https://bitbucket.org/pypa/pypi-metadata-formats personally I'd be -0 on it because I think accepting both is just complication and the 1.0a1 is already there and tooling using it01:05
mordredbut if it's "replace '-' with (a|b|c|rc)"01:05
mordredhrm. ok. I honestly didn't realize that the tooling only accepted 0a101:05
*** dcramer_ has joined #openstack-infra01:05
dstufftwell01:05
dstufftSo there's two things01:06
lifelessdstufft: so the goal we have with semver is deterministic, automatic version generation that can be mechanically transformed into debian and rpm versions01:06
lifelessdstufft: e.g. dev1 -> ~101:06
dstufft0.a1 is accepted by pip as close enough to PEP44001:06
* mordred ACTUALLY doesn't care about semver per-se01:06
dstufftbecause it uses a fuzzy version parser01:06
lifelessdstufft: as well as doing the right thing for version dependencies across the board for python01:06
mordreddstufft: then I'm fine with 0.a1 because pip is all I care about anyway01:07
mordredpersonally01:07
dstufftmordred: That's fine for your use cases :) It just means if we make a PEP440 + semver pep your semver doc will differ in that way:)01:07
mordredwe should probably just comply01:08
mordredI had a magical fairy world in my head where we coudl actually come up with a PE440 + semver that might be adopted outside of python01:09
dstufftPyPI may or may not accept .a1 down the road, I don't know, it needs a PEP before I can do that but i'd like it to at least enforce that we can fuzzy parse the version into a PEP440 style thin01:09
mordredI think 0a1 is more complex to reason about than 0.a1 - but I'm late to the party, so I'd rather play ball than be a bitch01:10
dstufftFWIW that predates me too01:10
lifelessso 0a1 is plain incompatible with debian01:11
lifelessbut01:11
mordredright01:11
mordredI think that's the other thing :)01:12
lifelessif there's a pep440 parser that can highlight 'and sort before' we can do something using ~01:12
dstufftwe took PEP386 and adjusted it to be more compatible with how setuptools did ordering, and also Nick added some additional stuff to make it easier01:12
dstufftpip uses distlib.version atm01:12
dstufftit doesn't have the greatest API in the world01:12
dstufftbut it does a thing01:12
lifelessanyhow like I say01:12
*** CaptTofu has joined #openstack-infra01:12
lifelessthe formatting thing really doesn't affect me, serialising a tuple of version components to 0.0.0.a0 or 0.0.0a0 is easy01:13
dstufftdistlib.version._normalized_key("1.0.1.0a1")01:14
dstufft((1, 0, 1), ('a', 1), ('_',), ('final',), ())01:14
lifeless>>> distlib.version._normalized_key("1.0.1.a1")01:15
lifelessdistlib.version.UnsupportedVersionError: Not a valid version: 1.0.1.a101:15
dstufftdistlib.version._suggest_normalized_version("1.0.1.0.a1")01:15
dstufft'1.0.1.0a1'01:15
lifeless>>> distlib.version._normalized_key("1.0.1.0.a1")01:15
lifelessdistlib.version.UnsupportedVersionError: Not a valid version: 1.0.1.0.a101:16
mordredlifeless: you're still preceeding a with . there01:16
mordredlifeless: what if we compromized between the two by just inserting a 0 in our semver doc01:16
dstufftyea _normalized_key is strict PEP440, you have to use the _suggest_normalized_version to turn something that is almost PEP440 compliant into a PEP440 compliant version01:16
mordred1.0.1.0a101:16
mordredit's PEP440 compliant01:16
dstufftyes01:16
dstufftthat would be equivilant01:17
dstufftto 1.0.1a101:17
mordredand it still makes the "just do semver but replace the - with a ." make sense01:17
dstufftwhen comparing values PEP440 has you strip all the trailing zeros01:17
*** CaptTofu has quit IRC01:17
mordred(leading)01:17
mordred?01:17
dstufftNo, 1 == 1.0 == 1.0.0 == 1.0.0.001:17
mordredah01:17
mordredgotcha01:18
dstufftbecause people are inconsistent with the number of segments01:18
*** Guest20271 is now known as cyeoh01:18
dstufftthey'll do 1.5 and 1.5.101:18
*** sarob_ has joined #openstack-infra01:18
mordredlifeless: does that pass your sniff test?01:18
dstufftSo you need to either make 1.5 < 1.5.0 or make them equiv01:19
lifelessmordred: lost track, does what?01:19
mordred1.0.0.0a1 instead of 1.0.0.a101:19
mordredlifeless: pre-pend a 0 to the a1 which  makes pep440 happy01:19
mordredand is just as deterministic and simple to parse for01:19
lifelessmordred: I'm fine doing that. The olso.config tag is wrong then01:20
lifelessmordred: 1.3.0a1 - should be 1.3.0.0a1 ?01:20
mordredin theory - although it's water under the bridge at this point01:20
lifelessmordred: well, the question is whether I write compat code, or we issue new tags in a few projects01:21
mordredlifeless: where is the code?01:21
lifelessmordred: which code?01:21
mordredlifeless: I don't know where you're writing compat code01:21
dstufftmordred: lifeless fwiw I hope i'm not coming off as being like YOU MUST DO IT OUR WAY or anything, If you want to stick with how you're doing it that's OK with me, I just wanted y'al to know :)01:21
mordreddstufft: no - I appreciate the feedback!01:22
lifelessmordred: it would be in pbr; I haven't written it yet.01:22
mordredthe goal is to tend towards compliance, not to continue to be snowflakes01:22
lifelessmordred: my semver code breaks because 0a1 isn't an int.01:22
mordredlifeless: gotcha. well, eithe way you're going to need to handle 0a1 to be pep44001:23
mordredapparently01:23
*** sarob_ has quit IRC01:23
dstufftyou could do what pip does and bundle distlib !01:23
lifelessdstufft: DIAF :)O01:23
mordredheh. probably not01:23
dstufft:D01:23
dstufftI find it hilarous pip bundles all the things01:24
dstufftbut it's less terrible :/01:24
lifelessmordred: so, do we need to handle any pep440 version in pbr ?01:24
mordredlifeless: no- we should handle our versions - but our current spec is apparently non-compliant01:25
mordredlifeless: so if we align our spec to be pep440 compliant moving forward01:25
lifelessmordred: then yes, we need to handle N{a/b/rc/dev}Y01:25
*** thuc_ has joined #openstack-infra01:26
*** CaptTofu has joined #openstack-infra01:26
mordreddstufft: do you think the idea of 1.0.0.0a1 as a basis for a pep440 + semver is a decent start? or before proposing that would you think something should change?01:26
lifelessmordred: https://bugs.launchpad.net/pbr/+bug/129328501:27
mordredlifeless: great. I have no idea how that bug is possible, btw01:27
dstufftmordred: well my personal preference would be for 1.0.0a1, but at that point it's just bikeshedding, it's fully compliant and it's not one of the horrendous versions that PEP440 allows01:27
dstufft(PEP440 allows some pretty dumb combinations in order to be flexible enough to capture more use cases)01:28
lifelessmordred: so semver can be PEP440 compliant with out us having to accept 0a1 as part of major/minor/patch01:28
mordreddstufft: yeah - our subset of pep440 + modified semver is intended to get rid of most of those variations01:28
mordredlifeless: what?01:28
mordredhow01:29
lifelessmordred: PEP440 accepts 1.3.0.0a1 right01:29
mordredyes01:29
lifelessmordred: major 1, minor 3, patch 0.01:29
*** thuc has quit IRC01:29
mordredlifeless: you are saying exactly what I was just saying I think01:29
lifelesssure01:30
lifelessso01:30
lifeless13:52 < lifeless> mordred: *secondly* I need to figure out what to issue as a version number for 'first commit after a tag that has an alpha/beta/tc marker'01:30
*** nosnos has joined #openstack-infra01:30
*** yaguang has joined #openstack-infra01:30
lifelessmordred: lets (for arguments sake) say oslo.config has a tag 1.3.0.0a101:30
lifelessmordred: and I do another commit locally.01:30
*** thuc_ has quit IRC01:30
mordredyah01:30
lifelessmordred: what version should pbr output01:30
mordredhrm. excellent question01:32
lifelessif we issue 1.3.0.0a201:32
lifelessthen the use can't tag that sanely01:32
*** thuc has joined #openstack-infra01:32
lifelessbecause we'll already generate 0a3 and 0a4 etc01:32
dstufftPEP440 allows 1.3.0.0a1.dev0 :V01:33
dstufftalthough it sorts before01:33
dstufftnot after01:33
mordredright01:33
dstufftyou could do 0a2.dev001:33
lifelesswe could exmit 1.3.0.0a2dev1 etc01:33
lifelessor 0a2.0dev101:33
dstufftdev has a leading period because ~reasons~01:33
dstufftmostly because it can be used after a a101:34
lifelessok sure01:34
lifeless0a2.dev101:34
dstufftyea01:34
lifelessbut semver doesn't capture this today01:34
mordredlifeless: so - we do not currently handle this, btw01:34
lifelessmordred: btw where do pypi-mirror bugs go?01:35
mordredopenstack-ci01:35
mordredlifeless: 1.3.0a0.12.g0c3a643 is what pbr is currently doing01:36
mordred1.3.0.0a0.12.g0c3a643 does seem slightly excessive - but it is deterministic01:37
*** shakamunyi has joined #openstack-infra01:37
*** bknudson has quit IRC01:38
dstufftoh hm01:38
dstufft0a0.12 isn't PEP440 btw (nor is the git tag, but I think that should jsut move to the build tag and PEP440 should get a build tag)01:39
mordredone could argue that it should be 1.3.0.0a0.post12.g0c3a64301:39
mordredI thnk g0c3a643 should clearly be in the build tag01:39
dstufftso post releases are supposed to be things tha don't affect the software01:40
dstufft"supposed"01:40
mordredgotcha01:40
mordredthen this would clearly be not post01:40
dstufftlike fixing a typo in the docs01:40
dstufftkind of things01:40
dstufftobviously you're allowed to do it, but it's "strongly discouraged"01:41
lifelessmordred: 0a2.dev12 would make sense01:41
dstufftversion numbers are hard :/01:41
dstufftyea what lifeless said01:41
mordredlifeless: no it wouldn't01:41
*** nibalizer has quit IRC01:41
mordredisn't dev supposed to be pre-prelease?01:41
dstufft0a1 is the last tag, 0a2.devN01:42
dstufftis the subsequent01:42
lifelessmordred: yes, this is pre-release01:42
mordredno.01:42
mordredhang on01:42
lifelessmordred: so 5th commit after 1.3.0.0a101:42
dstufftI think mordred missed the fact you incremented the aN01:42
lifelessmordred: would be 1.3.0.0a2.dev501:42
mordredright. please don't do that01:42
lifelessmordred: why not ?01:42
mordredbecause the next release might not be 1.3.0.0a2 and now we're mixing pre adn post versioning semantics01:43
lifelessmordred: we're not mixing anything01:43
lifelessmordred: forget about the pre and post heuristics. Just focus on semver for now.01:43
*** yamahata has joined #openstack-infra01:44
dstufftit doesn't really matter if the next release isn't 1.3.0.0a2, I don't think you can reasonably automatically version the next commit without making some assumption there01:44
lifelessmordred: what is the version for the Nth commit after a tag, assuming no API breaks are involved.01:44
mordredright01:44
mordredso, we can't forget about pre post heuristics01:44
mordredbecause I will tell you that we will have open revolt01:45
dstufftmordred: do you regret starting a packaging tool yet? ;)01:45
mordredif you have code in pbr that auto-versions the next commit after 1.3.0 as 1.3.1.dev101:45
mordreddstufft: it's not the tool that's the problem - this discussion has to be had in person with every person with a project in openstack if the tool doesn't do it right01:46
lifelessmordred: there is a bug *asking for that behaviour* right now01:46
*** thuc has quit IRC01:46
mordredlifeless: from who?01:46
dstufftmordred: I've more or less come to the conclusion that no matter what you do you're going to do it wrong for somebody01:46
lifelessJay Buffington01:47
*** thuc has joined #openstack-infra01:47
dstufftI think what lifeless is saying is probably correct for the most cases01:47
mordrednot from ttx?01:47
lifelessmordred: does ttx do client releases?01:47
openstackgerritJoshua Hesketh proposed a change to openstack-infra/zuul: Allow merge failures to have unique reporters.  https://review.openstack.org/7063601:47
lifelesshttps://bugs.launchpad.net/pbr/+bug/120673001:48
mordredlifeless: he's talking about a COMPLETELY different thing01:49
mordredwhich is the servers01:49
mordredwhich are not PE44001:49
mordredPEP44001:49
dstufftwhy not?01:49
dstufftaren't they just YYYY.NN01:49
mordredyah01:50
lifelessmordred: i'm thoroughly confused.01:50
mordredlifeless: server and client have different release numbering strategies01:50
lifelessmordred: I'm not confused about that.01:50
dstufftmordred: that's PEP440 now :)01:50
mordreddstufft: oh neat!01:50
dstufftwe added that01:50
lifelessmordred: but this discussion feels like boxing a cloud01:51
*** Daisy_ has joined #openstack-infra01:51
*** thuc has quit IRC01:51
lifelessmordred: Its very simple. Right now pbr versions post versions *backwards*.01:51
lifelessmordred: its broken. In every regard.01:51
*** nibalizer has joined #openstack-infra01:51
mordredlifeless: can we start from scratch then please - because I think we may be talkign about a few different things01:53
lifelesssorry, backwards is the wrong description for post-versioning01:53
mordredlifeless: let's just focus on post-versioing for now01:53
mordredas pre-versioning is its own special can of worms01:53
*** CaptTofu has quit IRC01:53
mordred(I do concede that this is not correct, so I think we're close to getting somewhere)01:54
lifelessmordred: so post versioning currently emits full releases on untagged commits.01:54
lifelessmordred: this is wrong. agreed?01:54
*** CaptTofu has joined #openstack-infra01:54
*** thuc has joined #openstack-infra01:54
mordredno. I'm not sure that is agreed01:55
lifelessthe 5th commit after 1.3.0 in oslo.config will ae an autogeenrated version of 1.3.0.501:56
mordredyes01:56
dstufftthat seems wrong to me FWIW01:56
lifelessthis isn't a release (its not tagged).01:56
mordredI hear that neither of you like that01:56
mordredI don't care01:56
lifelessI don't care isn't a helpfu answer01:56
mordredfair01:56
mordredlet me try again01:57
lifelessit makes me want to go fuckit and just do my own thing rather than trying to collaborate01:57
clarkbI'm with mordred. It isnt wrong but may not be desired01:57
dstufftit's not a release so calling it a release doesn't seem sane01:57
mordredlifeless: right. I'm just saying that you're stating an opinion is "wrong" which is also frustrating01:57
mordredbut let's figure it out01:57
clarkbI think lifeless should have the ability to do his thing01:58
mordredI agree01:58
clarkbbut it isnt an xor01:58
mordredwhat I'm trying to commuicate is the piece of inforamtion I know at this point01:58
lifelessclarkb: why isn't it wrong?01:58
dstufftor at least pip is going to see that as a final release and any other PEP440 tool will (also any setuptools based tool and probably any other tool)01:58
mordredwhich is that the fifth commit after 1.3.0 is related to 1.3.001:58
lifelessclarkb: is the 5th commit (untagged) after a tag a release, in the openstack world ?01:58
*** CaptTofu has quit IRC01:58
clarkblifeless because each commit can be a release01:59
clarkb(CD)01:59
lifelessclarkb: it may become one, but until its tagged, is it one?01:59
mordredit's only a release if we upload it to pypi - and it's not a release because it has a g2342345 after it01:59
clarkblifeless sure01:59
lifelessmordred: PEP440 doesn't understand that .gxxxx means 'not a release'01:59
mordredit doesn't make 1.3.0.5 it makes 1.3.0.5.g$sha01:59
lifelessclarkb: it is a release?01:59
clarkbits a commir01:59
mordredlifeless: we were just discussing that we shoudl add build tags to pep44002:00
dstufftlifeless: well that's invalid in PEP440 all together, that syntax, in a PEP440 + build tags world I'd assume it'd become 1.3.0.5+g$sha, which is kind of worse in this regards because then pip will see it as a final (whereas the current form it won't because it's invalid)02:00
mordredright. we're exploiting pip's behavior to get a build tag semantic02:01
mordredlifeless: I DO agree that it's non-optimal02:01
lifelessso I say its wrong because our intent is *not* tht it be a release, but pip perceives it as a release.02:02
*** alexandra_ is now known as alex-luncheon02:02
lifelessI will say 'incorrectly perceived as a release' for clearer comms02:02
lifelessIPAAR02:02
jhesketh__Does anybody here know where Jenkins sets the environment variables for workers to access? eg I'm looking for the part that takes zuul's parameters from gearman and sets them as OS envs02:03
mordredlifeless: pip doesn't perceive it as a release though02:04
lifelessmordred: no?02:04
mordredno02:04
mordredsee above02:04
dstufftwith the current version string it won't02:04
dstufft1.3.0.5.gwhatever02:04
lifelessbecause its an invalid version02:05
mordredright02:05
lifelessbut if it gets taught about build tags02:05
lifelessit will become a valid release02:05
dstufftcorrect02:05
mordredgotcha02:05
mordredok. we're on the same page now02:05
lifelessok, now what I want02:06
dstufftautomatically versioning after a tagged release is probably not possible to do without either pretending to be a release (1.3.0.5) or by making an assumption about what the _next_ release is going to be02:06
lifelessdstufft: so my proposal is to assume the minimum next version and do dev releases for that.02:07
lifelessdstufft: the minimum next version may never be released, but that doesn't matter02:07
dstufftthat's how I would do it02:07
dstufftit seems the most sane02:07
mordredk. now, I completely agree02:07
mordredbut02:07
mordredyou will get pushback from ttx and notmyname02:07
mordredwhich to me means they need to be convinced02:08
mordredbecause they think that a version that indicates it's leading up to a version that never gets released is undesirable02:08
dstufftit's the least bad option afaict02:08
mordreds/I completely agree/you've done a good job convincing me/02:08
lifelessnotmyname: ttx: ok ^ why? Not that pre-releases are not automatically installed by pop...02:08
lifelessbah, Note that...02:09
*** sarob_ has joined #openstack-infra02:09
*** thuc has quit IRC02:09
dstufftwhat if someone releases an actual 1.3.0.102:09
*** thuc has joined #openstack-infra02:09
lifelessdstufft: thats larger than 1.3.0.0a2, so thats fine.02:10
dstufftsorry I mean if you're doing 1.3.0.5 as the 5th release since 1.3.002:10
lifelessdstufft: if the last tag was 1.3.0, the next higher version is either 1.3.1 (if we do semver), or 1.3.0.1 (if we do generalised PEP440)02:10
lifelessdstufft: oh right, yes, issues with the current implementation02:11
mordredright. we assume that there will be a bit of sanity there02:11
mordredlifeless: however, let's assume we can make the case02:11
lifelessif we're doing semver, then 1.3.1.0a5 would be the 5th commit after 1.3.0, which leaves room for 1.3.1 as the next release.02:12
milkio.O02:12
dstufftin either case you have to make some assumptions about how many digits you're going to use in the version number02:13
dstufftlifeless: it might want to be 1.3.1.0a0.dev502:13
dstufftso that you can release a 1.3.1 alpha 102:14
lifelessdstufft: good point, that is what I should have typed02:14
clarkbjhesketh it happens in the gearman jenkins plugin02:14
lifelessdstufft: given the prose I wrote above02:14
*** sarob_ has quit IRC02:14
*** thuc has quit IRC02:14
clarkbit was an explicit thing before gearman but the vars are implicit now via the plugin02:14
jhesketh__clarkb: right, thanks. I took a look there where it decodes the JSON and places it into an  object, but I can't see where the system sets it on the OS?02:14
mordredlifeless: so we'd need to account for .dev being able to come after the patch version or the pre-release version02:15
mordredI think in our case we should only allow those two02:15
clarkbjenkins has an envar java object that ir splats into the env02:15
mordredso 1.3.1.dev1 and 1.3.1.0a1.dev1 - but no more, yah?02:15
*** Daisy_ has quit IRC02:16
lifelessmordred: major/minor/patch surely ?02:18
lifelessdstufft: actually02:18
*** sarob_ has joined #openstack-infra02:18
lifeless1.3.1 -> 1.3.2.devN (because dev0 < a0)02:19
lifeless1.3 -> 1.3.1.devN (becase 1.3 == 1.3.0)02:19
lifeless1 -> 1.0.1.devN02:19
lifeless1.3.1.0a1 -> 1.3.1.0a2.devN02:19
lifeless1.3.1.0b1 -> 1.3.1.0b2.devN02:20
mordredlifeless: I don't think we shoudl be that flexible - I think we shoudl enforce semver if we're going here02:20
lifeless1.3.1.0rc1 -> 1.3.1.0rc2.devN02:20
lifelessmordred: I believe I'm enforcing semver above02:20
lifelessmordred: using the precedence rules in the semver doc, with the serialisation tweak we discussed to get more PEP440 friendly versions02:20
mordred++02:20
mordredk. I follow02:20
lifelessdev tags are illegal02:21
dstufftlifeless: yes that makes more sense I think02:21
jhesketh__thanks clarkb, I'll take a look02:21
lifelessI presume02:21
mordredI think I was saying that we shoudl not really support 1.3.1.0a1.dev1.0a2.dev402:21
dstufftthat's illegal in PEP440 too FWIW02:21
mordredgood02:21
mordredit shold be02:21
dstufftyou can add a .devN to anything02:21
dstufftbut you can't do multiple layers of stuff02:21
dstufftso you can do like, 1.0.0a1.post3.dev502:22
dstufftbut that's like the craziest02:22
dstufft(5th development version of the 3rd post release of the first alpha of 1.0.0)02:22
lifelessmordred: so I think the rules for tags become02:23
*** asalkeld has joined #openstack-infra02:23
*** sarob_ has quit IRC02:23
asalkeldhi, are there instruction on releasing a python client for the first time?02:23
*** jhesketh__ has quit IRC02:24
asalkeldfrom what I understand it's just "git tag -a v1" and "git push gerrit"02:25
*** jhesketh__ has joined #openstack-infra02:25
lifelessyou can tag any X, X.Y, X.Y.Z release, and you can use 0aN or 0bN or 0rcN on any of those02:25
lifelessbut you can't tag a dev version02:25
lifelessand you can't tag arbitrary PEP440 stuff02:25
mordredasalkeld: two thigns02:26
dstufftlifeless: that seems completely reasonable to me02:26
mordredasalkeld: you need to make sure it's a signed tag02:26
lifelessmordred: ^ ?02:26
mordredasalkeld: and please don't prefix with the v02:26
asalkeldok02:26
mordredasalkeld: and then it's git push gerrit $tagname02:27
mordredlifeless: ++02:27
lifelessok02:27
asalkeldso 1.0.002:27
lifelessso I'll send an email to the list I think02:27
asalkeldis that better?02:27
*** thuc has joined #openstack-infra02:27
lifelessor hmm02:27
lifelessI'll make an etherpad02:27
mordredasalkeld: yes02:27
lifelessthen send mail02:27
*** yamahata has quit IRC02:27
dstufftlifeless: will this go to openstack-dev?02:27
asalkeldsure02:27
lifelessdstufft: yes02:28
dstufftOk02:28
mordredasalkeld: git tag -s 1.0.0 ; git push gerrit 1.0.0 will be perfect02:28
*** thuc_ has joined #openstack-infra02:28
lifelesshttps://etherpad.openstack.org/p/pbr-postversion-semver02:28
dstuffti was convinced to subscribe to that02:28
dstufftso I'll watch for it02:28
dstufftand comment :D02:28
asalkeldthanks mordred02:28
mordredasalkeld: sure nuff!02:28
mordredasalkeld: also, you'll need to have permissions to push tags ...02:28
asalkeldyeah, I know - another issue tho'02:29
*** thuc_ has quit IRC02:30
*** thuc_ has joined #openstack-infra02:30
*** zhiyan_ is now known as zhiyan02:30
*** thuc has quit IRC02:32
*** weshay has quit IRC02:35
*** zhiyan is now known as zhiyan_02:35
jhesketh__clarkb: so the problem I'm faced with is that I was asked to make zuul's swift instructions able to handle multiple result destinations. I implemented this as a list in the gearman data but it occurs to me this won't be very accessible to the worker02:39
*** thuc_ has quit IRC02:40
jhesketh__as best as I can tell Jenkins expects there to only be a key+value pair and casts the value to a string02:40
jhesketh__I'm actually not sure how the list would be interpreted at this point02:40
jhesketh__clarkb: I don't suppose you have any thoughts there?02:40
*** masayukig has joined #openstack-infra02:41
*** CaptTofu has joined #openstack-infra02:42
*** Daisy_ has joined #openstack-infra02:43
*** asalkeld has left #openstack-infra02:46
*** matsuhashi has quit IRC02:48
*** matsuhas_ has joined #openstack-infra02:52
*** Daisy_ has quit IRC02:53
*** Daisy_ has joined #openstack-infra02:56
jeblairjhesketh__: oh hi! i think we should probably explode the parameters...02:59
jhesketh__jeblair: yeah, that's my feeling02:59
*** dcramer_ has quit IRC02:59
jeblairjhesketh__: so if you have instructions for the foo and bar containers, we end up with FOO_SOMETHING and BAR_SOMETHING parameters02:59
jhesketh__I poked at Jenkins and I don't want to patch that02:59
jeblairjhesketh__: (or equivalent)02:59
jeblairjhesketh__: yeah, i think it's better not to have to encode anything about this into the intermediary gearman stuff03:00
nibalizer/quit03:00
*** nibalizer has quit IRC03:00
jeblairjhesketh__: and instead just expect that the things on both sides of the communication channel (the zuul swift module and the jobs) expect those flattened values03:01
jhesketh__jeblair: yep, that was what I had in mind too03:02
jhesketh__although it's not really an intermediary gearman thing, it's more of a zuul worker thing03:02
jhesketh__ie if I fixed it on the Jenkins level it'd allow zuul to send more complicated data structures (via gearman)03:03
jeblairjhesketh__: true; i guess that goes to whether the zuul-gearman protocol should become complex; i lean toward simple at the moment though -- i think it'll be easier to keep it stable and therefore support more kinds of workers03:04
*** dkehn has joined #openstack-infra03:04
jhesketh__jeblair: I agree. Although theoretically we're making the protocol more complicated by sending these instructions. For example, is it expected/required that a worker utilise the swift instructions03:05
jhesketh__(clearly not in our case, but as an example)03:05
*** eharney has quit IRC03:05
*** SumitNaiksatam has quit IRC03:06
*** dkehn_ has quit IRC03:06
jeblairjhesketh__: *nod*03:07
jhesketh__jeblair: okay, I'm rerolling now.. do you think we should use name.upper() in the swift destination name, or just leave it to the operator03:09
jeblairjhesketh__: operator i think03:13
jhesketh__jeblair: should we allow a set of instructions named "MyLogs" and "mylogs"?03:13
jhesketh__jeblair: Also, I think it perhaps should be "SWIFT_name_PARAM"03:18
jeblairjhesketh__: do you know if swift container names are case sensitive?  i'd follow the lead there, but i don't know off the top of my head.03:18
*** sarob_ has joined #openstack-infra03:18
lifelessdstufft: mordred: mail sent03:18
*** Daisy__ has joined #openstack-infra03:18
jhesketh__jeblair: a quick test shows they are case sensitive (ie I can have Logs and LOGS)03:19
jhesketh__but the name does not define the container03:20
*** Daisy_ has quit IRC03:21
*** peddamat has quit IRC03:21
jeblairjhesketh__: agreed, re SWIFT_name_PARAM03:21
*** matsuhas_ has quit IRC03:22
openstackgerritAngus Salkeld proposed a change to openstack-infra/config: Add new services to solum devstack setup  https://review.openstack.org/8088303:22
jeblairjhesketh__: true; my inclination would be to follow swift and just pass things through as much as possible; but i don't feel too strongly about that if, as you dig into this, you think we should take another approach.03:22
*** sarob_ has quit IRC03:23
jhesketh__yeah I'm also not opinionated here03:23
jhesketh__I think we'll leave it to the operator03:23
*** dkehn is now known as dkehn_03:23
jeblaircool03:23
*** dkehn__ is now known as dkehn03:23
*** yjiang has joined #openstack-infra03:26
*** medieval1 has quit IRC03:33
*** medieval1 has joined #openstack-infra03:33
*** medieval1 has quit IRC03:38
*** CaptTofu has quit IRC03:48
*** thuc has joined #openstack-infra03:51
*** thuc has quit IRC03:55
openstackgerritJoshua Hesketh proposed a change to openstack-infra/zuul: Send swift upload instructions to workers  https://review.openstack.org/6829703:56
*** emagana has joined #openstack-infra04:05
*** alex-luncheon is now known as alexandra_04:08
*** sarob_ has joined #openstack-infra04:18
*** wenlock has joined #openstack-infra04:20
*** Daisy__ has quit IRC04:22
mordredlifeless: thanks. and thanks for hammering away on this with me - I think we've refined things nicely04:22
*** sarob_ has quit IRC04:23
openstackgerritMonty Taylor proposed a change to openstack-infra/nodepool: Add bash completion to nodepool  https://review.openstack.org/8088904:24
*** yamahata has joined #openstack-infra04:25
mordredjeblair: you still aroudn?04:25
* mordred had a possibly terrible idea related to sequencing of puppet runs taht's possibly quicker/simpler/less moving parts than the salt plan04:26
openstackgerritJoshua Hesketh proposed a change to openstack-infra/config: Add a slave-script to Jenkins for pushing to swift  https://review.openstack.org/7118904:26
mordredwhich is - what if we allow the puppetmaster to ssh to each of the node and run puppet? as in - stop running puppet agent anywhere, and write a script on the master which does the git pull then the puppet run on each of the hosts04:27
*** wenlock has quit IRC04:28
*** wenlock has joined #openstack-infra04:28
mordredit would allow us to avoid stuck puppet runs, and also allow us to encode sequencing very easily04:29
mordredsuch as "run puppet on cgit slaves, then on gerrit" - purely by order04:29
mordredthe downside as I can see it is a) we'd serialize puppet runs (although maybe that's not terrible) b) security - we'd be granting puppetmaster some power04:29
mordredhowever, given that rooting the puppetmaster box is essentially full root everywhere, maybe it's not bad04:30
mordredbut also - we could turn off the 8140 port in puppetmaster's iptables rules - and we could have the ssh commands to the hosts forward 8140 so that puppetmaster port is only accessible during the puppet run04:31
mordredand with that- we could even put ina  jump box if we wanted to and completely turn off public ip access to the puppetmaster04:31
mordredHOWEVER  - I don't care about any of those things04:32
mordredthe main one was that turning off puppet agent daemon and doing sequencing would be a pretty easy thing to do04:33
mordredfungi, jeblair: ^^ when you wake up04:35
*** alff has joined #openstack-infra04:38
*** matsuhashi has joined #openstack-infra04:43
*** dstufft|laptop has joined #openstack-infra04:46
mattoliveraumordred: lol, I see you thinking out loud. Interesting idea. Would you then have to cron the script, or will humans control when it is run? If the former, could stuck puppet runs still exist?04:48
*** alff has quit IRC04:48
*** alff has joined #openstack-infra04:50
*** Daisy_ has joined #openstack-infra04:54
mordredmattoliverau: it would be cron'd - and I think they could stick - but my gut tells me that the stuck runs is realted to concurrency on the master05:02
*** zhiyan_ is now known as zhiyan05:02
mordredalso, however, we'd notice that puppet in general is stuck more easily - and could put a timeout in the driver script05:03
mattoliverauThat's true, a sensible timeout would be a useful plan even if it is stable.. cause you never know what future change will break a run.05:04
mordredyah05:05
mordredbut if we put the timeout into the cron (with an error message that we timed it out) it SHOULDN'T timeout frequently - but it would also allow us to log it and move on rather than just stick for all time05:06
mattoliverauAs long as a senible timeout is decided upon, even if it's rather large like an hour to 4 :)  Depending on the frequency of the cron job of course.05:07
mattoliverauThe thing is to stop stuck runs not penalise slower runs I aseume.05:08
mordredyah05:08
mordredmost of our runs are only a minute or two really05:08
mordredso long-runs are either somethign that needs to be designed or a problem05:09
mattoliverauTrue05:09
mattoliverauAnd in the script you could background any run that can run in parallel and serialise the ones that can't.. that's pretty cool.05:11
*** VijayTripathi has quit IRC05:14
openstackgerritMonty Taylor proposed a change to openstack-infra/nodepool: Reuse floating ips  https://review.openstack.org/8089305:17
mordredyah05:17
mordredI mean, it feels hacky - but the more I think about it the more I like it05:17
mattoliverauOr even better, grabs the list of nodes from site.pp and by default runs them in parellel (back ground) and you specify the ones you want to serialise. That way the maintenance of the script in minimalised. I.e. everytime a new infra node needed to be maintained is created the script doesn't need to me modified.05:17
mattoliverauYeah, I know what you mean. Puppet and salt exist for a reason.. and a script seems hacky.05:17
mordredwell... we don't have a list in site.pp because of wildcards05:17
mattoliverauor hosts file or dns or even better 'puppet cert list -a' :)05:18
*** sarob_ has joined #openstack-infra05:18
mordredpuppet cert list -a seems perfect05:18
mordredmight incite us to actually revoke certs for things where are not real things anymroe05:20
*** sarob__ has joined #openstack-infra05:21
mordredpuppet cert list -a  | grep '^\+'05:22
mattoliverauyeah, and you'll find them pretty quickly too, cron should log them for you :)05:22
mattoliverauYeah, the * are the ones that are signed, so even better :)05:22
*** sarob_ has quit IRC05:23
mattoliverau*and the ones that are start with a * i mean. So you might want to grep them out, unless everything is autosigned then I guess it doesn't matter.05:23
mordredbiggest question would be how we detect if someone is working and wants puppet to not run05:24
mattoliverauCheck to see if someone is logged in? who or w?05:24
mattoliverauYour sshing anyway.05:24
mattoliverauOr see if a bash binary and/or screen is running in case someone is working but not logged in.05:26
*** sarob__ has quit IRC05:26
mordredI guess "puppet agent --disable" actually prevents command line runs too05:26
mordredso as long as someone has done that, it should be fine05:27
mattoliverauYeah, I dunno, but that can be tested :)05:27
mordredyah05:27
mattoliverauIf it doesn't you could make a business decision like, if you want to work on a server and don't want it to run then create a file /root/NO-PUPPET and the existence can be checked in the script.05:29
mattoliverauYup, puppet agent --disable works:05:31
mattoliveraunotice: Skipping run of Puppet configuration client; administratively disabled; use 'puppet agent --enable' to re-enable.05:32
mordredyah. I Think that's perfect05:32
*** nicedice has quit IRC05:32
*** Daisy_ has quit IRC05:33
*** wenlock has quit IRC05:33
*** morganfainberg_Z is now known as morganfainberg05:34
*** alff has quit IRC05:41
*** vogxn has joined #openstack-infra05:43
*** Daisy_ has joined #openstack-infra05:48
*** CaptTofu has joined #openstack-infra05:49
*** vogxn has quit IRC05:51
*** nosnos has quit IRC05:54
*** nosnos has joined #openstack-infra05:54
*** CaptTofu has quit IRC05:54
*** matsuhashi has quit IRC05:56
*** matsuhashi has joined #openstack-infra05:57
*** matsuhashi has quit IRC05:57
*** vogxn has joined #openstack-infra05:59
*** matsuhashi has joined #openstack-infra06:00
*** rpodolyaka has joined #openstack-infra06:02
*** matsuhashi has quit IRC06:09
*** ildikov_ has quit IRC06:09
*** matsuhashi has joined #openstack-infra06:10
*** matsuhas_ has joined #openstack-infra06:12
*** matsuhashi has quit IRC06:14
*** rpodolyaka has quit IRC06:16
*** rpodolyaka has joined #openstack-infra06:16
jamielennoxcan anyone tell me what we left off of this new_project: https://review.openstack.org/#/c/73074/ to give not_registered in reviews: https://review.openstack.org/#/c/80897/06:17
*** sarob_ has joined #openstack-infra06:18
*** rpodolyaka has quit IRC06:19
*** sarob_ has quit IRC06:23
*** nosnos has quit IRC06:24
mattoliverauWell I'm off to cook dinner, see you all tomorrow, for all you American's who will read this in scroll back while I sleep, have a good Monday :)06:24
*** nosnos has joined #openstack-infra06:25
*** matsuhas_ has quit IRC06:25
*** matsuhashi has joined #openstack-infra06:25
*** rpodolyaka has joined #openstack-infra06:38
*** matsuhashi has quit IRC06:39
*** matsuhashi has joined #openstack-infra06:40
*** ildikov_ has joined #openstack-infra06:40
*** thomasbiege has joined #openstack-infra06:47
*** saju_m has joined #openstack-infra06:47
*** thomasbiege has quit IRC06:49
*** mrda is now known as mrda_away06:53
*** rpodolyaka has quit IRC06:56
*** rpodolyaka has joined #openstack-infra06:58
*** rpodolyaka has quit IRC07:00
*** skraynev_afk is now known as skraynev07:01
*** rpodolyaka has joined #openstack-infra07:03
*** rpodolyaka has quit IRC07:07
*** yolanda has joined #openstack-infra07:09
*** sarob_ has joined #openstack-infra07:18
*** sarob_ has quit IRC07:23
*** alexandra_ is now known as alex-awayu07:28
*** alex-awayu is now known as alex-away07:28
*** flaper87|afk is now known as flaper8707:30
*** vogxn has quit IRC07:30
*** peddamat has joined #openstack-infra07:32
*** mkoderer has joined #openstack-infra07:33
*** dstufft|laptop has quit IRC07:36
mordredSergeyLukjanov: ping07:38
*** jlibosva has joined #openstack-infra07:43
*** alff has joined #openstack-infra07:46
*** e0ne has joined #openstack-infra07:46
*** bookwar has joined #openstack-infra07:48
*** jamielennox is now known as jamielennox|away07:50
*** CaptTofu has joined #openstack-infra07:50
*** CaptTofu has quit IRC07:55
*** e0ne has quit IRC07:56
*** rpodolyaka has joined #openstack-infra07:57
*** nijaba has joined #openstack-infra08:02
*** rcarrillocruz has joined #openstack-infra08:02
*** rpodolyaka1 has joined #openstack-infra08:03
* ttx yawns08:05
*** rpodolyaka1 has quit IRC08:07
*** amotoki has joined #openstack-infra08:12
*** rcarrillocruz1 has joined #openstack-infra08:13
*** nosnos has quit IRC08:13
*** rcarrillocruz has quit IRC08:13
*** nosnos has joined #openstack-infra08:14
*** matsuhashi has quit IRC08:17
*** matsuhashi has joined #openstack-infra08:17
*** rcarrillocruz1 has quit IRC08:21
*** openstack has quit IRC08:21
*** openstack has joined #openstack-infra08:30
*** dizquierdo has joined #openstack-infra08:30
*** andreaf has joined #openstack-infra08:31
*** vponomaryov has joined #openstack-infra08:32
*** e0ne has joined #openstack-infra08:32
*** vogxn has joined #openstack-infra08:34
*** nosnos has quit IRC08:34
*** jcoufal has joined #openstack-infra08:36
*** bada_ has quit IRC08:40
SergeyLukjanovmordred, pong08:43
SergeyLukjanovttx, morning :)08:44
*** e0ne_ has joined #openstack-infra08:44
ttxSergeyLukjanov: o/08:44
*** morganfainberg is now known as morganfainberg_Z08:45
ttxSergeyLukjanov: how does the renaming go so far ?08:45
* ttx is still a bit behind in emails08:45
SergeyLukjanovttx, it's not bad08:45
ttx(nothing serious just a couple thousand emails to read)08:45
SergeyLukjanovttx, :)08:45
SergeyLukjanovttx, I hope will complete renaming this week08:46
*** e0ne has quit IRC08:48
*** jgallard has joined #openstack-infra08:55
*** vkozhukalov_ has joined #openstack-infra08:55
*** matsuhas_ has quit IRC08:56
kashyapttx, [Offtopic] I picked up the book by Bruce Schneir, by (your) implicit recommendation from your blog. I'm liking it, thank you!09:02
ttxkashyap: great!09:03
*** rpodolyaka1 has joined #openstack-infra09:03
* ttx grabs coffee before reading -dev09:03
*** johnthetubaguy has joined #openstack-infra09:04
*** andreaf2 has joined #openstack-infra09:04
*** johnthetubaguy1 has joined #openstack-infra09:06
*** johnthetubaguy has quit IRC09:06
*** matsuhashi has joined #openstack-infra09:06
*** andreaf has quit IRC09:07
*** rpodolyaka1 has quit IRC09:08
*** emagana has quit IRC09:09
*** rcarrillocruz1 has joined #openstack-infra09:11
*** rcarrillocruz has quit IRC09:12
*** yassine has joined #openstack-infra09:13
*** nosnos has joined #openstack-infra09:14
*** dizquierdo has quit IRC09:17
*** rcarrillocruz has joined #openstack-infra09:18
openstackgerritA change was merged to openstack-infra/config: Test only projects listed in projects.txt.  https://review.openstack.org/7917009:18
*** sarob_ has joined #openstack-infra09:18
*** rcarrillocruz1 has quit IRC09:20
*** jcoufal has quit IRC09:20
*** tnurlygayanov has joined #openstack-infra09:21
*** sarob_ has quit IRC09:23
*** rossella_s has joined #openstack-infra09:26
openstackgerritIvan Berezovskiy proposed a change to openstack-infra/config: Enable Gearman as default on Jenkins slaves  https://review.openstack.org/7321409:27
*** noorul has joined #openstack-infra09:27
*** johnthetubaguy1 has quit IRC09:27
*** johnthetubaguy has joined #openstack-infra09:31
*** persia has joined #openstack-infra09:32
*** persia has quit IRC09:32
*** persia has joined #openstack-infra09:32
*** Daisy_ has quit IRC09:34
*** yjiang has quit IRC09:37
*** krtaylor has quit IRC09:38
*** emagana has joined #openstack-infra09:39
*** saschpe has quit IRC09:42
*** chandan_kumar has joined #openstack-infra09:48
*** CaptTofu has joined #openstack-infra09:51
*** vkozhukalov_ has quit IRC09:51
*** saschpe has joined #openstack-infra09:52
*** IvanBerezovskiy has joined #openstack-infra09:55
*** nosnos_ has joined #openstack-infra09:55
*** emagana has quit IRC09:56
*** CaptTofu has quit IRC09:56
*** masayukig has quit IRC09:58
*** yolanda has quit IRC09:58
*** nosnos has quit IRC09:58
*** saschpe has quit IRC10:02
*** derekh has joined #openstack-infra10:02
*** derekh has quit IRC10:04
*** saschpe has joined #openstack-infra10:08
*** nosnos_ has quit IRC10:10
*** e0ne_ has quit IRC10:12
*** nosnos has joined #openstack-infra10:12
SergeyLukjanovttx, am I right that we're not adding requirements of non-official projects to global requirements10:13
SergeyLukjanov?10:13
*** saschpe has quit IRC10:13
*** e0ne has joined #openstack-infra10:14
ttxSergeyLukjanov: not sure10:14
*** saschpe has joined #openstack-infra10:15
SergeyLukjanovttx, it was when sahara wasn't incubated yet, but probably something changed10:16
*** yolanda has joined #openstack-infra10:16
SergeyLukjanovhttps://review.openstack.org/#/c/80756/10:16
*** saschpe has quit IRC10:16
*** saju_m has quit IRC10:17
*** tteggel has quit IRC10:18
*** sarob_ has joined #openstack-infra10:18
*** tteggel has joined #openstack-infra10:18
*** saschpe has joined #openstack-infra10:21
*** sarob_ has quit IRC10:23
*** saschpe has quit IRC10:26
*** pbelanyi has joined #openstack-infra10:27
*** saschpe has joined #openstack-infra10:28
*** saschpe has quit IRC10:28
*** saju_m has joined #openstack-infra10:32
*** matsuhashi has quit IRC10:38
*** yolanda has quit IRC10:39
*** rcarrillocruz1 has joined #openstack-infra10:42
*** afazekas has joined #openstack-infra10:43
SergeyLukjanovfungi, probably, you'd like to take a look on v10:45
SergeyLukjanovhttps://review.openstack.org/#/c/56823/10:45
*** rcarrillocruz has quit IRC10:45
openstackgerritA change was merged to openstack-infra/config: Gate python-glanceclient on PyPy  https://review.openstack.org/7607210:46
*** nosnos has quit IRC10:46
*** nosnos has joined #openstack-infra10:47
*** yamahata has quit IRC10:52
*** matsuhashi has joined #openstack-infra10:54
*** vkozhukalov_ has joined #openstack-infra10:57
*** saschpe has joined #openstack-infra10:57
openstackgerritA change was merged to openstack-infra/config: Implements: blueprint add-manila-to-gerritbot  https://review.openstack.org/7287210:58
*** rpodolyaka1 has joined #openstack-infra11:01
*** lcostantino has joined #openstack-infra11:03
*** yolanda has joined #openstack-infra11:04
*** rpodolyaka1 has quit IRC11:05
*** matsuhashi has quit IRC11:05
*** jgallard has quit IRC11:07
*** jcoufal has joined #openstack-infra11:09
*** openstackgerrit has quit IRC11:10
*** openstackgerrit has joined #openstack-infra11:11
*** matsuhashi has joined #openstack-infra11:13
*** jhesketh__ has quit IRC11:13
*** jhesketh has quit IRC11:13
*** saju_m has quit IRC11:15
rcarrillocruz1Ng: hi chris, are you around? If you are not too busy, I'd appreciate if you could give a core review to https://review.openstack.org/#/c/79205/ please...11:16
*** vogxn has quit IRC11:17
Ngrcarrillocruz1: hey, I'm afraid I'm not a core on openstack-infra. I can look and give it a +1, but I have no +2 powers there, sorry!11:17
*** sarob_ has joined #openstack-infra11:18
rcarrillocruz1ah, no biggie then, thanks :-)11:18
*** andreaf2 has quit IRC11:21
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: make highlighting work on the active document  https://review.openstack.org/8095111:22
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: provide a -e run target to run server locally  https://review.openstack.org/8095211:22
*** sarob_ has quit IRC11:23
*** dkranz has quit IRC11:24
*** matsuhashi has quit IRC11:31
*** chuck_ has joined #openstack-infra11:31
openstackgerritCyril Roelandt proposed a change to openstack-infra/nose-html-output: Port to Python 3.  https://review.openstack.org/8095611:33
openstackgerritCyril Roelandt proposed a change to openstack-infra/nose-html-output: Port to Python 3.  https://review.openstack.org/8095611:34
*** chuck_ is now known as zul11:34
*** zul has joined #openstack-infra11:34
*** rcarrillocruz1 has quit IRC11:35
*** saju_m has joined #openstack-infra11:36
openstackgerritSean Dague proposed a change to openstack-infra/config: set the group on nova-specs to nova  https://review.openstack.org/8095711:38
*** yfried has joined #openstack-infra11:39
*** yfried has left #openstack-infra11:41
*** dizquierdo has joined #openstack-infra11:42
*** e0ne has quit IRC11:45
*** weshay has joined #openstack-infra11:46
openstackgerritAlexander Jones proposed a change to openstack-infra/git-review: Fix parsing of SCP-style URLs, as these are valid in Git itself  https://review.openstack.org/7275111:46
*** katyafervent_awa is now known as katyafervent11:48
*** e0ne has joined #openstack-infra11:49
*** sdake has quit IRC11:49
openstackgerritNoorul Islam K M proposed a change to openstack-infra/config: Use python-jobs template and add release jobs for solum project  https://review.openstack.org/8078011:52
*** CaptTofu has joined #openstack-infra11:52
*** jhesketh__ has joined #openstack-infra11:54
*** jhesketh__ has quit IRC11:54
*** jhesketh has joined #openstack-infra11:55
openstackgerritA change was merged to openstack-infra/config: Note requirement to use 'new-project'  https://review.openstack.org/8069311:56
*** CaptTofu has quit IRC11:56
*** CaptTofu has joined #openstack-infra12:02
*** dprince has joined #openstack-infra12:03
*** aysyd has joined #openstack-infra12:04
openstackgerritSean Dague proposed a change to openstack-infra/config: add qa-specs to tempest group  https://review.openstack.org/8095912:06
pleia2good morning12:07
*** yamahata has joined #openstack-infra12:07
*** e0ne_ has joined #openstack-infra12:08
*** sandywalsh_ has quit IRC12:10
*** alexpilotti has joined #openstack-infra12:11
*** pdmars has joined #openstack-infra12:12
*** e0ne has quit IRC12:12
sdaguepleia2: morning12:12
sdagueyou up in maine this week?12:13
*** pdmars has quit IRC12:14
SergeyLukjanovsdague, morning, how are you?12:16
*** alexpilotti has quit IRC12:16
pleia2sdague: yep, snow and all12:16
sdagueSergeyLukjanov: good, up to 2nd cup of coffee12:17
sdaguepleia2: heh. yeh, I'm very happy that we missed the storm that hit DC last night. I like winter, but I'm ready for spring12:17
sdaguepleia2: what part of maine?12:17
*** dims has quit IRC12:18
pleia2sdague: central, inland; the cold and boring part :)12:18
sdagueheh12:18
*** sarob_ has joined #openstack-infra12:18
*** dims has joined #openstack-infra12:18
pleia2storm hit here right before I arrived, so I just get to enjoy the "already fallen" type of snow, which is nice12:18
*** yaguang has quit IRC12:19
*** pdmars has joined #openstack-infra12:20
*** esker has quit IRC12:21
*** chandan_kumar has quit IRC12:21
*** esker has joined #openstack-infra12:21
*** sarob_ has quit IRC12:23
*** miarmak has joined #openstack-infra12:25
*** esker has quit IRC12:26
*** lcostantino has quit IRC12:26
*** matsuhashi has joined #openstack-infra12:27
*** CaptTofu has quit IRC12:31
*** rfolco has joined #openstack-infra12:32
*** e0ne has joined #openstack-infra12:32
*** e0ne_ has quit IRC12:36
*** matsuhashi has quit IRC12:37
*** nosnos_ has joined #openstack-infra12:37
*** mbacchi has joined #openstack-infra12:37
*** nosnos has quit IRC12:37
*** matsuhashi has joined #openstack-infra12:37
*** AJaeger has joined #openstack-infra12:38
*** yassine has quit IRC12:42
*** matsuhashi has quit IRC12:42
*** yassine has joined #openstack-infra12:42
*** eharney has joined #openstack-infra12:43
*** e0ne has quit IRC12:45
*** e0ne has joined #openstack-infra12:45
*** lcostantino has joined #openstack-infra12:47
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: highlighting the way you expect  https://review.openstack.org/8096612:48
*** pblaho has quit IRC12:48
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: provide a -e run target to run server locally  https://review.openstack.org/8095212:50
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: highlighting the way you expect  https://review.openstack.org/8096612:50
*** CaptTofu has joined #openstack-infra12:50
*** jeckersb_gone is now known as jeckersb12:52
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: highlighting the way you expect  https://review.openstack.org/8096612:52
*** weshay has quit IRC12:54
*** saschpe has quit IRC12:54
*** CaptTofu has quit IRC12:54
*** adalbas has joined #openstack-infra12:56
*** smarcet has joined #openstack-infra12:56
*** jlibosva has quit IRC12:57
*** mriedem has joined #openstack-infra12:57
*** ArxCruz_ has joined #openstack-infra12:57
*** jlibosva has joined #openstack-infra12:58
*** kiall_ is now known as Kiall12:59
openstackgerritAlexander Jones proposed a change to openstack-infra/git-review: Fix parsing of SCP-style URLs, as these are valid in Git itself  https://review.openstack.org/7275112:59
*** jgallard has joined #openstack-infra13:02
*** matsuhashi has joined #openstack-infra13:03
*** saschpe has joined #openstack-infra13:05
*** matsuhashi has quit IRC13:05
*** sandywalsh has joined #openstack-infra13:05
*** matsuhashi has joined #openstack-infra13:05
maurosrguys where can I find the piece of code that filters the logs into warnings, traces, infos.. ?13:08
*** matsuhashi has quit IRC13:10
sdaguemaurosr: what do you mean?13:11
*** alexpilotti has joined #openstack-infra13:11
*** krtaylor has joined #openstack-infra13:11
*** nosnos_ has quit IRC13:12
maurosrsdague: like here http://logs.openstack.org/39/80939/1/check/check-tempest-dsvm-neutron/f09386c/logs/screen-c-api.txt.gz in the top of page there is a display level13:12
*** thuc has joined #openstack-infra13:12
*** saschpe has quit IRC13:12
sdaguethat's os-loganalyze, which I was hacking on this morning again13:13
*** thuc_ has joined #openstack-infra13:13
*** jlibosva1 has joined #openstack-infra13:14
*** ryanpetrello has joined #openstack-infra13:14
maurosrsdague: cool, guys here will need that to start hunt our ci skips ;), thanks for it13:14
*** dkehn__ is now known as dkehn13:14
sdaguethe config repo shows how we install it on our log server13:15
sdagueI'm not sure how you'd do it in front of swift13:15
maurosrsdague: yup, we cant, but I thought to run that in a local machine, and incrementally/mannualy refresh it as soon as we get rid of a new bug13:16
openstackgerritAlexander Jones proposed a change to openstack-infra/git-review: Fix parsing of SCP-style URLs, as these are valid in Git itself  https://review.openstack.org/7275113:16
*** emagana has joined #openstack-infra13:17
*** thuc has quit IRC13:17
*** jlibosva has quit IRC13:17
*** dstanek has joined #openstack-infra13:17
*** sarob_ has joined #openstack-infra13:18
*** hashar has joined #openstack-infra13:19
*** mfer has joined #openstack-infra13:19
*** fifieldt has quit IRC13:20
*** esker has joined #openstack-infra13:21
*** emagana has quit IRC13:21
*** julim has joined #openstack-infra13:22
*** sarob_ has quit IRC13:24
sdaguemaurosr: yeh, or build another handler in front of it. At some point we're going to have to figure out how to handle swift back ends as well13:27
*** alff has quit IRC13:29
*** noorul has left #openstack-infra13:32
*** wchrisj has joined #openstack-infra13:34
*** dkliban has joined #openstack-infra13:35
*** mwagner_lap has joined #openstack-infra13:36
sdaguefungi: you up yet?13:36
sdagueI was curious about new libvirt in the nodepool builds13:37
fungisdague: yeah13:37
fungisdague: curious about it in what way?13:37
*** VINOD__ has joined #openstack-infra13:37
sdaguedid it land13:37
sdaguehttp://status.openstack.org/elastic-recheck/index.html libvirt is still our top bug right now13:37
fungioh. um, did libvirt land in what way?13:37
fungilike did the new version wind up on the ubuntu mirrors?13:38
fungior what?13:38
sdagueyeh, I though they had published it out to precise updates13:38
fungii think jamespage was planning to get the precise packages updated in universe... checking to see if it's new13:39
*** blamar has joined #openstack-infra13:39
*** wchrisj has quit IRC13:39
sdagueI guess not - http://packages.ubuntu.com/precise-updates/libvirt-bin13:39
*** yaguang has joined #openstack-infra13:40
fungilibvirt_0.9.8-2ubuntu17.17.debian.tar.gz30-Jan-2014 20:35 142K13:42
fungihttp://archive.ubuntu.com/ubuntu/pool/main/libv/libvirt/13:42
funginothing newer in precise or precise-updates since that source package13:42
*** VINOD__ has quit IRC13:43
*** weshay has joined #openstack-infra13:43
*** jgrimm has quit IRC13:45
pleia2fungi: this review needs a nudge https://review.openstack.org/#/c/74196/ (approved, but got stuck)13:45
fungipleia2: i'll make sure it's got snow chains on the tires this time13:46
pleia2thanks :)13:46
*** jpeeler has joined #openstack-infra13:47
*** jpeeler has quit IRC13:47
*** jpeeler has joined #openstack-infra13:47
AJaegerfungi, good morning. the new jobs like openstack-manuals-manuals-propose-translation-update do not work. Do you have any idea why those are not executed at all ?13:49
openstackgerritLukas Bednar proposed a change to openstack-infra/jenkins-job-builder: scms: MultiSCM is generated for scms hidden in macro  https://review.openstack.org/6982713:50
*** jnoller has joined #openstack-infra13:50
fungiAJaeger: i started to look at them over the weekend... the jobs are definitely in jenkins and listed as being in the periodic pipeline in zuul's debug log from the last time it reloaded, but it doesn't seem to have tried to trigger them. i was going to pick jeblair's brain on that once he wakes up, in case he has suggestions on where else i should look13:52
*** jeckersb is now known as jeckersb_gone13:52
AJaegerfungi, thanks for seeing my note on the weekend!13:52
fungii saw it running other periodic jobs, i think, but i'll reconfirm that13:52
openstackgerritIvan Melnikov proposed a change to openstack-infra/config: Adding pypy jobs for taskflow  https://review.openstack.org/8097313:53
AJaegerfungi, ok, let's wait for jeblair to show up. Thanks for having this on your radar!13:53
*** amotoki has quit IRC13:53
*** dcramer_ has joined #openstack-infra13:54
*** dkranz has joined #openstack-infra13:54
AJaegerfungi, check https://jenkins.openstack.org/job/propose-requirements-updates/ - isn't that periodic as well?13:54
AJaegerLast run: 4 days ago13:54
*** sc68cal_ is now known as sc68cal13:54
fungiAJaeger: no, that runs in the post pipeline when a change merges to the openstack/requirements repository13:55
AJaegerfungi, ok13:55
*** saschpe has joined #openstack-infra13:56
AJaegerThis one run 7 hours ago as it should - and is periodic https://jenkins.openstack.org/job/ceilometer-propose-translation-update/13:56
*** jeckersb_gone is now known as jeckersb13:57
*** thuc_ has quit IRC13:58
*** bknudson has joined #openstack-infra13:58
*** thuc has joined #openstack-infra13:58
fungihashar: this seems to be caused by the pbr patch to jjb... http://paste.openstack.org/show/73660/ any idea what the solution is?13:59
*** saschpe has quit IRC14:00
hasharfungi: hello !14:00
*** wchrisj has joined #openstack-infra14:01
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Drive puppet from the master over ssh  https://review.openstack.org/8097614:01
hasharfungi: yeah I think I noticed a follow up patch, basically setup.cfg is missing a  [file] section14:01
mordredfungi: ^^ I had a bad idea14:01
fungimordred: i saw your idea, still trying to decice how i feel about it14:01
fungidecide14:01
hasharfungi: https://review.openstack.org/#/c/80724/    Install the jenkins_jobs package on setup14:02
*** thuc has quit IRC14:03
*** jcoufal has quit IRC14:03
fungihashar: yep, thanks! just found it myself14:03
mordredfungi: I figured code would be a good way to discuss it14:03
fungii'll see if that fixes it for us14:03
fungimordred: agreed14:03
hasharfungi: I am not sure why one need the [files] section though14:04
sdaguemordred: have you considered running puppet agent on cron?14:04
hasharfungi: nor whether it is used by pbr or setuptools :]14:04
*** jcoufal has joined #openstack-infra14:04
fungihashar: it does indeed allow me to run jenkins-jobs update on our jenkins masters again14:05
openstackgerritA change was merged to openstack-infra/gitdm: Add myself to the email and launchpad maps  https://review.openstack.org/7419614:05
hasharfungi: so I guess we can vote that change :°14:05
hasharfungi: would you mind voting/commenting on https://review.openstack.org/#/c/80724/ please?14:06
fungihashar: yes, i'm +2'ing but finding you a good answer on the purpose of the packages option in the files section of setup.cfg14:06
mordredsdague: yes. it doesn't help the problem we're talking about here14:06
*** rwsu has joined #openstack-infra14:07
mordredsdague: I'm looking at this as a way to potentially run some of the puppet runs in a sequence14:07
sdaguemordred: well, it helps the hang issue that you comment on14:07
sdaguesure14:07
fungisdague: the problem statement is order-dependent puppet updates between separate hosts14:07
sdaguecool, is there a good example of one of those?14:08
fungi(run when foo changes, first update host bar, then when that completes update host baz)14:08
sdaguesure, but is there something specific?14:08
mordredsdague: yes14:09
*** markmcclain has joined #openstack-infra14:09
sdaguebecause the theory on puppet is idempotency, so I wonder if there is a good test you con run on host baz to know if bar is correct14:09
fungisdague: yes, when review.projects.yaml is modified, first update puppet on the cgit servers so the create-cgitrepos exec creates empty repositories for any new projects, then once that's done update puppet on the gerrit server so that new projects are created and mirror replication is initiated to the git servers14:09
*** esker has quit IRC14:09
mordredsdague: what fungi said14:09
mordredthis is actually where puppet and chef are both shit14:10
fungisdague: basically, we need to create empty git repositories on multiple hosts, then once those exist (and only once they exist) trigger git replication to them from another host14:10
mordredbecause attempts to do cross-machine deps, while possible, quickly lead you into the land of insanity14:10
sdagueyeh, they definitely don't touch the orchestration side14:10
*** jasondotstar has joined #openstack-infra14:10
mordredI was looking at doing this with salt14:10
*** jraim has quit IRC14:11
*** thuc has joined #openstack-infra14:11
*** zul has quit IRC14:11
*** unicell has quit IRC14:11
*** simonmcc_ has quit IRC14:11
fungimordred: did you find a way to go about it without reactors (or did you find a good reactor example which touches depending on one thing completing successfully on multiple systems before doing another thing?)14:11
*** jraim has joined #openstack-infra14:11
openstackgerritFei Long Wang proposed a change to openstack-infra/config: Add docs gate for Marconi  https://review.openstack.org/8047914:12
sdaguefungi: what if the replication process tries a sample clone on all the targets first to make sure they exist?14:12
sdaguewhich I get is punting on the orchestration problem14:12
*** simonmcc_ has joined #openstack-infra14:12
fungisdague: that's an option, or so is having teh project creation script ssh to each git server and run create-cgitrepos there before proceeding on the gerrit project creation piece14:12
fungisdague: though the latter would need to update puppet on them14:13
mordredfungi: I didn't - and all the salt people I talk to never use reactors, so they don't know how to help me :)14:13
*** zul has joined #openstack-infra14:13
fungisdague: also if we go with the wait option, it's basically rechecking for 10-15 minutes before the git servers possibly are all caught up14:13
fungisdague: which significantly increases the runtime of the project creation exec14:14
sdaguefungi: sure, but it's a computer, doing things repetatively is easy for it14:14
fungiall things to take into consideration14:14
mordredjust - I mean, look at the patch - it's so simple - the other things seem much more complex to deal with14:15
mordredwe could also do a variation on it that instead of ssh puppet apply did salt $f puppet_apply14:15
*** Ryan_Lane has joined #openstack-infra14:16
miarmakhi all14:18
*** sarob_ has joined #openstack-infra14:18
sdaguemordred: sure, though I wonder what happens when it grows past this one problem and you end up with cycles in the dependencies14:19
pleia2fungi, mordred - when you have a chance, I could use some help moving this one forward (clarkb and jeblair reviewed): https://review.openstack.org/#/c/69510/14:19
mordredsdague: sure. well, maybe by that point we'll have heat up and going :)14:19
sdagueheh14:19
mordredpleia2: looking14:19
miarmakI need a piece of advice. Can anybody help please?14:20
sdaguespeaking of, is there a heat for dummies guide anywhere. Because I'd actually like to try to build the HA case as a tempest test, and I'm finding heat documentation very lacking14:20
pleia2miarmak: as away :)14:20
pleia2ask too14:20
openstackgerritNoorul Islam K M proposed a change to openstack-infra/config: Make gate-solum-requirements non-voting  https://review.openstack.org/8098014:20
*** pblaho has joined #openstack-infra14:21
sdaguefungi: something probably easy to take a look at - https://review.openstack.org/#/q/status:open+project:openstack-infra/os-loganalyze+branch:master+topic:onclick_inline,n,z  I was trying to get highlighting workign this weekend, self landed a couple of patches which almost do it, and here are the remaining fixes14:22
miarmakpleia2: okey) the question is about the virtualenv version) will it be updated to the newer version in the in the near future? Because it is 1.10 using now and we have some problems with it...14:22
*** emagana has joined #openstack-infra14:23
*** sarob_ has quit IRC14:23
*** thuc has quit IRC14:24
*** thuc has joined #openstack-infra14:25
*** flaper87 has quit IRC14:26
fungimiarmak: the virtualenv version where?14:26
fungimiarmak: i assume you mean on our testing systems?14:27
miarmakfungi: here: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/manifests/base.pp#L5414:27
*** jlibosva1 is now known as jlibosva14:28
*** rcleere has quit IRC14:28
*** thuc has quit IRC14:29
jamespagefungi, sdague: see hallyns last comment on https://bugs.launchpad.net/nova/+bug/125487214:30
jamespagehe's uploaded it but in order for it to be accepted into proposed and start the SRU process the bug needs a basic test case14:30
*** flaper87|afk has joined #openstack-infra14:31
*** flaper87|afk is now known as flaper8714:32
*** flaper87 has quit IRC14:32
*** flaper87 has joined #openstack-infra14:32
*** julim_ has joined #openstack-infra14:33
fungimiarmak: yes, we pinned that because of https://github.com/pypa/virtualenv/issues/521 which should now be fixed in 1.11.1 but at this point we're waiting for https://bitbucket.org/hpk42/tox/issue/150/posargs-configerror to be solved first because in most places we're actually running virtualenv under tox so we need a usable (for us) tox which bundles the newer virtualenv version anyway14:33
*** caleb_ has joined #openstack-infra14:34
*** julim has quit IRC14:36
fungimordred: distutils documentation is teg failz. i know what files.packages is supposed to be used for in setup.cfg, but i can't for the life of me find a mention in any official documentation backing up my understanding14:36
yolandahi jeblair, i was thinking in taking that bug14:37
yolandahttps://bugs.launchpad.net/openstack-ci/+bug/127473114:37
fungiis there some secret place i should be looking? i can find it documented in distutils2 but that's not exactly canonical14:37
yolandai saw you commented that a bit, can you explain me more about it?14:37
miarmakfungi: so you are planning to update virtualenv to 1.11.1 (or later) after tox posargs bugfix?14:40
*** maxbit has joined #openstack-infra14:43
fungimiarmak: we're planning to revert https://review.openstack.org/64709 at that point, along with https://review.openstack.org/6987214:43
sdaguejamespage: who are you expecting to write the test case?14:44
*** alff has joined #openstack-infra14:44
*** zns has joined #openstack-infra14:46
miarmakfungi: okey, clear. Thanks! And do you have some time expectations? When it can be reverted? (approximately)14:48
fungimiarmak: it's mostly in the hands of the tox developers now to either decide they're okay with clarkb's proposed fix or come up with an alternate solution (which may involve changes to all of our projects before we can make use of it)14:48
fungimiarmak: so really, not sure what the timeline is. i try not to place bets on such things14:49
sdaguefungi: https://review.openstack.org/#/c/80957 and https://review.openstack.org/#/c/80959/  would be nice to +A if they do what I think they do14:50
*** alff has quit IRC14:50
*** emagana has quit IRC14:50
fungisdague: i'm having trouble parsing the commit message on 8095714:51
*** rcleere has joined #openstack-infra14:51
openstackgerritBrad P. Crochet proposed a change to openstack-infra/jenkins-job-builder: Added support for Exclusion plugin  https://review.openstack.org/7794014:52
fungisdague: the groups parameter for a project in review.projects.yaml is (as far as i'm aware) only used to decide which bug to update if someone adds a bug header in the commit message of a review14:52
fungier, rather, limits the scope of bugs updated to match the specified lp project name, rather than a project named the same as teh gerrit project the review changes14:53
sdaguefungi: so how do we get nova-specs changes to update nova blueprints?14:53
sdagueI thought when I traced the code, that would allow that14:54
miarmakfungi: ok, thanks) actually, we have a problems with setuptools. One of our dependencies needs setuptools 1.1.6 or later. But in virtualenv 1.10.1 its version is 0.9.8... And our solution is updating virtualenv version. Have you faced such problem?14:54
*** rcarrillocruz has joined #openstack-infra14:54
*** che-arne has joined #openstack-infra14:54
fungisdague: oh, actually it does look like update_blueprint.py uses that too http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/update_blueprint.py14:54
miarmakfungi: maybe it has another solution?14:54
sdaguefungi: yeh, if it's not intended, that would be good to know14:55
*** skraynev is now known as skraynev_afk14:55
fungisdague: since we don't particularly use blueprints for infra work i keep forgetting what that hook does14:55
*** thuc has joined #openstack-infra14:55
sdagueheh14:56
fungimiarmak: i don't think we've dealt with that particular problem, though i'm also led to believe that explicit dependencies on setuptools break a lot of things and are generally not recommended14:56
*** atiwari has joined #openstack-infra14:56
*** thuc has quit IRC14:58
*** thuc has joined #openstack-infra14:58
*** thuc_ has joined #openstack-infra14:59
*** saschpe_ has joined #openstack-infra15:00
*** pcrews has joined #openstack-infra15:00
openstackgerritMartin Konrad proposed a change to openstack-infra/jenkins-job-builder: SCM module: Add support for multiple Git remotes.  https://review.openstack.org/8008415:00
*** thedodd has joined #openstack-infra15:01
miarmakfungi: but we don't have a choice( we have one dependency and in its turn it have another dependency) and only that dependency depends on setuptools =)15:02
openstackgerritA change was merged to openstack-infra/config: set the group on nova-specs to nova  https://review.openstack.org/8095715:02
openstackgerritA change was merged to openstack-infra/config: add qa-specs to tempest group  https://review.openstack.org/8095915:03
*** thuc has quit IRC15:03
*** saju_m has quit IRC15:03
openstackgerritA change was merged to openstack-infra/jenkins-job-builder: Install the jenkins_jobs package on setup  https://review.openstack.org/8072415:05
fungimiarmak: well, there's always a choice. we often work with the developers of our dependencies to find/implement alternative solutions to problems we face, help them better understand python packaging convention and so on15:05
fungimiarmak: is it possible there's an earlier version of that package which doesn't depend on newer setuptools? if so, you could just limit the maximum version of it in your requirements15:07
fungias a short-term workaround15:07
*** saschpe_ has quit IRC15:11
jeblairfungi, mordred: so one of the advantages of salt is "salt mumble git*.openstack.org" catches all the git hosts.  i suppose we can template the run_remote_puppet script so that whenever we add a replication target we update that script15:12
*** ominakov has joined #openstack-infra15:13
*** vkozhukalov_ has quit IRC15:14
*** andreaf has joined #openstack-infra15:14
*** yassine has quit IRC15:14
miarmakfungi: yeah) we have already done it) but we are looking for better solution15:16
*** unicell has joined #openstack-infra15:17
*** sarob_ has joined #openstack-infra15:18
miarmakfungi: and about work with the developers of our dependencies - it is great idea, but we are young project and do not have such practice15:19
miarmakfungi: maybe will discuss about it, thanks for advice15:19
*** saju_m has joined #openstack-infra15:20
*** markmcclain has quit IRC15:21
devanandag'morning, all15:22
zulheylo15:24
*** sarob_ has quit IRC15:24
mordredjeblair: yah. I actually think we could easily move run_remote_puppet to run salt instead of ssh15:25
openstackgerritChad Lung proposed a change to openstack-infra/config: Removing non-voting for gate-barbican-devstack-dsvm  https://review.openstack.org/8068615:25
mordredfungi: you will be quite sad if you try to look for docs in distutils for stuff we do in pbr15:25
fungimordred: oh, is setup.cfg parsing of files.packages done directly in pbr?15:26
mordredyes15:26
mordredfungi: what's the problem you're hitting?15:26
fungiahh! that 'splains why i couldn't find it mentioned in any part of stdlib packaging docs15:26
fungiso borrowed the syntax from distutils2 then?15:27
*** jgrimm has joined #openstack-infra15:28
devanandaanyone have a minute to review two small patches for ironic testing? https://review.openstack.org/#/c/80652/  and  https://review.openstack.org/#/c/80653/15:28
miarmakfungi: so thanks for answering my question. I am grateful for your help!15:28
*** david-lyle has joined #openstack-infra15:28
fungimiarmak: you'15:28
fungire welcome15:28
*** wenlock has joined #openstack-infra15:28
*** yassine has joined #openstack-infra15:29
*** shakamunyi has quit IRC15:31
*** zehicle_at_dell has joined #openstack-infra15:31
openstackgerritMarton Kiss proposed a change to openstack-infra/config: Openstackid track site version  https://review.openstack.org/8099615:32
*** flaper87 is now known as flaper87|afk15:34
*** unicell has quit IRC15:37
*** emagana has joined #openstack-infra15:38
dkranzfungi: This morning, Firefox started crashing when I click on a link from email or xchat but only links to review.openstack.org. Has any one else seen anything like this? Did something change?15:39
fungidkranz: nothing i'm aware of. maybe firefox or one of your plugins updated?15:39
*** mrodden has quit IRC15:40
dkranzfungi: ok. I don't know. I'll try re-installing. Really weird cause any other sites seem to have no problem.15:40
fungidkranz: well, gerrit's webui is pretty javascript-heavy, so it doesn't surprise me that it might interact negatively with some plugins15:41
dkranzfungi: Makes sense.15:41
*** CaptTofu has joined #openstack-infra15:41
*** andreaf has quit IRC15:42
*** alff has joined #openstack-infra15:44
*** annegentle has joined #openstack-infra15:46
*** unicell has joined #openstack-infra15:47
mordredfungi: yeah - and then distutils2 got killeded15:47
*** miqui has joined #openstack-infra15:47
openstackgerritJames E. Blair proposed a change to openstack-infra/config: Use unbound  https://review.openstack.org/8009215:49
*** saschpe_ has joined #openstack-infra15:49
pleia2oh, bugdaystats may not be on anyone's radar yet, could use some review: https://review.openstack.org/#/c/79800/15:50
openstackgerritRuslan Kamaldinov proposed a change to openstack-infra/storyboard: Fix DB migrations in unit tests  https://review.openstack.org/8083615:50
pleia2once this is done I'll add -infra to this so we'll have pretty graphs for our bug days :)15:50
jeblairpleia2: yep, it wasn't in my list; added, thx.15:52
*** marun has joined #openstack-infra15:53
*** mrodden has joined #openstack-infra15:53
mordredjeblair: I makred this WIP because it's untested - but I'd love feedback on the idea/approach if you have a sec15:54
mordredhttps://review.openstack.org/#/c/80893/15:54
*** andreaf has joined #openstack-infra15:54
*** markmcclain has joined #openstack-infra15:57
jeblairmordred: is the current thing bad or suboptimal in some way?15:57
fungijamielennox|away: your ci jobs are running correctly now. we had a packaging-related error introduced in jenkins-job-builder shortly before it would have created your jobs in our jenkins masters, so it was failing to do that until just a little while ago when i approved the fix15:57
*** nprivalova has joined #openstack-infra15:58
jeblairmordred: commented in review15:59
*** pbelanyi has quit IRC15:59
*** reed has joined #openstack-infra15:59
*** rossella_s has quit IRC16:01
*** rossella_s has joined #openstack-infra16:01
zaromorning16:02
*** IvanBerezovskiy has left #openstack-infra16:02
*** saschpe_ has quit IRC16:02
*** yassine has quit IRC16:03
*** saschpe has joined #openstack-infra16:04
*** saschpe has quit IRC16:06
*** primeministerp has quit IRC16:07
openstackgerritMartin Konrad proposed a change to openstack-infra/jenkins-job-builder: SCM module: Add support for multiple Git remotes.  https://review.openstack.org/8008416:07
gondoiI had a comment on https://review.openstack.org/79058 mentioning the use of #openstack-satori instead of #satori16:10
gondoiis there a guideline on irc room names I could review?16:10
gondoialso, we are currently only openstack related16:11
openstackgerritA change was merged to openstack-infra/storyboard: Fix DB migrations in unit tests  https://review.openstack.org/8083616:12
*** gyee has joined #openstack-infra16:13
*** wenlock has quit IRC16:15
*** yassine has joined #openstack-infra16:15
*** saju_m has quit IRC16:15
*** CaptTofu has quit IRC16:16
*** yaguang has quit IRC16:16
*** wenlock has joined #openstack-infra16:17
*** CaptTofu has joined #openstack-infra16:17
*** ihrachys has joined #openstack-infra16:17
*** jnoller has quit IRC16:18
*** Hefeweizen has quit IRC16:18
ihrachyshi all. doesn't it look like a circular dependency in gate that blocks the patch to pass checks: https://review.openstack.org/#/c/77982/ ? It fails when touching trove/stable branch in gate even though it's designed to disable this exact check16:18
*** sarob_ has joined #openstack-infra16:18
*** jasondotstar has quit IRC16:19
fungiihrachys: jogo was trying to solve it similarly with 8068716:20
fungiihrachys: but we discovered the script which runs that job needs fixing in pbr first16:21
*** CaptTofu has quit IRC16:22
fungiihrachys: https://review.openstack.org/80723 points out the underlying problem16:22
*** sarob_ has quit IRC16:23
*** afazekas has quit IRC16:23
jogofungi: those issues go even deeper16:23
ihrachysfungi: tnx for info!16:24
jogofungi: https://review.openstack.org/#/c/79756/1 trove isn't part of integrated reqs16:24
*** jcoufal has quit IRC16:24
*** caleb_ has quit IRC16:24
clarkbmorning16:24
*** SumitNaiksatam has joined #openstack-infra16:25
*** e0ne has quit IRC16:25
jogoclarkb: morning16:25
*** e0ne has joined #openstack-infra16:25
*** SumitNaiksatam has quit IRC16:26
fungijogo: argh! and it looks like yesterday hpcloud started failing pypy jobs the same way rax was wrt setuptools being upgraded by pip at the same time as installing other packages16:29
clarkbfungi: oh no!16:29
fungidstufft: ^ did you have any luck figuring out what's going on in pip there16:29
fungi?16:29
jogofungi: so many bugs so little time16:29
openstackgerritA change was merged to openstack-infra/gerritlib: Expose the gerrit watcher as a thread with defined transitions  https://review.openstack.org/7056416:29
jogofungi: is there an e-r query for it?16:30
*** jasondotstar has joined #openstack-infra16:30
*** SumitNaiksatam has joined #openstack-infra16:30
fungijogo: not sure. infra-facing bug is https://launchpad.net/bugs/129056216:33
*** ildikov_ has quit IRC16:33
clarkbno response on DNS ticket yet16:34
fungihowever, since i still have an hpcloud py3k-precise node held from before it started failing there, maybe i have a better chance of spotting how it differs from a current hpcloud node16:34
* fungi starts digging16:34
*** hashar has quit IRC16:36
*** eharney has quit IRC16:36
jogofungi: how does message:" UserWarning\: Unknown distribution option: 'zip_safe'" AND tags:"console" sound16:37
*** jswarren has joined #openstack-infra16:37
*** alff has quit IRC16:38
fungijogo: "16:38
fungier16:38
fungijogo: "error: option --single-version-externally-managed not recognized" may be more accurate for this16:39
fungi(matching on the error, not the warning)16:39
*** sabari2 has joined #openstack-infra16:40
jogofungi: sounds good16:40
clarkbis this failing 100% of the jobs?16:40
clarkbfor pypy16:40
openstackgerritRicardo Carrillo Cruz proposed a change to openstack-infra/gerritbot: Add support for notification of releases on IRC  https://review.openstack.org/7920516:43
fungiclarkb: at this point, i believe so16:43
fungiwe stopped running them on rax because it was failing there and not on hpcloud16:43
clarkbya16:43
clarkband now hpcloud fails too16:44
clarkbfungi: is that setuptools complaining the option doesn't exist?16:45
*** yassine has quit IRC16:45
fungiclarkb: i believe setuptools is not installed at that stage16:45
clarkbit appearts to be running mccabe's setup.py16:45
clarkband is passing --single-version-externall-managed to that setup.py16:46
fungiclarkb: if you upgrade setuptools and mccabe independently (in either order) it's fine16:46
fungiclarkb: but if you upgrade them in the same pip command line, boom16:46
clarkbhuh16:46
fungimccabe just being one example. you can recreate it with other packages using the same option16:46
*** sarob_ has joined #openstack-infra16:47
clarkbis this happening because distutils is being used as the fallback because setuptools is removed?16:47
openstackgerritJoe Gordon proposed a change to openstack-infra/elastic-recheck: Add fingerprint for bug 1290562  https://review.openstack.org/8101516:47
clarkband it is removed as part of the upgrade?16:47
*** rcarrillocruz1 has joined #openstack-infra16:48
dstufftugh16:48
dstufftsorry16:48
dstufftI forgot :(16:48
dstufftbasically yes setuptools is getting removed as part of the process16:49
clarkband not being replaced immeditely16:49
dstufftbut it should be getting immediately reinstalled16:49
dstufftsomething is making it so it's not16:49
*** amcrn has joined #openstack-infra16:49
dstufftthe actual error you're seeing comes from passing a setup tools flag to a distutils setup.py16:49
dstufftbecuse of the fallback16:49
fungiclarkb: i've confirmed that my older held hpcloud instance is still working and the one i just held is failing, so ought to be easy to play spot the difference there16:50
clarkbwoot I groked the problem16:50
*** rcarrillocruz has quit IRC16:50
dstufftyou'll also see it show up as not being able to import setuptools, if the setup.py doesn't have a distutils fallback16:50
dstufftwhat version of pip is involved here again?16:51
jogosdague: https://review.openstack.org/#/c/80027/ is ready16:52
*** sarob_ has quit IRC16:52
jogo(make partial-ncpu work)16:52
clarkbdstufft: I think pip 1.4.1 but fungi can confirm as he has nodes at hand16:52
jogodansmith: ^^16:52
clarkbjogo: oh cool it passes on that change \o/16:53
rcarrillocruz1hey guys, any core reviewer willing to review https://review.openstack.org/#/c/79205/ ? I rebased my branch to master, as last gate check run failed ....16:53
jogoclarkb: yup, keystone folks were kind enough to revert the breaking stable patches over the weekend16:53
fungiclarkb: dstufft: inside the virtualenv it's pip 1.5.4 http://paste.openstack.org/show/73060/16:54
dstufftlet me see if Marcus is around16:54
*** jlibosva has quit IRC16:54
dstuffthe's delt with these errors before and put the fixes we currently have into place16:54
jogodtroyer:  https://review.openstack.org/#/c/80027/ -- is now working for partial-ncpu16:54
clarkbfungi: isn't that a newer version of virtualenv than we expect?16:55
clarkbrcarrillocruz1: looking16:55
*** dstanek has quit IRC16:55
*** hogepodge_ has joined #openstack-infra16:55
fungiclarkb: yep, but that doesn't seem to explain away the issue16:56
jeblairclarkb, fungi: i'm thinking of approving a change that touches db configuration on slaves; do you anticipate any other need to build new images soon?16:56
openstackgerritA change was merged to openstack-infra/config: Trim down gantt check/gate jobs  https://review.openstack.org/7164816:56
fungijeblair: not unless i end up needing to rebuild py3k images to solve this pypy job issue16:56
clarkbjeblair: I don't have anything16:57
*** hogepodge has quit IRC16:57
clarkbjeblair: what db change?16:57
jeblairclarkb: the baremetal postgres one16:57
fungiclarkb: so, pip freeze on both nodes is identical. dpkg -l reports four differences... sudo, tzdata, tzdata-java and udisks packages got autoupgraded16:57
*** yassine has joined #openstack-infra16:58
clarkbfungi: pip freeze won't show you setuptools and pip differences16:58
clarkbpip list may work better16:58
*** sarob_ has joined #openstack-infra16:59
fungioh, hey, setuptools 3.3 released the same day too... every time we see one provider or the other start breaking this way, it coincides with a new setuptools release the same day... i wonder whether rax nodes have spontaneously started working now that hpcloud's have begun failing ;)16:59
dstufftmaybe I'll just make pip 1.6 default to installing "setuptools damnit"17:00
dstufftas part of executing setup.py :V17:00
dstufft~isolation~17:00
rcarrillocruz1hmm, I miss the code reviews that people put previously, what happened? is it maybe because of the rebase the changeset has a dependency , making previous code review comments disappear?17:00
clarkbrcarrillocruz1: they should still be there on the old patchsets17:01
*** JoshNang_ is now known as JoshNang17:01
*** saschpe has joined #openstack-infra17:01
rcarrillocruz1hmm, but they don't appear the +1s from the reviewer mini-spreadsheet17:02
rcarrillocruz1:(17:02
clarkbrcarrillocruz1: you lose the old votes when non trivial new patcsets are pushed17:02
*** hogepodge has joined #openstack-infra17:03
fungiwhere non-trivial means that git patch-id on both patchsets is identical17:03
fungier, is not identical17:04
rcarrillocruz1ah gotcha, ok, thx for the review, will look into it17:04
*** markmcclain has quit IRC17:04
clarkbfungi: does the old hpcloud node have setuptools 3.2?17:05
clarkbfungi: and new node 3.3?17:05
*** ildikov_ has joined #openstack-infra17:06
fungiclarkb: both report 3.3 inside the virtualenv17:06
clarkbfungi: in the log of a fiaeld run it says found setuptools 2.217:07
clarkbis 3.3 being installed after the mccabe failure? (/me wonders where 3.3 comes from if the job finds 2.2)17:08
fungiclarkb: yeah, i believe that's what's getting initially installed by virtualenv17:08
*** saschpe has quit IRC17:08
jeblairfungi: what's the status of the install modules without dependencies part of the puppetboard change?  is that tested and working now?17:08
fungijeblair: no idea. let me see if i said i tested/was testing it17:09
fungiclarkb: virtualenv bundles setuptools and installs it into the venv it creates17:09
*** harlowja_away is now known as harlowja17:09
fungiclarkb: then pip install comes along hitting some package declaring a dependency on setuptools and upgrades it to the most recent version17:09
jeblairfungi: ok; i thought i vaguely remember conversation about that; nbd if you don't know off the top of your head.17:10
clarkbfungi: right, but it seems to bail after uninstalling 2.2 and before updating to a newer version17:10
fungijeblair: i think i tested the previous bits but only reviewed that one17:10
*** sarob__ has joined #openstack-infra17:10
fungiclarkb: well, it seems to bail on using the new setuptools in evaluating the other package being installed, but looks like it does at least think setuptools is upgraded after that17:11
clarkbah gotcha17:11
*** jgrimm has quit IRC17:11
fungiat least based on inspection of the venv contents afterward17:11
*** rhsu has joined #openstack-infra17:11
clarkbfungi: /me has a theory for a workaround17:12
fungiclarkb: i'm all ears17:12
clarkbone sec I will push a patch17:12
clarkbIt is a bit of a hack though :/17:13
*** e0ne has quit IRC17:13
*** sarob_ has quit IRC17:14
*** morganfainberg_Z is now known as morganfainberg17:14
*** afazekas has joined #openstack-infra17:14
*** jgrimm has joined #openstack-infra17:14
* fungi expects "upgrade setuptools in the venv prior to installing any other packages17:14
fungisince that's the ugly hack workaround i was thinking of proposing17:15
openstackgerritA change was merged to openstack-infra/jeepyb: Keep py3.X compatibility for urllib  https://review.openstack.org/7612217:15
openstackgerritA change was merged to openstack-infra/config: Set up opportunistic bare-metal postgres db  https://review.openstack.org/7346117:15
*** mwagner_lap has quit IRC17:16
clarkbfungi: https://review.openstack.org/#/c/81023/17:16
fungiclarkb: that's definitely an alternative approach, until we hit a dependency declaring it needs a newer setuptools than virtualenv is providing17:17
*** markmcclain has joined #openstack-infra17:17
clarkbfungi: ya17:17
clarkbfungi: we can restrict that with an explicit pypy testenv that sets a different install_command too17:18
sdaguejogo: +A17:18
clarkbif we want to keep the existing behavior on py26 and py2717:18
clarkboh and py3317:18
fungiclarkb: i am less and less sure that this issue is unrelated to pypy... so far we've *only* seen it crop up with pypy virtualenvs. the bug may still be in pip, but something about pypy seems to be tickling it17:19
fungibut it's *possible* we could see it with other interpreters17:20
fungiwe just haven't so far17:20
openstackgerritA change was merged to openstack-infra/config: Add oslo.test integration test  https://review.openstack.org/7638117:20
*** hogepodge has quit IRC17:21
*** CaptTofu has joined #openstack-infra17:21
clarkbfungi: https://jenkins07.openstack.org/job/gate-python-novaclient-pypy/15/ it does seem to be a viable workaround17:22
morganfainbergclarkb, since you seem to be a person involved with tox (and therefore probably more familiar with mercurial than i am), is there a way to update the commit in a pull request on bitbucket? or do i just abandon the PR and make a new one?17:23
*** hogepodge has joined #openstack-infra17:23
clarkbmorganfainberg: you can add a second commit to the pr17:23
morganfainbergclarkb, i know, totally random17:23
morganfainbergclarkb, hm. ok so it works like github's PRs then17:23
clarkbmorganfainberg: but aiui hg doesn't let you do a proper rebase and change history on stuff other things know about17:24
clarkbso if you want clean history I think you may need a new PR17:24
clarkbmorganfainberg: I pushed a second commit to my PR and they seemed happy with that17:24
morganfainbergclarkb, i'll just do that. i don't like messy history (have i mentioned i _really_ like the gerrit workflow over PRs)17:24
dstufftI think mercurial lets you do that, you just need extensions :V17:24
dstufftalso git supremacy17:24
morganfainbergdstufft, and probably not with hosted.17:24
morganfainbergdstufft, aka bitbucket17:25
clarkbdstufft: I tried tem once (the rebase extension) it didn't do what I expected17:25
clarkbit was weirdness17:25
*** sweston has joined #openstack-infra17:25
morganfainbergclarkb, we should take over the world (of opensource) and convince everyone to use gerrit workflows.17:25
dstufftyou can force push on Hg17:25
dstufftafaik17:25
dstufftI doubt bitbucket prevents you17:25
morganfainbergdstufft, it actually rejected the force push.17:26
dstufftlol wat17:26
dstufftbitbucket u cray17:26
morganfainbergdstufft, but i am a hg noob17:26
morganfainbergdstufft, i'll just add another commit that fixes all the stuff to my previous one17:26
morganfainbergdstufft, clarkb, thanks17:26
dstufftclarkb: fungi I talked to Marcus, he's going to take a look later at the setuptools issue, he knows this code better than I do17:26
*** rcarrillocruz has joined #openstack-infra17:26
*** rcarrillocruz1 has quit IRC17:27
fungidstufft: thanks!17:27
dstufft[13:26:14]  <qwcode> dstufft, can they actually confirm after that setuptools is missing?17:28
dstufft[13:26:33]  <qwcode> dstufft, i.e. that it's not a path/env issue17:28
dstufftfungi: ^ :]17:28
*** sarob__ has quit IRC17:29
fungidstufft: inspecting the virtualenv shows that the new setuptools installed after it throws that error17:29
sdaguefungi / clarkb: https://review.openstack.org/#/c/80691/ - adding horizon error log will let us narrow a much of the horizon failures in ER17:29
*** sarob_ has joined #openstack-infra17:29
sdagues/much/bunch/17:29
dstufftfungi: if you do foo/bin/pip list it shows the new setuptools?17:29
*** yassine has quit IRC17:30
fungidstufft: foo/bin/pypy -c 'import setuptools;print(setuptools.__version__)' says 3.3 but list says setuptools (3.1)17:30
fungivery weird17:31
fungithis was after "Found existing installation: setuptools 3.1"17:31
*** annegentle has quit IRC17:31
fungior on the even older system, s/3.1/2.2/17:31
clarkbsdague: https://review.openstack.org/#/c/80691/2/modules/openstack_project/templates/logstash/indexer.conf.erb does the rfc822 timestamp match one of the formats on line 104 of that file?17:32
*** zhiyan is now known as zhiyan_17:32
*** annegentle has joined #openstack-infra17:32
* clarkb is looking17:32
*** sarob_ has quit IRC17:33
fungidstufft: so i guess the situation after that failure is that latest setuptools is available on import in the venv, but pip list doesn't register that the upgrade of it completed17:33
dstufftwhat does import setuptools; print(setuptools.__file__) say?17:34
fungidstufft: /home/fungi/foo/site-packages/setuptools/__init__.py17:35
dstufftok17:35
clarkbsdague: you will need to update line 104. I am writing a comment with the new format17:35
sdagueclarkb: cool17:36
clarkbsdague: done17:39
sdagueclarkb: thanks17:40
*** CaptTofu has quit IRC17:42
sdagueclarkb: what is the language of this file anyway?17:43
sdagueif I wrap the array is it going to be an issue?17:44
clarkbsdague: logstash config http://logstash.net/docs/1.3.3/filters/date is the date filter used on line 10417:44
clarkbsdague: yeah that I am not sure17:44
*** eharney has joined #openstack-infra17:44
sdaguebecause the date formats definitely make more sense when you can see them on top of each other17:44
clarkbit isn't terrible to test it if you grab logstash and fire it up locally17:44
sdagueis there a cheat sheet for that?17:45
*** vkozhukalov_ has joined #openstack-infra17:45
clarkbnot really. I always refer to those docs and often read the ruby source17:45
clarkboh you mean spinnin gup logastsh17:45
clarkbyup17:45
devanandaclarkb: hi! have a  minute to look at two small patches for ironic? would like to see if this fixes our CI job17:46
*** zns has quit IRC17:46
clarkbsdague: http://logstash.net/docs/1.3.3/tutorials/getting-started-simple then basically erplace our input and output with stdin input and stdout output17:46
clarkbsdague: since you don't need the fancy es and tcp stuff when doing simple local tests17:46
*** khyati has joined #openstack-infra17:47
openstackgerritSean Dague proposed a change to openstack-infra/config: add horizon_error to the indexed logs  https://review.openstack.org/8069117:47
openstackgerritA change was merged to openstack-infra/config: Repack git repositories daily  https://review.openstack.org/7791917:47
sdagueclarkb: so this isn't tested that the wrapped lines work, but that should be the changes17:48
clarkbdevananda: sure, do you have links?17:48
clarkbsdague: ok, I can give it a whirl maybe17:48
sdagueclarkb: does that go in order?17:49
openstackgerritSean Dague proposed a change to openstack-infra/config: add horizon_error to the indexed logs  https://review.openstack.org/8069117:49
sdagueit just occurred to me that I needed to change the order on optional Z17:49
devanandaclarkb: https://review.openstack.org/#/c/80652/2 and https://review.openstack.org/#/c/80653/17:49
devanandaclarkb: thanks!17:49
clarkbsdague: their docs don't say but typically yes they iterate over arrays in order17:49
*** pblaho has quit IRC17:50
*** Ajaeger1 has joined #openstack-infra17:50
fungidstufft: another point of interest, 'foo/bin/pip install -U setuptools==3.1 mccabe' succeeds but ==3.2 or 3.3 breaks as described17:51
*** atiwari has quit IRC17:51
dstufftugh17:51
dstufftthis migt be a seupools bug17:51
fungiand the rabbit hole goes deeper still...17:52
*** ominakov has quit IRC17:52
clarkbbe careful you don't get stuck down there17:52
*** wenlock has quit IRC17:52
*** ominakov has joined #openstack-infra17:52
*** wenlock has joined #openstack-infra17:53
*** dizquierdo has quit IRC17:54
clarkbdevananda: any idea why all of those havana tests failed on the d-g change?17:54
openstackgerritA change was merged to openstack-infra/zuul: Document the Zuul triggers  https://review.openstack.org/7784317:55
openstackgerritA change was merged to openstack-infra/zuul: Add configurable footer-message reports  https://review.openstack.org/7774017:55
openstackgerritA change was merged to openstack-infra/config: offset nodepool update by 12 hrs  https://review.openstack.org/7893917:56
*** ominakov has quit IRC17:57
fungidstufft: also, downgrading pip to 1.3.1 in the virtualenv before installing/upgrading setuptools and other packages seems to cause this problem not to happen17:57
*** markmcclain has quit IRC17:57
sdagueclarkb: havana was bonkered on requirements and keystoneclient friday17:58
*** isviridov has quit IRC17:58
clarkbsdague: thanks17:59
*** markmcclain has joined #openstack-infra17:59
*** tstevenson has joined #openstack-infra17:59
*** fbo is now known as fbo_away17:59
clarkbsdague: can you look at https://review.openstack.org/#/c/80653/ and see if those failures look familiar?17:59
sdaguewill do17:59
openstackgerritA change was merged to openstack-infra/config: Make storyboard run over ssl  https://review.openstack.org/7874718:00
* clarkb installs java18:00
clarkbsdague: first step looks good. logstash didn't throw any errors when I started it up with your config changes18:01
sdaguecool18:02
*** VijayTripathi has joined #openstack-infra18:02
sdagueI think it's a ton more readable with the fold, so easier to be right in the reviews18:02
clarkbnow I need to get my geard running and throw jobs at it, but first breakfast18:03
*** salv-orlando has joined #openstack-infra18:03
Ajaeger1fungi, did you have a chance to talk with jeblair ?18:03
sdaguedevananda: why is ironic getting added to enabled services?18:04
*** zns has joined #openstack-infra18:04
devanandasdague: lemme check18:04
fungiAjaeger1: oh, i hadn't done so yet... jeblair: not sure if you saw in scrollback, but there were several new periodic translation jobs for openstack manuals which zuul showed (in its debug log) were in the periodic pipeline and which the jenkins masters had as available but which were not getting triggered when the other periodic jobs ran... wondering if you had suggestions for where else i should18:05
fungilook?18:05
Ajaeger1jeblair: this is one of the jobs: https://jenkins.openstack.org/view/Openstack-manuals/job/operations-guide-manuals-propose-translation-update/18:05
Ajaeger1jeblair: jobs adding them: https://review.openstack.org/#/c/80515/18:05
Ajaeger1fungi, thanks18:05
*** rcarrillocruz1 has joined #openstack-infra18:05
jeblairAjaeger1, fungi: my guess is "branch: master" may have something to do with it18:06
fungijeblair: ah! good eye18:07
fungii keep forgetting to check for that on periodic jobs18:07
jeblairAjaeger1: i think that would cause the branch to only run on an event triggered on the "master" branch, but timer triggers don't have branches (at least, not yet anyway; they could, and perhaps should)18:07
*** rcarrillocruz has quit IRC18:07
devanandasdague: so i'm not sure -- there are checks for is_service_enabled ir-api and ir-cond, but I dont see any explicitly for "ironic"18:07
jeblair"cause the job to run" i mean18:07
devanandasdague: is there a reason /not/ to add "ironic" to enabled services?18:08
Ajaeger1jeblair: ok, will sent a patch. Thanks!18:08
fungiAjaeger1: so, yes, need to remove the jobs matches for those which specify branch master18:08
*** mrodden has quit IRC18:08
*** ildikov_ has quit IRC18:08
sdaguedevananda: because it's not supposed to be there18:09
*** ildikov_ has joined #openstack-infra18:09
sdagueENABLED_SERVICES should be daemon names18:10
fungiAjaeger1: so just need to remove the one for ^.*manuals-propose-translation-update$ (which is in periodic) but not ^.*manuals-upstream-translation-update$ (which is in post) i think18:10
sdagueor screen session names, basically18:10
JayFjeblair: Hey, I'm the guy working on ironic-python-agent merge req. When I tried to do 'git review -t new-project', my changes are being rejected because there are no changes. Any advice?18:10
sdaguethe "meta" names, like nova are deprecated, and we're purging them all out18:10
devanandasdague: ah, gotcha18:10
sdagueso we shouldn't be adding more in18:10
sdagueif you remove that add, I'm +218:10
devanandasdague: I saw several still there so didn't realize that. will remove it now18:11
jeblairJayF: if you don't have anything else to change, make a trivial change to the commit message (add a space or period or something)18:11
Ajaeger1fungi: yes, I agree18:11
sdagueyeh, it's still in flux, I was trying to handle the heat case the other day18:11
JayFjeblair: okay, thanks. Was going to do that but wanted to ensure there wasn't a better trick18:11
openstackgerritJason-oldos proposed a change to openstack-infra/config: Add openstack/ironic-python-agent  https://review.openstack.org/7908818:11
*** rcarrillocruz has joined #openstack-infra18:12
fungiJayF: the better trick is, i believe, that once we upgrade to latest gerrit you18:12
fungi'll be able to edit the topic without a new patchset18:12
JayFCool, thanks18:12
*** rcarrillocruz1 has quit IRC18:12
openstackgerritDevananda van der Veen proposed a change to openstack-infra/devstack-gate: Configure localrc for virtual-ironic tests  https://review.openstack.org/8065318:12
fungiat least i believe i heard that was in the list of new features18:12
openstackgerritAndreas Jaeger proposed a change to openstack-infra/config: Fix periodic manuals-propose-translation-update jobs  https://review.openstack.org/8103718:13
Ajaeger1fungi, jeblair: Here's the patch^18:13
*** afazekas has quit IRC18:13
jrollis there a way to install *only* openstack.common.log to a project? I don't see an oslo.log or anything :/18:13
devanandasdague: thanks for pointing that out. after some more grep'ing, it looks like nothing in devstack is keyed off that anyway18:13
openstackgerritA change was merged to openstack-infra/elastic-recheck: Make IRC bot list which failures were seen in which job.  https://review.openstack.org/7879018:14
dhellmannjroll: we can help with that in #openstack-oslo18:15
fungijroll: looks like it's still incubating... http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/log.py ?18:15
zarosdague: you wanted the build timeout plugin to report timeout, right?18:15
fungijroll: but yeah, what dhellmann said18:15
jrollthanks18:15
sdaguezaro: to pass it down, yes18:15
*** rcarrillocruz1 has joined #openstack-infra18:15
sdaguedevananda: yeh, I remember the ironic devstack patch actually did is_ironic_enabled correctly (new style), so I didn't think it would be need18:16
*** mrodden has joined #openstack-infra18:16
*** rcarrillocruz has quit IRC18:16
zarosdague: PR https://github.com/jenkinsci/build-timeout-plugin/pull/22 has merged.  new release at end of month.18:17
sdaguezaro: awesome!18:17
sdaguenice work18:17
zarothx.18:17
sdagueonce that gets into the infrastructure, we should be able to simplify a bunch of stuff18:17
sdaguethanks for tackling it18:18
zaronp.18:18
adalbassdague, hi! is is somewhere documented how to install os-loganalyze (deps, configuration)? I'm looking to install it in a fresh server, with no other ci stuff.18:21
*** mkoderer has quit IRC18:21
sdagueadalbas: mostly in the config repository18:23
fungiadalbas: looks like http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/manifests/static.pp#n111 says we just do 'python setup.py install'18:23
sdaguethere is a sample apache.conf in the os-loganalyze project as well18:23
dhellmannmordred: have a sec to discuss a pbr release?18:23
sdagueit's honestly a pretty simple wsgi filter18:23
fungiadalbas: and the apache vhost config we use with it is http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/templates/logs.vhost.erb18:23
adalbasfungi, sdague tks. i was looking if there are any specific requirements, other then the ones in requirements.tx18:24
fungiadalbas: on line #64 there, "WSGIScriptAlias /htmlify /usr/local/lib/python2.7/dist-packages/os_loganalyze/wsgi.py"18:24
sdagueadalbas: no, I think we basically are only using python built ins18:24
fungiand the rewrites immediately above it18:24
adalbastks!!18:24
sdaguefungi: the docs link seems to be broken on os-loganalyze at the moment18:25
sdague* Documentation: http://docs.openstack.org/developer/os_loganalyze18:25
sdagueany idea what's not connected there18:25
fungisdague: was it ever? was that some boilerplate link which got copied, but maybe we have no documentation job publishing to it?18:26
sdaguecould be18:26
sdaguehonestly, I don't know18:26
* fungi looks18:26
adalbasi could not find it here http://ci.openstack.org/18:27
sdagueadalbas: yeh, this used to be a funny little script inside config, and we broke it out mostly to add better testing18:27
fungisdague: http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n2802 no jobs besides pep8 and python2718:27
*** _nadya_ has joined #openstack-infra18:27
sdaguefungi: you have a preference about whether it's worth adding that, or just purging the reference?18:28
fungisdague: no preference... looks like the content in http://git.openstack.org/cgit/openstack-infra/os-loganalyze/tree/doc/source is still just the template18:29
*** jgallard has quit IRC18:29
sdagueyep18:29
*** Hefeweizen has joined #openstack-infra18:30
sdagueI'm leaning on delete the reference18:30
*** blamar has quit IRC18:30
Ajaeger1fungi: thanks for the +2 on 81037. I would appreciate if somebody could approve this today.18:30
clarkbAjaeger1: looking now18:31
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: update README for accuracy  https://review.openstack.org/8104318:32
clarkbAjaeger1: fungi actually wait18:32
clarkbAjaeger1: fungi: we only want that job to run on the master branc18:32
clarkbso we should double check that the script does that for us18:32
fungiclarkb: good point18:32
*** vhoward has left #openstack-infra18:33
_nadya_fungi, clarkb, hi! I need to test Ceilometer against Mongo in tempest. That's why I need an ability to upgrade mongo on devstack+ubuntu. Could you please advise? I've created a change request to devstack https://review.openstack.org/#/c/81001/ . Is it appropriate solution in general?18:33
*** vhoward has joined #openstack-infra18:33
fungiclarkb: the script will only be run once, but if it has a hard dependency on getting a branch passed to it from zuul or a zuul ref or something, it will not work as expected18:33
*** vhoward has left #openstack-infra18:33
clarkb_nadya_: dims is working to get UCA into the gate18:33
clarkb_nadya_: UCA should come with newer mongodb18:34
clarkbfungi: ya18:34
Ajaeger1clarkb: script is modules/jenkins/files/slave_scripts/propose_translation_update_manuals.sh18:34
fungi_nadya_: also, the devstack maintainers mostly hang out in #openstack-qa18:34
*** sdake_ is now known as sdake18:34
* fungi is not a devstack core reviewer18:34
Ajaeger1it only expects as parameter the project, no ZUUL ref18:35
clarkbfungi: Ajaeger1 I think we need to add gerrit git prep to the job definition in jenkins jobs18:35
*** afazekas has joined #openstack-infra18:35
clarkbwhich should fall back on master nicely18:35
Ajaeger1clarkb: will look into it, brb. Thanks!18:36
*** jerryz has joined #openstack-infra18:36
Ajaeger1you're right, git-prep was missing ;(18:37
fungiclarkb: Ajaeger1: good point, as it's written now, it's going to just use the state of the workspace on proposal.slave, which likely will contain no repository at all, right?18:37
clarkbfungi: riht18:37
fungiand then fail mightily18:37
jogowhats the benifit from rerunning the check queue on a -1 patch?18:38
fungijogo: it might depend, for example, on finctioanlity in another project which hadn't previously merged?18:38
fungifunctionality18:38
Ajaeger1looking at the change that I did (https://review.openstack.org/#/c/80515/), I also removed the scm setting - I guess that was wrong, wasn't it? Let me fix it...18:38
jogofungi: then you can just say 'recheck no bug'18:39
Ajaeger1https://review.openstack.org/#/c/80515/8/modules/openstack_project/files/jenkins_job_builder/config/translation-jobs.yaml - line 7218:39
clarkbjogo: -1 patch? do you mean -1 comment?18:39
jogoclarkb: yeah18:39
*** changbl has quit IRC18:39
fungijogo: as a common example, change to a project's requirements file is failing the requirements enforcement job, and then suddenly starts succeeding once the global requirements change merges18:39
jogoexample:  https://review.openstack.org/#/c/77341/18:39
clarkbjogo: because it will show us bitrot18:39
clarkbremember you can merge with a -118:39
_nadya_fungi: ok, thanks. I just not sure in solution. Is it ok to create a job with param like mongo_deb=http://repos/mongo-latest.deb to install it on devstack. I will go to qa-channel anyway18:40
*** nicedice has joined #openstack-infra18:40
*** blamar has joined #openstack-infra18:41
fungi_nadya_: we don't reuse the machines where that gets run, so it's not necessarily a security risk if it only happens for the jobs which need it... but it's more up to the devstack maintainers as to whether they're okay with that approach18:41
jogoclarkb: sure thats true, but it doesn't seem very useful ...  especially when we regularly use up all our resources18:41
openstackgerritAndreas Jaeger proposed a change to openstack-infra/config: Fix periodic manuals-propose-translation-update jobs  https://review.openstack.org/8103718:41
Ajaeger1fungi, clarkb: How does this look like?18:41
jogoit just doesn't seem like a lot of bang for our buck18:41
jogocurrently jbos are waiting about 16 minutes in check queue before being processed18:42
jogoand we have a light load18:42
clarkbjogo: but it is useful if we correctly mark a change as unmergable18:43
rcarrillocruz1jeblair , clarkb: re: gerritbot irc notifications, here's my rationale for treating ref-updated event as a special case18:43
rcarrillocruz1http://paste.openstack.org/show/73683/18:43
rcarrillocruz1just posted the comment in the review as well18:43
jogoclarkb: how? and why not just run the mergable job then?18:43
_nadya_clarkb: and what is the estimate? Will it be available soon? The problem is that all ceilometer tests works only on Mongo (I know, it's mostly Ceilometer's problem, but anyway). It would be great to test on gating+Mongo. Do you think it is possible within icehouse?18:43
*** melwitt has joined #openstack-infra18:43
clarkbjogo: because it will catch the bitrot if there is bitrot18:44
jogoclarkb: if a patch gets a -1 review, 9 out of 10 times that means there will another revision or at least a +1 or +2 review18:44
clarkb_nadya_: you will need to ask dims18:44
jogoclarkb: sure but we don't have enough resources to check everything for bitrot all the time18:44
_nadya_clarkb: ok, I will :) Thanks for your time!18:44
*** afazekas has quit IRC18:44
_nadya_fungi: Thank you for help, will consult with devstack-guys18:45
jogoclarkb: also bitrot is commonly used to refer to media failure (disk failures etc)18:45
jogoclarkb: it just seems like that rerunning check queue won't do anything useful the vast majority of the time. and we are limited on the number of nodes we have18:46
*** e0ne has joined #openstack-infra18:48
fungijogo: we're regularly running out of available resources, or just during feature freeze run-up and exception?18:48
openstackgerritAndreas Jaeger proposed a change to openstack-infra/config: Fix periodic manuals-propose-translation-update jobs  https://review.openstack.org/8103718:48
Ajaeger1fungi, now without scm builder. thanks18:49
* jogo checks graphite18:50
*** johnthetubaguy has quit IRC18:51
*** rcarrillocruz has joined #openstack-infra18:52
*** Sukhdev has joined #openstack-infra18:52
jogosdague: well for one thing we don'18:53
jogot have enough data since this change was so recent18:53
*** ominakov has joined #openstack-infra18:53
*** rcarrillocruz1 has quit IRC18:54
jogohttp://graphite.openstack.org/render/?from=-2weeks&height=180&until=now&width=334&bgcolor=ffffff&fgcolor=000000&areaMode=stacked&target=color(alias(sumSeries(stats.gauges.nodepool.target.*.*.*.building),%20%27Building%27),%20%27ffbf52%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.*.*.*.ready),%20%27Available%27),%20%2700c868%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.*.*.*.used),%20%27In%20Use%27),%20%276464ff%27)&targe18:54
fungijogo: yeah, i'd rather see what things look like through more of a dev cycle before we go fine-tuning for a base activity level which is unrealistic most of the time18:54
jogofungi: do we collect how long something stays in check queue for?18:55
jogofungi: if there is one thing we have learned is 'base activity level' just goes up over time18:56
fungijogo: i think we collect the number of jobs waiting for workers at any point in time. you could probably extrapolate18:56
jogoalso we are in feature freeze things should be pretty silent now18:56
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: add persistence of anchors  https://review.openstack.org/8104718:56
jogofungi: do you know what that is called18:56
zarofungi: looks like git.o.o picked up gerrit-2.8.3 release. you have time to make a branch today?18:56
*** mrda_away is now known as mrda18:57
fungijogo:18:57
fungihttp://graphite.openstack.org/render/?from=-24hours&height=180&until=now&width=334&bgcolor=ffffff&fgcolor=000000&target=color(alias(stats.gauges.zuul.geard.queue.running,%20%27Running%27),%20%27blue%27)&target=color(alias(stats.gauges.zuul.geard.queue.waiting,%20%27Waiting%27),%20%27red%27)&target=color(alias(stats.gauges.zuul.geard.queue.total,%20%27Total%20Jobs%27),%20%27888888%27)&target=color(ali18:57
fungias(stats.gauges.zuul.geard.workers,%20%27Workers%27),%20%27green%27)&title=Zuul%20Job%20Queue&_t=0.1325414417994177418:57
*** gordc has joined #openstack-infra18:57
fungijogo: or the job queue graph at the bottom of the zuul status page18:57
jeblairjogo: resident18:58
fungizaro: yes, meant to do so friday night and then got sidetracked--sorry. doing it now18:58
jeblairjogo: resident_time18:58
clarkbsdague: I am getting grokparse failures with your regex18:58
*** ominakov has quit IRC18:58
clarkbsdague: currently debugging that, but I think we are close to having this in18:58
sdagueok18:58
fungizaro: you want to branch openstack/2.8.3 from the v2.8.3 (2014-03-14 07:44:49) tag?19:00
*** dguerri_ has joined #openstack-infra19:00
sdaguejogo: what's the thing you want to change?19:00
fungizaro: done. the head of that openstack/2.8.3 branch is 315ef4219:01
*** rpodolyaka1 has joined #openstack-infra19:02
sdaguejogo: I'd be +1 on not rerunning changes on a -2, but on a -1, you can still get overridden, so we should have fresh results on it.19:02
*** sabari2 is now known as sabari19:02
fungizaro: http://git.openstack.org/cgit/openstack-infra/gerrit/log/?h=openstack/2.8.319:02
sdaguethe other idea would be take the "idle refresh" completely out of band19:03
jogojeblair: found stats.timers.zuul.pipeline.check.resident_time.mean  but not sure hwo to parse it19:03
jogosdague: don't trigger the auto recheck on a -1 comment19:03
sdaguethat woul require other zuul patches, but that would probably be a good option19:03
jogoif someone else comes along and gives a +1 then you trigger then anyway19:03
clarkbsdague: it appears to be an issue with the brakcet escapes19:03
sdaguejogo: yeh, I'm -1 on removing on -119:03
clarkbsdague: the first [] don't need them but the second does19:03
jogosdague: becuase?19:03
sdagueclarkb: interesting...19:03
clarkbsdague: not sure why that is19:03
clarkbjesusaurus: ^ do you know what is going on there?19:04
sdague<sdague> jogo: I'd be +1 on not rerunning changes on a -2, but on a -1, you can still get overridden, so we should have fresh results on it.19:04
sdaguejogo: because that patch you linked right now I could +A it in19:04
jogoright, when someone comments on it they get new data anyway19:04
Ajaeger1fungi, clarkb: I hope that https://review.openstack.org/81037 is fine now.19:04
jogoso yes there are edge cases for this19:04
sdaguejogo: the edge cases where what was killing us19:05
* jesusaurus reads a bit of scrollback19:05
jogobut we still rerun everything in check before gate anyway19:05
jogoso I don't see how this can hurt us19:05
clarkbjesusaurus: [%{DATESTAMP_RFC822:logdate}]%{SPACE}\[%{LOGLEVEL:loglevel}\]%{SPACE}%{GREEDYDATA:logmessage} as a filter works according to https://grokdebug.herokuapp.com/19:05
jogous==gate19:05
clarkbjesusaurus: that is one pair of [] escaped and one pair not escaped19:05
sdaguejogo: honestly, I'm not going into another one of these roundabouts today. :) I'm -1, on changing that fact, we can dive through it all again at summit.19:06
jesusaurusclarkb: i think you want to escape both sets19:06
jogosdague: and the check queue can take hours to run sometimes. right now things are not bad at all with a 10 minute delay19:06
jogoso I bring this up now because this is hitting everybody in a real way19:06
clarkbjesusaurus: it doesn't work that way19:06
clarkbjesusaurus: whcih is really odd19:06
fungiAjaeger1: clarkb: it made me start looking closely at the other translations proposal job, and i don't see where it's dealing with the initial git checkout either, i wonder if that one is also broken but working because there happens to have been a git clone in the workspace previously?19:07
*** jnoller has joined #openstack-infra19:07
jesusaurusotherwise they will be parsed as a set of chars19:07
clarkbfungi: the others have g-g-p19:07
jesusaurusclarkb: thats odd19:07
jogotoday its not very bad but it can be19:07
jogoand has been19:07
*** afazekas has joined #openstack-infra19:07
clarkbjesusaurus: oh huh19:07
clarkbjesusaurus: so it "works" but doesn't actually aprse the date correctly19:07
jesusaurusclarkb: [abc] is parsed as (a|b|c)19:08
sdaguejogo: there are plenty of other places to look for purging things, or get more quota. I think this is the wrong place19:08
fungiclarkb: '{name}-propose-translation-update' does not... http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/jenkins_job_builder/config/translation-jobs.yaml#n1519:08
jogosdague: if you have had this discussion, before is there a place you can point me to to catch up19:08
clarkbjesusaurus: yeah gotcha so it makes the other matches work, I tink the rfc822 thing isn't quite right19:08
jesusaurusso it's valid, just not what you want19:08
fungiclarkb: and seems to use the scm builder instead?19:09
* jesusaurus -> lunch19:09
*** mgagne has joined #openstack-infra19:09
fungiclarkb: is that provided by the scm jenkins plugin?19:09
clarkbfungi: oh huh, yup we need scm19:09
clarkbfungi: ya19:09
fungiclarkb: does ggp need tweaks to support this use case then, or should ir already be able to do what we want (and so we can switch off scm on the old job too)?19:10
jogosdague: in the long run perhaps, but this delay can get pretty long on a regular basis.19:10
clarkbsdague: the problem with that grok is rfc822 is year before time19:10
jogowe broke 120 jobs in check queue last week -- during FF19:11
clarkbbut horizon error log is time then year...19:11
*** thuc_ has quit IRC19:11
*** mbacchi has quit IRC19:11
sdagueclarkb: oh, man, so I messed that part up19:11
zarofungi: thanks.19:11
sdaguejogo: if by "we" you mean races in openstack that aren't fixed, sure19:11
*** thuc has joined #openstack-infra19:11
*** mgagne1 has quit IRC19:11
jogothis is check queue not gate, what do races have to do with it?19:12
sdagueI'm really not positive about optimizing around bugs and running tests less often because we might block code19:12
*** afazekas has quit IRC19:12
sdagueok, you mean we had > 120 jobs19:12
sdagueI thought you mean breaking test results :)19:12
jogoohh haha.19:12
jogobtw check this out: http://status.openstack.org/elastic-recheck/data/uncategorized.html and click 2 days19:13
sdaguejogo: well, it was a really slow weekend :)19:13
sdagueso that doesn't really count19:13
*** afazekas has joined #openstack-infra19:14
sdaguejogo: you want more nodes back, #1 - patch zuul to be able to gate-noop without throwing away a nodepool node19:14
jogoso the problem as I see it is: the check queue can get backed up. The underlying issue is not enough resources for the load we are generating.19:14
sdaguethat gets us back a few hundred nodes a day19:14
jogosdague: can you point me in the right direction for that?19:14
*** caleb_ has joined #openstack-infra19:14
sdaguejeblair might be able to19:14
sdaguethat was a discussion last week19:14
jogosdague: that sounds like a good use of my time19:14
*** _nadya_ has quit IRC19:15
jogoor anyones19:15
jogojeblair: ^19:15
jeblairjogo: we have not hit our quota today19:15
jeblairjogo: look at the graph19:15
*** sarob_ has joined #openstack-infra19:15
jogojeblair: then why are check queue jobs queued19:15
jogoalso I don't know what the quota19:15
jogois19:15
jeblairjogo: i have to get lounch, back later19:16
*** thuc has quit IRC19:16
jogojeblair: kk19:16
jeblairjogo: (it's the flat line at the top of the test nodes graph)19:16
jeblairjogo: (it's not visible currently)19:16
jogojeblair: ohh19:16
clarkbsdague: I am still hitting it with a hammer, hope to have a proper regex shortly19:16
jogosdague: in that case my mistake, there are other factors in delay right now19:16
sdagueclarkb: cool, thank you19:16
jogoI only see building, ready, inuse and deleting in the graphite source for the test nodes graph19:18
sdaguejogo: basically if you can see green in that graph, and there isn't a flat line on top, we're fine19:19
*** weshay has quit IRC19:19
sdaguejogo: or figure out that with the new nova-network bit if we can go back to higher parallism19:20
jogoso given it lools like we do hava extra resources. I am still perplexed why jobs are in queued in check queue19:23
jogoand there are no zuul events to process19:24
*** thomasbiege has joined #openstack-infra19:25
*** vkozhukalov_ has quit IRC19:25
*** mrodden has quit IRC19:25
*** mrodden has joined #openstack-infra19:26
sdaguejogo: well that would be the one to get to the bottom of19:26
fungiclarkb: the reason i suspect ggp may not work for this as-is... compare http://git.openstack.org/cgit/openstack-infra/config/tree/modules/jenkins/files/slave_scripts/gerrit-git-prep.sh#n31 and https://jenkins.openstack.org/job/nova-propose-translation-update/564/parameters/19:27
devanandasdague, clarkb: looks like https://review.openstack.org/#/c/80653/ passed tests after my last fix19:27
*** gokrokve has joined #openstack-infra19:27
sdaguedevananda: +219:27
jamespagefungi, dims: libvirt 1.2.2 + selected patches is now in the icehouse cloud archive19:27
jamespagesdague, fungi: I think hallyn was looking for someone who could reproduce the problem with 0.9.8 to write a short test case19:28
fungiclarkb: how do you feel about a patch to ggp which will fall back on master when there's no zuul ref passed? we'll presumably need it in a post-jenkins world anyway, and this would let us drop the scm plugin from the other template too19:28
fungijamespage: as i understand it, the bug we're encountering is known upstream, but reproducing it requires high-volume testing to get it to sometimes occur19:29
*** changbl has joined #openstack-infra19:29
jamespagefungi, OK - we have some precedent for this type of issue19:29
jamespagefungi, I'll catch hallyn tomorrow to discuss19:29
devanandasdague: thanks!19:29
clarkbjamespage: run tempest against libvirt19:30
sdaguejamespage: right, there was a very specific scenario layed out in the upstream commit19:30
fungi(a bunch)19:30
sdagueyeh, a bunch19:30
*** jasondotstar has quit IRC19:30
sdaguejamespage: the reason I asked, was mostly to make sure it was clear that I don't think anyone here is going to build an ubuntu specific test case that's outside of the openstack flow19:30
sdagueand I wanted to make sure there wasn't a deadlock19:31
*** yassine has joined #openstack-infra19:31
*** alff has joined #openstack-infra19:32
*** thuc has joined #openstack-infra19:33
*** ominakov has joined #openstack-infra19:34
gordchi folks, i recently added openstack-server-publish-jobs to pyCADF library (https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L985)19:35
gordci merged in the first batch of doc files yesterday (https://review.openstack.org/#/c/65139/) but they didn't seem to get pushed to docs.openstack.org/developer/pycadf... (i did see a NOT REGISTERED comment in Zuul when i glanced at the job)... was there a step i missed to enable doc generation?19:36
*** _nadya_ has joined #openstack-infra19:36
*** zns has quit IRC19:37
fungigordc: jenkins job builder was broken for a few days in master, and since we cd from master on our jenkins servers no jobs added in the past few days worked until earlier today when the fix merged19:37
openstackgerritClark Boylan proposed a change to openstack-infra/config: add horizon_error to the indexed logs  https://review.openstack.org/8069119:37
clarkbsdague: ^19:37
fungigordc: any which run now should in theory work19:37
clarkbfungi: that was the pbr installation thing?19:38
*** comstud has quit IRC19:38
fungiclarkb: yes19:38
clarkband with that time for lunch19:38
gordcfungi: ah cool. let me give it another try again. thanks for the info.19:38
sdagueclarkb: is %{SPACE} optional?19:38
*** comstud has joined #openstack-infra19:38
clarkbsdague: dependson19:38
* fungi is in %{SPACE}19:38
clarkbsdague: %{SPACE} will optionally match any number of whitespace19:39
clarkbso the areas without it must have a single space19:39
sdaguebut not 0?19:39
clarkbit will match 019:39
sdagueok19:39
clarkbwhich is why i put it before TZ because the TZ may not be present19:39
sdagueyep19:39
sdagueok, good19:39
sdague+119:39
sdaguethanks for fully debugging that19:39
clarkbsdague: I tested against http://logs.openstack.org/77/80177/4/check/check-tempest-dsvm-full/e840a87/logs/horizon_error.txt.gz fwiw19:40
sdaguegreat19:40
dguerri_hello everyone19:40
*** thuc_ has joined #openstack-infra19:40
*** thuc has quit IRC19:40
clarkbdguerri_: hello19:40
dguerri_I would like to propose a tool we are currently using at HP to track upstream openstack project that now has been released as an opensource sw (apache lic)19:41
dguerri_it's called git-upstream (so it can be used as a git subcommand)19:41
clarkbdguerri_: and by track you mean it keeps a local repository in sync with an upstream?19:42
clarkbjeepyb can do this for you today19:42
dguerri_clarkb: it allows to simplify some steps needed to rebase local carried patches onto upstream commits (or tags)19:42
*** ominakov has quit IRC19:43
dguerri_if you cherry-picked some commits from upstream, it will detect them (comparing gerrit Change-Id, ATM)19:43
jogosdague: any thoughts on how to deal with troves depedencies? https://review.openstack.org/#/c/80690/419:44
fungidguerri_: while the tool sounds neat and useful, i worry that it may encourage workflows openstack is trying hard to undo (companies carrying their own patches on top of openstack rather than getting features integrated upstream)19:45
dguerri_basically we are using it with 2 jenkins jobs: one periodically mirrors an upstream project and the other one rebase local carried patches on top of the mirrored copy of the repo19:45
*** jasondotstar has joined #openstack-infra19:45
jogosdague: full list of missing deps https://review.openstack.org/#/c/79756/119:45
clarkbfungi: not only that but itmay encourage forks19:46
*** ominakov has joined #openstack-infra19:46
clarkbwhich as an upstream doesn't seem like an appropriate thing to do19:46
dguerri_fungi: yep, I understand. But it can be used to maintain patches which have been proposed upstream but that have not been yet merged/included19:46
sdaguejogo: that was already proposed as individual reviews from the trove team19:47
jogosdague: ahh19:47
*** mkoderer has joined #openstack-infra19:47
jogoand they all hit the pypy failure19:47
sdagueyeh, everything is hitting that19:47
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: refresh devstack log  https://review.openstack.org/8105719:47
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: update README for accuracy  https://review.openstack.org/8104319:47
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: provide a -e run target to run server locally  https://review.openstack.org/8095219:47
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: add persistence of anchors  https://review.openstack.org/8104719:47
openstackgerritSean Dague proposed a change to openstack-infra/os-loganalyze: highlighting the way you expect  https://review.openstack.org/8096619:47
*** hashar has joined #openstack-infra19:48
openstackgerritSergey Lukjanov proposed a change to openstack-infra/devstack-gate: Don't enable savanna service for sahara  https://review.openstack.org/8105819:49
*** _nadya_ has quit IRC19:49
jogosdague: do we need to get that sorted out by icehouse?19:50
jogoor not19:50
fungii'm a little worried that it may be necessary to either pin all our infra to setuptools<3.2 (if that's even doable), stop upgrading packages in virtualenvs when pip installs, or cease testing pypy until it's solved19:50
dguerri_fungi: clarkb: let me know if you are interested19:51
*** dstanek has joined #openstack-infra19:52
clarkbdguerri_: I don't think it is something upstream should carry. I agree it would have its uses, but openstack shouldn't have an official fork openstack project19:52
*** caleb_ has quit IRC19:52
fungior really anything which makes it easier for providers not to bother getting their patches incorporated upstream, further driving incompatibilities between different openstack services throughout the internet (something as a project we've been trying very hard to reign in recently)19:53
*** alff has quit IRC19:54
lifelessclarkb: so uhm19:54
sdaguefungi: why does this only nuke pypy?19:54
lifelessclarkb: why not? We have an explicit expectation that CD deployers- HP, Rackspace, etc - are going to carry minor divergence regularly.19:55
clarkblifeless: do we?19:55
lifelessclarkb: why shouldn't supporting that be something the community maintains?19:55
clarkblifeless: because of fungi's statement19:55
clarkbboth of them19:55
sdaguefungi: and, honestly, do we care? because I don't think pypy being busted in a funny way should block the rest of openstack19:55
clarkbsdague: beacuse peopel put effort into making pypy work. maybe they can help fix this19:56
lifelessclarkb: you can't both not gate on providers exact configurations and expect that they never need to do their own QA polish19:56
dimsjamespage, excellent, will take a look19:56
sdagueclarkb: so who are those pypy people? because I think blocking all of requirements changes for icehouse forever is probably not a good trade off19:57
lifelessclarkb: we've chosen to gate on only what is open source and reproducable by individual devs; the corollary is that CD deployers can't presume trunk works, and thus they have a floating set of 'current fixes' on top of trunk.19:57
lifelessclarkb: making it harder to do that well increases the cost of CD, which means they have less bandwidth for working upstream.19:57
fungilifeless: it seems like something that interested members of the community could collectively maintain if they want to use it. i just don't think it sounds suitable as an openstack-infra project19:57
lifelessclarkb: its basically the exact opposite of what we want to achieve.19:58
lifelessfungi: I don't think its openstack-infra either19:58
lifelessfungi: but clarkb was saying 'upstream doesn't want this'19:58
lifelessfungi: which is a different statement19:58
fungilifeless: "upstream" in this channel implying openstack-infra was completely the basis for my evaluation19:59
sdaguelifeless: so you are making an explicit assumption that if CD is easier people will contribute more to upstream, and if CD is harder, they will contribute less19:59
sdaguewhich I'm not sure I buy19:59
*** weshay has joined #openstack-infra19:59
lifelesssdague: I'm relaying what folk at both HP and rackspace have told me about where they get to spend time19:59
clarkbsdague: Alex_gaynor19:59
*** changbl has quit IRC20:00
lifelesssdague: I agree that it is certainly not as simple as as a linear see-saw :)20:00
sdaguelifeless: and those people said if they weren't doing that they'd be contributing to upstream QA more (for instance?)20:00
dguerri_I think using that tool is a way better than maintaining patches "manually". Its focus is on maintaining patches on top of upstream commits which means you are willing to be updated (which is good) and as you will run into some rebase problem if you are just patching existing code20:00
sdaguebecause I think one of the major reasons for carrying these out of tree patches is requiring undefined behavior in upstream20:01
clarkbI agree using a tool is a great idea and there is utility there.20:01
dguerri_probably if you are maintaining some new cool feature you don't want to release, you will not release it even if rebasing it is difficult...20:01
lifelesssdague: so for HP, upstream QA and upstream tracking+feature work are different teams, so I'm quite certain lower friction around CD wouldn't get more tempest work in and of itself20:01
*** dprince has quit IRC20:01
lifelesssdague: actually, we can probably get some stats on exactly what and why for HP cloud20:02
sdaguelifeless: that would be valuable regardless20:02
lifelesssdague: so if we're up for a little latency, we can have facts rather than speculation for this discussion :)20:02
clarkbbut I also agree with fungi that it sets a bad stage for upstream cooperation20:02
sdaguelifeless: yeh, I don't think there is an urgency on a decision here, so facts are good20:02
*** mbacchi has joined #openstack-infra20:03
clarkbsupporting not releasing a cool new feature isnt something I want to encourage20:03
lifelessdguerri_: reckon we could get a pareto chart (reason for carrying a local patch vs frequency?) for the patches we've carried using this tool ?20:03
lifelessclarkb: *that* case is almost totally unreleated20:04
lifelessclarkb: HPCloud uses plugins for that20:04
sdagueI also share concerns with making it an openstack project that basically tells everyone to expect to run with out of tree patches. Because I think there are already way too many folks doing that, and honestly we should be trying to figure out how to help people avoid that20:04
clarkbit was just used as an example20:04
lifelessclarkb: if the set of examples is 0, the argument is void20:04
clarkbhuh20:04
lifelessclarkb: so, while I realise it was an example, we need real ones.20:04
clarkbsee sb20:04
Alex_Gaynorclarkb: what's up?20:05
clarkbpypy is broken20:05
sdagueAlex_Gaynor: pypy is 100% failing requirements changes atm20:05
mordreddhellmann: hey20:05
Alex_Gaynorlink?20:05
sdagueAlex_Gaynor: https://review.openstack.org/#/c/80850/20:05
dhellmannmordred: hi, I'd like to do a pbr release to fix an issue with "python setup.py --name" that breaks the oslo config generator in some situations20:05
sdagueone example20:05
dhellmannmordred: wanted to check with you as the primary maintainer, first20:06
sdaguebut if yuo look at the requirements repo in general, the wall of -1s are all from the pypy job20:06
dguerri_sdague: I disagree (sorry) you are not encouraging ppl to run their own patches. You are encouraging them to stay updated...20:06
mordreddhellmann: I'm probably pretty fine with that - while I've got you - did you happen to read scrollback about versioning or read lifeless' email?20:06
Alex_Gaynorsdague: this looks like the bug someone was looking into the other day where doing things in a certain order made pip barf if you tried to pip install setuptools <something else> ? And it can be solved with pip install setuptools && pip install something else20:06
dguerri_they will run their patches if they want to.. with or without a tool20:06
dhellmannmordred: I saw the email, but not the scrollback. I haven't absorbed the email yet.20:07
mordredAlex_Gaynor, sdague: pip installing setuptools <something else> is almost always fraught with peril in our experience aroud here20:07
dguerri_it is all about how you are presenting it20:07
dguerri_:)20:07
sdaguedguerri_: sure, I don't expect people not to have local patches20:07
*** atiwari has joined #openstack-infra20:07
sdagueI'm a realist20:08
*** mwagner_lap has joined #openstack-infra20:08
mordreddhellmann: the scrollback _MAY_ give better or worse framing - it's a long conversation between lifeless dstufft and I20:08
sdaguehowever I also do get concerned with making it dumb simple, because people won't realize that git rebase can get things terribly wrong20:08
mordreddhellmann: it's possible that seeing the arguments for and/or against would be helpful - but I'd specifically  like you and ttx to provide feedback20:09
sdagueand at a certain point, it's like building your own lightsaber20:09
* mordred wants a lightsaber20:09
dguerri_they will realise that earlier if you are fostering upstream tracking (staying up to date)20:09
dguerri_hehe20:09
dhellmannmordred: I'll take a look, but it would be really nice if one of you took the time to summarize on the ML. Is that what lifeless' etherpad is?20:09
sdaguedguerri_: maybe... I'm not sure you've seen the same crazy that gets submitted to our projects :)20:10
lifelessdhellmann: my mail the ML was the summary :)20:10
mordreddguerri_: I actually have some patches on git-upstraem I need to give you20:10
dguerri_mordred: cool20:10
*** esker has joined #openstack-infra20:11
mordredsdague, clarkb: my general thought was, as we refactored manage-projects into multiple instead of one tool - making our current upstream tracking code and the git-upstream tools for faciliting merging of such upstream branches into a thing20:12
dhellmannlifeless: that may be too summarized20:12
dhellmannlifeless, mordred : let me read a bit20:12
*** jeckersb is now known as jeckersb_gone20:12
sdaguemordred: is this the gerrit of gerrits idea?20:13
mordredwe ourselves have been tracking an upstream with patches for a couple of years - and we have forks of a couple of others. it happens, even with the best of intentions20:13
mordredsdague: yah20:13
mordredor one of the steps towards it20:13
*** jasondotstar has quit IRC20:14
mordredif we have the smarts to tell a gerrit that it's tracking another gerrit's thing - then I think overall that helps facilitate people submitting their patches upstream20:14
*** adalbas has quit IRC20:14
mordredbut I may just be an optimist - it's certainly my hope that that's what the result would be20:14
sdagueyeh, I just get concerned with handing a tool to "bob's local cloud" which tries to autorebase his hot fixes and push to production, we're probably not doing him a service20:15
sdaguebecause there is a lot you need to be sure of in that process20:15
sdagueif it was more this gerrit chain, which would include a robust revalidation, that's a bit different20:16
fungiAlex_Gaynor: right, that was me looking into it, and then dstufft... bug on the openstack side is https://launchpad.net/bugs/1290562 and it seems that with the setuptools 3.3 release yesterday this is now impacting hpcloud as well, not just rackspace20:16
Alex_Gaynorfungi: at least it's more consistently reproducable? ~~computer~~20:16
lifelesssdague: so thats where tripleo comes in, because we're all about CD - testing20:16
mordredsdague: that would certainly be the intent -which is why I think it shoudl associate with manage-projects20:16
lifelesssdague: and only deploying things we know work20:16
fungiAlex_Gaynor: right20:16
*** rcarrillocruz1 has joined #openstack-infra20:17
mordreddhellmann: tl;dr - 1.0.0b1 is pep440 but not semver. 1.0.0.b1 is current pbr semver but compat with nothing. 1.0.0.0b1 happens to fill both intents - and there are a few other tweaks20:17
pleia2apparently when a 2 year old needs to be fed, dinner comes early :) bbiab20:18
sdagueAlex_Gaynor: so any idea why it's pypy only that's failing this?20:18
Alex_Gaynorsdague: Not really, I can imagine vaguely some gc thing, or dict ordering, but I don't know; let me poke around the pip source code20:18
*** rcarrillocruz has quit IRC20:18
sdaguecool20:18
sdaguebecause this is blocking some things we need for icehouse, so if we don't have an answer soon, I'd like to drop the pypy job on requirements from voting20:19
*** rcarrillocruz has joined #openstack-infra20:19
*** alff has joined #openstack-infra20:19
dhellmannmordred: so what's the potential downside? just that we're changing?20:20
lifelessdhellmann: the change I'm really interested in is the version calculation bit, not the serialisation of 1.0.0 beta 1 :)20:20
dhellmannlifeless: the "next version" calculation stuff? is that different from what we do now, or do we punt and use "number of commits + hash"?20:21
lifelessdhellmann: e.g. from 1.0.0.5 as fifth commit after 1.0.0 to 1.0.1.0a0.dev520:21
lifelessdhellmann: right now we punt and use number of commits + hash (the hash would be present in both cases)20:21
fungiAlex_Gaynor: if you're trying to reproduce, use virtualenv 1.11.4 to make a pypy venv (it will get an initial setuptools 2.2 bundled in). then try to 'pip install -U setuptools mccabe' in that venv, and when pip tries to upgrade setuptools from 2.2 to 3.3 it seems to end up not being available when setup.py gets run for mccabe (which is just an example where we've seen it fail in the wild, but pretty20:21
dhellmannlifeless: yeah, that seems like a reasonable enhancement to me20:21
fungimuch any package which relies on setuptools functionality could be substituted to a similar result)20:21
dhellmannlifeless: perhaps this should wait until the openstack feature freeze lifts, thought20:22
mordreddhellmann: ++ OR ...20:22
*** rcarrillocruz1 has quit IRC20:22
mordreddhellmann: we release your pbr relase you want20:22
lifelessdhellmann: perhaps. OTOH I'm blocked moving some stuff to git on this, so I will whinge ;)20:22
* dhellmann is becoming better at ignoring whinging20:22
mordredthen we put lifeless change into a major version bump or something that this version of openstack won't consume and we don't bump the pins until post feature freeze20:22
dhellmannmordred: yeah, that release is a bug fix for the doc folks20:23
dhellmannmordred: do we ping our version of pbr?20:23
* dhellmann can't type20:23
mordredlifeless: I think we shoudl add a simple utility that will take a pbr version and do the filter to produce a debian version20:23
dhellmanndo we *pin* our version of pbr?20:23
lifelessmordred: I'm not sure this counts as an incompatible change :)20:23
mordreddhellmann: yes. to my knowledge20:23
fungiAlex_Gaynor: as for systems where we've seen it happen consistently, ubuntu 12.04 lts with the pypy backport ppa20:23
mordredlifeless: it does20:23
mordredlifeless: there are people currently doing version transforms on our intermediary versions to my knowledge20:24
lifelessoh20:24
jeblairjogo: to finish the thought from earlier; the 0-16 minute delay before starting check jobs is likely the time needed to spin up nodes, which means that nodepool doesn't have nodes immediately ready20:24
lifelessok, so yes it does then.20:24
jeblairjogo: that's certainly related to volume of patches20:24
jeblairjogo: but could possibly be improved by having nodepool set its threshold to "demand+min_ready" instead of "max(demand, min_ready)" which i think is what it does now20:24
mordredlifeless: which is why I'm thinking - perhaps we also make a little filter program as a present for those folks, so we can say "just use this now"20:25
jeblairjogo: that would probably need to be followed by re-tuning the min_ready values in our config20:25
mordreddguerri_: https://github.com/emonty/git-upstream20:25
jeblairjogo: but sdague's point about noop is good -- it's very silly that we are running 200+ jobs a day that do literally nothing; that should be internalized into zuul either as a special case, or a zuul-internal noop worker20:25
mordreddguerri_: I did some work to get it up to general build tooling standards20:26
jeblairjogo: and finally, we need to move from hpcloud 1.0 to hpcloud 1.1 where we will recover some quota that we have lost (at hp's request)20:26
jeblairjogo: and would actually be in a position to ask for more20:26
sdaguejeblair: https://review.openstack.org/#/c/76796 this is the swift backend to os-loganalyze patch20:26
*** adalbas has joined #openstack-infra20:26
mordreddguerri_: I'd like to chat about how we can move the upstream-tracking functionalities from jeepyb's manage-projects into this - but it's bedtime for me now - so perhaps we can chat about that tomorrow20:27
lifelessmordred: that would be nice. setup.py --debian-version ?20:27
jeblairsdague: yes!20:27
jeblairsdague: the zuul part of that is just about to go in, and jhesketh has a tool to upload logs staged20:28
sdagueI'm reading through it now, it completely breaks the progressive nature of it, so for nova-cpu we're going to pull a 20MB file from swift to apache, explode it into an array (another 20+ MB) then spoon feed it back to the client20:28
jeblairsdague: so we're very close to being able to test that20:28
mordredlifeless: or "setup.py --version | pbr debian-version-filter" - or something20:28
mordredlifeless: I'm meh on the exact vehicle if you have strong feelings20:28
sdagueany idea if there is a away to get the content from swift in a more progressive way?20:28
jeblairsdague: very good point, we definitely don't want to do that.  obj[1].split('\n') on line 316 does look :(20:29
sdagueyep20:30
*** SumitNaiksatam has quit IRC20:30
*** SumitNaiksatam has joined #openstack-infra20:31
*** lcostantino has quit IRC20:31
jeblairnotmyname: do you know if there's a way to read an object in a streaming fashion with swiftclient?  get_object looks like it grabs the entirety...20:32
*** afazekas has quit IRC20:32
notmynamejeblair: ya, give me a sec.20:33
jeblairnotmyname: oh, i'm looking at the source, it looks like in some cases, the body get_object returns might be a generator20:34
notmynamejeblair: ya, it should be. the client isn't buffering the whole object anywhere (that would be a bug)20:34
*** jnoller has quit IRC20:34
*** zns has joined #openstack-infra20:35
jeblairhttp://git.openstack.org/cgit/openstack/python-swiftclient/tree/swiftclient/client.py#n80220:35
dhellmannmordred, lifeless : I tried to summarize our conversation for the ML, please correct me if I got it wrong.20:35
jeblairnotmyname: it looks like it uses the generator if you specify resp_chunk_size, though that defaults to None20:36
notmynamejeblair: ah, yes. do that20:36
sdaguenotmyname: any chance we could specify a separator instead of a chunk size?20:37
*** dizquierdo has joined #openstack-infra20:37
notmynamesdague: how do you mean? what are you trying to do?20:37
*** julim_ has quit IRC20:37
sdaguewe're trying to make the wsgi filter which does the log formatting on logs.openstack.org be able to back to swift20:37
*** yassine has quit IRC20:38
sdagueit's currently backing to files, and we're using fileinput to make it a generator based on reading lines from files and processing them one at a time20:38
notmynamesdague: are you talking about a delimiter in the stream? or multipart mime chunks? or...20:38
sdagueso I was mostly trying to avoid having to write a line oriented generator on top of a chunk oriented generator20:39
sdaguenotmyname: the first20:39
notmynameah, so I'm guessing you want to ask the cluster for "give me the next line of the object"20:39
sdaguenotmyname: right, exactly20:39
sdaguewhich I get is a weird thing20:39
notmynameheh20:39
sdaguedepending on implementation20:39
sdaguebut figured it was worth asking before doing these generator stacks20:39
*** sandywalsh has quit IRC20:41
*** caleb_ has joined #openstack-infra20:41
*** lcostantino has joined #openstack-infra20:42
*** caleb_ has quit IRC20:42
openstackgerritA change was merged to openstack-dev/pbr: Factor run_cmd out of the base class.  https://review.openstack.org/8044720:43
rcarrillocruzbleh20:43
rcarrillocruztox 1.7 was giving me quite a bit of grief20:43
openstackgerritlifeless proposed a change to openstack-dev/pbr: Teach pbr VersionInfo about debian versions.  https://review.openstack.org/8107420:44
openstackgerritlifeless proposed a change to openstack-dev/pbr: Allow examining parsing exceptions.  https://review.openstack.org/8085620:44
openstackgerritlifeless proposed a change to openstack-dev/pbr: Permit pre-release versions with git metadata  https://review.openstack.org/8085720:44
openstackgerritlifeless proposed a change to openstack-dev/pbr: Teach pbr about post versioned dev versions.  https://review.openstack.org/8044920:44
openstackgerritlifeless proposed a change to openstack-dev/pbr: Add a converter to version_tuples.  https://review.openstack.org/8045720:44
*** harlowja is now known as harlowja_away20:44
lifelessdhellmann: looking20:45
lifelesssdague: there are lines-from-chunk generators around already; not sure if they are accessible for reuse but - pretty trivial.20:45
lifelesssdague: in fact - the io module one is definitely reusable.20:45
sdaguelifeless: yeh, it's not terrible. Just trying to avoid if possible.20:46
sdagueI did run into an issue around compressed files the last time20:46
sdaguewhich is why the current approach is written like it is20:46
*** ominakov has quit IRC20:46
sdaguejeblair: which, we should confirm, we're going to store uncompressed in swift, right?20:47
sdaguebecause otherwise this gets way more complicated20:47
notmynamesdague: if that's to be done, it would need to be done client-side, not server side. therefore it would either be in python-swiftclient or in your app that is using swiftclient20:47
notmynamesdague: in which case, it seems to make sense to have it in your app20:47
sdaguenotmyname: sure, just thought I'd ask20:47
*** jeckersb_gone is now known as jeckersb20:48
*** rossella_s has quit IRC20:49
jeblairnotmyname: what's your thinking on compression?  should we compress before sending to swift, or does swift compress internally and we shouldn't worry about it?20:49
jeblairsdague: if we do compressioun ourselves, surely we could stick an uncompress generator between the linebreak and http read ones?20:50
sdaguejeblair: so my experience is it's a lot trickier than you think20:50
sdagueI actually tried that the last time20:50
jeblairsdague: oh, hrm, what was the problem?20:51
notmynamejeblair: hang on, I gotta go check that. but I think we might have a really good story there20:51
sdagueI don't remember right now20:51
jeblairnotmyname: cool, i love good stories!20:51
sdaguethe general problem with generators on top of generators though is none of your chunks align20:51
*** signed8bit has joined #openstack-infra20:52
*** rpodolyaka1 has quit IRC20:52
jeblairsdague: yeah, but having, say, 8k of memory used because you're reading 4k chunks doesn't sound terrible20:52
*** Sukhdev has quit IRC20:52
sdaguesure20:52
sdaguethat's not really the issue20:52
*** rpodolyaka1 has joined #openstack-infra20:53
sdaguethe issue is you need natural alignment boundaries20:53
sdagueso you have to figure out if you have enough to yield to the next layer sanely, and then only pass up the boundary correctly20:53
sdaguekeep the extra, to build the next go around20:53
dhellmannmordred: so you think it's safe to release pbr 0.7?20:54
*** sandywalsh has joined #openstack-infra20:54
jeblairsdague: hrm, i don't look at it that way; i look at it as "the linebreak generator reads from the uncompress generator until it hits a newline and retains the extra for the next iteration"20:54
*** dizquierdo has quit IRC20:55
jeblairsdague: and so forth down the stack20:55
sdaguejeblair: sure20:55
sdagueexcept uncompress generators are tricky20:55
*** dizquierdo has joined #openstack-infra20:55
*** sarob_ has quit IRC20:55
sdaguemaybe someone else will have better luck this time around20:56
sdagueI hit some real issues on that last time, and the basic answer was "don't do that in python"20:56
jeblairsdague: true, in that they output, in our case, 10x more than they are given in input, so it's much more than the 2x waste of ram i cited earlier, but it still seems to be sane overall20:56
clarkbya thats why gearman log worker loads into memory20:56
*** thuc_ has quit IRC20:56
mattoliverauMorning all20:57
clarkbincremental inflate is tricky with existing python zip tools best I could tell20:57
*** thuc has joined #openstack-infra20:57
sdagueI'm almost 100% sure the fileinput compressed filter is implemented in native code20:57
*** rpodolyaka1 has quit IRC20:57
mordreddhellmann: do you think it's a major ersion bump?20:57
*** ominakov has joined #openstack-infra20:57
jeblairsdague: okay, let's see what notmyname says is the best approach, and ask jhesketh to look into that; i'm sure he'll dig into the problem20:57
sdagueclarkb: yeh, that was my findings. Basically all the other approaches assumed you just loaded into memory20:57
mordreddhellmann: "major"20:58
notmynamejeblair: still looking20:58
dhellmannmordred: python version support changes; reporting output of some commands change; requirements are updated20:58
jeblairsdague: main thing is, i think we probably want this stuff compressed somehow, because "hey rax, can we have a petabyte to store logfiles uncompressed" isn't a question i'm looking forward to asking.  :)20:58
mordreddhellmann: lemme look20:58
*** mfer has quit IRC20:59
*** jlibosva has joined #openstack-infra20:59
dhellmannmordred: http://paste.openstack.org/show/73693/20:59
sdaguejeblair: heh20:59
dhellmannjeblair: do they need to be on rax? I don't have compute to offer yet, but could come up with some storage21:00
sdaguedhellmann: a petabyte?21:00
lifelessmordred: btw - debian version stuff in gerrit now21:00
mordredlifeless: ossum21:00
sdaguewell, in fairness, it would probably only be about 30 TB / 6 months21:00
*** afazekas has joined #openstack-infra21:00
*** jlibosva has quit IRC21:00
lifelesssince dhellmann is on board21:00
lifelessI'm going to polish up the branch, make sure it supports a/b/rc versions etc21:01
dhellmannlifeless: is there a blueprint for that work?21:01
* dhellmann puts on PTL hat21:01
jeblairsdague: we're currently using 9.4TB -- so assuming 90% compression, that's close to 100TB / 6 months21:01
lifelessdhellmann: FIIK21:01
* dhellmann isn't sure if he wants to google that acronym21:01
*** rossella_s has joined #openstack-infra21:01
lifelessdhellmann: there's an etherpad. I can create tracking paperwork if you want21:01
*** thuc has quit IRC21:01
lifelessdhellmann: swearword If I Know21:02
jeblairdhellmann: that's a really good point.  we've mostly been focused on getting this working on one provider, but we really should see if we can distribute it out across multiple swift clusters21:02
dhellmannlifeless: it's ok for this cycle, but I think next cycle we're going to start keeping better records21:02
*** pdmars has quit IRC21:02
lifelessdhellmann: I still totally fail to see the value in blueprints here, they are terrible for discoverability, accessability, and usability.21:02
dhellmannlifeless: by "here" do you  mean pbr or at all?21:03
mordreddhellmann: I'm still not sure, looking at the diff, that the major needs bumped. BUT - I'm also not strongly opinioned21:03
mordreddhellmann: so - I defer to your judgement21:03
lifelessdhellmann: I think they have value in the at-scale parts of openstack21:03
dhellmannmordred: sdague scolded me the last time I didn't bump the major version with a requirements change21:03
lifelessdhellmann: but things with 5 contributors....21:03
mordreddhellmann: although if you do want to 0.7 - could you semver it at 0.7.0 ish/21:04
dhellmannlifeless: pbr is part of oslo, and I'd like to just have one way I track stuff for release planning21:04
dhellmannmordred: ok21:04
lifelessdhellmann: if you want one, I'll give you one.21:04
lifelessdhellmann: wearing my PTL hat, I just find them annoying :)21:04
dguerri_mordred: ack21:05
dhellmannsdague: DreamObjects has just over 2 petabytes available, but you can't have all of that for free :-)21:05
*** ominakov has quit IRC21:05
dhellmannlifeless: yeah, I get it, the tool isn't great, but it beats keeping little slips of paper on my desk to remind me which changes actually need to be reviewed :-)21:05
*** yolanda has quit IRC21:06
lifelessdhellmann: so, you'd like one?21:06
*** e0ne has quit IRC21:06
dhellmannlifeless: not this time around, but like I said, during juno I think I'm going to start requiring them more21:06
dhellmannassuming it's up to me, of course21:06
*** e0ne has joined #openstack-infra21:07
lifelessdhellmann: FWIW I use gerrit to tell me what I need to review :)21:07
*** ominakov has joined #openstack-infra21:07
*** afazekas has quit IRC21:07
dhellmannlifeless: I have not had as much luck with that lately; scale of number of repos changed this cycle21:07
dguerri_mordred: I also have a couple of new commits, I will push them to your repo tomorrow21:08
dhellmannand that's only going to get worse in juno21:08
dhellmannjeblair, sdague : email me some details about volume for these logs and I'll see if I can hook you up with an account21:08
*** dguerri_ is now known as dguerri21:08
*** rcarrillocruz1 has joined #openstack-infra21:09
*** caleb_ has joined #openstack-infra21:09
notmynamejeblair: ah, found what I was looking for21:10
*** caleb_ has quit IRC21:10
dhellmannlifeless: reviewing open pull requests, I saw https://review.openstack.org/#/c/73737/ -- is that going to interfere with what you're doing?21:10
dhellmannlifeless: nevermind, that's parsing requirements input files not dealing with the version number generation21:10
*** e0ne has quit IRC21:10
lifelessyeah21:11
notmynamejeblair: so 3 years ago (almost to the day!) I was involved in getting a new feature out for cloud files. but unfortunately it was just for the CDN, not for swift itself. basically, it allows stuff to honor the "Accept-Encoding: gzip" request header21:11
jogojeblair: ahh, I am a litte shocked at how long it takes to spin up a node21:11
*** hashar is now known as hasharMeeting21:11
notmynamejeblair: http://www.rackspace.com/blog/cloud-files-cdn-compresses-at-the-edge/ is the CDN thing, and no, it isn't supported in requests directly to swift (but it would be a cool feature!!)21:11
dhellmannmordred: I'm going to wait until tomorrow morning to push the 0.7.0 tag, so I don't break things and then sign off for the night21:11
*** rcarrillocruz has quit IRC21:12
jogojeblair: how much of that is openstack21:12
lifelessdhellmann: https://blueprints.launchpad.net/pbr21:12
lifelessdhellmann: is not configured21:12
dhellmannlifeless: :-|21:12
dhellmannlifeless: fixed21:12
sdaguedhellmann: instead of using a million lps, why not use one?21:13
sdaguelike infra does21:13
dhellmannsdague: yeah, I'm not creating any new ones21:13
jogojeblair: and lastly what can I do to help.21:13
dhellmannI guess we could put the pbr blueprints in the oslo project21:13
dhellmannlifeless: yeah, I'm going to do that, deconfigure it and add a note about using the oslo tracker instead21:14
clarkbgah what did we do to logstash21:14
lifelessdhellmann: doh21:14
lifelessdhellmann: I was just about to create first-post-better-untagged-versions as the blueprint21:14
dhellmannlifeless: have you done it yet?21:14
dhellmannI can just move it21:14
*** ominakov has quit IRC21:15
lifelessdhellmann: I haven't21:15
*** e0ne has joined #openstack-infra21:15
lifelessdhellmann: and it wouldn't be as funny in a group :)21:15
dhellmannlifeless: heh21:15
*** rwsu has quit IRC21:16
lifelessdhellmann: sdague: BTW LP has a very strong one-codebase-one-project model - e.g. you cannot have multiple tasks within a single project21:16
lifelesswhat infra does isn't something to copy (for bugs) - blueprints I don't care about ;>21:16
lifelesstripleo does just one place for blueprints21:16
*** dkranz has quit IRC21:17
dhellmannwe already have separate projects for oslo.messaging and pbr, but I was going to use the oslo project for all the new libs we make next cycle21:17
dhellmannand then use tags on bugs and blueprints to make it easier to filter stuff21:17
openstackgerritA change was merged to openstack-infra/config: Save md5 and sha1 checksums with artifacts  https://review.openstack.org/7693321:17
Ajaeger1clarkb, fungi - I would really appreciate if tomorrow's periodic job includes the fixed propose-translation-update jobs - could you please put https://review.openstack.org/#/c/81037/ on your list?21:17
clarkbAjaeger1: did you catch where fungi thought we would need a g-g-p patch to make that work?21:18
*** ominakov has joined #openstack-infra21:18
clarkbAjaeger1: the other jobs use the scm plugin21:18
Ajaeger1clarkb: I've updated the patch to use gerrit-git-prep21:19
clarkbAjaeger1: right I think fungi discovered g-g-p won't work today21:20
Ajaeger1do I just need to wait another day - or change something?21:20
jeblairjogo: all of it is openstack (we spin up from custom images; i gather that could make things a little slower); hpcloud 1.0 is faster than rax, i don't have as good of an idea about hpcloud 1.1.21:20
*** ominakov has quit IRC21:20
fungiclarkb: did you have any input on whether or not i should just make ggp support that so we can ditch the scm plugin?21:20
jogojeblair: once we are on hpcloud 1.1 we should revisit what is slow in openstack. because at that point we will be running trunk21:21
clarkbfungi: I think we will need that eventually, but that takes at least a day for new images (typically)21:21
clarkbfungi: probably easier to add scm plugin to oen job now then g-g-p all other jobs later21:21
jogoand can fix things upstream and get it in CI in a few weeks21:21
jogojeblair: silly question -- where are nodepool unit tests21:21
fungiclarkb: basically make the slave script for it allow for a missing zuul ref and assume head of the default branch?21:22
Ajaeger1Argh, missed fungi's latest comment on the other translation jobs. Let me double check what else I missed ;(21:22
jogojeblair: min_demand = start_demand + total_image_min_ready[image_name]21:22
*** esker has quit IRC21:22
clarkbfungi: yeah thats what I am thinking. if -z ZUUL_REF (or whatever the appopriate ZUUL_* is) then git checkout remotes/origin/HEAD21:22
fungiAjaeger1: basically you added the scm plugin because you copied it from the other translation proposal job, which was working because as it turns out gerrit-git-prep assumes it will have a zuul ref and periodic jobs don't21:22
*** rpodolyaka1 has joined #openstack-infra21:23
openstackgerritSergey Lukjanov proposed a change to openstack/requirements: Add saharaclient to global requirements  https://review.openstack.org/8108321:23
openstackgerritSergey Lukjanov proposed a change to openstack/requirements: Remove python-savannaclient from globalr req  https://review.openstack.org/8108421:23
fungiAjaeger1: so just repropose your patch like you had in the previous patchset and i'll stack a wip change on top of that which makes ggp do what we want and removes/replaces all instances of the scm plugin21:23
Ajaeger1fungi: so, I should send the previous patch again that included both ggp and scm plugin?21:24
jeblairjogo: probably.  testing nodepool involves running the steps in README; it doesn't have a test suite.  I would love it if it had a functional test suite (i'm generally more excited about that than unit tests per se)21:24
clarkbAjaeger1: no remove ggp21:24
Ajaeger1Ok, will do. Thanks21:24
dstufftmordred: soooo21:24
dstufftI had an idea21:24
jeblairjogo: (the faked out stuff described in the readme might make a good start for a functional test suite)21:25
dstufftto prevent setuptools from every touching the network even if someone isn't using pip (in a pip 1.6+ world at least :V)21:25
openstackgerritSergey Lukjanov proposed a change to openstack-infra/reviewstats: Rename Savanna to Sahara  https://review.openstack.org/8108621:25
openstackgerritSergey Lukjanov proposed a change to openstack-infra/reviewstats: Add alazarev to sahara-core  https://review.openstack.org/8108721:25
lifelessdhellmann: https://blueprints.launchpad.net/oslo/+spec/better-untagged-versions21:26
openstackgerritAndreas Jaeger proposed a change to openstack-infra/config: Fix periodic manuals-propose-translation-update jobs  https://review.openstack.org/8103721:26
dhellmannlifeless: thanks21:26
Ajaeger1fungi, clarkb: like this?21:26
fungiAjaeger1: yep. lgtm21:27
Ajaeger1Uff, great21:27
*** thomasbiege has quit IRC21:27
*** alff has quit IRC21:27
jeblairfungi, clarkb: deleting leaked tripleo keypairs (we're at quota)21:27
clarkbAjaeger1: do the docs have a {gitbub-org} var?21:27
*** rpodolyaka1 has quit IRC21:27
clarkbmight be good to use that for more flexibility but I don't think it is strictly required here21:27
Ajaeger1clarkb: All use openstack21:27
*** thuc has joined #openstack-infra21:27
SergeyLukjanovfungi, clarkb, jeblair, mordred, sdague, could you please take a look at https://review.openstack.org/81083 (sahara client addition to the global requirements)21:28
openstackgerritJoe Gordon proposed a change to openstack-infra/nodepool: Raise min_demand due to slow node boot times  https://review.openstack.org/8108821:28
fungiAjaeger1: in jenkins_jobs/config/projects.yaml21:28
Ajaeger1clarkb: then I would need to double check that it's set correctly; ) let me check projects.yaml...21:28
sdagueSergeyLukjanov: so until the pypy thing is resolved, it's sort of pointless21:28
dhellmannlifeless: I marked that as a juno item, but I see in your ML thread you want it for icehouse. How much disruption do you expect that to cause?21:28
Ajaeger1yeah, is set correctly21:29
* Ajaeger1 changes21:29
openstackgerritAndreas Jaeger proposed a change to openstack-infra/config: Fix periodic manuals-propose-translation-update jobs  https://review.openstack.org/8103721:29
Ajaeger1here it comes again...21:29
SergeyLukjanovsdague, oh...21:29
SergeyLukjanovsdague, reading scrollback21:29
*** rfolco has quit IRC21:29
clarkbsomething changed around 20:15 to make all of our logstash worker output graphs look like http://cacti.openstack.org/cacti/graph.php?action=view&local_graph_id=1365&rra_id=all21:30
clarkband that is about when the gearman queue graph takes off21:31
*** rwsu has joined #openstack-infra21:31
clarkbbut I don't see anything that is a blatant culprit. any ideas?21:32
Ajaeger1fungi, clarkb: Thanks for all your help! I'm signing off now. If I should do more changes, just comment on the patch and I'll fix tomorrow.21:32
lifelessdhellmann: it only affects untagged versions, not tagged versions21:32
clarkbsdague: we didn't do anything like the libvirt crazy logging again did we?21:32
* clarkb checks worker node21:32
lifelessdhellmann: and the versions it will produce are all strictly greater than the current behaviour21:33
sdagueclarkb: not that I know of21:33
lifelessdhellmann: so I expect the fallout to concentrate on folk that are consuming untagged versions and casting them into e.g. debian package versions21:33
dhellmannlifeless: so this won't change alpha versions, for example?21:33
dhellmannlifeless: hmm, ok, so me then :-)21:33
*** Ajaeger1 has quit IRC21:33
dhellmannoh, no, we don't use the version info from the package, we make our own version numbers, so not me21:34
dstufftlifeless: doesn't it make the version number 0aN instead of aN21:34
dstufftfir alphas21:34
dstufftto be PEP440 compliant21:34
lifelessdhellmann: if you tag a version, the tag will always be obeyed21:35
dhellmannlifeless: ok21:35
*** beekneemech is now known as bnemec21:36
clarkbsdague: is nova cond logs usually >6MB compressed?21:36
*** thuc has quit IRC21:36
sdagueI think it got more gorpy after oslo.messaging sync21:36
lifelessdhellmann: dstufft: yes, part of the proposal is to change how we label alphas21:37
lifelessdhellmann: so 1.3.0a1 isn't valid PEP44021:37
clarkbsdague: or is this os-loganalyze being slow? /me isn't finding the bottleneck in the pipelines yet21:37
clarkbES is happy21:37
lifelessdhellmann: but that is a tagged release. The proposal is to use 1.3.0.0a1 to tag such a release in future.21:38
sdagueclarkb: it shouldn't be unless the log server is overloaded21:38
sdagueis there a cacti graph on that?21:38
lifelessdhellmann: (and to issue new tags for all our current pre-releases to make them PEP440 compliant, but that should happen *before* the changes go into pbr21:38
sdaguealso, conductor is huge, however it's all debug21:38
jeblairsdague: http://cacti.openstack.org/cacti/graph_view.php?action=tree&tree_id=121:38
dhellmannlifeless: but we'd have to do that by hand? you're not going to add, for example, the ability to say "python setup.py tag-alpha" and have it compute that tag automatically?21:38
sdagueI think there are 40 non debug lines in it21:38
vishydhellmann: ping21:38
clarkbhttp://cacti.openstack.org/cacti/graph.php?action=view&local_graph_id=311&rra_id=all seems to be happy21:38
jeblairsdague: http://cacti.openstack.org/cacti/graph_view.php?action=tree&tree_id=1&leaf_id=1321:38
*** changbl has joined #openstack-infra21:38
lifelessdhellmann: that would be a logical further extension21:39
jogojeblair: put up a nodepool patch.  as for the functional testing thing.  as for the functional test idea I can look into it later today, but have a few questions first when you have a few minutes (no rush)21:39
lifelessdhellmann: and I have some prototype code for deciding when to do major/minor/point changes as well21:39
*** gordc has left #openstack-infra21:39
jeblairjogo: did we lose gerritbot again?21:39
lifelessbut thats future21:39
vishydhellmann: trying to figure out if there is an ubuntu package for the oslo.sphinx rename21:40
fungiopenstackgerrit is here21:40
vishyit has http://mirrors.kernel.org/ubuntu/pool/main/o/oslo-sphinx/python-oslo.sphinx_1.1-0ubuntu2_all.deb21:40
dhellmannlifeless: ok -- I think I'm ok with making this part of 0.8 if we're careful with the pins in the stable branches21:40
vishydo you know if that will be updated to the new stuff? or does it need a new package to work?21:40
dhellmannvishy: yeah, sorry about that -- it should be "oslosphinx" everywhere now21:40
jogojeblair: I saw the notifcation pop up but this channel is pretty active today21:40
kevinbentonwho runs stackalytics.com?21:41
dhellmannvishy: I don't know if they have created a package with the new name21:41
fungidhellmann: the debian/ubuntu package maintainer should hopefully switch to the new package name and leave a dummy transitional package at the old name to accommodate that21:41
vishyadam_g: ping ^^21:41
fungikevinbenton: i believe that's a mirantis internal project21:41
vishyzul: ^^21:41
jeblairjogo: ok, thx21:42
kevinbentonfungi: ok, thx21:42
SergeyLukjanovfungi, kevinbenton, yup, sources located at stackforge21:42
jeblairkevinbenton: http://git.openstack.org/cgit/stackforge/stackalytics/21:42
fungikevinbenton: hopefully they put some contact info on the site?21:42
dhellmannvishy, zul, adam_g : that package definitely has the old version of the lib21:42
fungioh, totally forgot that ended up in stackforge21:42
*** smarcet has quit IRC21:43
kevinbentonfungi: yeah, that was the part that threw me off21:43
sdagueclarkb: nothing I can see21:43
dhellmannfungi: thanks21:43
jogojeblair: so  two questions about testing nodepool21:43
jogo1) would it work with sqllite?21:43
sdagueclarkb: we didn't accidentally lose filtering by debug from gearman did we?21:44
clarkbsdague: I don't think so21:44
jogo2)  where does the load for nodepool come from (the data to test it out)21:44
clarkbreading the logs it is still pulling with ?level=INFO21:44
sdaguethe console logs are bigger again, because we're dumping errors there, but they are no bigger than they used to be (still smaller from when devstack output was in them)21:44
clarkbsdague: but we are indexing devstack too? is there a significant different between the combined size?21:45
sdagueactually not21:45
sdagueas I put the devstack logs on diet21:45
devanandaone more review for ironic's CI support - https://review.openstack.org/#/c/80652/221:45
jeblairjogo: 1) unlikely -- sqlite deals very poorly with the massive threading nodepool does; we basically had to move production from sqlite to mysql because of that, so tests are probably likely to run into the same problem21:46
*** ominakov has joined #openstack-infra21:46
jeblair2) the fake-servers.py script in tools has some basic stuff to generate load; it lets you tell nodepool that a job is finished, or that gearman has a huge demand for a certain job21:46
sdagueclarkb: any way to figure out what files things die on?21:46
lifelessmordred: sound ok to you?21:46
jeblairjogo: ^ it's _very_ rudimentary, but it does exercise all the bits21:47
jogojeblair: too bad because sqllite would make things very self contained.21:47
*** ominakov has quit IRC21:47
jogoI was thinking of setting something up like this http://git.openstack.org/cgit/openstack-infra/elastic-recheck/tree/tox.ini#n2721:47
jogowhere you just run a tox env21:47
sdaguejogo: you can mostly do that in mysql, with only minor setup21:48
clarkbsdague: I don't think it is dying on stuff21:48
sdaguewe do that for the opportunistic tests in nova21:48
jeblairjogo: yeah; though we have the openstack_citest mysql db on the slaves.  i wouldn't mind having that locally21:48
clarkbsdague: everything seems to be moving, just more slowly21:48
sdagueclarkb: that rise is pretty crazy21:48
*** dcramer_ has quit IRC21:48
sdaguejogo: or the way the migrate project does real db testing21:48
clarkbwhich is why I was curious about upstream stuff (like file sizes and os-loganalyze)21:48
jogosdague: right, just thought sqllite would make it very self contained21:48
jeblairjogo, sdague, clarkb: this always reminds me of the "use drizzle in unit tests idea" because drizzle is mysql compatible and completely self-contained (eg, can run in a throwaway tmpdir)21:48
clarkbjeblair: except for the places where it isn't quite compatible :)21:49
jogojeblair: yeah just waiting for mordred to do it ;)21:49
sdaguejeblair: sure, but the setup for a development mysql is all of 30 seconds, once21:49
clarkbbut it speaks the protocol21:49
sdagueas long as you are on a reasonable os :)21:49
jogoanyway I will play around with this a little later tonight ... overall it looks like getting a rudamentry *mostly* automated test is fairly straight forward21:50
jeblairsdague: in general, i agree, and lacking something like this, expecting a dev to have a mysql they can use is not a high bar.  but re drizzle, i believe the thinking is that the unit tests could set up drizzle to run in a tmpdir, so no config required, plus is more secure on a workstation.21:50
*** MarkAtwood has joined #openstack-infra21:51
*** mattymo has quit IRC21:51
clarkbjeblair: sdague: and we could do stuff like not have crazy perms on test slaves for mysql21:51
*** mattymo has joined #openstack-infra21:51
jeblairjogo: cool, thanks!21:52
sdagueclarkb: so are you trying to get to the bottom of the indexing issue?21:52
clarkbsdague: I am definitely poking at it, but need to afk shortly to go back to seattle21:53
clarkbthe airlock on the fermentor is bubbling my work here is done >_>21:53
sdaguethat giant leap, and then flatline, is really suspicious21:54
*** rcarrillocruz has joined #openstack-infra21:54
clarkbthe watchdog for logstash processes didn't trip at 20:15 so I don't think ES/logstash themselves are to blame21:54
*** sarob has joined #openstack-infra21:56
sdaguedid they suffer a network issue - http://cacti.openstack.org/cacti/graph_view.php?action=tree&tree_id=1&leaf_id=11121:56
sdagueit looks like their throughput dropped to almost nothing21:56
clarkbI am digging into the indexer logs now21:56
*** afazekas has joined #openstack-infra21:56
clarkbsdague: right in which case the watchdog should'ev tripped21:56
*** rcarrillocruz1 has quit IRC21:56
clarkbI think throughput dropped to nothing because they weren't doing work21:56
sdagueclarkb: that looks like of like a classic slowstart curve on the upside of eth021:57
sdagueI wonder if rax network just went to crap21:57
clarkbsdague: you may be right, the are massive gaps in log timestamps indicating they weren't pulling jobs off the queue21:58
*** CaptTofu has joined #openstack-infra21:58
clarkbsdague: http://paste.openstack.org/show/73700/22:00
clarkbsdague: whcih seems to fit your theory22:00
clarkbit took 25 minutes to deal with that one file22:00
clarkband the trend is much better now22:01
*** e0ne has quit IRC22:02
zulvishy:  not yet22:03
*** jamielennox|away is now known as jamielennox22:03
vishyzul: when you do it will the package be renamed to python-oslosphinx?22:03
*** david-lyle has quit IRC22:04
zulvishy:  this week probably22:04
*** rossella_s has quit IRC22:05
zulvishy:  i was on vacation last week :P22:05
*** wchrisj has quit IRC22:05
*** jhesketh_ has joined #openstack-infra22:06
vishyzul: also we need a new version python-pbr as well it appears22:06
jhesketh_Morning22:07
zulvishy:  yep will do it this week22:07
*** lcostantino has quit IRC22:08
*** thedodd has quit IRC22:08
*** thuc has joined #openstack-infra22:10
*** adalbas has quit IRC22:10
*** thuc_ has joined #openstack-infra22:12
*** nibalizer has joined #openstack-infra22:12
*** thuc has quit IRC22:15
clarkbthe logstash queue is falling, must've been a network thing22:16
clarkbI think I am going to take this as an opportunity to begin the drive back to seattle. Back in about 3-4 hours to hopefully review more code22:16
jeblairjhesketh_: good morning; there was some talk about os-loganalyze and swift.  most of it is in the review...22:17
*** harlowja_away is now known as harlowja22:17
*** ryanpetrello has quit IRC22:17
jhesketh_oh cheers jeblair, I'll take a look22:17
fungiclarkb: drive safe. btw i came up with another distasteful workaround to the pypy testing issue... http://paste.openstack.org/show/73701/22:17
jeblairjhesketh_, sdague: we did have a mostly unfinished conversation about compression; and my take on what we heard from notmyname is that we should compress before sending to swift and decompress in os-loganalyze.22:17
clarkbfungi: nice!22:18
jeblairsdague and clarkb say that's very difficult/impossible in python (in a chunky manner, say, using a generator)22:18
clarkbfungi: we should hit approve on those changes then chase that with some whiskey >_>22:18
notmynamejeblair: I've got to make a phone call, but I'll be back in a bit22:18
jeblairjhesketh_: though i think finding a way to do it is worthwhile22:18
*** afazekas has quit IRC22:19
clarkbalso if anyone makes it to portland in about 3 weeks I should have 5 gallons of homebrew in a keg >_>22:19
jeblairnotmyname: cool, thanks for your help.  i think we want to avoid requiring the rax cdn, so it sounds like we need to compress at the app level (or submit a change to add that to swift itself)22:19
openstackgerritA change was merged to openstack-infra/config: Add direct-release for meetbot and nose-html-output  https://review.openstack.org/7933022:19
*** aysyd has quit IRC22:19
sdaguejhesketh_: so that will be the trick of it22:20
*** rcleere has quit IRC22:20
sdaguejhesketh_: https://github.com/openstack-infra/os-loganalyze/blob/master/os_loganalyze/wsgi.py#L212-L225 basically means that if we are file backed, we only have 1 line of the file in memory at a time22:20
sdagueso something equiv has to be done if we are swift backed22:21
jhesketh_sure, okay22:21
jhesketh_I had admittedly thought about that when I wrote it, but figured as a starting point it was less important and wanted to get a proof of concept up22:22
*** yamahata has quit IRC22:22
jhesketh_that said, I'm happy to reroll that today22:22
openstackgerritA change was merged to openstack-infra/config: Fix periodic manuals-propose-translation-update jobs  https://review.openstack.org/8103722:22
sdagueit's probably worth making a test case for this as well which we could stand up on a devstack node easily enough, to actually test it working with swift22:23
*** thuc_ has quit IRC22:24
*** adalbas has joined #openstack-infra22:24
*** rpodolyaka1 has joined #openstack-infra22:24
*** thuc has joined #openstack-infra22:24
sdagueand if anyone is interested in reviewing some incremental improvements in UI - https://review.openstack.org/#/q/status:open+project:openstack-infra/os-loganalyze+branch:master+topic:onclick_inline,n,z22:24
sdagueI was hacking some this weekend22:24
*** yamahata has joined #openstack-infra22:25
openstackgerritA change was merged to openstack-infra/zuul: Add more logging to zuul merger process  https://review.openstack.org/7938522:26
openstackgerritA change was merged to openstack-infra/config: Remove logging of sahara projects to #savanna  https://review.openstack.org/7954522:27
*** rcarrillocruz1 has joined #openstack-infra22:28
*** rpodolyaka1 has quit IRC22:28
*** fifieldt has joined #openstack-infra22:29
jeblairnibalizer, mattoliverau: is it possible to disable the ec2 facter plugin in puppet?22:29
*** rcarrillocruz has quit IRC22:29
jeblairnibalizer, mattoliverau: it's timing out a lot on one of our providers (who is currently having problems with their metadata server)22:29
vishyany idea what this is? /usr/share/openstack-pkg-tools/pkgos.make22:29
jeblairnibalizer, mattoliverau: and i'm pretty sure we don't actually use any facts from it22:30
*** e0ne has joined #openstack-infra22:30
jeblairclarkb: btw, any word on that ticket?22:30
openstackgerritMichael Krotscheck proposed a change to openstack-infra/storyboard-webclient: Added user preference handling  https://review.openstack.org/8110022:30
*** mriedem has quit IRC22:32
clarkbjeblair: nope nothing yet22:32
nibalizerjeblair: i don't know how to disable facts22:32
nibalizerim not sure if you can22:32
*** asalkeld has joined #openstack-infra22:36
asalkeldhi, should we be temporarily disabling pypy until https://code.launchpad.net/bugs/1290562 is fixed?22:37
*** adrian_otto has joined #openstack-infra22:37
fungiasalkeld: quite possibly. Alex_Gaynor: did you get a chance to reproduce that yet?22:38
asalkeldyeah, I can't get anythink though22:38
asalkeldanything22:38
asalkeldthey all fail22:38
fungiasalkeld: for projects which want to test pypy compliance, one fairly trivial way is to patch your tox.ini for now to do http://paste.openstack.org/show/73701/22:38
*** e0ne has quit IRC22:38
fifieldtmorning all22:39
jeblairfifieldt: good morning!22:39
jeblairfifieldt: have you registered your nick with nickserv?  if not, you should do that22:39
fungiasalkeld: for reasons as of yet unidentified, pip is able to upgrade setuptools to 3.1 safely but if it tries to go any higher, that's when we hit this bug22:39
*** openstackgerrit has quit IRC22:39
asalkeldok22:39
fifieldtjeblair, indeed I should - thanks for the reminder22:40
*** openstackgerrit has joined #openstack-infra22:40
jeblairfifieldt: let me know once you're done, and i'll add you to the list of irc ops for all of our channels (54+)22:41
fifieldtooh22:41
fifieldtnow there's a carrot :)22:41
jeblairfifieldt: heh, i'm not sure if that particular carrot is delicious or poisoned.  ;)22:42
notmynamejeblair: correct22:43
fifieldtmmmm poison carrot22:43
fungijeblair: fifieldt: it's a carrot which is only poisonous during apac daytime hours22:43
fifieldtmmm variably poisonous carrot22:44
fifieldtI think I'm identified onw22:44
fungiand temporally variable at that22:44
fifieldtnow*22:44
*** hasharMeeting has quit IRC22:44
fifieldthttps://review.openstack.org/#/q/reviewer:welcome-message,n,z <-- does my gerrit query syntax look OK there ? I feel like I got it right, because it didn't pop up an error message (though there are no reviews) :)22:45
*** asalkeld has left #openstack-infra22:45
jeblairfifieldt: cool, i'll add you to the list in a bit (may be a couple days for the changes to make it through review)22:45
fungififieldt: i'll try to do a correlation from the log22:46
openstackgerritSean Dague proposed a change to openstack/requirements: workaround pypy in requirements  https://review.openstack.org/8110322:46
fifieldtcheers jeblair22:46
sdaguefungi: given that saraha is blocking on that one, it's probably worth taking in22:47
sdagueit didn't seem like anyone else had yet proposed it22:47
jeblairclarkb: i've got the dns stuff in a good enough order that we are now failing on the unbound+ubuntu+dnssec+puppet bug in hpcloud.  i'll try your suggested workaround.22:48
fungisdague: thanks--let's see if it passes22:48
*** _nadya_ has joined #openstack-infra22:49
*** andreaf has quit IRC22:50
*** michchap has joined #openstack-infra22:50
nibalizerjeblair: is the fact comming from our code, can we just comment it out?22:50
*** markmcclain has quit IRC22:51
mattoliveraujeblair: looks like thre are feature requests in to add the funtionality to disable facts but you can't in code. Looking at the ruby code, there is a Facter.add so you can add custom facts but no delete/remove function. That being said if you want to do a dodgy, it looks like ec2 facter plugin is: /usr/lib/ruby/vendor_ruby/factor/ec2.rb which also includes vendor_ruby/factor/util/ec2.rb.22:51
mattoliveraunibalizer jeblair looks like it's built in to factor (a factor plugin included in the puppet package).22:51
*** ominakov has joined #openstack-infra22:52
nibalizeroh ew22:52
openstackgerritA change was merged to openstack-infra/config: Add docs gate for Marconi  https://review.openstack.org/8047922:52
mattoliverauSo I'm guessing we *could* use Factor.add in puppet to potentically override it in the factor collection, or do the dodgy and remove/move it from the source and hope nothing breaks :P22:53
*** michchap_ has quit IRC22:53
*** _nadya_ has quit IRC22:53
nibalizerwhats the facter version?22:54
mattoliverauBut I haven't done it before, so don't know if it breaks things.. it'll need to be tested on a test environment. Here is some examples of add custom http://is.gd/ybr6gh I wonder if you can use it to override as well, as it seems Factor is just treated as a collection (map/dict) in ruby.22:57
*** mbacchi has quit IRC22:57
nibalizerso the problem is what? facter just hangs waiting for a response from the amazon api?22:58
mattoliverauI can't get onto the infra servers, but I do have a puppet master in my test environment build with the infra build scripts, and there version of facter I have is 1.7.422:59
jeblairso looking at ec2.rb, i'm wondering why it's even trying...23:03
jeblairi don't see the arp table entry or the mac addr it's looking for23:03
jeblairthough i have no idea why the arp table entry _isn't_ there, since there actually is a host at 169.254.169.254...23:03
*** caleb_ has joined #openstack-infra23:04
jeblair(even after i telnet to it's port 80)23:04
jeblairperhaps it sends gratuitous arps at boot or something and they are gone now...23:04
*** blamar has quit IRC23:07
mattoliverauyeah maybe23:09
*** jhesketh_ has quit IRC23:09
openstackgerritDevananda van der Veen proposed a change to openstack-infra/config: Fix the virtual-ironic job's export list  https://review.openstack.org/8065223:13
*** blamar has joined #openstack-infra23:13
*** ryanpetrello has joined #openstack-infra23:13
arosenHi, I saw this bug report: https://github.com/openstack/tripleo-incubator and was wondering if anyone could tell me where this is exactly happening. I don't see any tripleo support in devstack23:14
arosennor do i see this configuration being done in the tripleo-incubator repo23:14
arosenhttps://bugs.launchpad.net/tripleo/+bug/1293782 whoops this bug report<----23:14
openstackgerritJames E. Blair proposed a change to openstack-infra/config: Use unbound  https://review.openstack.org/8009223:15
arosennvm i think i found it.23:17
*** dhellmann has quit IRC23:18
*** yamahata has quit IRC23:18
openstackgerritA change was merged to openstack-infra/config: Removing non-voting for gate-barbican-devstack-dsvm  https://review.openstack.org/8068623:20
*** 23LAAV2X6 has joined #openstack-infra23:21
*** jhesketh_ has joined #openstack-infra23:21
*** dhellmann has joined #openstack-infra23:23
*** dims has quit IRC23:24
zarofungi: can we fast track these? https://review.openstack.org/#/q/status:open+project:openstack-infra/gerrit+branch:openstack/2.8.3,n,z23:24
*** rpodolyaka1 has joined #openstack-infra23:24
*** HenryG has quit IRC23:25
zarofungi: those are the same changes that merged into openstack/2.8 branch23:25
fungizaro: those are the reproposals of the patches which were on the 2.8 branch?23:25
fungiright. approving if tests pass23:25
fungiand seems they do23:25
jeblairoh i'm just approving23:25
*** MarkAtwood has quit IRC23:26
zarothanks.23:26
fungiyeah, jeblair got all of them except 81061, which i just approved23:27
openstackgerritJames E. Blair proposed a change to openstack-infra/config: Use unbound  https://review.openstack.org/8009223:27
*** ominakov has quit IRC23:28
*** rpodolyaka1 has quit IRC23:29
*** thuc has quit IRC23:29
*** thuc has joined #openstack-infra23:30
*** ryanpetrello has quit IRC23:30
*** thuc_ has joined #openstack-infra23:31
arosenHi, I was wondering if anyone here could give me any insight on how: check-tripleo-overcloud-precise setup works. I'm trying to fix that gate which was broken by the event stuff in neutron.23:33
arosenI need to add a few things to the neutron.conf it's using.23:33
arosenSeems like it's using devstack-gate but I don't see any tripleo stuff in there.23:34
*** thuc has quit IRC23:34
jeblairsdague: when you have a sec: https://review.openstack.org/#/c/80727/23:35
*** reed has quit IRC23:37
jeblairarosen: you can find the job definition here: http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/jenkins_job_builder/config/tripleo.yaml#n8023:37
*** rhsu has quit IRC23:37
arosenjeblair:  thanks for the pointer. I'll check it out.23:38
jeblairarosen: in turn, that should lead you here: http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/toci_gate_test.sh23:38
arosenyup23:38
*** bknudson has quit IRC23:39
jeblairarosen: and if you have questions about things much deeper in the stack than that, you may want to ask in #tripleo23:39
*** dims has joined #openstack-infra23:40
*** CaptTofu has quit IRC23:41
*** CaptTofu has joined #openstack-infra23:41
*** zns has quit IRC23:42
*** miqui_ has joined #openstack-infra23:42
*** ryanpetrello has joined #openstack-infra23:42
*** miqui has quit IRC23:43
*** sarob has quit IRC23:44
*** thuc has joined #openstack-infra23:45
*** sabari has quit IRC23:45
*** CaptTofu has quit IRC23:46
*** thuc_ has quit IRC23:46
*** thuc_ has joined #openstack-infra23:47
*** ryanpetrello has quit IRC23:47
openstackgerritA change was merged to openstack-infra/config: Use python-jobs template and add release jobs for solum project  https://review.openstack.org/8078023:47
*** maxbit has quit IRC23:48
openstackgerritA change was merged to openstack-infra/config: Add new services to solum devstack setup  https://review.openstack.org/8088323:48
*** Ryan_Lane has quit IRC23:49
*** thuc has quit IRC23:49
*** adrian_otto has quit IRC23:50
*** maxbit has joined #openstack-infra23:53
*** blamar has quit IRC23:53
openstackgerritA change was merged to openstack-infra/config: Simplify gate jobs for python-openstacksdk and add docs  https://review.openstack.org/8071323:54
openstackgerritSlickNik proposed a change to openstack/requirements: Add mockito to global_requirements  https://review.openstack.org/8085023:54
openstackgerritJeremy Stanley proposed a change to openstack/requirements: workaround pypy in requirements  https://review.openstack.org/8110323:57
fungisdague: minor correction ^23:57
openstackgerritSlickNik proposed a change to openstack/requirements: Add pexpect to global_requirements  https://review.openstack.org/8084923:57
*** rdwrer has quit IRC23:58
openstackgerritSlickNik proposed a change to openstack/requirements: Add wsgi_intercept to global_requirements  https://review.openstack.org/8085123:59
*** sarob has joined #openstack-infra23:59

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