Monday, 2013-10-28

*** markwash has quit IRC00:00
*** senk has quit IRC00:12
*** ericw has joined #openstack-infra00:15
*** che-arne has quit IRC00:16
*** matsuhashi has joined #openstack-infra00:19
mordredfungi: re: https://review.openstack.org/#/c/52367/ - do you feel strongly about trying to do the other format?00:27
*** rakhmerov has quit IRC00:28
fungimordred: nah, what you have is more compact. my original goal was merely to shrink the resulting changelog size anyway00:30
*** matsuhashi has quit IRC00:31
fungimordred: though per your and lifeless's comments in there, i think my algorithm got the tags while omitting the merges by making multiple passes00:32
*** matsuhashi has joined #openstack-infra00:32
mordredfungi: I agree00:32
fungifirst a git tag pass, then a git log for each tag range00:32
* fungi looks back at his script00:33
*** dcramer_ has quit IRC00:36
*** matsuhashi has quit IRC00:37
fungiyeah, i did a loop over the git tag output, filtered for only release tag patterns, and then did a git log (well, shortlog in mine) --no-merges over each successive pair of tags to get the changes between them00:37
fungiseemed to work even if the tag was on a merge commit00:38
mordredfungi: yeah - I agree that will work. I'm not sure the extra author info is worth the double loop thing though. I think lifeless point was that it's sad we can't just do a single git invocation and get the log output in the format we want00:41
lifelessright00:41
*** michchap has quit IRC00:41
lifelessparsing is overhead00:41
lifelessmanual recursive descent more so00:41
fungiahh, right. yeah, parsing or loop are the two options00:41
lifelessif we can have git DTRT we avoid all that00:41
*** michchap has joined #openstack-infra00:42
lifelessif we can't, then I start suggesting parser generators (like pyparsing or parsley) to mordred00:42
mordredyah. except this is pbr, so I'm not going to add a dep on pyparsing or parsley00:43
mordredto get potentially more elegant code implementing the changelog writing :)00:43
mordred(in fact, I'm not going to add a depend on anything)00:44
mordredI do agree that getting git to do it directly would be baller00:44
lifelesspbr isn't allowed to depend on anything ?00:45
fungii agree that, as a module targeting basic packaging functionality, its dependency list should be as tight as possible00:46
*** ericw has quit IRC00:46
*** SergeyLukjanov has joined #openstack-infra00:47
mordredlifeless: at the moment, I believe that all depends to pbr need to be MASSIVELY scruitinzed00:47
mordredlifeless: because pbr comes in via setup_requires, which is operated by easy_install, which is a pile of bork00:47
mordredthe more complex we make pbr installation, the more opportunities we introduce for corner cases and fundamental breaking00:48
*** SergeyLukjanov has quit IRC00:49
mordredso, I'm not going to say 'not allowed' - but I think the chances of finding a case where it's justified are slim00:49
mordredand this one is certainly not one00:49
*** matsuhashi has joined #openstack-infra00:49
fungimordred: out of curiosity have you compared the size of nova's changelog before and after?00:49
mordredfungi: I have not - that's an excellent idea00:49
fungii was seeing something like a fourfold reduction in size, so i'd expect similar00:50
mordredhere it is with trunk pbr00:50
mordred-rw-r--r-- 1 mordred mordred 7162597 Oct 27 20:50 ChangeLog00:50
lifelessmordred: why is it pbr that does ChangeLog generation?00:52
mordredand condensed00:52
mordred-rw-r--r-- 1 mordred mordred 915127 Oct 27 20:52 ChangeLog00:52
mordredlifeless: because it handles setup.py interactions00:52
mordredof which sdist is one00:52
*** nosnos has joined #openstack-infra00:52
mordredpbr is a collection of repeated code that otherwise would go into setup.py00:53
funginice, so eightfold or so00:53
mordredyah00:53
mordredthat should make zigo happier00:53
fungiof course the actual space savings will depend on the relative verbosity of commit messages in a given project00:54
mordredsure. I think the real win is that the result is MUCH more useful to read00:54
fungivery much so00:55
mordredand also underscores the point of having nicely readable commit summaries00:55
mordredoh. you know what? I should strip trailing periods in the output. OR I should add periods if they aren't there00:55
mordredso that the ChangeLog reads consistently00:55
mordredregardless of commit subject style choice00:55
fungiboth, commit subhects with no period should get one added, and those with one should have it stripped. that way you can annoy everyone00:56
mordredfungi: ++00:56
*** markwash has joined #openstack-infra00:58
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Make ChangeLog more condensed  https://review.openstack.org/5236701:01
mordredfungi: also - I was thinking - perhaps if we included support for not including commit lines that contained something01:02
mordredlike "NIT: Fix typo" or something01:02
fungiit's a savings which wouldn't be realized in established projects for a long time, but it's not a terrible idea01:03
mordredyah. was mainly thinking in terms of making the ChangeLog something that communicates things that were done01:04
mordredthere are usually commits like that which do not communicate anything01:04
*** markwash has quit IRC01:05
mordredmaybe NIT: and AUTO: so we can also mark things like requirements changes that are just mechanical system commits01:05
fungiprobably needs a bit of an rfc to find out the variety of ways devs might be interested in filtering commits out of the changelog01:07
mordredyah01:07
mordredlet's make that a follow on change01:07
Shrewsmordred: go as expected last night?01:08
*** dims has quit IRC01:11
openstackgerritA change was merged to openstack-dev/pbr: Move base test case logic out of __init__.py  https://review.openstack.org/4886001:13
mordredShrews: yeah - it was really good01:16
*** dkranz has quit IRC01:21
*** yamahata has joined #openstack-infra01:24
*** rakhmerov has joined #openstack-infra01:25
*** sdake has quit IRC01:26
*** alexpilotti has quit IRC01:28
*** fallenpegasus has joined #openstack-infra01:38
*** guohliu has joined #openstack-infra01:39
*** senk has joined #openstack-infra01:46
*** markwash has joined #openstack-infra01:46
*** bingbu has joined #openstack-infra01:47
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Make ChangeLog more condensed  https://review.openstack.org/5236701:50
mordredfungi: ^^01:50
mordredthat updates the logic around lines with multiple commits01:50
*** michchap has quit IRC01:53
*** ericw has joined #openstack-infra01:53
*** michchap has joined #openstack-infra01:55
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Ignore boring commit messages  https://review.openstack.org/5404801:57
*** rakhmerov has quit IRC01:59
*** sdake has joined #openstack-infra02:00
*** wenlock has joined #openstack-infra02:00
mordredfungi, clarkb: fyi - I have released a new pbr version so that the windows guys won't be screwed anymore02:01
*** dims has joined #openstack-infra02:01
mordredit SHOULD not break anything02:01
mordredbut heads up anyway02:01
fungimordred: when you say lines with multiple commits, are you talking about tags on merge commits? or something else?02:04
mordredfungi: what I meant is a single commit with more than one tag02:05
fungiaha! yes, okay now i see what you're solving02:05
mordredwhich is the case with 2013.2 and 2013.2.rc102:05
lifelessmordred: speaking of mailmap02:05
lifelessdid you see my RFC about it ?02:05
mordredspeaking of - the merge-tags-back-to-master script didn't work because we were tryin to do something bad in the script which I beliveve we fixed02:06
mordredlifeless: I did not02:06
lifelessmordred: 'consolidating .mailmap?02:06
lifeless'02:06
mordredfungi: a) that landed, right? and b) should we retrigger that job now that the script sucks less?02:06
mordredlifeless: hrm. yah. it's definitley still needed. copying from centrally certainly seems like a decent idea02:07
mordredespecially since we have user to email mappings elsewhere too02:07
lifelessconsolidating .mailmap?02:07
mordredyah02:07
lifelessbah, mouse fail02:07
fungimordred: i can't remember what was broken in the tag merge script now, but pretty sure the fix did merge02:07
lifelessanyhow yeah, having 40 separate mailmaps seens like a pain02:08
fungimordred: oh, right, we weren't merging to the right branch or something02:08
mordredlifeless: ++02:08
fungiwe were skipping milestone-proposed which was the only place it would have done anything02:08
fungiyeah02:08
mordredlifeless: similar to requirements update, we could write the sync script such that it only copies in relevant entries02:09
lifelessmordred: whats .mailmap used for ?02:09
mordredfungi: yup. because we were filtering on branch, but tag events don't have a branch02:09
fungiright-o02:09
mordredlifeless: most directly for AUTHORS file (removes duplicates)02:09
lifelessmordred: and AUTHORS is generated when /how ?02:09
mordredalso, if people want their git log output to show02:09
mordredlifeless: sdist time02:10
mordredlifeless: by pbr02:10
lifelessmordred: ok, so if we copy mailmap in before sdist happens02:10
lifelessthen we can do it lazily02:10
lifelessbut I don't think we can otherwise, because race conditions02:10
mordredhrm. that would mean that a person running sdist locally would get a potentially surprising result02:10
lifelessyou don't know who you need until they start contributing to that repo02:10
mordredI'm not sure how much I care02:10
*** ArxCruz has quit IRC02:10
mordred(about the local surprising result)02:11
*** harlowja_at_home has joined #openstack-infra02:11
harlowja_at_homefungi, u want to try my new zuul curses viewer?? :-P02:11
harlowja_at_homeor others, https://github.com/harlowja/gerrit_view/#czuul :)02:11
mordredlifeless: if we did that, we might wind up shipping a large .mailmap file in all of our tarballs02:12
mordredlifeless: at least until we put it in as a global exclude02:12
mordredor - actually, it wouldn't e in git, so no we wouldn't02:12
mordrednevermind02:12
*** rcleere has joined #openstack-infra02:12
*** ljjjustin has joined #openstack-infra02:14
fungimordred: out of curiosity, why does pbr manually remap from the mailmap file? git log already claims in its manpage to respect it02:15
*** guohliu has quit IRC02:15
mordredfungi: uhm. now that you ask that question, I do not know02:15
fungiman git-log briefly mentions it, but directs you to the git-shortlog manpage for details02:16
fungiharlowja_at_home: installing it into a venv now to take it for a spin02:18
harlowja_at_home:)02:19
harlowja_at_homecool02:19
lifelessmordred: we shouldn't ship .mailmap in tarballs anyway02:20
lifelessmordred: so meh02:20
*** lnxnut has quit IRC02:20
harlowja_at_homefungi, i could probably use screen space better, but pgup, pgdown, up/down arrow keys to move around (when u try it out)02:24
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Let git do mailmap mapping for us  https://review.openstack.org/5405002:25
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Ignore boring commit messages  https://review.openstack.org/5404802:25
mordredfungi: there you go. there's a patch to let git do the mailmap mapping for us02:25
mordredwow. merge conflict. that's so sexy02:28
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Make ChangeLog more condensed  https://review.openstack.org/5236702:30
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Ignore boring commit messages  https://review.openstack.org/5404802:30
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Let git do mailmap mapping for us  https://review.openstack.org/5405002:30
mordredand I had to rebase the stack. sigh02:31
mordredlifeless: if you want to review https://review.openstack.org/52367 and https://review.openstack.org/54048 I will not scream at you02:31
mordredI eam https://review.openstack.org/54050 not https://review.openstack.org/54048 - https://review.openstack.org/54048 is not ready yet02:32
*** guohliu has joined #openstack-infra02:32
*** UtahDave has quit IRC02:32
*** bingbu has quit IRC02:32
*** rakhmerov has joined #openstack-infra02:32
mordredfungi: also, there are several sexy git-review patches outstanding, :)02:34
harlowja_at_homesexy02:34
*** michchap has quit IRC02:36
*** ljjjustin has quit IRC02:37
*** ljjjustin has joined #openstack-infra02:37
notmynamemordred: still around? I see you're referencing me on twitter and proposing ideas on the mailing list. :-)02:39
*** xchu has joined #openstack-infra02:39
mordrednotmyname: I constantly reference you on twitter02:39
mordrednotmyname: although sadly it does not appear that that SAT solver is going to be immediately helpful in our current SAT solver interest02:40
notmynameah. too bad02:40
notmynamecause auto requirements is pretty useless without it02:40
mordredyeah. the author has a rather weird hatred of python versioning02:40
mordredit's not useless. it just doesn't solve your use case02:40
mordredI do agree though that it can be improved to the point where it does02:40
mordrednotmyname: in any case - yes! I'm still here02:41
*** vipul has quit IRC02:41
notmynameat best I'd call the current state "unwieldy", and boardering on useless. eg we may have some patches in eventlet that would be of interest, but that doesn't mean everyone needs to force upgrade to bleeding-edge eventlet (actual case, but substitute whatever package and get the same result)02:42
notmynameanyway, dependencies isn't what I wanted to focus on tonight. we've covered that plently before02:42
*** vipul has joined #openstack-infra02:42
notmynameand it seems the new thing you found doesn't meet our needs :-(02:43
mordrednot yet. we'll get there02:43
*** dims has quit IRC02:43
mordreddstufft is still working on a SAT solver that will02:43
notmynamelike you, I'm always hopeful02:43
notmynamefirst, the probably less contentious one: consolidated mailmap. wouldn't tarball makers care very much about the AUTHORS file?02:44
notmynameif for nothing else, it's necessary for making the same hash02:44
notmynameand it contains info that is otherwise not in the tarball (VCS info)02:45
mordredit's a good question02:45
mordredthe question is - how important is the contents of AUTHORS to people making their own tarballs?02:45
mordred(I do not have a strong opinion on this one)02:46
mordredso it's an honest question02:46
mordredlifeless: ^^ (we're talking about you)02:46
clarkbmailmap is for deduping right?02:46
clarkbdo we need to bother?02:46
mordredclarkb: yes.02:46
clarkbthe list is correct without dedup02:46
mordredclarkb: sure. but it's a little ugly, and we do have the dedup machinery02:47
mordredI certainly don't think we should replace the mailmap files with nothing02:47
clarkbit seems to solve all the problems but uglyness :)02:47
mordredI think there are a few different options02:47
*** harlowja_at_home has quit IRC02:48
notmynameI'm a fan of keeping .mailmap local to a project, if for nothing else to keep the dependency trees shorter when building packages and running stuff02:48
notmyname(that's my opening position)02:48
mordreda) keep the individually managed mailmap files in the repos02:48
mordredb) have a central list from which mailmap entries can be synced by a computer as needed, with the results stored in the repo02:48
*** ericw has quit IRC02:49
mordredc) have a central list which is used at infra tarball creation time that does not have any relationship to the git repo02:49
*** bingbu has joined #openstack-infra02:49
mordredd) have a central list which is used at infra tarball creation time that does not have any relationship to the git repo but which is included in the tarball02:50
mordredany other combos? I'm missing?02:50
mordreda) is clearly the easiest, since it requires no changes, but is the most effort in terms of ongoing maint of the lists02:51
notmynameit doesnt' seem that git shortlog respects .mailmap being in .gitignore, FWIW02:51
mordrednotmyname: what do you mean?02:52
mordredlike, if you put it in gitignore, it doesn't see it?02:52
notmyname(b) seems to be the worst of both worlds: per project file + extra dependency and syncing problem02:52
notmynamemordred: as in even with it ignored, shortlog applies it02:52
*** matsuhashi has quit IRC02:53
mordrednotmyname: can you explain what you mean by "extra dependency" ?02:53
*** matsuhashi has joined #openstack-infra02:53
mordred(I think th emore I think about it, btw, I agree that b is not a great choice - just want to make sure I'm capturing your thoughts)02:54
notmynamesimilar to pbr now being a build-time dependency (and I'm hopeful that one day it won't be). depends if this is separate from pbr or not. if part of pbr, then it's an extra "hook" that makes it harder to decouple later. if not, then it's a new dependency for builders/deployers02:54
mordredoh - I was TOTALLY thinking that this would be a jenkins related thing02:56
mordredthat just copies a file in place before doing something02:56
mordrednot that it would be something that setup.py knew anything about02:56
notmynameor pbr sdist hooks?02:56
mordredpbr already does the authors processing with the mailmap file02:56
mordredso all that is required is for the file to be present02:57
mordredif it's not, it's a no op02:57
notmynameFTFY: pbr already does what git shortlog does ;-)02:57
mordrednotmyname: it actually is deferring to git to do the mailmap work in a commit above, fwiw02:57
mordredI think that running code in pbr to _fetch_ a global mailmap from somewhere else would be HORRIBLE02:57
notmynamegood. we agree on that :-)02:57
*** matsuhashi has quit IRC02:58
mordredI believe the mechanism choices are "do we havea  mechanism to mupdate the currently existing mailmap file  automatically"02:58
clarkbnotmyname: curious about the pbr not being a build time dependency. aiui that is pbr's reason for existence02:58
mordredor "do we inject a mailmap file on the build hosts"02:58
mordredif we do the second thing, it would mean that poeple other than us making sdist tarballs would have a different and possibly less featureful experience02:59
notmynameso we make an -infra jenkins-ish thingy to create a .mailmap file. how do people who want to know who did what get along? they have to pull from the centralized jenkins-ish thingy?02:59
notmynameclarkb: happy to talk about that, but I'm only smart enough for one fun conversation at a time ;-)02:59
lifelessmordred: you're talking about me?02:59
mordrednotmyname: yah. that's ultimately the problem with not committing the changes to the repo03:00
lifelessmordred: I will review those things for you03:00
mordredlifeless: we're discussing your mailmap thoughts03:00
notmynamemordred: wouldn't git blame break too?03:00
mordrednotmyname: does git blame use mailmap?03:00
lifelessmordred: I don't know that I have thoughts03:00
lifelessmordred: I just know that maintaining the same mapping in 40 repos is a waste of a good life03:00
mordrednotmyname: so it does. that changes my opinion of the options03:00
notmynamenot sure, but AFAIK all of git that looks at authors does03:00
lifelessmordred: if I was doing the work I'd be inclined to just copy the contents into every relevant repo, no editing03:01
notmynamemordred: so while a per-project .mailmap may have some duplicated info, keeping it the repo on a per-project basis may be the best03:01
mordredI think given that, it is important for the appropriate contents to be in the git repos03:01
mordrednow - having a tool or script that could, if desired, grab a global openstack mailmap and copy it into your repo seems very simple03:02
mordredor, screw a tool03:02
mordredjust having an accessible globla mailmap is all you'd need03:02
mordredthe tool is wget :)03:02
mordredif you, as a project, wanted to copy it in and commit it - neat. if you don't? neat.03:02
mordredas this is not an operational set of information that is related to actual build things, I do not feel that we need to have a strong opinion on enforcing an automated sync03:03
mordredright?03:03
lifelessmordred: I don't follow03:03
fungiproposal job which submits a review to sync up your .mailmap file if entries in your git log contain authors in the central mailmap file?03:04
notmynamemordred: I support you having that opinion (while my own is stronger to keeping them per-project)03:04
lifelessmordred: there is a mapping which is needed to get correct behaviour from multiple tools (pbr, git).03:04
mordredthat behavior is cosmetic at best03:04
lifelessmordred: the mapping should be the same for the same person in all git repos in OpenStack03:04
mordredlifeless: because notmyname and swift will actively become unhappy if jenkins started proposing mailmap changes03:05
mordredlifeless: I do not feel that it is worth a fight03:05
*** guohliu has quit IRC03:05
lifelessmordred: what would make them unhappy?03:05
mordredrequirements is03:05
notmynamelifeless: "should be"? why?03:05
mordredit has crossproject functional effects on the testing of openstack03:05
*** guohliu has joined #openstack-infra03:05
clarkbnotmyname: because gerrit03:05
notmynamemordred: well, I started this topic by saying it's less contentious03:05
mordredauthors file contents is - less important03:05
mordrednotmyname:  :)03:05
clarkbgerrit does enforce it to a degree03:05
notmynameclarkb: hmm...good point.03:06
lifelessnotmyname: what aspect of having the same mailmap as nova (either same for the same people, or same verbatim) would make you/swift unhappy?03:06
mordredlifeless: it would be commits that potentially suggest changes to their local file that are not relevant to their repo03:07
notmynamewhile I'd be mildly annoyed at having hundreds/thousands of lines in a .mailmap file in swift for people who have never even looked at the code, syncling that isn't worth too much of a fight at this point IMO03:07
notmynameand "syncling" is a weird-sounding word03:07
mordredI like it!03:07
mordredsimilarly, I have other fish to fry, so I don't feel strongly enough about it to make notmyname mildly annoyed. if we could sync only authors who have commits in the target repo...03:08
mordredthen I doubt we'd see significant pushbach03:08
lifelessthat surely doable03:08
mordredor pushback03:08
notmynameI'm happy to hear that the decision at this point is to auto-proposed updates or not. I'm fine to leave it there (I don't really care too much). I'm strongly against having a central dependency requirement to pull a .mailmap from03:09
lifelessjust minor race condition (and strictly speaking no worse than the current often-stale dataset we have today)03:09
*** dcramer_ has joined #openstack-infra03:09
*** matsuhashi has joined #openstack-infra03:09
fungiwhat if it only proposed updates to the mailmap if authors in that project's git log were present in the global mailmap file? in the way that requirements sync only proposes updates for entries in your project's requirements lists?03:09
mordrednotmyname: I 100% agree. pulling a dep would be awful03:09
mordredfungi: yes03:09
mordredlifeless: well, and if someone did choose to add themselves to a mailmap file in their first commit from a different email than their previous commit, it would not break things03:10
notmynamelifeless: fungi: what caused this question to arise? what's the pain point?03:10
fungidryness03:10
notmynamenot sure I follow03:10
lifelessnotmyname: DRY; hidden non-discoverable datasources suck, etc03:10
notmynamegotcha03:10
notmynameIOW you don't want to keep your .mailmap entry up to date across N projects03:11
lifelessright03:11
lifelessplus several separate metric systems03:11
lifelessplus the foundation web page03:11
lifelessSTAB STAB STAB STAB03:11
* mordred fixes this problem by committing with the same email address everywhere03:12
notmynameya, the metrics and the foundation seems that they could benefit, but isn't that info already in gerrit anyway? shouldn't they pull from there rather than git shortlog?03:12
clarkbthe foundation webpage is what got me to thinking we could just stop carring (there are tons of dups on the havana release page)03:12
mordrednotmyname: oh - the metrics systems should pull from somewhere else for sure03:12
lifelessnotmyname: well, I'd like to have just one source of all this info03:12
mordredclarkb: well, god only knows where the foundation got that data03:12
mordredit certainly wasn't from ANY system managed by the project03:12
lifelessnotmyname: and clear instructions on the new contributor signup page saying 'do X to set this up, and Y if you change affiliation || email in future'03:12
notmynamelifeless: agreed. IMO the foundation (and gerrit) is or should be tracking all that and have the authoritative source03:13
notmynamelifeless: sure, but docs for new contribs don't have to spell out every eventuality.03:13
lifelessnotmyname: so basically I'm bringing up any redundant source I see and going 'hey, this is perpetuating the overall problem'03:13
fungigerrit doesn't make a lot of that queryable without being a gerrit admin, so we'd have to expose data from it through some additional mechanism03:13
lifelessnotmyname: they don't, but there are only two situations. New, and changed.03:13
mordredfungi: once the user db system stops being stupid03:13
lifelessnotmyname: point it new contributors don't even *know* that it's a thing at the moment.03:13
fungimordred: yep03:14
*** vipul is now known as vipul-away03:14
lifelessnotmyname: so a) reduce the number of things that we all need to care about, and b) then it's sane to tell people.03:14
notmynamelifeless: they don't know that what's a thing at the moment? .mailmap?03:14
lifelessnotmyname: the big set of data sources; AFAICT there is no list of all the things that store this mapping data03:15
lifelessnotmyname: and there should need to be; it should be maintained in one place03:15
notmynameexcept the currently-hard-to-get-but-it's-there gerrit system03:15
mordredI'm going to push VERY hard for there to be a central, authoitative and accessilbe source for this this cycle03:15
notmynamewhich actually has the CLA info etc03:15
mordredbecause right now if we did something it would be ADDING another source to the list03:15
mordredrather than reducing the number03:16
*** gyee has joined #openstack-infra03:16
lifelessnotmyname: gerrit is one such system03:16
mordredbut if we get the membership system to stop sucking, then we can build thigns that can query it when we need, etc03:16
notmynameok. /me is done talking about sync'ing .mailmap files until mordred fixes the world ;-)03:16
lifelessnotmyname: but it's not authoritative; *that* is the problem.03:16
*** gyee has quit IRC03:16
notmynamemordred: next thing I want to talk about is changelog files03:17
mordrednotmyname: awesome!03:17
fungiit's almost like he's reading through your list of pending pbr patches03:17
notmynamemordred: (I say this because we know each other and in this rare case I think it will translate in a text-based medium) filtering "boring" commit messages from an auto-generated changelog seems like such a waste of time. go solve a real problem03:18
notmyname /rant03:18
mordrednotmyname: only thought about it at all because I was right there in the code anyway03:19
* notmyname is a strong proponent of hand-curated CHANGELOG files03:19
notmynameI agree that changelogs that are simply the result of `git shortlog` are useless03:19
mordredwell, we don't use git shortlog03:19
notmynamewell, "the git changelog"03:20
notmynamefrom your email03:20
mordredgotcha.03:20
*** guohliu has quit IRC03:21
mordredin general, rant noted. I do not plan on spending much energy on the topic (it's good plane hacking fodder, tbh)03:21
* mordred WANTS to be hacking on wheel support, but that requires way less laggy network than he has now03:21
notmynamethe audience for CHANGELOG is people who need to see what's the high-level status of a project, what's important, and what to watch out for. it's an executive summary for the deployer, packager, and admin03:21
notmynameauto-generated files can't do that03:21
mordredI kinda think of NEWS files or release notes as being that03:22
mordredbut honestly, on the fast moving projects, manually curated changelog entries would be very difficult to manage03:24
mordredeither you're adding entries as you go, in which case you're increasing merge conflict fodder03:24
mordredor you're adding them at release time, which means the file is out of date in the repo until then, and someone has to track things for longer03:25
notmynameIOW the changelog doesn't have info about a release until the release happens?03:25
notmynamefor the 2nd point03:25
mordredright.03:25
mordredbut for people running from trunk03:25
notmynamehow is that a problem?03:25
mordredyou grab it, and you look for the curated information, since git log is not good enough for deployers03:26
mordredbut it's not filled in, because of merge problems03:26
notmynameif a deployer is running at trunk, they have the chops to see what's going on since the last release was cut03:26
mordredhow can anyone run openstack and NOT have those chops?03:27
mordredin a real prod env03:27
notmynamethey run someone's product/distro/bundling of it03:28
notmynamepiston/nebula/red hat/mirantis/cloudscaling/etc03:28
mordredin which case, they are reading the product release notes03:28
mordredfrom the value add company03:28
lifelessmordred: release time doesn't exist03:28
mordredwho is curating things for them03:28
lifelessmordred: its a fallacy.03:28
mordredlifeless: it does. we're not to your world yet03:28
lifelessmordred: enough folk are that from a planning perspective...03:29
mordredOpenSTack makes 6 month releasesuntil we decide other wise03:29
lifelessmordred: yes, it does.03:29
notmynamelifeless: true :-) when are we going to do away with this whole release cycle thing anyway? ;-)03:29
lifelessmordred: but 'fix stuff up at the end' is already not an option03:29
mordredlifeless: indeed. which is another reason that write the changelog at release time is a no-go03:29
lifelessnotmyname: J timeframe I hope03:29
mordredessentially, it's an even more complex issue than finding the right time to land the commit that changes the version number - the real process just doesn't work that way03:30
mordredwhich means manual curation would be back to a thing needing to be done continaully03:30
mordredwhich has merge conflict issues big-time03:31
mordreddue to the form of the thing03:31
fungirun-parts style changelog assembly ;)03:31
mordredfungi: boom! you win! :)03:31
notmynamemordred: our goal for swift now is that master is deployable at any point (we've missed this recently, sadly). every so often, we bundle together what's happened and cut a "release". at this point I curate the AUTHORS and CHANGELOG file from what's happened (BTW, this happens much more often than every 6 months)03:31
mordrednotmyname: right. because YOU have a sooner than 6 month release cycle03:32
mordredcurating that file for you is not nearly as much of a nightmare03:32
mordredimagine curating it for a nova release03:32
notmynamemordred: well, importantly for conflicts sake, I'm the one who does it03:32
mordredright03:32
mordredyou also probably actually know everytihng that landed in swift in a cycle03:33
*** guohliu has joined #openstack-infra03:33
notmynamemordred: only if I keep on top of it nearly every day03:33
notmynameI get very far behind on all the trips ;-)03:33
mordredoy. tell me about it03:33
mordrednotmyname: so you're saying you keep up a set of notes about what the changelog is going to be?03:34
notmynameperhaps. or even have the PTL work on in as it goes03:34
notmynamepoint being is that russellb does a great job knowing what's going on. I guarantee you that any PTL can tell you what's going on at the drop of a hat. personally, I have to look through the VCS logs at every release to know everything that's merged03:35
mordrednod03:35
notmynameI've done both: updating it at release time and keeping it updated during a release03:35
mordredwell, I mean, ultimately skip_changelog is an option in setup.cfg for a reason03:36
notmynameeither way, the PTL is the one updating it and making sure that there is a good high-level summary for stuff. this is especially important with features that cross many commits03:36
notmynamemordred: it's not there just because you like me so much? ;-)03:36
mordrednothing is preventing anyone from manually curating one - but if that is not a thing a person wants to do, making one that contains _something_ that might be informative is better than no information in the tarball03:37
mordrednotmyname: well, there are two reasons :)03:37
notmynamelo03:37
notmynamelol03:37
mordredbcwaldon also preferred manaul curation back when he still hacked on openstack03:37
notmynameI've heard interest from jgriffith too03:38
mordredbut if we can get best-effort from automation and it's good enough for a wide variety of things, then awesome, one less thing for folks03:38
mordredjgriffith: you are more than welcome to turn off ChangeLog generation in your repo should you like03:38
mordredaltohugh, what bcwaldon wound up doing was this: http://docs.openstack.org/developer/python-glanceclient/#release-notes03:39
mordredmaintaining the curated thing in the sphinx docs03:39
mordredand then having the ChangeLog file be the autogenerated thing03:39
*** nati_ueno has quit IRC03:40
mordredthat way there is also, in addition ot the tarball, a published web version of the notes03:40
mordredthat can be linked places03:40
notmynamedo you worry that an autogenerated changelog may give too much weight to "raw" data? IOW, if it's not there and someone has to go digging in VCS for it, they kinda know that thye have to figure out what the big stuff is. that implicit understanding is gone with an easily available changelog file that is essentially git shortlog output03:40
*** lnxnut has joined #openstack-infra03:40
*** nati_ueno has joined #openstack-infra03:40
mordredI'm not sure I follow the concern03:41
mordredI also, btw, think that git is a pretty frequently used vehicle from which to get the source code03:41
mordredand honestly think that changelog files are a dinosaur from a time when that was not the case03:41
mordredand when the tarball was actually the only mechanism you had to get the code, and the VCS history was simply not available03:42
notmynameso you've got a big feature that spans a few commits or one that landed early in the cycle. take a look at the ChangeLog (that was generate from git shortlog), and you've got to wade through hundreds to thousands of messages before you get to the big stuff03:42
mordredsure. that's why I actually like http://docs.openstack.org/developer/python-glanceclient/#release-notes as a compromise for the folks who want to maintain it03:43
notmynameya, I guess my point is that hand-curated is awesome and should be required. if that's in sphinx or the actual CHANGELOG file is someone less important (especially if considering greenfield projects)03:44
notmynameI don't make a hand-curated changelog for python-swiftclient. I should.03:45
mordredyeah. I can totally see that, and I would not be unhappy if everyone started doing a release notes style hand curated thing03:45
*** nati_ueno has quit IRC03:46
notmynamemordred: so where does that leave us? please don't work on filtering changelog mesages. at least until you figure out the really important stuff. like vim modelines in files03:47
mordrednotmyname: :)03:47
mordrednotmyname: I did not bring that one up03:47
notmynameI know :-)03:47
mordredbut I've automated all of the things that were the source of my commits in the last cycle - I've got some up with _something_ to keep my commit count high! ;)03:48
mordredelse people might think I've turned into a manager03:48
notmynamehorror!03:48
notmynameclarkb: so pbr as not a build-time dependency...03:48
mordredspeaking of - python-glanceclient does not seem to be using the openstack sphinx theme...03:48
* mordred sits back to watch this one03:49
clarkbya, mostly just curious how that would work03:49
clarkbsince pbr is python build reasonableness03:49
notmynameclarkb: in my ideal world, pbr would be a tool that is used to build stuff (specifically for pip, not packages), similar to debuild for debian. ie feed a repo in and get out a thing that can be installed03:49
notmynameI think it's most egregious in client libraries (where it becomes another dependency to install when especially for clients we should be _reducing_ these things)03:50
mordrednotmyname: that's actually possible, but I thnk it would REALY piss off the packagers working from git and not from tarballs we generate03:51
notmynamemordred: how so?03:51
clarkbnotmyname: I think we may have some philosophical differences about that :) (I think swiftclient should include its "optional" dependencies at least when installing from pip03:51
mordrednotmyname: because it would be a tool you'd HAVE to use to interact with the source code repository03:51
mordredwhereas right now you can interact with setup.py like other python projects do03:52
notmynamemordred: it wouldn't be `pbr /path/to/some/git/repo`?03:52
mordredyup. THAT would work03:52
mordredbut you'd need pbr at build time still03:52
notmynameclarkb: python-*client should run anywhere. our APIs are HTTP! we should be runnable on py2.0 on every computer ever made03:53
mordrednotmyname: we are03:53
mordredpbr does not prevent that03:53
clarkbnotmyname: I agree, but that doesn't rule out dependencies03:53
mordredit ONLY prevents using pre-secure pip03:53
mordredand I do not feel the need to support that03:53
mordredas it's a horrible idea03:53
mordredand actively destructive03:53
notmynamemordred: why would you need pbr for build time?03:54
mordredin any case, with the tool approach03:54
mordredyou could remove the need for pbr at pip install time03:54
mordredBUT03:54
mordredyou'd increase the surface area of people who woul dhave to learn about pbr directly03:54
notmynameclarkb: sure, but as a general idea in client libs (for any project), less deps >> more deps03:54
mordredbecause every single person wanting to install from git03:54
mordredwould have to learn about running pbr03:55
clarkbnotmyname: but broken features isn't good either03:55
notmynamemordred: that's what I don't get yet. why? I don't need debuild to run from source on a debian machine?03:55
clarkbit is really ocnfusing when you just want swiftclient to push objects to $publiccloud and it can't in a default install03:55
notmynameclarkb: nobody is promoting broken features03:55
mordredyou DO need it to build debian packages though03:55
mordredand the way pip and friends work right now03:56
mordredis via source-level installs03:56
mordredso it's not analogous to how debuild/dpkg work03:56
mordredonce we start using wheels, btw03:56
mordredyou will not need pbr on your machien to install things03:56
mordredso, actually, that ^^ is probably what you really want03:57
notmynamecould you say that when we have wheels the install process will be on rails?03:57
mordredoy03:57
* notmyname doesn't actually know what "wheels" in this context means03:57
mordredat that point, you will not need "build" depends to install03:57
mordrednotmyname: it's a new binary distribution mechanism for python03:57
mordredit allows us to build "built" distributions of software03:58
mordredthat can be installed without running setup.py03:58
notmynamegems?03:58
*** harlowja has quit IRC03:58
mordredI believe gems still run ruby code at install time03:58
mordredthis is something that can run _no_ python code at install time03:59
notmynameI don't actually know much about how the ruby word works..03:59
mordredme either03:59
mordredthe upshot is, the only people who will need pbr03:59
notmynameinteresting...so where is it supported?03:59
mordredpip >= 1.403:59
mordredso, first step is03:59
mordredwe're going to start to upload wheels (and only wheels) of pre-release versions of things to pypi04:00
*** bingbu has quit IRC04:00
mordred(this goes hand in hand with pip 1.4 not downloading pre-release software by default)04:00
mordredwhich means we'll have by-default non-downloaded pre-release things no matter what version of pip you happen to be running04:00
mordredsince pip pre 1.4 will not see the wheels at all04:01
notmyname"pre-release versions" == every commit? or == milestones?04:01
mordredmilestones. things like oslo.config==1.2b404:01
*** fifieldt has joined #openstack-infra04:01
notmynameso "releases" that aren't part of the six-month cycle, essentially04:01
notmynamewhat about client libs?04:01
mordredclient lib releases are releases04:02
mordredso for those, we'll upload both things04:02
*** changbl has joined #openstack-infra04:02
notmynameand what happens when pip >1.4 sees a wheel?04:02
notmynameoh, ok. go on04:02
mordredso, when pip >1.4 sees a wheel, if you have set PIP_USE_WHEEL or --use-wheel, it will prefer the wheel over the tarbal04:02
mordred(there are still flags around this because it's still a new feature)04:03
mordredand if there  is a wheel that matches the system on which you are running, it will download the wheel and just unpack it directly04:03
mordredrather than running the setup.py code that was in the source repo04:03
notmynameok. and what about earlier versions of pip?04:03
mordred(setup.py gets run at wheel creation time, similar to debuild)04:03
mordredearlier versions of pip will default to grabbing the tarball as usual04:04
notmynameok, so pbr would be needed for "wheel builders"?04:04
mordredyes04:04
notmynameor pip pre 1.404:04
mordredyes04:04
notmynamewhen is pip 1.4 released?04:04
mordreda few months ago04:05
mordredit's the version of pip in latest ubuntu04:05
mordredand, if you are using pip, it's the version you should be using04:05
mordredthere is no valid reason to use pip < 1.404:05
notmyname"should" is often not what our users are doing04:05
mordredbecause, by definitoin, if you are using it, you are using it to install software via pip04:05
mordredso you, by definition, are ok with instaling softare via pip :)04:06
*** lnxnut has quit IRC04:06
mordredwell, for regular users, installing one of our things right now on old pip will give you a dependency error saying to upgrade your pip04:06
mordredwhich is pretty clear04:06
notmynameyup04:06
*** lnxnut has joined #openstack-infra04:06
notmynameI'm quite aware of that one ;-)04:06
mordredI could investigate figuring out a way to print a more verbose warning04:07
mordredwhich explains "seriously, dude. upgrade pip. you are opening yourself to being rooted right now"04:07
notmynameeven when building packages and there is an older version of pip installed (even if you aren't using it...)04:07
mordredthat should not be the behavior04:07
mordredif you are building packages04:08
mordredand if it is, it's a bug04:08
notmynameright. packagers should use the pbr env flags04:08
notmynameis that what you mena?04:08
mordredactually, they should not be necessary04:08
mordredit turns out04:08
*** primeministerp has quit IRC04:08
mordredas dh_python already passes --single-versoin-externaly-managed and I _think_ that should triger the SKIP_PIP_INSTALL codepath as well04:09
mordredit's on my todo list to tighten that up and get more tests to ensure that it is the case04:09
mordredbut _certainly_ the packagers can be explicit and use the var04:09
notmynamemordred: on lucid, not using pip (but distro version installed), `python ./setup.py develop` doesn't work because pip isn't new enough04:10
mordredthat is correct04:10
mordredbecause pip is a requirement of pbr04:10
*** dcramer_ has quit IRC04:10
mordredSKIP_PIP_INSTALL=1 python setup.py develop should work on lucid though04:11
*** lnxnut has quit IRC04:11
mordredI do not understand who the theoretical lucid user we're targetting here is though04:11
mordredso it's hard to design a solution for them04:11
notmynamein this case, it's me since my precise VM is hosed after my OS X update04:12
notmynameand I have a lucid VM in the cloud already04:12
mordredheh. good. well, I assume you're smarter than average04:12
mordredso that's helpful04:12
*** bingbu has joined #openstack-infra04:13
*** dripton_ has quit IRC04:13
notmynamenope. the env var doesn't help04:13
* mordred looking for his lucid image04:14
mordrednotmyname: that not working i s a bug04:14
notmynamehmm..pbr isn't installed at all on this box04:14
notmynamemaybe a bootstrapping thing?04:14
mordreddo you have a pbr egg in that directory?04:15
notmynameI love the tracebacks with this line: "raise VersionConflict(dist,req) # XXX put more info here"04:15
mordredyah04:15
notmynamemordred: no. no traces of pbr that I can find04:15
*** oubiwann has quit IRC04:15
mordredit's very odd that any code is executing then, as setup.py has no functionality at all without pbr04:16
*** wenlock has quit IRC04:16
*** yamahata has quit IRC04:16
mordredas in, will fail to operate with an argument error04:16
mordredI dont' seem to have my lucid node any more - lemme spin one up04:16
notmynamesetuptools is there and will execute. that's the call that setup.py is making04:17
*** matsuhashi has quit IRC04:17
*** yamahata has joined #openstack-infra04:17
*** rcleere has quit IRC04:18
notmynameto the cloud!04:18
*** sdake has quit IRC04:18
mordredbut setuptools can't do anything without pbr04:18
*** ryanpetrello has joined #openstack-infra04:18
mordredthe first thing it should try to do is download it because of setup_requires04:18
mordrednotmyname: which repo are you doing, btw04:19
notmynameswift04:19
mordredk04:19
mordredand you've installed all of swift's depends by packages?04:19
mordredis ther e a place I can copy pate  a command to do that (want to duplicate env)04:20
notmynameIt's been a long time since I've logged into this box. I'm honestly not sure04:20
*** matsuhashi has joined #openstack-infra04:20
notmynameI copied the code over to the lucid box, cd'd to the dir, and `sudo python ./setup.py develop`04:20
mordredwow. SO OLD SO OLD04:22
mordredubuntu@lucidtest:~$ sudo apt-get install git-core04:22
mordred:)04:22
notmynameyup04:23
*** matsuhashi has quit IRC04:23
jgriffithmordred: notmyname only catching part of the context in scroll back...04:23
jgriffithmordred: notmyname changelog generation?04:23
notmynamejgriffith: once upon a time you mentioned that a curated might be nice04:23
jgriffithnotmyname: ahh... yes, likely while I was updating release notes for python-cinderclient04:24
notmynamejgriffith: mordred was mentioning that you can easily turn off the auto-generation for cinder ifyou want04:24
jgriffithnotmyname: or release notes for cinder G04:24
mordredjgriffith: there are two optoins for that - you can either turn off auto generatoin - or you can do them in sphinx docs like glanceclient: http://docs.openstack.org/developer/python-glanceclient/#release-notes04:24
mordrednotmyname: ok. I see the bug. I will fix it04:25
notmynamemordred: ah really? I was sure I was doing something wrong04:25
jgriffithmordred: so I kinda decided I liked having them in sphinx and published on pypi04:25
mordrednotmyname: nope. it's a bug. I apologize04:25
jgriffithfor the client at least04:25
mordredjgriffith: awesome04:25
jgriffithmordred: notmyname auto-magically generating is the topic I think we talked about04:25
jgriffithmordred: notmyname that would still be quite nice04:26
mordredjgriffith: wait - what do you want?04:26
jgriffithmordred: haha... depends on when you ask04:26
mordredhahahaahahahaha04:26
jgriffithmordred: so... I *think* IIRC the conversation with notmyname was around trying to post process the release notes04:26
jgriffithand we had talked about a way to aut-generate off of say like BP or Bug tags in the commit04:27
jgriffithas it stands now... for cinder-client I go through commit history and manually try and fill in what's happened since the last release04:27
jgriffithin docs/index.rst04:28
jgriffithwhich I like because it shows up in pypi when you browse to the package04:28
*** matsuhashi has joined #openstack-infra04:28
jgriffitherr...hmmm04:28
* jgriffith lies04:29
jgriffithit does not04:29
jgriffithI would have to modify the README for that04:31
jgriffithanyway... not sure if that's the context notmyname was recalling or not?04:31
jgriffithbahhh!!04:31
jgriffithmordred: continuous upgrade session conflicts :(04:31
notmynamejgriffith: I remember something much more general about just how changelogs are done in swift. but I need to start handling the swiftlclient changelog, and I'm leaning towards the sphinx docs like you use04:32
*** primeministerp has joined #openstack-infra04:33
jgriffithnotmyname: cool... I think I was complaining to you late one night when I was trying to pull everything together :)04:33
notmynamejgriffith: I think we all do that every time any of us sees someone else in person ;-)04:34
jgriffithnotmyname: LOL... indeed!04:34
mordrednotmyname: you havea found a fascinating edge case04:37
notmynamemordred: oh goody04:37
*** yamahata has quit IRC04:40
mordrednotmyname: it might be unfixable04:41
notmynamemordred: what's the issue? need pbr to resolve but pbr isn't installed?04:42
mordrednope. it's that setuptools itself is reading the requires list out of the pbr egg it downloads from EGG-INFO/requires.txt04:42
mordredwhich means that pbr's suppression of things hasn't been gotten to yet04:43
* mordred trying a few evil things real quick04:43
notmynamemordred: kk. which would also be an issue for package building since that would require setup.py to be run04:44
mordredactually, not really04:44
mordredpackage building gets build deps via packages04:44
notmynameah, right04:45
mordredwhich means that the easy_install codepath in setuptools is not triggered04:45
mordredit's setuptools easy_install that is the culprit in everything04:45
notmynamehmm...but even then, packaging (or at least the lucid packaging I know) still uses setup.py for sphinx docs generation. so that would trigger it, at least04:47
mordredyes. but that's fine04:47
notmynamenot sure of other setup.py references04:47
mordredbecuase in _that_ context you're driving the setup.py in the conetxt of the SKIP_PIP_INSTALL04:47
mordred(there is a patch I need to make still - but different problem)04:48
mordredat least, I think I need to make it - I have a patch which will fix a thing I _thought_ was your problem :)04:48
mordredbut that's not your problem04:48
*** reed has quit IRC04:49
notmynamemordred: thanks for looking04:53
mordrednotmyname: I'm going to keep beating my head against it, because the sequence doesn't make me happy04:53
*** ljjjustin has quit IRC04:53
lifelessmordred: so, why does pbr need to be the place ChangeLog generation happens in?04:53
mordredbut the best thing I can come up with is to remove the version specification from pip in requirements.txt04:54
lifelessmordred: like, why couldn't be in (say) pbr_utils which pbr arranges for install of ?04:54
mordredlifeless: hang on - lemme finish this thought04:54
*** vipul-away is now known as vipul04:54
*** ljjjustin has joined #openstack-infra04:55
mordrednotmyname: I worry about doing that because while it will allow you to skip past your current thing, it widens the possibility that people will operate software with a known insecure version of things04:55
mordrednotmyname: I'm landing - let me noodle on it further and see what the options might be04:56
notmynamemordred: kk. thanks again. (I'm out for the night too)04:56
*** senk has quit IRC05:06
*** nati_ueno has joined #openstack-infra05:15
*** nicedice__ has quit IRC05:16
*** yamahata has joined #openstack-infra05:22
*** nosnos_ has joined #openstack-infra05:37
*** nosnos has quit IRC05:37
*** SergeyLukjanov has joined #openstack-infra05:44
mordrednotmyname: my pleasure! let me know when you're back on, I have further thoughts05:54
mordredlifeless: morning!05:54
*** matsuhashi has quit IRC05:56
*** matsuhashi has joined #openstack-infra05:57
*** katyafervent has joined #openstack-infra06:00
mordredlifeless: I now have the bandwidth to discuss pbr and changelog generation06:01
*** denis_makogon has joined #openstack-infra06:01
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Skip the install of pip  https://review.openstack.org/5406106:02
*** mattymo has joined #openstack-infra06:02
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Make ChangeLog more condensed  https://review.openstack.org/5236706:05
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Let git do mailmap mapping for us  https://review.openstack.org/5405006:05
openstackgerritA change was merged to openstack-infra/config: Add havana branch to gerritbot for #openstack-doc  https://review.openstack.org/5319206:11
openstackgerritA change was merged to openstack-infra/config: add stable/grizzly for openstack-chef cookbooks  https://review.openstack.org/5241606:12
*** davidhadas_ has quit IRC06:16
*** tian has joined #openstack-infra06:18
lifelessmordred: cool06:46
*** vipul is now known as vipul-away06:57
*** davidhadas has joined #openstack-infra07:01
*** matsuhashi has quit IRC07:02
*** matsuhashi has joined #openstack-infra07:02
*** amotoki has joined #openstack-infra07:03
*** nosnos_ has quit IRC07:05
*** ryanpetrello has quit IRC07:05
*** nosnos has joined #openstack-infra07:05
*** matsuhashi has quit IRC07:07
*** matsuhashi has joined #openstack-infra07:07
rakhmerovmordred: could you please have a look at https://review.openstack.org/#/c/51205? Most likely you'll disapprove it for a couple of things, but I want to make sure before sending another patchset :)07:09
*** ljjjustin has quit IRC07:10
*** ben_duyujie has joined #openstack-infra07:16
*** ljjjustin has joined #openstack-infra07:21
*** ljjjustin has quit IRC07:28
*** davidhadas_ has joined #openstack-infra07:32
*** davidhadas_ has quit IRC07:32
*** davidhadas has quit IRC07:33
*** davidhadas has joined #openstack-infra07:34
*** DinaBelova has joined #openstack-infra07:44
*** dkliban has joined #openstack-infra07:49
*** flaper87|afk is now known as flaper8708:01
*** dkliban has quit IRC08:02
*** ben_duyujie has quit IRC08:02
*** davidhadas_ has joined #openstack-infra08:02
*** davidhadas has quit IRC08:02
*** nati_ueno has quit IRC08:09
*** matsuhashi has quit IRC08:09
*** nati_ueno has joined #openstack-infra08:09
*** matsuhashi has joined #openstack-infra08:10
*** matsuhas_ has joined #openstack-infra08:12
*** tkammer_ has joined #openstack-infra08:12
*** matsuhashi has quit IRC08:13
*** nati_ueno has quit IRC08:13
*** yamahata has quit IRC08:19
*** marun has joined #openstack-infra08:22
*** che-arne has joined #openstack-infra08:24
ogelbukhyay, now we have the change request: https://review.openstack.org/#/c/53858/08:26
*** boris-42 has quit IRC08:28
*** che-arne has quit IRC08:32
*** dizquierdo has joined #openstack-infra08:43
*** alexpilotti has joined #openstack-infra08:43
*** Bada has joined #openstack-infra08:45
*** marun has quit IRC08:47
*** denis_makogon has quit IRC08:49
openstackgerritAndreas Jaeger proposed a change to openstack-infra/config: Split Install Guide into Debian and Ubuntu guides  https://review.openstack.org/5407608:52
*** hashar has joined #openstack-infra08:54
*** DinaBelova has quit IRC09:02
*** marun has joined #openstack-infra09:06
*** yassine has joined #openstack-infra09:12
openstackgerritDzmitry Horbach proposed a change to openstack-infra/jenkins-job-builder: Added default value of -1 for all logrotate attributes  https://review.openstack.org/5407909:19
*** ljjjustin has joined #openstack-infra09:19
*** fallenpegasus has quit IRC09:22
*** fbo_away is now known as fbo09:23
*** fallenpegasus has joined #openstack-infra09:27
katyaferventmordred, Hi) I have tiny question) Do we need someone else approval or it may happened that somebody forget to check approved?) Please take a look here https://review.openstack.org/#/c/52092/09:28
ekarlso-Anyone care to sign off on this ? https://review.openstack.org/#/c/51066/09:30
ekarlso-it's been there for 2 weeks and is pretty small :)09:30
*** ljjjustin has quit IRC09:32
*** bingbu has quit IRC09:32
*** dkliban has joined #openstack-infra09:34
*** boris-42 has joined #openstack-infra09:36
*** dizquierdo has quit IRC09:36
*** saschpe has quit IRC09:36
*** saschpe has joined #openstack-infra09:40
*** che-arne has joined #openstack-infra09:40
*** xchu has quit IRC09:47
*** SergeyLukjanov has quit IRC09:50
*** SergeyLukjanov has joined #openstack-infra09:51
*** SergeyLukjanov has quit IRC09:51
*** DinaBelova has joined #openstack-infra09:54
*** matsuhas_ has quit IRC09:58
*** matsuhashi has joined #openstack-infra09:59
*** matsuhashi has quit IRC10:03
openstackgerritPeter Liljenberg proposed a change to openstack-infra/jenkins-job-builder: Added support for Jenkins plugin Blame upstream committers  https://review.openstack.org/5408510:06
*** pcm_ has joined #openstack-infra10:10
*** davidhadas_ has quit IRC10:12
*** pcm_ has quit IRC10:12
*** pcm_ has joined #openstack-infra10:12
SteapHey, I'm not familiar with StackForge and have just read this comment: https://review.openstack.org/#/c/53306/6/modules/openstack_project/files/gerrit/acls/stackforge/sphinxcontrib-docbookrestapi.config . Grepping through the sources, I'm under the impression that not many projects use a "-ptl" group, am I right ?10:18
SteapSince I don't think my project will be extremely huge, is it fine to keep a "-core" group for the "pushTag" action, and move to "-ptl" if, for some reason, it becomes quite big ?10:19
*** amotoki has quit IRC10:37
*** davidhadas has joined #openstack-infra10:48
*** shardy has joined #openstack-infra10:50
mattymottx, ping10:52
*** nosnos has quit IRC10:53
ttxmattymo: pong10:53
*** nosnos has joined #openstack-infra10:54
mattymottx, I saw your reply about #openstack-fuel10:56
mattymottx, think it's worth waiting for others to voice their opinion on this or just agree that your view is what the majority will hold?10:56
ttxmattymo: probably worth waiting10:57
ttxmattymo: have no idea what the others think about that10:57
*** ArxCruz has joined #openstack-infra10:58
*** nosnos has quit IRC10:58
mattymottx, I was hoping the fact that Mirantis is a foundation member and that we're in stackforge that it would influence the group10:59
mattymobut of course a line must be drawn somewhere10:59
*** guohliu has quit IRC11:10
ekarlso-anyone here familiar with the config file generation stuff ?11:10
ekarlso-https://review.openstack.org/54101 < I do "./tools/config/generate_sample.sh -b ./ -p libra -o etc" and I get "RuntimeError: Unable to find group for option daemon, maybe it's defined twice in the same group?"11:15
*** flaper87 is now known as flaper87|afk11:15
*** DinaBelova has quit IRC11:20
*** dizquierdo has joined #openstack-infra11:22
*** davidhadas has quit IRC11:30
*** davidhadas has joined #openstack-infra11:31
*** dims has joined #openstack-infra11:34
*** Bada has quit IRC11:40
*** Bada has joined #openstack-infra11:41
*** adalbas has joined #openstack-infra11:46
*** fallenpegasus has quit IRC11:49
jog0grenade is trying to upgrade from grizzly11:49
*** davidhadas has quit IRC11:49
jog0sdague: ^11:49
*** davidhadas has joined #openstack-infra11:50
sdaguejog0: yes, it is11:50
sdaguethere is a whole bunch of stuff in process to try to fix that11:50
jog0sdague: is that why grenade is failing ATM?11:50
sdaguejog0: I don't know11:50
jog0or at least making the issue worse11:50
jog0sdague: http://logs.openstack.org/59/53859/5/check/check-grenade-devstack-vm/2bea2b1/11:51
sdaguethat's a failure to validate old11:52
sdagueit's not even tried to upgrade11:52
sdaguesomeone broke agregates in grizzly?11:52
jog0sdague: right, but its a grizzly failure11:52
* jog0 pulls up griz git logs11:52
jog0this may explain how the issue got in.  do we run grenade on stable branches?11:53
sdagueno, again, spent many days working on this last week :)11:53
sdagueto try to get us there, bug apparently someone managed to break it first11:53
jog0sdague: btw I saw your email blogs this weekend, do you ever take time off?11:53
*** luisg has quit IRC11:54
sdaguesometimes :) honestly my brain really wanted to work through some of these issues this weekend11:54
*** luisg has joined #openstack-infra11:54
jog0we need more people like you11:54
sdagueI find that I just let my interest take me where it wants, otherwise I just end up doing one thing but thinking about something else11:54
*** fallenpegasus has joined #openstack-infra11:55
jog0https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:stable/grizzly,n,z11:55
jog0nothing looks obvious in that list, or even timewise11:56
*** simonmcc has quit IRC11:56
*** simonmcc has joined #openstack-infra11:56
jog0sdague: where is grenade configured to set old=grizzly11:56
*** fallenpegasus has quit IRC11:56
*** dkranz has joined #openstack-infra11:57
sdaguedevstack-gate11:58
sdaguethis is the change we need to get sorted - https://review.openstack.org/#/c/53940/11:58
sdaguebut that's having issues at the moment, and not sure why11:58
sdaguealso there are related grenade changes, look for the changes by mauro11:59
jog0sdague: so grenade isn't version agnostic?12:00
sdagueno, it includes the specific fixups needed to get between two versions12:01
* jog0 cries a little12:01
sdaguebecause, you can't upgrade openstack without that12:01
jog0sigh12:01
*** fallenpegasus has joined #openstack-infra12:01
sdaguehey, more hands making all services roll forward with no changes required to configs, appreciated :)12:02
jog0sdague: hope to work on that for TripleO in the next few months12:02
jog0but in the CD story12:02
sdaguethe point of grenade was at least we'd have them all documented12:02
sdagueyeh, I still don't see how you get around some of it12:02
jog0sdague: yeah I am not disagreeing just sad12:02
sdaguelike turning on v3 api12:02
jog0sdague: anyway back to the critical issue unbarring gate12:03
jog0unbreaking*12:03
sdagueso the aggregates call fails12:03
jog0sdague: but why12:03
sdaguehttp://logs.openstack.org/59/53859/5/check/check-grenade-devstack-vm/2bea2b1/console.html#_2013-10-28_10_41_58_612 is the problem, I think12:04
jog0we know this broke about 6 hours ago12:04
jog0grenade uses trunk clients right?12:07
sdaguethe exercises, yeh12:08
sdagueoh, look at that12:08
sdaguecommit a1391b2ead18c617bc5ce373a621f8a74c9cd95212:08
sdagueMerge: fbb01be 6374ee012:08
sdagueAuthor: Jenkins <jenkins@review.openstack.org>12:08
sdagueDate:   Mon Oct 28 06:57:07 2013 +000012:08
sdague    Merge "Nova aggregate-details should be more human friendly"12:08
sdaguelast commit in python-novaclient12:08
jog0sdague: I tried taht12:08
jog0I tried reverting12:09
jog0didn't fix12:09
sdagueand?12:09
jog0https://review.openstack.org/#/c/54105/12:09
jog0I checked jenkins for the results so they didn't get pasted back12:09
jog0that 409 is expected12:11
jog0here is a passing grenade http://logs.openstack.org/35/51135/5/check/check-grenade-devstack-vm/fa4fcb1/console.html12:11
jog0http://logs.openstack.org/35/51135/5/check/check-grenade-devstack-vm/fa4fcb1/console.html#_2013-10-28_03_31_36_67012:12
jog0this may be a dep issue12:12
jog0sdague: pypi was updated around the time things started dying (6AM) http://pypi.openstack.org/openstack/?C=M;O=D12:13
sdagueactually, I'm pretty sure it's that nova client change12:13
sdagueI'm going to push the revert again12:13
jog0sdague: can't hurt12:14
sdagueand let everything run through to see12:14
jog0sdague: hold on12:14
jog0I'll unabandon and recheck12:14
sdaguenova aggregate-details $AGGREGATE_ID | egrep "{u'availability_zone': u'$AGGREGATE_A_ZONE'}|{}"12:15
sdaguejog0: I did another push already of the revert12:15
jog0sdague: just noticed12:15
sdaguebut that's the line where we die, so the fact a display change was pushed would definitely trigger that12:16
jog0https://jenkins02.openstack.org/job/check-grenade-devstack-vm/3467/consoleFull12:17
jog0that was the output from my patch12:17
*** dprince has joined #openstack-infra12:18
jog0plus that change should have been self-gating12:18
jog0scratch tat12:18
jog0no it should have: https://review.openstack.org/#/c/50438/12:18
sdagueso assuming this passes - https://review.openstack.org/#/c/54111/1 - I'll push that in12:22
sdagueit will at least give us more info12:22
*** weshay has joined #openstack-infra12:22
jog0sdague: cool12:23
jog0sdague: yours failed too http://status.openstack.org/zuul/12:26
jog0any chance we are seeing an async issue?12:26
jog0http://logs.openstack.org/59/53859/5/check/check-grenade-devstack-vm/2bea2b1/logs/pip-freeze.txt.gz12:27
jog0and aren't actually using proposed change to novaclient?12:28
sdagueyeh, that's what I'm thinking12:28
jog0sdague: GAH12:28
jog0http://logs.openstack.org/59/53859/5/check/check-grenade-devstack-vm/2bea2b1/console.html#_2013-10-28_10_39_07_14512:28
sdaguethat's going to need more experienced folks than I12:28
katyaferventfungi, Thanks a lot!)12:30
openstackgerritA change was merged to openstack-infra/config: Add murano-metadataclient to stackforge  https://review.openstack.org/5209212:30
fungiSteap: it's fine if your core group is just going to be a couple of people who will participate in tagging releases on it. and my other concern on that change (pypi registration) seems addressed now12:30
sdaguejog0: yeh, so we knew that this assymetric with stable was going to eventually be a problem12:31
sdagueso I guess we know that it is today12:31
sdagueis this a jeblair vacation week?12:32
jog0also its using github?12:32
jog0sdague: yup12:32
jog0in the Scottish Highlands12:32
sdaguejog0: no, I don't think so12:32
jog0http://logs.openstack.org/59/53859/5/check/check-grenade-devstack-vm/2bea2b1/console.html#_2013-10-28_10_41_55_28512:32
sdaguejog0: yeh, but the trees are preppred in the wrap script12:33
jog0?12:34
Steapfungi: yes :)12:36
*** thomasem has joined #openstack-infra12:36
Steapfungi: honestly, I'm currently the  only member of the project; I'll probably be joined by some Ceiloemter devs, but I doubt we'll ever be "a lot of people"12:36
sdaguejog0: we're never actually cloning in grenade12:37
sdaguein the gate, all the trees are created for us12:37
*** alaski has joined #openstack-infra12:37
fungikatyafervent: no problem. i expect he didn't approve on +2 simply because he was on an airplane at the time12:38
fungiSteap: sounds good, and i see the pypi registration looks correct. thanks!12:38
Steapfungi: np :)12:39
Steapfungi: thx for the review12:39
jog0sdague: but you clone the other repos still right?12:39
sdaguenot in the gate12:40
sdaguethe entire environment is set up in advanced by the devstack-gate wrapper scripts12:40
jog0ohh the git_clone script doesn't clone git haha12:41
sdagueyeh12:41
sdagueit's a function for a reason, and it has a lot of ways to bail early12:41
sdaguewhich we take advantage of12:41
sdagueso yeh, it's the novaclient change12:41
sdagueit changed formatting12:41
sdaguefungi: can you ninja merge something for us?12:41
fungisdague: i can12:42
sdaguehttps://review.openstack.org/#/c/54108/12:42
jog0sdague: can we fix gate to pull that in instead?12:42
fungithe novaclient revert?12:42
sdaguefungi: yeh12:42
jog0to use novaclient proposed change in grenade?12:42
sdaguejog0: it will probably take days to get that sorted correctly, especially with jeblair not around12:42
jog0sdague: but don't we do that for other projects already12:43
sdaguejog0: we've never sorted out the stable side of the grenade equation12:43
jog0sdague: this isn't stable this is clients12:43
sdaguethis was actually the thing I was working on for two days last week :)12:43
fungiyeah, if the grenade job is currently using released novaclient when testing novaclient, i agree the gate breakage isn't going to be immediately fixable without an override.12:43
sdaguejog0: except.... I don't think the old tree is actually getting latest changes12:44
sdaguethere are two issues of stable side, stable jobs, and the stable /...../old/... tree12:44
sdaguehonestly, this is matrix hell in some ways to get all the moving parts sorted :)12:45
sdaguefungi: so lets see if the novaclient revert gets us sorted, then we can deal with the rest of it when we aren't on fire12:46
fungiit's merged now12:46
jog0sdague: sounds good to me12:47
jog0didn't realize how bad it was12:47
sdaguefungi: cool, thanks12:47
jog0sdague: want to send the ML response out saying life is good again12:47
sdagueyeh, it's going to be a rough week with jeblair gone and mordred on a plan again to somewhere12:47
*** flaper87|afk is now known as flaper8712:47
sdaguejog0: only once we know that it is12:47
sdaguehttps://review.openstack.org/#/c/54111/ - recheck, should be a good test12:47
jog0sdague: heh I had no idea how delicate this stuff was12:48
jog0btw why doesn't neutron have grenade?12:49
jog0do we not have a neutron version?12:49
sdaguebecause grenade only really checks 5 services - nova, cinder, swift, keystone, glance12:51
sdagueand runs in nova-network mode12:51
jog0more matrix hell :)12:52
sdagueyeh, and honestly, until neutron can run under tenant isolation, parallel, and a full tempest run, thinking it might upgrade test well... is *optimistic*12:52
jog0sdague: fair enough12:53
*** yamahata has joined #openstack-infra12:55
*** anteaya has joined #openstack-infra12:55
sdagueand, basically there are very few people that help with grenade, so coverage is what it is12:55
*** lnxnut has joined #openstack-infra12:57
jog0sdague: which 'project' ownes it?12:58
jog0ci devstack qa?12:58
sdagueqa12:58
sdaguethe reality is it's me and dtroyer, and whoever else I can con into helping :)12:59
ArxCruzclarkb: fungi can you guys help me with a zuul/jenkins issue ?12:59
sdaguethat set of ci stats for openstack really made the rounds yesterday13:00
jog0sdague: I may have conned myself into helping -- I want to get the RPC / rolling upgrade test up13:00
jog0but using grenade will be a bit of a burdon at least at first13:00
sdaguehonestly, with the complexity of getting the gate setup correctly for 2 trees, I think the only sane path is to work it into grenade scope13:01
*** zul has quit IRC13:02
sdagueI really think any other approach just ends up building a grenade like fork of a thing, which is then 2 upgrade test frameworks with not enough reviewers to handle the crazy matrix13:02
sdaguei.e. this is a harder problem than you realize, to make it gate friendly13:03
*** ericw has joined #openstack-infra13:03
*** lnxnut has quit IRC13:04
*** dripton has joined #openstack-infra13:04
*** julim has joined #openstack-infra13:04
jog0sdague: its not an upgrad test at first13:04
jog0its a RPC compat test13:04
sdaguejog0: I get that13:04
*** lnxnut has joined #openstack-infra13:04
sdaguebut it is a test that needs 2 different versions of openstack checked out13:05
jog0sdague: but yeah I tend to agree, in the long term for sure13:05
jog0in the short term not sure13:05
sdagueas you can see... getting that right in the gate is hard13:05
*** zul has joined #openstack-infra13:05
sdaguestarting over from scratch on that is just silly13:05
*** lnxnut has quit IRC13:05
*** lnxnut has joined #openstack-infra13:06
sdaguebecause you'll just end up having learn, the hard way, all the things you need to do to make that work right in the gate13:06
sdagueand build another crazy set of ifdefs in devstack-gate13:06
*** ruhe has joined #openstack-infra13:06
*** fallenpegasus has quit IRC13:06
jog0sdague: I did POC that ran after devstack finished13:07
jog0not during ... eww13:07
jog0anyway we don't have to sort this out now13:08
jog0won't happen before summit anyway13:08
*** lnxnut has quit IRC13:10
*** lnxnut has joined #openstack-infra13:10
fungiArxCruz: what's the issue?13:11
*** fallenpegasus has joined #openstack-infra13:11
*** lnxnut has quit IRC13:15
anteayasdague: that blog post was great13:15
anteayafor those who haven't seen it yet: http://dague.net/2013/10/27/openstack-ci-by-the-numbers/13:16
*** annegentle has joined #openstack-infra13:18
*** b3nt_pin has joined #openstack-infra13:20
*** b3nt_pin is now known as beagles13:20
*** guohliu has joined #openstack-infra13:20
sdaguejog0: the thing is, if your setup ever relies on "then we git clone" ... -2, because zuul has to do all the cloning in the gate13:21
sdagueor git anything, honestly13:21
jog0sdague: :(13:22
fungisdague: well, you can clone and then fetch the zuul ref passed in as an envvar13:22
sdaguezuul has to set up all the refs13:22
*** mriedem has joined #openstack-infra13:22
jog0the basic worflow I tested was: given a devstack13:22
sdaguefungi: yeh, but the reality is zuul needs to do all the tree setup13:22
jog0checkout grizzly, kick nova-compute, run tempest13:23
*** SergeyLukjanov has joined #openstack-infra13:23
sdaguejog0: so how do you know to checkout grizzly?13:23
jog0sdague: on my own env 'git checkout ...'13:23
sdagueand what if it's actually supposed to be a gerrit tree13:23
sdaguebecause it's a grizzly change13:24
jog0sdague: yeah ... I agree13:24
sdagueand what if there is code in the nova tree which hasn't dynamically loaded yet13:24
jog0anyway lets punt this to a HK chat13:24
sdaguesure :)13:24
sdaguebut I'm a big -2 on another framework here :)13:24
sdagueand you are going to need a lot of evidence that grenade *can't* be made to cover this issue to get me to change my mind13:25
fungithinking through the latest excitement and how it specifically could have been prevented, i think once there are proper backward-compat jobs running for clients (so that the novaclient change in question would have failed to merge because it broke stable/grizzly, right?) this specific bit of the pain could be avoided?13:25
sdagueso, I actually know why the current situation failed13:25
sdaguebecause I was in this code friday, I just didn't understand this until then13:25
sdaguebut we currently *never* set zuul refs on old13:25
* fungi goes to find and review the client backward-compat testing change again13:26
*** jgriffith has quit IRC13:26
sdaguewhich is basically the issue13:26
sdagueand I think it might be subtle about how we do that13:26
sdagueas the gate has never been set up to do tat13:26
*** jgriffith has joined #openstack-infra13:27
fungisdague: what if there was already a separate job which ensured that what was set up for old was functional? (e.g. backward-compat devstack tempest-full)13:27
sdagueso old actually was functional13:27
jog0mordred: is working on that AFAIK13:28
*** SergeyLukjanov has quit IRC13:28
sdaguefungi: maybe that's a beer conversation?13:28
sdagueso here's the thing13:28
*** SergeyLukjanov has joined #openstack-infra13:28
sdagueeven in the best of cases, we are probably only testing 20% of surface13:29
fungioh, was it only grenade tripping over the change in novaclient behavior and devstack-tempest on the starting stable branch would have been fine? if so, yeah that's a different kettle of fish13:29
fungijog0: yes, he is, i was merely recalling that i need to review it again13:29
zulno new pbr yet?13:29
jog0greande is working again https://review.openstack.org/#/c/54092/13:29
fungizul: i thought he tagged it yesterday13:30
sdagueso I remain skeptical that we could keep the kind of throughput that we have today if we pulled the base case validation further away from the tests13:30
zulfungi: still not pypi13:30
sdaguebecause it's not like we have 100% behavior definition13:30
jog0sdague: want to respond to the ML thread or should I13:30
fungizul: i see it as 0.5.22 (uploaded today, utc)... https://pypi.python.org/pypi/pbr13:30
sdaguejog0: I need to head to the office, so go for it (back on in 30)13:30
jog0kk13:30
zulfungi:  oh duh i totally need more caffine13:31
fungizul: me too, me too13:31
*** rpodolyaka has left #openstack-infra13:40
fungibodepd_: on https://review.openstack.org/51079 you're importing a git repository which has what look like a bunch of topic branches in it. those will be imported automatically with it unless you a) delete them there first or b) point your review.projects.yaml.erb entry at a fork with only the branch(es) you want imported13:42
*** jaypipes has joined #openstack-infra13:45
*** SergeyLukjanov has quit IRC13:47
fungibodepd_: i'll follow up in the review since you're probably not in the office yet13:49
mattymofungi, fyi bodepd_ was online until 3am your time. he might not show up for a few hrs13:51
fungimattymo: yeah, that was only midnight his time13:52
fungii had merely forgotten for a moment which tz he's in13:52
mattymoit happens13:52
mattymofungi, regarding my channel request, it looks like I have resistance on both sides13:52
mattymo#fuel was registered by someone 7 years ago so I get to wait for freenode staff to review and convert it13:53
fungimattymo: i feel bad--i'm so far behind on ml threads i haven't actually read it yet. taking a review break to look at it now13:53
*** SergeyLukjanov has joined #openstack-infra13:54
*** nati_ueno has joined #openstack-infra13:54
fungioff-topic rant... shell server vm on a host which is rebuilding its software raid-1 after a failure. i/o starvation city: population me13:56
mattymoas we say in Russia, it's normal13:56
*** DinaBelova has joined #openstack-infra13:57
zulfungi: heh13:59
*** beekneemech is now known as bnemec14:00
fungizul: i would call the sysadmin and yell at him, but yelling at myself isn't going to solve anything i'm afraid14:00
rakhmerov:)14:00
*** nati_ueno has quit IRC14:00
*** nati_ueno has joined #openstack-infra14:01
zulfungi:  you could look at yourself in the mirror and then start to yell14:01
*** boris-42 has quit IRC14:02
*** b3nt_pin has joined #openstack-infra14:02
sdaguefungi: you got some time today to help on diving through the d-g scripts to see if we can come up with a "once and for all" approach that would have preventing the novaclient break?14:02
*** dcramer_ has joined #openstack-infra14:03
rakhmerovfungi: thanks for reviewing Mistral stuff at https://review.openstack.org/#/c/51205. I have a question on that. You left some comments some time ago and after that it's been there for a while and nobody else reviewed it. Do you think it makes sense to wait a little longer or it's better to fix those non-critical (if I understood your overall feedback) asap? Just not sure what to do next :(14:03
*** yamahata has quit IRC14:05
*** nati_ueno has quit IRC14:05
*** oubiwann has joined #openstack-infra14:06
fungisdague: if i understand the problem you're trying to solve, i don't think it can be done with one job14:06
*** yamahata has joined #openstack-infra14:06
fungiat least not trivially14:06
*** fallenpegasus has quit IRC14:07
fungiconsider, for a client/library change you want grenade to test two things... that the change isn't breaking the base scenario, and that the change works when applied to the upgraded version14:07
fungiwell, actually i guess with libraries, you're not actually testing an upgrade of the library right?14:08
sdaguecorrect14:08
sdaguewhat I'm trying to do is prevent this wedge14:08
fungionly upgrades of servers14:08
sdagueand what I'm trying to figure out is if setting 0 => 1 there is going to ruin the world - https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate-wrap.sh#L49014:09
*** alcabrera has joined #openstack-infra14:09
fungiso we need to use the proposed change, if it's a library, in both the base scenario and the upgraded one. but if it's a server we only want the change in one or the other (in the base scenario for a stable branch test and in the upgraded scenario for a master branch change)14:09
sdagueright, well the issue right now is on "old" we never update with zuul refs14:10
sdagueever14:10
sdaguewhich is how we got the wedge14:10
sdagueas novaclient was able to run through old verification with an old version, and new verification is different tests14:10
fungiokay, and doing so is going to require that the base scenario setup considers the zuul branch (to decide whether this is a test on stable or master so we know which direction we're testing in) and the zuul project (so we can decide whether it's one which gets the zuul ref in only one scenario or both)14:12
*** fallenpegasus has joined #openstack-infra14:12
*** ruhe has quit IRC14:14
*** oubiwann_ has joined #openstack-infra14:15
funginote i'm mainly thinking in terms of "upgrade from change on stable" just to make sure we don't paint ourselves into a hole which makes that harder to implement later. i know it's not actually being done yet14:15
sdagueyeh, though I actually think it's all related14:16
fungidig ourselves into a corner, whatever ;)14:16
sdaguethe point being, we have 2 trees14:16
sdagueand we get a zuul change in14:16
sdagueactually, let's etherpad this14:16
fungidefinitely14:17
sdaguehttps://etherpad.openstack.org/p/dg-for-grenade14:17
mordredmorning all14:17
anteayamorning14:17
*** oubiwann has quit IRC14:17
*** dkliban has quit IRC14:19
sdaguemordred: so, it finally hit us, the stable upgrade grenade wedge14:20
*** b3nt_pin has quit IRC14:20
mordredsdague, fungi: I am not fully awake enough to be super helpful yet14:20
sdaguefungi: honestly that third thing is the thing I'm scared about understanding14:20
mordredbut, I think we have to consider zuul refs for both old and new14:20
sdaguewhen we have a deep zuul queue14:20
fungimordred: sdague yep14:20
*** beagles has quit IRC14:21
mordredI don't think the 3rd thing is too terrible14:21
sdaguefungi: so if we blindly just say "apply to old" are we smart enough to only do that with the right branches?14:21
fungisdague: there is logic in devstack which does that14:21
*** b3nt_pin has joined #openstack-infra14:21
fungior rather in devstack-gate i think14:21
*** b3nt_pin is now known as beagles14:21
fungifirst tries to find the zuul ref on the target branch then falls back14:21
mordredoh - you know what - jeblair and I already kinda stepped through the logic on this a little bit for the stable-client code14:21
*** oubiwann_ is now known as oubiwann14:22
sdaguemordred: ok, cool14:22
mordredI think. I'm still caffinated14:22
mordreduncaffinated14:22
sdaguefungi: yeh I guess it's unclear to me if the fallback branch is doing the right things, or only covers the client case14:23
fungisdague: well, i think the fallback branch selection gets more complex in grenade14:23
*** ruhe has joined #openstack-infra14:23
*** markmcclain has joined #openstack-infra14:24
fungibut point was we can use similar logic around the zuul ref existing, we just need to have a bit more work surrounding fallback branch selection14:24
*** SergeyLukjanov is now known as _SergeyLukjanov14:24
*** _SergeyLukjanov has quit IRC14:24
*** fifieldt has quit IRC14:24
*** senk has joined #openstack-infra14:25
*** johnthetubaguy1 has joined #openstack-infra14:25
*** ryanpetrello has joined #openstack-infra14:26
*** rcleere has joined #openstack-infra14:26
*** dkliban has joined #openstack-infra14:27
*** johnthetubaguy1 is now known as johnthetubaguy14:27
sdagueyeh, man, I want to really refactor the wrap script to make it make more sense to me. I'm so used to our heavy function style in devstack14:27
*** datsun180b has joined #openstack-infra14:27
fungiwell, it *is* self-gating, now backward on on stable release branches of tempest jobs too14:28
*** che-arne has quit IRC14:28
fungiso if we want to refactor it some, we can have a fair amount of confidence we're not breaking the gate (though less confidence that it's still testing the things we think it's testing)14:29
*** senk has quit IRC14:30
anteayarakhmerov: I would suggest that you address fungi's comments with a new patchset14:30
anteayabasically his comments amount to, "This patch won't achieve your goal the way it is written."14:31
rakhmerovanteaya: ok, will do14:33
rakhmerovthanks14:33
anteayanp14:33
anteayathought I would jump in since he is in the middle of another conversation14:33
fungiyeah, i'm reading back over what i wrote now. it may work as written, but i don't know14:33
*** senk has joined #openstack-infra14:36
*** SergeyLukjanov has joined #openstack-infra14:36
*** prad_ has joined #openstack-infra14:36
*** davidhadas_ has joined #openstack-infra14:37
*** davidhadas has quit IRC14:39
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: extract git_checkout into common function  https://review.openstack.org/5413214:40
*** che-arne has joined #openstack-infra14:40
*** davidhadas_ has quit IRC14:41
*** wenlock has joined #openstack-infra14:43
*** beagles has quit IRC14:44
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: move single host setup activities to setup_host  https://review.openstack.org/5413314:45
ArxCruzALL: I'm listening review.openstack.org in my intern infrastructure, and my zuul is returning ZUUL_REF with a Z in front which make my jobs fail since it can't find the ref. I'm using layout.yaml from dev just to listen instead of send reviews back to review.openstack.org. Does anyone know what's could be wrong?14:46
*** yamahata has quit IRC14:47
mordredArxCruz: zuul keeps its own copies of the repos where it constructs the refs to be changed14:48
*** fallenpegasus has quit IRC14:48
fungiArxCruz: zuul refs have a Z at the start of their name so we can tell them apart from other refs (branches, tags, shas...)14:48
mordredArxCruz: you need to make sure that you clone/fetch from your zuul14:48
*** vipul-away is now known as vipul14:48
ArxCruzmordred: and how I do that? where do i configure it ?14:49
mordredArxCruz: in whatever job zuul is triggering, you need to fetch the ZUUL_REF right?14:49
mordred(you are already trying to do that, because you said it's failing)14:49
fungiArxCruz: if you follow the puppetry for our zuul.openstack.org configuration, you'll see we have apache serving git repositories for it14:49
mordredwhen you do that, point it at your zuul14:49
ArxCruzmordred: fungi i'm cloning to my zuul, when zuul start he's cloning to /var/lib/zuul/git in my server14:50
mordredArxCruz: yes. that's right14:50
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: Let us gate grenade forward  https://review.openstack.org/5394014:50
mordredArxCruz: your jobs need to fetch the Z refs from the repos in /var/lib/zuul/git14:51
ArxCruzmordred: okay, i will check here14:51
ArxCruzby the way, there's a z repository here that's failing, is that okay ?14:51
mordredI don't know what you mean be failing?14:51
fungii don't know what you mean by a z repository14:52
mordredsdague: Co-Authored-With: ... our AUTHORS script checks for Co-Authored-By: ... should it check for both?14:52
sdaguemordred: doh14:52
sdaguelet me fix14:52
ArxCruzERROR zuul.Repo: Unable to initialize repo for ssh://arxcruz@review.openstack.org:29418/z/tempest14:52
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: Let us gate grenade forward  https://review.openstack.org/5394014:52
ArxCruzfungi: mordred ^14:52
*** mrodden has joined #openstack-infra14:53
*** b3nt_pin has joined #openstack-infra14:53
*** fallenpegasus has joined #openstack-infra14:53
mordredArxCruz: what's z/tempest ?14:56
ArxCruzmordred: nevermind, it's just a project in layout.yaml in zuul-dev14:56
ArxCruz:)14:56
mordred:)14:56
fungiArxCruz: i'd need to read back through the zuul source, but first guess is that there's a config option to specify the path to where you want zuul to build its working repositories and you've specified ssh://arxcruz@review.openstack.org:29418/z as the path?14:56
ArxCruzfungi: i didn't specify nothing :) just puppet it14:57
fungiph, that14:57
*** b3nt_pin is now known as beagles14:57
fungioh, that14:57
ArxCruzin layout.yaml have a project z/tempest14:57
fungiz/tempest is a fake project to force shared queues for the jobs in it14:57
*** senk has quit IRC14:58
fungii bet we have the same error in our zuul logs at startup14:58
*** senk has joined #openstack-infra14:58
*** senk has quit IRC14:58
*** senk has joined #openstack-infra14:59
*** dcramer_ has quit IRC15:00
openstackgerritMatthew Mosesohn proposed a change to openstack-infra/config: add fuel-dev channel to gerritbot  https://review.openstack.org/5365615:00
*** Ryan_Lane has quit IRC15:00
*** xeyed4good has joined #openstack-infra15:01
*** xeyed4good has left #openstack-infra15:01
ArxCruzfungi: mordred it seems the problem is in devstack-vm-gate-wrap.sh15:02
ArxCruzexport ZUUL_URL=${ZUUL_URL:-http://zuul.openstack.org/p}15:02
mordredyes. you'll want to set ZUUL_URL to point to your zuul instead of our zuul15:02
ArxCruzmordred: okay, the problem is that my vm is being created on demand through nodepool15:03
ArxCruzthere's no way to set that automatically15:03
ArxCruzcorrect ?15:03
mordredsure there is15:03
*** nati_ueno has joined #openstack-infra15:03
mordredwhat's calling devstack-vm-gate-wrap.sh ?15:03
ArxCruzthe jenkins job15:03
mordredyup. so set it in the jenkins job15:03
ArxCruzmordred: aha! but, if I do that, next time puppet service begin, it will fix that ;D15:04
ArxCruzgot it ?15:04
mordredArxCruz: set it in the jenkins-job-builder description of the job15:04
mordredso that puppet sets it15:04
ArxCruzmordred: i didn't get it :/15:05
mordredArxCruz: you have a set of yaml files in your local env that contain the descriptions of the jenkins jobs, right?15:05
mordredArxCruz: such as one called devstack-gate.yaml ?15:05
ArxCruzmordred: yes15:06
mordredArxCruz: so edit them, and before it calls devstack-vm-gate-wrap.sh, do "export ZUUL_URL=http://my.local.zuul.server/p"15:06
*** changbl has quit IRC15:06
mordredArxCruz: then puppet will see the change, apply it to your jenkins, and when jenkins tries to run the script, it will set the ZUUL_URL for you15:07
ArxCruzmordred: I got it, thanks15:07
mordredfungi: ^^ we may want to think about a way to parameterize that interaction slightly better15:07
*** dcramer_ has joined #openstack-infra15:07
ArxCruzmordred: yes! need it :)15:07
mordredfungi: in terms of people like ArxCruz setting up local testing15:07
mordredfungi: especially for the ones who do the thing we tell them they shoudl do - which is just use a copy of our stuff :)15:08
*** UtahDave has joined #openstack-infra15:09
ArxCruzmordred: and it's pretty easy to set15:09
fungimordred: it is absolutely the case that we have lots of silent defaults to our own settings in various places, which makes them less discoverable since we don't need to set them in our configs15:09
mordredyup15:09
* mordred bets wenlock has found many of those :)15:09
ArxCruzI can change the yaml to export ZUUL_URL=<? some_config >15:09
ArxCruzif there's no some_config15:10
mordredwenlock: speaking of - when you get to zuul, you may hit this ^^15:10
*** reed has joined #openstack-infra15:10
ArxCruzthe export ZUUL_URL=${ZUUL_URL:-http://zuul.openstack.org/p} line in devstack-vm-gate-wrap.sh will change it to the default one15:10
mattymofungi, I already managed to get #fuel registered. It seemed much harder to just go around you guys than to go through15:10
mordredArxCruz: you could - except I don't think we're doing any of our jenkins_job_builder things as templates, only as raw files15:10
mattymoerr much easier just to go around*15:10
wenlockreading back...15:10
wenlockindeed we have hit this!15:10
*** SergeyLukjanov has quit IRC15:10
wenlockwe were going to ask for help this week on that15:11
ArxCruzi found this issue with zuul before, and what I did was a workaround let me show you15:11
mordredheh. great timing15:11
openstackgerritsebastian marcet proposed a change to openstack-infra/config: Review and create Puppet configuration for dev server blueprint sso-openid-provider  https://review.openstack.org/5364415:11
ArxCruzmordred: i did it: http://paste.openstack.org/show/50058/15:12
fungimattymo: yeah, it's become a bit of a pain point now that we have 80 stackforge projects and counting15:12
mordredmattymo: there are a few things we haven't designed for with stackforge popularity - irc channels are clearly one of them :)15:12
ArxCruzso, I ran a sed after jenkins job is installed switching the zuul.openstack.org to my own15:12
mordredArxCruz: hah. nice hack15:12
krtaylorArxCruz, maybe a blueprint for this work, we can come up with a plan to parameterize as we get all this running in our environment15:13
krtaylormordred, fungi ^^^15:14
ArxCruzkrtaylor: to parameterize we need to move the yaml files from files to templates in puppet15:14
fungikrtaylor: in many cases (such as this one) it is parameterized already, but not necessarily discoverable without reading through the source15:15
mordredfungi: it's not though15:15
mordredfungi: because chaning the param would involve forking the puppet, which would make it exceedingly hard to track upstream changes15:15
fungiit's at least parameterized in the devstack-gate scripts in this particular case, and defaulting to our preferred config15:15
fungibut yes, not parameterized in jjb configuration nor in puppetry15:16
krtaylorArxCruz and I were brainstorming how we could do this, maybe with heira15:16
mordredthe question is - how can one put all localized parameters into site.pp - which has NO expecetations of reusability15:16
mordredI don't think you need to go heira15:16
mordredif you can just get it to be something that you put in manifests/site.pp and passed in to the modules, it should be ok15:17
ArxCruzmordred: like that sed ? I think that's a very ugly workaround :)15:18
mordredArxCruz: it is an ugly workaround - I think we can figure out something better15:19
*** mgagne has joined #openstack-infra15:21
ArxCruzmordred: it seems this problem is only on devstack-gate, would be possible, move devstack-gate.yaml to templates, adding a new property on puppet like zuul_server_url, with the default to zuul.openstack.org and put this as an parameter in devstack-gate.yaml, then change in devstack-vm-gate-wrap.sh check if the parameter is set or not and change if necessary ?15:23
*** markmcclain has quit IRC15:23
*** ryanpetrello has quit IRC15:23
*** changbl has joined #openstack-infra15:24
krtaylorJust curious, how many 3rd party CI test environments exist? It would be useful to know so we could discuss the snags and how they were solved15:27
fungikrtaylor: https://review.openstack.org/#/admin/groups/91,members15:27
krtaylormaybe that is more of an email thread, or summit bof15:27
mordredkrtaylor: summit bof!15:27
mordredkrtaylor: I think figuring out the best way to discuss issues with third-party copies of infra without killing the infra team is a great idea15:28
*** sarob has quit IRC15:28
krtaylorprob too late for next week  :)15:28
mordredArxCruz: I think that wold work - but I tihnk it might make the repo weird. I think that's close though15:28
*** sarob has joined #openstack-infra15:28
krtaylormordred, agreed, we can help each other, bring forward plan to generalize things15:29
fungii agree that there's a great long-tail benefit to be realized from helping other groups get copies of our different tools/systems up and running (since that means more people who can understand and improve on it eventually), but in the short term it's definitely very time-consuming to help those people get started15:29
ArxCruzi can't see this group 91,members :(15:29
krtaylornor I15:30
fungioh, right, it's not visible. fixing15:30
ArxCruzmordred: or we can move everything to templates already, even if it's note necessary for all the yaml's file15:30
fungitry again. there's really no reason we shouldn't make the list of bot accounts in our gerrit public15:31
ArxCruzwill became more easy if in the future need to change something15:31
*** SergeyLukjanov has joined #openstack-infra15:31
mordredfungi, clarkb: ^^ thoughts on moving jjb things from files to templates?15:31
*** davidhadas has joined #openstack-infra15:31
mordreddoes directory inclusion work on templates? or do we have to list each one individually?15:32
fungimordred: i don't think it does. at least that was the reason i assumed we were using flat directories for templates in our modules15:32
*** yamahata has joined #openstack-infra15:33
*** sarob has quit IRC15:33
fungiperhaps if jjb could read from multiple directories, we's be able to put the templates in one and manage the other with just a file tree15:33
fungier, we'd15:33
fungithough it may be that you can put a template in a puppet-managed directory and the resulting file counts as being a puppet-managed file for that directory15:34
fungiif the docs say that works, i'm not looking in the right place15:35
fungion a separate note, fyi github's api endpoint is all fsck'd up again. manage-projects isn't running successfully today because of random github api errors15:36
*** yassine has quit IRC15:36
ArxCruzfungi: that would be the same as move only the devstack-gate.yaml to a template huh?15:36
fungiArxCruz: right15:36
fungiArxCruz: because i think it would still be nice for people to be able to add jjc files in the config repo without having to make accompanying edits to a manifest for each15:37
fungier, jjb15:37
ArxCruzfungi: Is it possible use a directory as a template ?15:38
fungiArxCruz: not sure. i've not tried that before, but there is documentation for puppet15:39
openstackgerritA change was merged to openstack-infra/elastic-recheck: refactor templates into query_builder  https://review.openstack.org/5281815:40
*** ruhe has quit IRC15:40
fungiagain, i don't see anything which says that's a feature, but i could be looking in the wrong part of the puppet docs15:41
*** chuck_ has joined #openstack-infra15:41
ArxCruzfungi: http://projects.puppetlabs.com/issues/664915:41
ArxCruzit seems there's a module to do that15:41
ArxCruzbut it's not a feature in puppet15:41
*** miqui has joined #openstack-infra15:41
fungiright, wontfix'd in puppet core anyway15:43
ArxCruzfungi: I believe it would be possible just move the devstack-vm.yaml to template15:43
ArxCruzcreating a new puppet config only for jjb who needs parameters15:44
ArxCruzand another to read the jenkins_jobs_builder/config15:44
ArxCruzso, if you just want to add a new file without any changes, put in /config15:44
ArxCruzif you know it will need paramerter to be configured, change the puppet script15:45
ArxCruzit will split the jjb but it's the best solution I can see so far :/15:45
fungiright, just hoping puppet management of that directory won't step on puppet managing a specific file within the directory. would need testing15:45
*** krotscheck has joined #openstack-infra15:45
ArxCruzfungi: say no more, I will test in my infra15:46
ArxCruz:)15:46
ArxCruzif works, I will submit a patch :)15:46
krtaylorArxCruz, +1, consider it added to our weekly spring backlog :)15:46
fungiit's far easier to discuss these things when there's concrete code behind them. thanks ArxCruz!15:46
ArxCruzfungi: :)15:46
*** krotscheck has quit IRC15:47
ArxCruzkrtaylor: working on that right now, this will improve our work in like 90% for this week :)15:47
*** sdake has joined #openstack-infra15:50
*** fallenpegasus has quit IRC15:51
*** hogepodge has joined #openstack-infra15:51
*** yassine has joined #openstack-infra15:52
*** ruhe has joined #openstack-infra15:53
*** boris-42 has joined #openstack-infra15:56
*** fallenpegasus has joined #openstack-infra15:56
*** senk has quit IRC15:57
*** ruhe has quit IRC16:01
*** mrodden1 has joined #openstack-infra16:06
*** ^d has joined #openstack-infra16:06
*** ^d has quit IRC16:07
*** ^d has joined #openstack-infra16:07
*** mrodden has quit IRC16:07
*** senk has joined #openstack-infra16:08
*** gyee has joined #openstack-infra16:09
anteayaso reading up on how a puppet module is supposed to be created, should this be in modules/seafile/files rather than in modules/seafile/templates: https://review.openstack.org/#/c/54030/12/modules/seafile/templates/ccnet/seafile.ini16:10
*** senk1 has joined #openstack-infra16:10
anteayasince it isn't a template16:10
mattymoanteaya, are you staff?16:10
anteayaha ha ha16:10
*** marun has quit IRC16:10
anteayaI can answer questions16:10
mattymobut not approve change requests :)16:11
anteayaI am not core infra so I can't kick a server16:11
mattymofungi, maybe you can https://review.openstack.org/#/c/53656/16:11
anteayano, I am not infra-core so I can not approve patches for merging16:12
*** senk has quit IRC16:12
*** nati_ueno has quit IRC16:12
*** nati_ueno has joined #openstack-infra16:13
fungimattymo: did you /msg chanserv access #fuel add jeblair +AFRfiorstv (i can't check since chanserv tells me i'm not authorized to pull an access list for that channel)16:17
*** nati_ueno has quit IRC16:17
*** jcoufal has joined #openstack-infra16:18
*** chuck_ has quit IRC16:18
*** DinaBelova has quit IRC16:20
mattymofungi, done16:20
*** esheffield_ has joined #openstack-infra16:20
anteayamattymo just to give you a sense, fungi clarkb mordred and jeblair (who is on holidays this week) are all infra-core16:23
anteayamyself pleia2 and zaro are also infra team members though not infra-core, but pleia2 and zaro are core on other projects16:24
anteayaand we are all paid to be here16:24
*** ben_duyujie has joined #openstack-infra16:26
*** dstanek has joined #openstack-infra16:26
*** larsbutler has joined #openstack-infra16:26
*** tsufiev has joined #openstack-infra16:28
*** esheffield_ has quit IRC16:28
larsbutlerhi there, I noticed that the *-coverage jobs on openstack CI have not been run in while: https://jenkins.openstack.org/search/?q=coverage&max=20016:29
tsufievhi there! is this channel a suitable places for asking questions about pbr?16:29
larsbutlerMany of them, including swift-coverage, keystone-coverage, and nova-coverage, have not been run since around August 5th/6th16:29
larsbutlerIs this a bug?16:29
*** ryanpetrello has joined #openstack-infra16:30
larsbutlerI ask because I stumbled upon this bug just a while ago, which probably would have been caught if the coverage job for keystone had been running: https://bugs.launchpad.net/keystone/+bug/124553916:30
uvirtbotLaunchpad bug 1245539 in keystone "Error running test coverage: "no such option: --coverage"" [Medium,In progress]16:30
SpamapShm, PBR people.. any idea what this problem is: https://bugs.launchpad.net/bugs/1245372 ?16:30
uvirtbotLaunchpad bug 1245372 in trove "kick-start mysql is not working" [Undecided,Confirmed]16:30
anteayatsufiev: it is, though one person knows the most about pbr, the author mordred, so ask away - be prepared for pauses16:31
anteayamordred: you have a pbr audience16:31
tsufievanteaya: thank you, will ask him16:31
anteayatsufiev: post your question in channel and he will read it when he gets to the backscroll16:32
anteayawho knows, maybe someone else can answer too16:32
tsufievanteaya: yeah, I need a few minutes to type my issue in :)16:33
anteayatype away, or consider a paste.openstack.org16:33
anteayafor code samples and such16:33
fungilarsbutler: the coverage jobs run on either jenkins01 or jenkins02 now that we have multiple masters, and jenkins.o.o is only for security-sensitive jobs at this point16:33
*** markmcclain has joined #openstack-infra16:34
*** moted has joined #openstack-infra16:34
larsbutlerfungi: ah, I see16:35
*** jpeeler has quit IRC16:35
*** senk1 has quit IRC16:35
*** julim has quit IRC16:35
larsbutlerfungi: I found the keystone build failure associated with my issue: https://jenkins01.openstack.org/job/keystone-coverage/127/console16:35
*** jpeeler has joined #openstack-infra16:35
larsbutlerso, is coverage just not a critical part of the build?16:36
*** guohliu has quit IRC16:36
*** thedodd has quit IRC16:37
fungilarsbutler: i think the discussion has come up before, as far as making coverage jobs latch or ratchet style enforcement, but we currently don't gate on it no16:37
ArxCruzfungi: mordred it works for me changing the devstack-vm.yaml to templates and adding a File(...) on puppet16:37
ArxCruzhttp://paste.openstack.org/show/50064/16:37
fungiArxCruz: puppet doesn't complain or blow away the templated file then, eh? sounds like a potential solution16:38
ArxCruzfungi: I remove the devstack-vm.yaml from files/jenkins_job_builder/config directory16:38
ArxCruzand add it on templates/jenkins_job_builder/config16:39
*** adalbas has quit IRC16:39
tsufievmordred: have you ever seen the following pbr-ed setup.py strange behaviour? I have an 'ordereddict' requirement line in project's requirements.txt, but when i run python setup.py egg_info (python --version -> 2.7.3), ordereddict line is silently ignored and doesn't get to the <project_name>.egg-info/requires.txt.16:40
larsbutlerfungi: okay, understood. Do you think it would be worthwhile better integrate coverage runs into the builds? Or is there a good reason to not do this?16:40
tsufievmordred: but if i change requirement line to the 'ordereddict==1.1', it gets there16:40
ArxCruzfungi: mordred and in my job I have this now: http://paste.openstack.org/show/50065/16:40
fungilarsbutler: one problem is that jenkins only has two ways to finish a job. success state or failure state. so we'd need two jobs--one which runs coverage and reports its results, a second which tries to run coverage and gates on whether or not you've broken the job16:41
mattymofungi, what do we need to do for jeblair on #fuel-dev16:43
fungilarsbutler: that basically means always running coverage twice, and it's slow/expensive on larger code bases. also worth noting, we have the same situation on a lot of other non-voting jobs16:43
mattymo?16:43
fungimattymo: oh, i just realized that was #fuel-dev and not #fuel16:44
fungimattymo: /msg chanserv access #fuel-dev add jeblair +AFRfiorstv16:45
mattymofungi, it's done16:46
fungichanserv will actually give me an access listing for that channel, so i should be able to confirm it for him16:46
larsbutlerfungi: I don't quite understand. Why does there have to be one to run coverage & report, plus one more to run coverage & vote? (I'm totally new to the project, so I'm just trying to wrap my head around things)16:47
fungimattymo: yep! i see him in there now. thanks!16:47
mattymofungi, why do we need this? #puppet-openstack doesn't have any core members16:47
mattymoand it has gerritbot16:48
*** guohliu has joined #openstack-infra16:48
ryanpetrellohttps://review.openstack.org/#/c/42393/ anybody want to finally push this one through :)?16:48
clarkbmorning16:50
fungimattymo: i think it was recently realized that if that's not done pretty much as soon as the channel is registered, it becomes much, much harder for us to get access later. apparently jeblair has a backlog of channels he's trying to get founder status on so we can help troubleshoot issues with the bots we're managing on them16:50
*** lnxnut has joined #openstack-infra16:51
mattymofungi, ok16:51
fungiin a lot of cases the channel gets registered by a lone founder who later disappears and then nobody has control over it any longer16:51
mattymofungi, so can it be finished today and pushed through? are we waiting on him?16:51
mattymofungi, and I trust you folks to be the benevolent dictators)16:52
*** vipul has quit IRC16:53
fungimattymo: since i was able to confirm it in jeblair's absence (he's vacationing at the moment), if clarkb wants to get a double-check in on it we can probably put it through16:53
*** vipul has joined #openstack-infra16:53
*** dcramer_ has quit IRC16:53
*** ArxCruz has quit IRC16:54
mattymoclarkb, are you feeling generous today?16:55
fungihttps://review.openstack.org/53656 being the change we're talking about16:55
*** ArxCruz has joined #openstack-infra16:55
*** dcramer_ has joined #openstack-infra16:55
*** lnxnut has quit IRC16:55
fungii suppose https://review.openstack.org/52085 is in the same boat now too16:56
*** lnxnut has joined #openstack-infra16:56
*** markmcclain has quit IRC16:57
*** harlowja has joined #openstack-infra16:57
*** ryanpetrello has quit IRC16:58
openstackgerritA change was merged to openstack-infra/config: Add IRC bot to #openstack-climate for all Gerrit changes  https://review.openstack.org/5208516:58
funginot sure why #openstack-climate didn't need our intervention to register though. i wonder whether freenode staff are selectively enforcing namespace registrations?16:59
*** ArxCruz has quit IRC17:00
clarkbmattymo: fungi: looking17:00
clarkbfungi: may have been registered before the restrictions17:00
fungigood point17:00
mordredtsufiev: well, that's definitley a bug - but not the bug you think it is :)17:01
*** dcramer_ has quit IRC17:01
mordredtsufiev: I thought ordereddict was not needed on 2.7 ?17:01
reedwhich reminds me that #openstack-community is not registered with you guys17:02
*** dizquierdo has quit IRC17:03
fungimordred: also, in case you missed SpamapS's comment earlier (and/or bug e-mails), today's pbr release is apparently causing problems for (at least) heat and trove... https://launchpad.net/bugs/124537217:04
uvirtbotLaunchpad bug 1245372 in trove "kick-start mysql is not working" [Undecided,Confirmed]17:04
mordredfungi: awesome17:04
fungi[pbr] Processing SOURCES.txt ... error: No such file or directory17:05
*** julim has joined #openstack-infra17:05
fungiprobably their setup mentions a nonexistent file--i haven't checked yet17:05
*** markwash has quit IRC17:05
*** ArxCruz has joined #openstack-infra17:06
SpamapSheat-cfntools specifically17:06
tsufievmordred: yeah, it is not needed in 2.7, but we have one requirements.txt both for ubuntu (python2.7) and CentOS (python2.6). I can bypass this, nevertheless it's still a bug :)17:06
mordredtsufiev: it's actually a feature :)17:06
mordredtsufiev: it explicitly doesn't install it on 2.7 so that people can have one requirements.txt and not have it pull in unneeded thing17:07
mordredtsufiev: (this was a request from ... I forget, someone)17:07
*** Ryan_Lane has joined #openstack-infra17:07
*** guohliu has quit IRC17:08
tsufievmordred: I understand it could be nice in some circumstances, but it is confusing that pbr does that thing quietly17:08
*** Ryan_Lane has quit IRC17:08
mordredtsufiev: would you like it to print a message about that it's skipping it on purpose?17:09
mordredwould that be helpful?17:09
tsufievmordred:  yes, it would be great17:09
*** markmcclain has joined #openstack-infra17:12
fungimordred: SpamapS: mmm, so i think maybe the "warning: LocalManifestMaker: standard file '-c' not found [...] error: No such file or directory" could be related after all. trying to see where it's picking up a -c17:12
*** yassine has quit IRC17:12
SpamapSfungi: thanks for investigating.17:14
clarkbmattymo: fungi: approved17:14
*** esheffield_ has joined #openstack-infra17:15
*** dkliban has quit IRC17:15
*** Ryan_Lane has joined #openstack-infra17:15
openstackgerritA change was merged to openstack-infra/config: add fuel-dev channel to gerritbot  https://review.openstack.org/5365617:15
mordredSpamapS, fungi: I cannot reproduce that17:15
mordredvirtualenv foo17:15
mordredfoo/bin/pip install heat-cfntools17:16
mordredworks for me17:16
*** DinaBelova has joined #openstack-infra17:16
*** vipul is now known as vipul-away17:16
*** ruhe has joined #openstack-infra17:17
*** hashar has quit IRC17:17
*** ruhe has quit IRC17:17
fungimordred: yeah, i wonder whether something on the reddwarf end is contributing to this17:17
*** olaph has quit IRC17:17
fungis/reddwarf/trove/17:17
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: Let us gate grenade forward  https://review.openstack.org/5394017:18
tsufievmordred: there was a short network failure in our office, didn't i misssed your replies?17:19
fungitsufiev: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2013-10-28.log17:19
tsufievok, nothing was missed :)17:20
sdagueso before I spend too much time on some of the d-g refactoring, it would be good to know if - https://review.openstack.org/#/c/54132/ and https://review.openstack.org/#/c/54133/ are the kinds of cleanups that people want to see (I'm currently sitting my grenade upgrade stuff behind them)17:23
*** flaper87 is now known as flaper87|afk17:23
*** krotscheck has joined #openstack-infra17:24
ArxCruzALL: Have you guys seen this problem: http://paste.openstack.org/show/50070/17:24
ArxCruzI have the ip command in /usr/sbin/ip and I can execute as jenkins, stack, and root users17:24
ArxCruzbut when it's running through jenkins it's failing17:24
*** vipul-away is now known as vipul17:25
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Make sure that we ioudly skip versioned 2.6 libs  https://review.openstack.org/5415217:27
mordredtsufiev: ^^17:27
sdagueArxCruz: /usr/sbin might not be in the path by default on fedora17:27
ArxCruzsdague: i think it's in jenkins default path17:27
*** markmcclain has quit IRC17:27
sdaguebut this is under the stack user17:27
*** yassine has joined #openstack-infra17:27
sdagueso the path would be reset17:28
*** yassine has quit IRC17:30
*** olaph has joined #openstack-infra17:31
*** markmcclain has joined #openstack-infra17:32
*** Ryan_Lane has quit IRC17:35
*** mgagne has quit IRC17:37
*** mgagne has joined #openstack-infra17:37
*** mgagne has joined #openstack-infra17:37
tsufievmordred: that was fast :)17:38
*** fbo is now known as fbo_away17:39
ogelbukhfungi: mordred: clarkb: gentlemen, could you please tell me what's needed to move a project to stackforge from public github repo?17:41
*** reed has quit IRC17:41
ogelbukhi filed a change request already to the config repo: https://review.openstack.org/#/c/53858/17:41
pleia2ogelbukh: have you seen http://ci.openstack.org/stackforge.html17:42
ogelbukhsure17:42
pleia2ok, cool :)17:42
ogelbukhi think i'll need to provide some additional information17:42
*** tkammer_ has quit IRC17:43
pleia2yeah, you'll need to request a group set up with initial core reviewers17:43
fungiogelbukh: mostly time. we're a bit backlogged with releases, upcoming summit preparations, conferences and travel. also, stackforge-related work is generally a lower priority for us than work on openstack itself17:44
ogelbukhpleia2: thanks!17:44
*** markwash has joined #openstack-infra17:44
fungibut we do try to get through and review all submitted changes17:44
pleia2ogelbukh: but that's after your change has merged, so as fungi says - time :)17:44
ogelbukhfungi: fair, thamnk you!17:45
ogelbukh-m17:45
clarkbfungi: ogelbukh: ya this week is going to be hard to get "real" work done17:48
*** reed has joined #openstack-infra17:48
fungiinteresting statistic... 189 projects in review.openstack.org. 42% stackforge, 35% openstack, 18% openstack-infra, 5% openstack-dev17:49
pleia2stackforge sure has grown17:49
*** sarob has joined #openstack-infra17:51
ogelbukhstackforge is representing ecosystem, so it's natural, i guess17:51
reeddoes seafile support storing files in swift?17:53
pleia2fungi: worth some informal chatting about at summit re: allocation of resources?17:53
fungipleia2: probably at least twice... maybe one of those without beer17:55
pleia2++17:55
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: Let us gate grenade forward  https://review.openstack.org/5394018:02
sdagueso close....18:02
sdaguefungi: so I think https://review.openstack.org/53940 is functionally right, we just need to do this lockstep thing with the grenade upgrade18:02
sdagueso I need to make it run grizzly as stable on master until we get working havana => master grenade18:03
fungican that be phased, or will both changes have to be force-merged in tandem?18:03
clarkbsdague: I am reviewing 5349018:04
* fungi is as well18:06
klrmnlifeless: testresources does not work out-of-the-box with nose, i had to write a nose plugin to force it to use the OptimisingTestSuite. i'll let you know when i publish the plugin…first it has to survive the fire that will be refactoring all my tests to use it18:07
lifelessklrmn: cool18:07
clarkbsdague: reviewed18:09
bodepd_fungi: thanks fungi. I didn't even realize those branches were there. Looking into it now18:09
sdagueclarkb: thanks, good catches18:11
sdagueI'm going to let this run to completion to see if the grenade job actually worked this time18:11
clarkbwfm18:11
sdaguefungi: yes, so the attempt as phasing it is doing the wrong thing in this change and setting old=grizzly for master18:12
sdaguethen fixing grenade18:12
sdaguethen fixing this to old=havana for master18:12
sdagueclarkb: my comments on your comments there. On missed variable, and one bad merge :)18:13
fungicompletely unrelated, but i confirmed you can get git tab completion to do some nasty local code execution tricks by backticking a command in a tag name, as long as you respect git's limitations on what characters are valid for a tag18:15
fungiit's actually pretty funny18:15
*** dcramer_ has joined #openstack-infra18:15
*** ruhe has joined #openstack-infra18:16
clarkbfungi: your idea of funny is disturbing :)18:17
fungifor example, create a backdoor.sh (doing something like "touch pwnd") script in your repo and make it executable, then tag a commit as `./backdoor.sh` and try tab-completing git branch -D18:17
*** adalbas has joined #openstack-infra18:17
fungithis cropped up from some earlier work i did on trying to inject arbitrary code in tags we reference in our release jobs, which turned out not to be viable but the side effect was that i started getting file-not-found errors when tab-completing refnames in that checkout. only just noticed it18:19
reedI love CLAs corner cases18:19
*** yaguang has joined #openstack-infra18:19
*** SergeyLukjanov is now known as _SergeyLukjanov18:19
*** _SergeyLukjanov has quit IRC18:20
*** DinaBelova has quit IRC18:21
*** DinaBelova has joined #openstack-infra18:22
clarkbfungi: that is pretty funny. are '$'s allowed in tag names?18:23
clarkbsomething like `echo "Hello, $USER this is git. Nice to meet you."` would be an excellent tag name18:23
fungiclarkb: well, the biggest trick is that spaces aren't allowed18:24
clarkbwell we use underscores then!18:24
clarkband not echo18:24
fungibut you could stuff that echo into a script in the repo and have the tag exec it18:24
*** ruhe has quit IRC18:25
*** katyafervent has quit IRC18:26
fungioh, also it seems stdout gets swallowed, but things like file interaction still work18:26
*** mattymo has quit IRC18:26
*** tsufiev has quit IRC18:26
lifelessjgriffith: hey18:27
lifelessjgriffith: you should totally hang out in #tripleo18:27
lifelessfungi: hard space!18:28
*** Bada has quit IRC18:28
fungiheh18:28
fungii think tag names may be ascii only, so utf-8 hard space wouldn't be an option18:28
fungia very strict printable ascii subset, if memory serves (i looked it up in the manpage a while back)18:29
*** dkliban has joined #openstack-infra18:30
*** fallenpegasus has quit IRC18:30
*** SergeyLukjanov has joined #openstack-infra18:31
*** esker has joined #openstack-infra18:35
*** fallenpegasus has joined #openstack-infra18:36
*** changbl has quit IRC18:37
*** ben_duyujie has quit IRC18:43
openstackgerritArx Cruz proposed a change to openstack-infra/config: Adding support to a generic zuul server in JJB for devstack-gate  https://review.openstack.org/5416018:45
ArxCruzfungi: mordred ^18:46
*** dkliban has quit IRC18:46
*** thedodd has joined #openstack-infra18:47
*** fallenpegasus has quit IRC18:47
*** changbl has joined #openstack-infra18:50
*** ArxCruz has quit IRC18:51
*** ArxCruz has joined #openstack-infra18:51
*** yaguang has quit IRC18:54
*** larsbutler has quit IRC18:54
*** jergerber has joined #openstack-infra18:56
*** hogepodge has quit IRC18:59
openstackgerritArx Cruz proposed a change to openstack-infra/config: Adding support to a generic zuul server in JJB for devstack-gate  https://review.openstack.org/5416019:00
*** markmcclain has quit IRC19:02
*** dims has quit IRC19:07
openstackgerritAnita Kuno proposed a change to openstack-infra/config: Create a seafile instance.  https://review.openstack.org/5403019:07
*** dims has joined #openstack-infra19:10
openstackgerritArx Cruz proposed a change to openstack-infra/config: Adding support to a generic zuul server in JJB for devstack-gate  https://review.openstack.org/5416019:11
*** rainya has quit IRC19:13
*** melwitt has joined #openstack-infra19:14
*** DinaBelova has quit IRC19:15
openstackgerritArx Cruz proposed a change to openstack-infra/config: Adding support to a generic zuul server in JJB for devstack-gate  https://review.openstack.org/5416019:16
ArxCruzfungi: mordred do I need, in my openstack installation, open the 35357 door in order to jobs run?19:17
*** DinaBelova has joined #openstack-infra19:19
*** DinaBelova has quit IRC19:22
*** jcoufal has quit IRC19:24
*** johnthetubaguy has quit IRC19:24
*** jcoufal has joined #openstack-infra19:24
openstackgerritArx Cruz proposed a change to openstack-infra/config: Adding support to a generic zuul server in JJB for devstack-gate  https://review.openstack.org/5416019:26
*** danger_fo_away has quit IRC19:27
*** nicedice__ has joined #openstack-infra19:28
sdaguefungi: did you have any other comments on this - https://review.openstack.org/#/c/53940/ ?19:29
sdaguebefore I respin with the fixes clarkb suggested19:29
sdagueas I managed to get it to pass grenade... yay!19:29
*** dstufft has quit IRC19:29
*** dstufft has joined #openstack-infra19:30
*** LinuxJedi_ has joined #openstack-infra19:30
*** danger_fo_away has joined #openstack-infra19:31
*** nati_ueno has joined #openstack-infra19:31
openstackgerritArx Cruz proposed a change to openstack-infra/config: Adding support to a generic zuul server in JJB for devstack-gate  https://review.openstack.org/5416019:31
*** yamahata has quit IRC19:31
*** jeblair has quit IRC19:31
*** LinuxJedi has quit IRC19:31
*** uvirtbot has quit IRC19:32
*** yamahata has joined #openstack-infra19:32
*** jeblair has joined #openstack-infra19:33
*** davidhadas has quit IRC19:34
*** markwash_ has joined #openstack-infra19:34
fungisdague: no, seems safe enough, those couple items aside19:34
*** mtreinish has quit IRC19:35
openstackgerritJoe Gordon proposed a change to openstack-dev/hacking: Continue reserving H6xx namespace for calling methods  https://review.openstack.org/5416519:35
fungiside note, we have rather many branch variables in devstack-gate scripts. wish there were better ways to distinguish them'19:36
jog0clarkb, sdague:  ^^ last patch before ready to cut hacking 0.8.019:36
*** markwash has quit IRC19:36
*** markwash_ is now known as markwash19:36
*** mtreinish has joined #openstack-infra19:40
fungiclarkb: good news on the git tag tab completion command injection front... can't seem to reproduce running debian's 1.8.4~rc3-1 package19:48
sdaguefungi: yes, for sure, something maybe to think about in the grenade session19:48
fungihopefully the old bash tab completion file was screwy19:49
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: Let us gate grenade forward  https://review.openstack.org/5394019:53
fungiyeah, i can reproduce it on precise :(19:55
sdagueok, so that should be good to go. fungi / clarkb you guys ok with the refactor patches under it?19:59
sdagueor should I rebase that on master?19:59
openstackgerritAnita Kuno proposed a change to openstack-infra/config: Create a seafile instance.  https://review.openstack.org/5403020:01
*** mrodden1 has quit IRC20:01
*** mrodden has joined #openstack-infra20:01
*** emagana has joined #openstack-infra20:02
wenlockquick config question for gerrit group settings.  is there a reason why Release Managers group is visible to all but Stable Maintainers gorup is not?20:03
*** LinuxJedi_ is now known as LinuxJedi20:03
*** sarob has quit IRC20:03
wenlocksame question for External Testing Tools group... why is that visible and not Continuous Integration Tools group?20:05
*** sarob has joined #openstack-infra20:05
fungiwenlock: probably just oversight on our part. about the only things i feel we should keep non-visible are the cla-related groups, but it's probably something we ought to discuss with the other infra team members20:07
wenlockfungi, thanks... i was just trying to understand it... i get some groups are more sensative than others20:08
wenlocki was thinking the logic might have been reversed though20:08
fungiin particular we started making the .*-core groups visible so people with reviews knew who to reach out to if necessary20:09
wenlockie; protect the managers more than the maintainers.... or same for the ci accounts, protect the names since they arn't real people20:09
fungibut ultimately i think there's very little sensitive about the vast majority of our groups20:09
wenlockyeah, *-core groups being visible makes perfect sense20:09
wenlockgreat, thanks20:10
fungiit's mostly that gerrit defaults to making group details and membership invisible unless you're a member of that group, but we override that for all of our automatically-generated groups these days20:10
*** hashar has joined #openstack-infra20:11
wenlockyeah... it was bugging me because when you add a group via ssh, if you try automating the make visible flag, there is no way to do it via api that i can see.  if you insert the entry into mysql, then gerrit will want a restart to make it visible.20:12
*** markmcclain has joined #openstack-infra20:12
openstackgerritAnita Kuno proposed a change to openstack-infra/config: Create a seafile instance.  https://review.openstack.org/5403020:13
*** dprince has quit IRC20:15
*** julim has quit IRC20:15
*** changbl has quit IRC20:21
fungiwenlock: you want 'gerrit create-group --visible-to-all mynewgroup'20:21
wenlockfungi, awesome!20:21
*** jcoufal has quit IRC20:22
wenlockdidn't even see that as an option...20:22
fungiwenlock: http://git.openstack.org/cgit/openstack-infra/gerritlib/tree/gerritlib/gerrit.py#n11620:22
fungithat's what we're calling from the manage-projects script in jeepyb20:22
wenlockperfect20:23
sdaguejog0: +2 on your previous review request20:24
*** mrodden has quit IRC20:25
*** vipul has quit IRC20:26
*** vipul has joined #openstack-infra20:27
wenlockfungi, just tried it.  that works20:28
wenlockno server restart needed :D20:28
fungicrap, so the puppet refactoring for mysql in gerrit which i approved over the weekend seems to be having a puppet problem on review.o.o which did not manifest on review-dev20:30
fungifix on the way20:31
wenlockhmm, i had looked at that over the weekend as well... it looked like an ok change.20:32
fungifor those playing along at home, the error is... "Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter mysql_password at /opt/config/production/modules/openstack_project/manifests/review.pp:171 on node review.openstack.org"20:33
*** dcramer_ has quit IRC20:33
*** sarob has quit IRC20:33
*** sarob has joined #openstack-infra20:34
wenlockahh yes, we had forked that file, forgot to post on the forum that it broke us :P20:34
wenlocki mean irc20:34
*** changbl has joined #openstack-infra20:36
clarkbgerrit defaults to non visible groups. I think we just negelected to make them visible20:37
*** ericloo has joined #openstack-infra20:37
wenlockclarkb, so they should all be visible?  I mean the groups we create by hand per this site: http://ci.openstack.org/gerrit.html  (groups section)20:38
clarkbwenlock: I think so, there might be a small argument that Project Bootstrappers shouldn't be20:38
*** sarob has quit IRC20:39
*** denis_makogon has joined #openstack-infra20:39
wenlockclarkb: ok, cool.  i was improving my changes for gerrit server setup to bootstrap gerrit without doing all the manual setup20:39
*** changbl has quit IRC20:40
*** openstackgerrit has quit IRC20:41
*** openstackgerrit has joined #openstack-infra20:41
*** sarob has joined #openstack-infra20:42
clarkbsdague: I think we may need to sort out when to setup the workspace20:44
clarkbsdague: I think it needs to happen before the reexec in order to make sure the new d-g is abailable to reexec20:44
clarkbsdague: what if you put the branch selection and setup of new workspace before reexec?20:45
clarkbI think that gives us maximum coverage of the reexec testing20:45
*** davidhadas has joined #openstack-infra20:45
openstackgerritJeremy Stanley proposed a change to openstack-infra/config: Don't pass mysql passwords to project gerrit class  https://review.openstack.org/5417720:46
fungiclarkb: that could stand some ninja ^20:46
clarkbfungi: looking20:47
fungiit was correct in review_dev.pp but not in review.pp, so testing on review-dev didn't expose it20:47
clarkbfungi: how does review.o.o know its mysql info?20:47
fungiclarkb: up in the gerrit::mysql block20:48
clarkbfungi: gotcha20:48
fungiit's a brown bag fix from something which got missed in 6a2e31d20:48
clarkbfungi: lgtm, feel free to push through20:49
openstackgerritA change was merged to openstack-infra/config: Don't pass mysql passwords to project gerrit class  https://review.openstack.org/5417720:52
fungifwiw, that ^ got "tested" in production (applying it un-broke puppet on review.o.o)20:52
clarkbk20:52
sdagueclarkb: ok, I thought you wanted me to move it up. I can move it back down to after the workspaces20:52
clarkbI figured you had done that20:52
clarkbsdague: I think we need something in the middle20:52
clarkbsdague: we want the section that reexecs to happen as early as possible, but it must happen after the new workspace is configured20:53
fungibasically anything which runs before the reexec is not self-tested20:54
sdagueok20:54
*** luhrs1 has joined #openstack-infra20:55
clarkbthere may be some way to just deal with d-g repo first then check reexec then setup workspaces proper20:55
clarkbdo something like gerrit git prep just for d-g20:55
*** moted_ has joined #openstack-infra20:56
*** hashar_ has joined #openstack-infra20:56
ArxCruzfungi: https://review.openstack.org/#/c/54160/ i believe the failure in gate-config-layout it's because I move the devstack-gate jobs is it possible to you verify ? I remove all the blank and tabs spaces :)20:56
fungiArxCruz: in a bit. i have to cook dinner but i'll try to look while i do so20:57
*** ^d has quit IRC20:57
*** hashar has quit IRC20:57
*** moted has quit IRC20:57
*** hashar_ is now known as hashar20:57
*** moted_ is now known as moted20:57
*** che-arne has quit IRC20:57
ArxCruzfungi: take your time :)20:58
*** aspiers has joined #openstack-infra20:59
sdagueclarkb: so, in patchset 9 - https://review.openstack.org/#/c/53940/9/devstack-vm-gate-wrap.sh I had this down after the workspace setup21:00
sdaguejust go back to that?21:00
*** ^d has joined #openstack-infra21:01
*** changbl has joined #openstack-infra21:02
clarkbArxCruz: fungi: why do shell scripts in jenkins jobs need to know where ZUUL is located? I think it might be better to supply that info from zuul itself21:02
clarkbsdague: we can go back to that, it would nice if there is something in between that we can do21:02
*** Ajaeger1 has joined #openstack-infra21:03
sdagueok, let's start there, and we can make it better later21:03
clarkbsdague: do the bare minimum to sort out branches, then setup workspace/new, check reexec then setup workspace old21:03
ArxCruzclarkb: oh...21:03
sdagueclarkb: so what's the concern on setting up workspace old before it?21:03
clarkbArxCruz: it might need a patch to zuul to do that, but I think since zuul is driving the whole thing it can just inject that into the build parameter list21:03
ArxCruzclarkb: thanks for make a lot of ctrl+c ctrl+v useless21:03
sdaguejust that it's slow?21:03
ArxCruz:)21:03
*** mrodden has joined #openstack-infra21:03
clarkbsdague: no, changes to d-g won't be self tested on their ability to setup workspace old21:04
ArxCruzclarkb: yes, zuul is better, I didn't though that21:04
fungiArxCruz: yes, i think you're right about the failing layout and comparison jobs... they'd need extra intelligence to deal with one of the config files being a puppet template21:04
fungiArxCruz: clarkb: and yes, if we can supply that from zuul directly, all the better21:04
ArxCruzclarkb: but zuul send ZUUL_URL info ?21:04
fungididn't even think of that earlier when discussing it with ArxCruz and mordred21:05
clarkbArxCruz: yeah, zuul is triggering these jobs and injecting environment variables, rather than pass that data through in weird third party places, just do it directly21:05
Ajaeger1infra team, we're splitting up the install guide and I would love some good review on this patch https://review.openstack.org/54076, please21:05
clarkbthen you can point at different zuuls without any configuration changes21:05
sdagueclarkb: ok, so what we really need is devstack-gate setting itself up independently, ok, let me slice this again.21:06
clarkbsdague: ya that would be the proper fix21:06
clarkbsdague: fwiw if that is terrible I am fine doing what patchset 9 did for now21:06
ArxCruzclarkb: so, if pass ZUUL_URL in zuul, it will export the variable correctly without the need of changes in jjb ?21:07
sdagueso, honestly, I think the proper fix requires a lot more refactoring of setup_workspace so that it can take a project as a param21:07
sdagueso I think, given that we wedged ourself this morning on a novaclient change, I'd like to get the patch 9 version moving forward now21:07
clarkbArxCruz: correct if you look at https://jenkins02.openstack.org/job/check-tempest-devstack-vm-full/3598/parameters/? you see there are parameters that are being directly passed into the job from zuul21:08
sdaguebecause we have real possible breaks happening. Then we do this right later.21:08
*** beagles has quit IRC21:08
*** thomasem has quit IRC21:08
ArxCruzclarkb: okay, cool21:08
clarkbsdague: sounds good to me, sorry I didn't fully grasp why it was moved initially. Want to push up a thing with the other fix in patchset 10 that is otherwise patchset 9?21:08
ArxCruzfungi: so, can I just abandon https://review.openstack.org/#/c/54160/ ?21:09
*** yamahata has quit IRC21:09
fungiArxCruz: yeah, there is definitely a better, more elegant way21:09
*** yamahata has joined #openstack-infra21:09
ArxCruz:)21:09
ArxCruzokay, hacking zuul now...21:10
openstackgerritSean Dague proposed a change to openstack-infra/devstack-gate: Let us gate grenade forward  https://review.openstack.org/5394021:11
sdagueclarkb: yeh, I split it a little bit to do the old setup after21:11
sdagueand left a big comment21:11
sdagueclarkb: also, per previous question, that's sitting on top of 2 refactoring clean ups. Would be good to know if you are good with those as well, as I think it would be good to get this whole series in soon, so we can actually land the havana => master grenade changes, then get that switched on21:13
*** beagles has joined #openstack-infra21:13
*** misterpink has joined #openstack-infra21:14
*** misterpink has quit IRC21:15
*** misterpink has joined #openstack-infra21:18
*** fbo_away is now known as fbo21:19
zuli think we should turn on the gate for py3 for cinderclient/novaclient21:19
clarkbzul: It should be on for novaclient21:21
zulsweet21:21
clarkbzul: but we should do cinderclient too if it is ready21:24
*** dcramer_ has joined #openstack-infra21:25
zulclarkb:  its ready ill do it tonight21:25
*** mrodden1 has joined #openstack-infra21:28
*** jhesketh has joined #openstack-infra21:30
*** mrodden has quit IRC21:31
*** alcabrera has quit IRC21:32
*** dkranz has quit IRC21:34
fungijgriffith: python-cinderclient works and passes tests on python 3.3 now?21:41
fungizul: that's awesome news, btw21:41
clarkbjog0: sdague: do we expect py33 and pypi tests to not pass for hacking https://review.openstack.org/#/c/54165/1 I ask because novaclient and soon cinderclient are gating on py33 and while flake8 isn't run on them with py33 it isn't far fetched that someone may try that21:41
*** ruhe has joined #openstack-infra21:41
fungii thought they did pass at one point and then regressed?21:42
clarkbyeah I think that may be what happened, just checking that it is ok21:42
*** mriedem has quit IRC21:43
* fungi could be misremembering21:43
*** ruhe has quit IRC21:43
fungiit's past beer-o'clock here now, so my memory is increasing in fuzziness21:43
fungiwell, technically saké-o'clocky but who's counting?21:44
*** justinabrahms has quit IRC21:44
*** thomasem has joined #openstack-infra21:44
*** thomasem has quit IRC21:45
*** luhrs1 has quit IRC21:45
*** thomasem has joined #openstack-infra21:45
*** justinlilly has joined #openstack-infra21:46
*** che-arne has joined #openstack-infra21:46
*** justinlilly is now known as justinabrahms21:47
*** rakhmerov has quit IRC21:47
*** justinabrahms has quit IRC21:52
*** pcm_ has quit IRC21:52
openstackgerritArx Cruz proposed a change to openstack-infra/zuul: Add the possibility to pass the zuul url  https://review.openstack.org/5419621:53
Ajaeger1fungi, I can only offer virtual beers and will throw a virtual round for reviews ;) - but it's really good German beer ;)21:53
ArxCruzclarkb: fungi I think I did it right now ^21:53
*** slong has joined #openstack-infra21:53
fungiAjaeger1: if it comes in liter steins, i'll start looking for plane tickets ;)21:54
fungiArxCruz: lookin'21:54
Ajaeger1:)21:54
*** dcramer_ has quit IRC21:54
SpamapSfungi: did anything ever come of the pbr bug noted this morning?21:55
*** weshay has quit IRC21:56
clarkbArxCruz: that change looks good to me other than the pep8 failure21:57
fungiSpamapS: we... think? it's trove-setup-specific?21:57
*** Ajaeger1 has quit IRC21:57
fungiSpamapS: were you able to recreate it by installing via pip?21:57
ArxCruzclarkb: it's really annoying these blank lines21:59
fungineither mordred nor i had any luck coming up with a trivial test case to cause that error (note: redstack mysql kickstart doesn't count as "trivial")21:59
*** esker has quit IRC21:59
anteayaI feel soiled having to type the code I have to type. like being forced 2 tp lik ts21:59
anteaya*shudder*21:59
openstackgerritArx Cruz proposed a change to openstack-infra/zuul: Add the possibility to pass the zuul url  https://review.openstack.org/5419621:59
clarkbanteaya: huh? did you end up in AIM land?22:00
anteayaew22:00
fungii thought her keyboard started rebelling22:00
anteayareading how to puppet downloading and unpacking a tarball22:00
anteayasometime (rarely, but sometimes) I wish I drank22:00
anteayathe last time was when I had to take a live squirrel out of the wall22:01
anteayathis is another one22:01
fungianteaya: sometimes the computers do respond more favorably to beer22:01
anteayaI'll pour beer on my keyboard22:01
SpamapSfungi: https://bugs.launchpad.net/ubuntu/+source/python-pbr/+bug/124567622:02
fungiit looked like seafile had instructions for building/installing from source, but it did require some additional dependencies be installed on the system22:02
anteayawould that be easier than the tarball?22:02
anteayaI would still have to download and unpack something, get it in the right directory22:03
anteayause the exec {} resource22:03
anteayawould I not?22:03
fungiSpamapS: that looks a lot more specific--thanks22:03
fungianteaya: in that situation we at least have examples of doing that via the vcsrepo module22:04
SpamapSfungi: np, thank andrew_plunk though. :)22:04
anteayafungi I saw vcsrepo usage for git cloning22:04
fungiSpamapS: well, i'm thanking you for bringing it to my attention sooner than i got back around to that maildir22:04
anteayadoes it work with tarballs as well?22:04
anteayaI'll look22:04
*** ^d has quit IRC22:04
*** andrew_plunk has joined #openstack-infra22:04
anteayaall hail andrew_plunk22:05
SpamapSfungi: thank you fungi, thank you #openstack-infra.. thank you, thank you, thank you-ooo-ooo</alanis>22:05
andrew_plunkahaha hello22:05
*** ^d has joined #openstack-infra22:05
fungianteaya: you'd use it to clone their git repository and then follow their installation from source instructions (but write a script to encode them)22:05
clarkbanteaya: there are a couple of archive puppet modules on puppet forge that look like they may make the situation more san22:05
anteayaokay, let me try that22:05
clarkb*sane22:05
fungiandrew_plunk: many thanks for responsible and detailed bug reporting!22:05
anteayaclarkb: the puppet forge modules are named archive?22:05
andrew_plunknp fungi: I was just trying to follow the instructions on launchpad22:06
anteayaall hail andrew_plunk's responsible and detailed bug reporting22:06
anteayaI haven't read it yet myself, I'm trusting fungi's judgment here22:06
andrew_plunkahaha22:06
*** ^d has quit IRC22:07
* anteaya reads the andrew_plunk bug report22:07
* anteaya nods agreement with fungi's original assessment22:08
fungii'm reading through it now, but it has a full transcript of pip install failure for pbr22:08
*** thomasem has quit IRC22:08
fungilooks vaguely like a pypi problem...22:08
* anteaya goes back to puppet examples22:09
anteayasigh22:09
ArxCruzclarkb: fungi jenkins gave the +1 so if you guys don't mind, go there and gave your blessings :D22:09
fungiArxCruz: did that work on your systems? (just curious)22:10
ArxCruzfungi: I'm still waiting some job who uses that :/22:10
ArxCruzunless there's a way to force the job22:10
*** ^d has joined #openstack-infra22:12
*** ^d has joined #openstack-infra22:12
sdagueok, time to head home for the night - d-g changes: https://review.openstack.org/#/c/54132/, https://review.openstack.org/#/c/54133/, https://review.openstack.org/#/c/53940/ are needed to get grenade actually working on havana (and set up the forward grenade upgrades)22:13
sdaguethe above would have prevented the python-novaclient wedge this morning (which I assume is going to be reproposed as soon as someone realizes we reverted them)22:13
fungiheh. it'll make an excellent test ;)22:14
*** senk1 has joined #openstack-infra22:14
sdaguehttps://review.openstack.org/#/c/53739/ - is d-g protection from tempest being able to wedge the world if we aren't up to date on requirements22:14
*** lnxnut_ has joined #openstack-infra22:14
*** andrew_plunk has quit IRC22:14
sdaguefungi: yep, that was going to be my first test after that's merged, revert the revert22:14
anteayaclarkb: what are the names of the puppet modules to which you refer?22:14
anteayaso far I haven't seen them myself22:15
*** dkliban has joined #openstack-infra22:16
jog0clarkb: fungi is correct, pypi  passed but there was a regression22:17
jog0clarkb: I agree both should pass, just waiting for someone to pick it up22:18
*** lnxnut has quit IRC22:18
*** rakhmerov has joined #openstack-infra22:18
*** rcleere has quit IRC22:18
*** senk1 has quit IRC22:19
clarkbanteaya: something/archive. it looks like there are several of them22:20
clarkbprobably all forks of each other22:20
anteayak thanks22:20
anteayalooks worth a look: http://forge.puppetlabs.com/smarchive/archive22:21
anteayaappears to be worth a look22:22
anteayaor look, look, look22:22
anteayait is moved to here: https://github.com/gini/puppet-archive22:24
anteayaso would the module be called smarachive/archive still or gini/archive, I wonder?22:25
anteayagini22:25
*** rakhmerov has quit IRC22:25
*** senk has joined #openstack-infra22:26
openstackgerritClark Boylan proposed a change to openstack-infra/elastic-recheck: Better end of console log indexing detection.  https://review.openstack.org/5348722:26
*** UtahDave has quit IRC22:26
jog0clarkb: I will respin 54165 because of the H903 typo22:27
clarkbjog0: ok22:27
clarkb53487 has been rebased on sdague's e-r changes. I still haven't quite tested it, but left a comment in the review about testing (want ot make sure I set up the functional tests properly)22:28
*** beagles has quit IRC22:28
*** senk1 has joined #openstack-infra22:29
lifelessmordred: so, changelog and pbr22:30
*** senk has quit IRC22:30
openstackgerritJoe Gordon proposed a change to openstack-dev/hacking: Continue reserving H6xx namespace for calling methods  https://review.openstack.org/5416522:30
*** jerryz has joined #openstack-infra22:31
*** prad_ has quit IRC22:33
openstackgerritA change was merged to openstack-infra/jenkins-job-builder: Make --delete-old more robust  https://review.openstack.org/5226222:38
*** hashar has quit IRC22:38
*** datsun180b has quit IRC22:41
*** dims has quit IRC22:43
*** adalbas has quit IRC22:44
harlowjabtw, bumped https://pypi.python.org/pypi/gerrit-view with czuul , comments/feedback welcome22:45
harlowjahttps://github.com/harlowja/gerrit_view/#czuul (screenshot there)22:45
clarkbfungi: don't let me forget but we should sort out the puppet running on puppetmaster stuff this week as it may make applying keys or removing them summit time interesting22:49
fungiclarkb: very good point (i have a pending change i need to push for that myself tonight too)22:51
fungiharlowja: i did actually start playing around with it last night, but no feedback yet22:52
harlowjanp22:52
harlowjaits pretty basic, ha22:52
fungii tend to work in traditional 80x25 terminals (yay greenscreen nostalgia), so some of it seemed a bit cramped22:52
clarkbfungi: yeah I need to push one too22:52
harlowjahmmm, ya the 25 part is tough22:53
harlowjaonly so much u can do with 25 :-P22:53
* fungi does a lot in 25 lines x a dozen terminals on his monitor, but yeah, understood22:53
harlowjaactually just checked, mine is 156x28, so i guess not that much diff22:54
harlowjaha22:54
*** lnxnut_ has quit IRC22:54
*** lnxnut has joined #openstack-infra22:55
sdagueclarkb: on this - https://review.openstack.org/#/c/53487/2 - that's matching success runs as well now right? that intentional?22:55
*** dims has joined #openstack-infra22:55
clarkbsdague: no, I should add a filter on build_status, thanks22:56
sdagueyep, that should do it22:56
clarkbsdague: basically need something that happens at the end of every console log and the line where it copies itself works22:56
clarkbbut I should filter on build_status22:56
sdagueyep22:57
sdagueheh, I should go -1 it and leave the feedback there as well :)22:58
*** lnxnut has quit IRC22:59
*** DennyZhang has joined #openstack-infra22:59
openstackgerritClark Boylan proposed a change to openstack-infra/elastic-recheck: Better end of console log indexing detection.  https://review.openstack.org/5348722:59
clarkbsdague: ^ that should fix it23:00
clarkbthanks23:00
*** sarob_ has joined #openstack-infra23:02
sdague+223:02
*** sarob_ has quit IRC23:02
*** DennyZhang has quit IRC23:02
*** senk1 has quit IRC23:03
*** sarob_ has joined #openstack-infra23:03
*** sarob has quit IRC23:06
*** sarob_ has quit IRC23:07
lifelessclarkb: your https://review.openstack.org/#/c/52689/ has inventory :)23:10
clarkblifeless: thanks23:10
*** dkliban has quit IRC23:11
openstackgerritAdrian Otto proposed a change to openstack-infra/config: Adding project Solum to StackForge  https://review.openstack.org/5315123:12
clarkblifeless: fwiw the file specific comments are common around these parts23:13
openstackgerritAnita Kuno proposed a change to openstack-infra/config: Create a seafile instance.  https://review.openstack.org/5403023:13
lifelessclarkb: -infra ?23:14
clarkblifeless: yes23:14
lifelessclarkb: huh, well up to you guys :)23:14
clarkbthe other thing should defnitely be fixed though23:15
lifelessclarkb: with the focus on one-concept changes and why-over-what, I don't think anyone else feels the need for per-file-comments.23:15
lifelessbut shrug23:15
lifelessclarkb: also a test, I realised I hadn't asked for one.23:15
clarkblifeless: that captures why and what23:15
lifelessclarkb: right, I know you did :)23:16
lifelessclarkb: if you haven't I would have also whined about hat23:16
lifelesss/hat/that/23:16
clarkbalso test, good point (I whipped the change up after dealing with the issue as a way to remind myself to make it so, I should add a test now)23:17
*** ^d has quit IRC23:17
jerryzclarkb: i see in the code that e-r queries elastic search based on change id and patch id. but if i use recheck to trigger a second build if the first fails due to a known bug, e-r will comment with two bugs if the second build fails due to a different known bug.23:21
*** oubiwann has quit IRC23:22
jerryzclarkb: is this  by design or could build uuid be part of the query?23:22
*** rakhmerov has joined #openstack-infra23:23
clarkbjerryz: build_uuid should be part of the query23:23
clarkbjerryz: or log_url which includes part of the build_uuid23:23
openstackgerritAnita Kuno proposed a change to openstack-infra/config: Create a seafile instance.  https://review.openstack.org/5403023:24
reedguys, is the sched for the DEsign Summit sessions ready?23:24
openstackgerritAdrian Otto proposed a change to openstack-infra/config: Adding project Solum to StackForge  https://review.openstack.org/5315123:24
jerryzclarkb:     def classify(self, change_number, patch_number, comment):23:25
clarkbreed: I think the schedule for infra is ready, not sure about the other projects23:25
clarkbjerryz: comment is the magic bit that includes the uuid23:25
*** hashar has joined #openstack-infra23:25
anteayahey hot and rainy in hk next week23:26
reedclarkb, thanks23:26
clarkbwoot23:26
pleia2reed: I am both amused and depressed by your sched tweets today (I feel your pain)23:27
pleia2reed: if you do find an ical integration mechanism, you'll be my bff23:27
jerryzclarkb: i don't quit understand. uuid is a part of the comment for jenkins log_url23:27
*** rakhmerov has quit IRC23:27
jerryzclarkb: but not part of the elastic-recheck comment23:27
reedpleia2, unfortunately I found no way without loosing the possibility to sync the actual source of data23:28
clarkbjerryz: if you look at the mechanism around that comment variable it is checking that the log_url left in the gerrit comment by zuul/jenkins matches the log_url in elasticsearch23:28
pleia2reed: sigh23:28
openstackgerritAnita Kuno proposed a change to openstack-infra/config: Create a seafile instance.  https://review.openstack.org/5403023:28
reedpleia2, even with how Sched suggests to operate (add the personal calendar to google), google pulls only once a day23:28
*** cyeoh_ is now known as cyeoh23:29
reedmy owncloud server cannot import an .ics23:29
pleia2ah23:29
anteayawhat version of owncloud are you on, reed?23:29
reedI can put it in Thunderbird but then it sits there... useless, as I need it on my phone23:29
reedanteaya, let me check23:29
anteayak23:29
reedanteaya, 5 something23:30
anteayaokay23:31
anteayayeah I was on 5 something too23:31
anteaya5.0.12 is latest stable23:31
anteayathen 6 alpha23:31
anteayaI was on 5.0423:31
reedhonestly, I am starting to think that it messes up with the calendars23:31
anteaya5.0.423:31
reedhard to diagnose though as my brain may be as buggy23:31
clarkblifeless: I think I may need to bug jeblair about testing that change. It looks like TestScheduler overrides zuul.merger's init mechanism23:31
anteayawe I'm pounding away on seafile now, we had better all like seafile23:32
clarkblifeless: not sure if that should be torn out or if we need to do something more silly23:32
pleia2I'll probably just end up using the sched inteface again on my tablet, hope for the best with things on my other calendar (whatever, people know I'm traveling, I can miss things :))23:32
clarkblifeless: but I definitely think we should have a test (as my discovery shows)23:32
reedanteaya, trying to update... it fails with no discernible error23:32
clarkbreed: clearly the solution is printouts23:33
anteayayeah, I couldn't update owncloud from the admin page on owncloud either23:33
clarkbreed: I am probably going to print out a schedule just beacuse23:33
*** dcramer_ has joined #openstack-infra23:33
jerryzclarkb: this is what i see in the debug log about the query: Making a request equivalent to this: curl -XGET 'http://10.145.81.231:9200/_search?size=10' -d '{"sort": {"@timestamp": {"order": "desc"}}, "query": {"query_string": {"query": "( @message:\" 503\" OR message:\" 503\" ) AND filename:\"logs/syslog.txt\" AND syslog_program:\"proxy-server\"\n AND build_change:\"34951\" AND build_patchset:\"1\""}}}'23:33
reedclarkb, why didn't I think of that? :)23:33
anteayanever updated, no output23:33
*** b3nt_pin has joined #openstack-infra23:33
reedclarkb, unfortunately not a solution for me: I need to be able to see in *one* place all of my appointments23:33
clarkbjerryz: right, the matching happens in e-r (it can probably be done in elasticsearch proper but isn't today)23:33
reedsessions I *have to* be in and personal meetings23:34
clarkbreed: ah23:34
reedif things are not on my calendar they don't happen23:34
clarkbyeah if you have more than just sessions to juggle then printouts will be hard23:34
reedand given that walking from one side to another in HK may take as long as 15 minutes...23:34
fungireed: clarkb: my solution is a text file with a list of where i intend to go when ;)23:34
reedI need to have a very *solid* system or I'll miss lots of meetings23:35
fungigranted, my text file doesn't beep at me to let me know when something is coming up23:35
clarkbfungi: you'll be surprised at how hard it is to edit a simple txt file on chromeos. It is the biggest flaw so far23:35
reedfungi, a paper agenda would work too... but it doesn't ring to remind me to get the hell out of the meeting and run to a session23:35
reedor viceversa :)23:35
reedi don't like to trust my brain23:36
clarkblike seriously how hard can it be to expose the vi(m) that must be on the system23:36
reedclarkb, are you taking a disposable chrome os?23:36
clarkbreed: yup23:37
reeddamn, you paranoid23:37
fungithat would risk exposing ways to risk rooting and installing of non-googOS[TM]23:37
reednow you make me feel like I'll be out there like naked in the snow23:37
clarkbwell "disposable" I am not super paranoid about it but need a light machine with good battery life that isn't completely insecure23:37
fungiclarkb: i'm bringing tamper-evident evidence bags, evidence-tape and foil stickers, in case you want to partake (i'll have plenty to go around)23:38
reedclarkb, did you have to sign your soul to google to use it?23:38
clarkbreed: yes23:38
*** SergeyLukjanov is now known as _SergeyLukjanov23:38
reedclarkb, good :)23:38
* reed feels better now23:38
clarkbnone of my other machiens have secure boot23:38
fungigood for when you don't trust the hotel room safe and want to leave your disposable hardware while you dine23:38
clarkbwhich is sort of necessary to trust disk encryption23:38
reedfungi, geez23:38
*** _SergeyLukjanov has quit IRC23:38
reedthey can tamper your laptops once they stole it :)23:39
clarkbfungi: nice, I may have to partake23:39
*** dcramer_ has quit IRC23:39
fungireed: if they steal it, good riddance. i just want to know if they try to put it back after23:39
anteayamy syntax is okay with puppet lint and that is all I can do tonight, I still haven't run it, if anyone has a boatload of spare time and can't wait to give me the benefit of their time, I welcome your comments or I'll just keep on it tomorrow23:39
reed:)23:39
anteayahttps://review.openstack.org/#/c/54030/1823:39
clarkbreed: it has a decent IPS display which makes me want an IPS display on everything now23:40
reedseafile seems interesting... does it store files in swift or just git?23:40
clarkband ~6 hour battery life which is about 4 hours better than the alternatives23:40
anteayastorage on the my beta is mysql23:40
*** mrodden1 has quit IRC23:40
reedwikipedia:IPS_display23:40
anteayawe are going for trove once it is up23:40
reedanteaya, it stores files in mysql?23:41
anteayait doesn't use swift23:41
anteayamysql was the only db I set up for the beta installs23:41
*** jergerber has quit IRC23:42
reedi became a big fan of sshuttle over the weekend: looks like it works on my wife's mac os too23:42
reedso very simple ssh sessions in different datacenters will give me VPN tunnels easily23:43
*** nati_uen_ has joined #openstack-infra23:43
*** jhesketh_ has joined #openstack-infra23:43
reedon different ports, too... very easy, no need to mess up with openvpn or ipsec23:43
*** jhesketh has quit IRC23:45
clarkbreed: fwiw I would not use a chromebook for daily use23:45
*** b3nt_pin is now known as beagles23:45
clarkbbut as a travel device it seems decent23:45
*** nati_ueno has quit IRC23:46
*** beagles has quit IRC23:47
*** yamahata has quit IRC23:47
*** denis_makogon has quit IRC23:47
fungii like traveling with a cheap netbook. bonus is i'm not stuck with teh googolz23:47
*** b3nt_pin has joined #openstack-infra23:48
*** b3nt_pin is now known as beagles23:48
*** SergeyLukjanov has joined #openstack-infra23:48
*** weshay has joined #openstack-infra23:51
*** dcramer_ has joined #openstack-infra23:52

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