Wednesday, 2013-09-04

*** dims has quit IRC00:00
jeblairclarkb: the documentation for the -n and -t options suggest to me that is the case00:00
*** bearhands is now known as comstud00:00
clarkbjeblair: I know that when doing a git remote update you only get tags on the branches being tracked00:01
fungijog0: yeah, e-mail thread later in the week (maybe thursday) to start comparing opinions might be good. i gather we should also be using subcategory tags and can put more than one on a talk, so that might also be a good way to coordinate some things00:01
clarkbjeblair: and git remote update is just fancy git fetch so I think that is correct00:01
jog0fungi: yeah00:02
*** amotoki_ has quit IRC00:06
*** amotoki_ has joined #openstack-infra00:06
mordredclarkb: you have machiens that are still  borked?00:07
clarkbmordred: no I fixed them00:07
mordredclarkb: ok00:08
clarkbmordred: I have a feeling that if you tried this on one of our precise slaves that needs newer pbr you will see the failure00:08
clarkbmordred: zuul-dev maybe00:08
mordredclarkb: I can see the pbr upgrade failure00:08
mordredclarkb: it's the other failure I can't see00:08
clarkbmordred: the install pbr failure?00:09
lifelesshow do you do multiline file contents in yaml ?00:09
mordredlifeless: :-00:09
clarkbI would expect the same sort of issue on zuul-dev00:09
mordredlifeless: one sec - I will paste example00:10
mordredlifeless: https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml#n1300:10
mordredlifeless: : | is what I meant :)00:10
*** amotoki_ has quit IRC00:12
*** dkranz has joined #openstack-infra00:12
*** michchap has joined #openstack-infra00:16
*** dims has joined #openstack-infra00:16
lifelessis an ssl chain file needed ?00:16
openstackgerritlifeless proposed a change to openstack-infra/config: Phase 3 infra bootstrap docs: gerrit.  https://review.openstack.org/4497000:18
clarkbwoo I htink we have non deterministic sudoing in neutron tests when mocks are not setup ahead oftime00:20
*** jhesketh_ has joined #openstack-infra00:21
clarkbmarun: https://review.openstack.org/#/c/43558/ my comments on that review hopefully provide more details00:22
*** svarnau has quit IRC00:22
lifelessclarkb: the top of review.projects.yaml.erb is not like the bottom00:23
lifelessclarkb: does the homepage key have special meaning?00:23
clarkblifeless: correct. review.projects.yaml.erb comes in two sections, first section is of defaults and second section is a list of projects with possible default overrides00:23
clarkblifeless: it sets the homepage on github.org. We should probably start overriding thosefor stackforge projects00:25
clarkb*github.com00:25
clarkblifeless: https://github.com/openstack-infra/config where it says website, that value comes from homepage00:26
clarkbmordred: ^00:26
lifelessclarkb: where are teh docs for adding projects again?00:26
clarkblifeless: http://ci.openstack.org/stackforge.html00:26
lifelesscool00:27
lifelesswhat does the separation of gitbhu users achieve?00:27
lifelessdo derivers need to do that ?00:27
clarkblifeless: which separation? stackforge vs openstack or the one about actual users?00:28
*** nati_uen_ has quit IRC00:28
lifeless  gerrit-user: openstack-project-creator                                                                      |g00:28
lifeless  gerrit-committer: OpenStack Project Creator <openstack-infra@lists.openstack.org>                           |r00:28
lifeless  gerrit-key: <%= ssh_project_key %>                                                                          |o00:28
lifelessin the erb file00:28
*** fbo_away has quit IRC00:29
clarkbyou don't strictly need to do that, but it does do one really nice thing. It prevents you from needed to use an account interactively that always has super powers00:29
clarkbI find it really annoying when reviewing code to have the extra buttons unless I need them (because 99% of the time I don't want them and don't want to misclick)00:30
lifelessisn't that user also set in hiera? Why is it hardcoded in this template.00:30
lifelessoh, I'm thinking github users.00:30
lifelessbah00:30
clarkbI am going to run home now but should follow IRC again once there if you have more questions00:31
lifelessthanks00:31
lifelessI will00:31
lifelessI made no progress the last two days without a ready source of institutional knowledge00:31
*** Ryan_Lane has quit IRC00:33
*** rfolco has quit IRC00:38
*** UtahDave has quit IRC00:40
openstackgerritJames E. Blair proposed a change to openstack-infra/config: Use gerrit for the remote update in post jobs  https://review.openstack.org/4498800:41
mordredlifeless: so, this  may be late in framing...00:46
*** mgagne has quit IRC00:48
mordredlifeless: but heira is essentially just a collection of input parameters - so perhaps the knowledge about what the heira bits do is really a deficiency in describing what the input params need?00:48
clarkbmordred yes the params should be better documented in puppet00:48
mordredlifeless: also, probably out of scope for right now, but I do believe that ::gerrit and openstack_project::gerrit is not split where it should be in all places00:49
mordredsome things should be split out and combined via composition - and other things should really just be features of the underlying gerrit module - I've been meaning to do a refactor for a while00:49
*** rfolco has joined #openstack-infra00:50
clarkbjeblair is that temporary until the zuul change?00:50
clarkbmordred ++ see hunners roles and profiles example on github00:51
mordredclarkb: aroo?00:51
lifelessmordred: it is, which is why I document the hiera bits in the .pp files.00:51
mordredlifeless: cool00:51
* mordred catching up by just poking people00:51
jeblairclarkb: yes; it should only be used by post jobs, so the additional load on gerrit should be small00:52
jeblairpost,release,pre-release00:52
*** nos_ has joined #openstack-infra00:54
*** nos_ has quit IRC00:54
*** nosnos has joined #openstack-infra00:55
*** changbl has quit IRC00:55
clarkbmordred: https://github.com/hunner/roles_and_profiles00:56
clarkbjeblair: wfm00:56
clarkbmordred: our puppet modules should start looking like that, then we can use r10k to pull in modules (and split our modules out) leaving openstack-infra/config with launch/, a puppetfile, and the openstack_project module00:59
clarkbmordred: and some scripts00:59
mordredclarkb: what's r10k?01:00
clarkbmordred: it is like puppet librarian but actually works according to the author01:00
*** yjiang5 is now known as yjiang5_away01:00
*** changbl has joined #openstack-infra01:00
mordredclarkb: I do not understand how that example is different01:01
mordredclarkb: there is also no puppetfile01:01
clarkbmordred: roles and profiles is a compeltely different problem than what puppetfiles solve01:02
clarkbmordred: all modules that are not roles or profiles could be serviced by a puppetfile01:02
mordredclarkb: ah.01:02
mordredgotcha01:02
clarkbmordred: but by organizing the specific bits into roles nad profiels you end up with nicely reconsumable bits01:02
clarkbin the other modules01:03
lifelesswhats test-manage-project.config  for ?01:03
lifelessthe name test in it is ambiguous - is it for ci,or for manual testing of things or ???01:03
clarkblifeless: it is used against review-dev01:04
clarkblifeless: there is a test-manage-project on review-dev01:04
mordredclarkb: ah. ok. (reading presentation)01:05
mordredclarkb: I think this is a more complete version of what I was trying to do with the openstack_project:: module and how we're doing things in site.pp01:06
clarkbmordred: yup01:06
mordredEXCEPT01:06
clarkbhunner brought it up when he tried using our gerrit module and that is what I told him. "We seem to have tried to do something like this but never got there"01:06
mordredclarkb: so the expectation is that hiera calls go into profiles?01:07
clarkbmordred: yeah I disagree with that01:07
mordredI do too01:07
clarkband there was some arguing :) but overall  Ithink the structure is good01:07
mordredhrm. SO01:08
mordredhiera in profiles would reduce a lot of the copying of parameters we do01:09
mordredbut I don't like that it means that it's hard to do a simple different site.pp without going heira on it01:09
clarkbit would, and if we explicitly make profiles not reconsumable we could get away with it01:09
clarkbyeah that. for testing you want to reconsume site.pp01:09
clarkband other folks probably will still pull openstack-infra/config even if it is skeletonized01:10
lifelessso I'm doing about 90% copying 10% parameterisation atm01:10
lifelessI would do it better and refactor, but ETIME.01:10
mordredyah01:10
mordredlifeless: that's what I did with the HP gerrit01:10
mordredand then filed a note with myself to go back and refactor where I could not parameter01:10
mordred(I did send some patches upstream)01:10
*** pcrews has joined #openstack-infra01:10
lifelessmordred: yeah01:11
lifelessmordred: I figured you had a fairly good reason for leaving me with this pile of poo :)01:11
jeblairi'm so glad i've spent time helping01:12
mordredlifeless: there's a big enough refactor in some places that it just hasn't bubbled up01:12
lifelessjeblair: it's been very helpful!01:12
lifelessjeblair: by poo, I didn't mean the infrastructure is bad01:12
lifelessjeblair: I meant that mordred had already done a full pass over this, but it's still copy-paste material.01:13
mordredyup. that's on me01:13
mordredI meant to document what I did01:13
mordredand then I got busy01:13
lifelessjeblair: I didn't mean to cast aspersions on -infra or the config tree as a whole.01:14
jeblairlifeless: np.  i now understand what you were saying.01:14
* mordred hangs head01:15
lifelessjeblair: sorry for the phrasing there; in person I think it would have come across properly01:16
*** jhesketh has quit IRC01:16
*** jhesketh has joined #openstack-infra01:16
*** amotoki_ has joined #openstack-infra01:20
lifelessthe run things many times thing with puppet is super annoying01:22
marunclarkb: thanks for the review pointer, I'll see if I can help get that fixed.01:23
*** amotoki_ has quit IRC01:24
jeblairlifeless: yeah, if we had the test system we really want, we'd spin up (at least) a new node for each puppet change and make sure things don't bitrot and can work once from a fresh run; as it is, we only catch bitrot when we build new servers01:25
lifelessjeblair: yeah; the tripleo story has the same issue, we're working towards the same grail01:26
lifelessjeblair: [catching things early that is]01:26
lifelessI have a manage-projects issue01:27
lifelessparamiko.SSHException: not a valid DSA private key file01:27
lifelessbut01:27
lifelessI presume it's looking at less /home/gerrit2/review_site/etc/ssh_project_rsa_key01:27
lifelesswhich is - by name anyhow - meant to be an RSA file01:27
lifelessand in fact,01:27
lifeless# file /home/gerrit2/review_site/etc/ssh_project_rsa_key01:27
lifeless/home/gerrit2/review_site/etc/ssh_project_rsa_key: PEM RSA private key01:27
lifelessalso I need a hand with apache ssl - it wants an intermediate chain file, and I have no clue about that for self signed certs01:28
clarkblifeless: for the self signed certs we typically just use the one that comes in /etc/ssl/certs ssl-cert-snakeoil.pem iirc01:29
*** tian has joined #openstack-infra01:30
clarkbthough you may actually care about the contents of your self signed cert01:30
clarkblifeless: https://github.com/saltstack/salt-cloud/pull/68 could your exception be for similar reasons?01:31
jeblairlifeless: you should be able to omit the chain file for an ssl cert01:33
jeblairlifeless: most of our modules do that if you set the chain file contents to '' in hiera01:33
jeblairlifeless: unsure if the gerrit module does that01:33
mordredjeblair: it does01:34
lifelessSyntax error on line 30 of /etc/apache2/sites-enabled/50-review.testing-cabal.org.conf:01:36
lifelessSSLCertificateChainFile: file '/etc/ssl/certs/intermediate.pem' does not exist or is empty01:36
lifelessAction 'start' failed.01:36
clarkbthat may be a bug01:37
lifelessgerrit_ssl_chain_file_contents: ''01:37
lifelessin hiera01:37
clarkblifeless: I wonder if that is creating a string that != "" in the vhost .erb01:38
lifelessclarkb: I made a new self signed cert, will that be compatible with the /etc/ssl/certs/ssl-cert-snakeoil.pem you're mentioning ?01:38
clarkblifeless: no you just use the snakeoil cert instead01:38
clarkblifeless: oh the vhost erb is checking the chain file and not chain file contents01:39
clarkblifeless: so either unset the file variable or change the check in the vhost erb01:39
lifelessclarkb: ./modules/meetbot/templates/vhost.erb ?01:40
clarkblifeless: modules/gerrit/templates/gerrit.vhost.erb01:41
*** HenryG has joined #openstack-infra01:42
lifelessclarkb: just adding _contents on the end will be sufficient ?01:42
clarkbhmm actually no01:43
clarkbI think the check there is correct, because you may hve a chain file that isn't managed by puppet01:43
lifelessclarkb: is that a use case?01:43
clarkblifeless: yes, I think so01:43
lifelessclarkb: surely the answer is 'update it in hiera' in that case?01:43
clarkbmaybe you don't have hiera or some sites cohabitate01:44
clarkbunsetting the other variable is easy enough01:44
clarkblifeless: and appears to be unset by default in ::gerrit and ::openstack_project::gerrit.pp01:45
lifelessclarkb: how do you unset it ? I certainly haven't set it.01:45
clarkblifeless: openstack_project::review.pp has it hardcoded01:46
*** pabelanger has joined #openstack-infra01:46
lifelessclarkb: this seems like needless complexity to me, but sure.01:47
lifelessclarkb: just '' ? falsey?01:47
clarkblifeless: review.pp isn't meant to be reconsumed...01:47
lifelessclarkb: see the discussion I raised the other day about what is config and what is design01:48
*** nati_ueno has quit IRC01:48
clarkblifeless: I totally understand and grok that argument. The roles and profiles thing should get us there01:48
clarkblifeless: but today the outermost onion layer isn't mean to be used that way01:48
*** nati_ueno has joined #openstack-infra01:48
lifelessclarkb: sure; so my instructions I'm writing - viewable in the review - are 'copy and paste and make X adjustments'01:49
lifelessclarkb: w.r.t. complexity I'm saying having a 'not managed by puppet' use case in a puppet managed file is very odd01:49
clarkblifeless: so you can either update teh vhost erb like you suggested (but I don't think that is a proper fix, others may disagree) or update openstack_project::review to make this configurable or write your own review.pp01:50
clarkblifeless: the certs themselves don't have to be managed by puppet01:50
clarkbyou might have some other key management mechanism (whcih isn't uncommon aiui)01:50
*** adalbas has quit IRC01:51
mordredclarkb: I think that our assumption that review.pp isn't reconsumable is a split of things in the wrong place01:51
clarkbmordred: anything in openstack_project isn't meant to be directly reconsumable if you want to be different01:52
mordredclarkb: cause most of the people who are trying to reconsume our stuff are wanting a gerrit that works like ours01:52
clarkbright which means you need a chain file01:52
mordredclarkb: I know - but I think we may have underestimated how much "OpenStack's Gerrit" is a thing people want01:52
mordredas opposed to just "a gerrit"01:52
mordredAH01:52
clarkbI am totally on board with the make it better this is not ideal01:52
mordredI follow what you are saying01:53
clarkbbut this is how things are today01:53
lifelessclarkb: thats not related to 'works like openstacks', thats related to 'has a public certificate not a self signed one'01:53
lifelessclarkb:01:53
lifelessclarkb: 'certs are in hiera' is related to 'works like openstacks'01:53
clarkblifeless: but puppet itself is config01:53
clarkband in the outermost layer the config mixes with the design01:53
lifelessclarkb: there is config and there is config01:53
lifelessclarkb: there is server config and there is project config; imagine for a second that the openstack ci infrastructure was an aaS thing.01:54
clarkblifeless: I totally get that01:54
lifelessclarkb: which bits would be API driven, and which bits would be deployer problems?01:54
clarkblifeless: and my suggestion to move towards something using the roles and profiles paradigm will get us there01:54
lifelessThis is clearly a deployer problem. What projects to manage is an API consumer thing.01:54
clarkbbut today that isn't the case01:54
lifelessclarkb: right, we're all agreed ;)01:54
lifelessclarkb: I want to be clear - I'm not whinging about what I'm needing to do.01:55
lifelessclarkb: I'm arguing that *in the current setup*, the template file supporting a case openstack doesn't deploy is hair on the yak.01:55
clarkblifeless: why, we would like it to be consumable by others01:56
lifelessclarkb: and that the future setup, with roles profiles etc might be a time that that matters - or it might now.01:56
clarkbI think it matters now beacuse you can take the gerrit module and reuse it01:56
clarkbyou will just end up with a Gerrit gerrit not an OpenStack gerrit01:56
lifelessI'm super wary of early generalisation with this sort of thing.01:57
mordredclarkb: I do not think that is true01:57
clarkbmordred: which thing isn't true?01:57
mordredclarkb: I believe we have openstack isms split across both modules01:57
lifelessI appreciate the story - support folk with pluggable certificate management infrastructures.01:58
mordredclarkb: ::gerrit does not get you a gerrit gerrit01:58
clarkbmordred: right but those are bugs01:58
clarkbwe shouldn't create more bugs because it makes life easy now01:58
lifelessBut having two variables that are tied together like this with non-obvious side effects seems like a non-scalable [in terms of understanding and predictability] pattern.01:58
mordredclarkb: yah. I'm just supporting the yak shaving argument - if gerrit gerrit doesn't work, and we're wanting to refactor to roles/profiles anyway...01:58
mordredclarkb: then patches to suppor tthe thing that actually comes up right now, namely, reconsuming openstack gerrit, are proably more important01:59
clarkblifeless: welcome to puppet01:59
lifelessclarkb: I'd much rahther see a top level thing in puppet for managing 'this is an SSL key and it might come from lots of places and it might have an intermediate file and so on'01:59
clarkbmordred: but it is reconsumable...01:59
*** yaguang has joined #openstack-infra01:59
lifelesswooo02:00
clarkbmordred: I am arguing that it isn't reconsumable from openstack_project::review.pp if you want something other than an OpenStack Gerrit02:00
lifelesshttps://review.testing-cabal.org/#/q/status:open,n,z02:00
lifeless^ wooo02:00
uvirtbotlifeless: Error: "wooo" is not a valid command.02:00
lifelesswoo woow woo02:00
clarkbmordred: openstack_project::gerrit actually is reconsumable02:00
clarkbI think02:00
mordredclarkb: ok. I grok02:00
mordredclarkb: it's sort of reconsumable02:00
mordredthere are bugs02:00
lifelessclarkb: at the moment it's copy-pastable; I presume thats not what you mean ?02:00
clarkblifeless: right, should be able to reconsume without copy pasta02:01
mordredclarkb: or, rather, let me say a different thing...02:01
Alex_Gaynorhmmm, pasta02:01
lifelessclarkb: you will want to review my docs where I say to copy-paste it then :)02:01
mordredI think that "OpenStack's Gerrit" and "An OpenStack Gerrit" are different things02:01
clarkbmordred: thats fair02:02
clarkbmordred: and openstack_project::review is OpenStack's Gerrit. openstack_project::gerrit is an Openstack Gerrit02:02
mordredclarkb: and right now I think that there e are elements of "OpenStack's Gerrit" that bleed into the description of "An OpenStack Gerrit"02:02
mordredclarkb: and that they do is a bug :)02:02
mordredbut it's been low priority for _us_02:02
clarkbmordred: I actually think that in this case there isn't much bleeding02:03
clarkbopenstack_project::gerrit doesn't have the issue, only openstack_project::review does02:03
clarkbrunning openstack_project::gerrit on two servers has helped one of which uses snakeoil certs :002:03
clarkb* :) so at least in this particular case I think we are fine. There are definitely bugs though02:04
*** gyee has quit IRC02:04
anteayapleia2: if I see docs that tell me to install packages on xUbuntu 12.04 can I use Ubuntu? or would not using xUbuntu trip me up?02:04
anteaya*I don't know the difference very well*02:05
lifelessclarkb: no, thats not the manage-projects issue02:05
lifelessclarkb: I can ssh to ssh -p 29418 robertc@review.testing-cabal.org02:05
lifelessclarkb: though I get a permission denied of course, as I haven't setup users yet.02:05
mordredlifeless: I've been meaning to add initial user creation steps to the puppet module02:06
mordredlifeless: so I welcome work on your side in this area :) (I think that doing it via sql will likely be required, due to how initial admin user account works in gerrit)02:07
lifelessso do you guys lookup passwords in hiera whenever you need them (e.g. for the manual mysql root commands in gerrit.rst ?)02:07
clarkbI typically use the gqsl interface02:07
anteayabah I'll just install it and watch it go up in flames if it is going to go02:08
lifelessclarkb: gsql ?02:08
mordredlifeless: if I need to do sql on the box, I log in as root and just run mysql02:09
mordredlifeless: the root user is configured to be able to log in to the mysql on the box02:09
lifelesshah so bad instructions02:09
clarkblifeless: ssh gerrit gerrit gsql02:09
clarkbits a gerrit command02:09
mordredbut clarkb's thing is safer02:09
lifelessclarkb: can you do that for initial setup?02:10
mordredno. for initial setup you'll need direct mysql commands02:10
lifelessclarkb: and by ssh gerrit, do you mean the port 29418 ?02:10
mordredlifeless: ssh -p 29418 robertc@review.testing-cabal.org gerrit gsql02:11
clarkblifeless: yeah talking to the gerrit ssh server02:11
clarkblifeless: and yes, we also tend to use the root account with its mysql conf file to do things automagically02:12
lifelesshmm, i don't see any initial-user setup stuff02:12
mordredlifeless: there is none02:13
mordredlifeless: initial-user setup is all manual02:13
mordredcurrently02:13
lifelessmordred: yes, but I don't see any docs for it.02:13
mordredthe first person to log in to the gerrit TTW gets admin/root02:13
lifelessoh02:14
clarkbthere is some stuff in git-review we might be able to genericize02:14
clarkbthat does initial setup for gerrit so that tests can run against it02:14
clarkbbut it is still pretty rough, I had to hack on it last week to get it to work with gerrit 2.402:15
mordredAlex_Gaynor: what's fox?02:17
Alex_Gaynormrodden: I assume it's like tox, but I typod it02:17
mordredAlex_Gaynor: hahahaha02:17
mordredAlex_Gaynor: (that should work02:17
Alex_Gaynormordred: most confusing things I say can be explained by the fact that I'm a very poor typist02:18
mordredAlex_Gaynor: unless it's expecting a c thing to be installed - all the gate is doing for ceilometer is what you desscfribe02:18
mordredAlex_Gaynor: what broke02:18
Alex_Gaynormordred: I think I probably need to be running mongodb02:18
mordredAlex_Gaynor: I have learned that I cannot type without direct visual feedback02:18
lifelessdoes puppet setup the gerrit user for manage-projects etc?02:18
mordredAlex_Gaynor: you should not need to be running mongo - clarkb <-- ?02:19
mordredlifeless: nope02:19
lifelessis there a concordance of such users somewhere?02:19
clarkblifeless: that is the only one02:19
*** melwitt1 has quit IRC02:19
clarkbwe got rid of the sync user so there shouldn't be others02:20
clarkbmordred: what about mongo?02:20
mordredclarkb: does ceilo need mongo to run tox tests?02:20
clarkbmordred: oh yeah ceilometer does mongodb tests, but they should be opportunistic02:20
mordredlifeless: http://ci.openstack.org/gerrit.html#gerrit-configuration <-- don't forget those steps :)02:20
clarkbbecause they don't run on our precise hosts which have ancient mongodb02:20
mordredlifeless: and then http://ci.openstack.org/gerrit.html#access-controls02:21
clarkbyou might need the dependencies though so that deps can build02:21
clarkbbut actual tests probably won't run02:21
mordredlifeless: lists all of the global acls which are also not managed by anything02:21
mordredlifeless: as well as the groups that one would need02:21
openstackgerritlifeless proposed a change to openstack-infra/config: Make gerrit DB setup match actual practice.  https://review.openstack.org/4499302:21
openstackgerritlifeless proposed a change to openstack-infra/config: Phase 3 infra bootstrap docs: gerrit.  https://review.openstack.org/4497002:21
*** rcleere has joined #openstack-infra02:22
mordredlifeless: and the user needs to be in the Project Bootstrappers group02:23
*** markmcclain has joined #openstack-infra02:23
mordred(we also have it in Administrators)02:23
lifelesswhat we're doing for tripleo is writing api scripts to drive these sorts of setups02:24
lifelessso they aren't tied into machine-orchestration layers [like pupper]02:24
lifelesstime for a short break for me02:24
*** pcrews has quit IRC02:25
*** ryanpetrello has joined #openstack-infra02:29
*** ryanpetrello has quit IRC02:40
*** ryanpetrello has joined #openstack-infra02:42
*** nati_ueno_2 has joined #openstack-infra02:42
*** ryanpetrello has quit IRC02:43
*** nati_ueno has quit IRC02:46
*** nosnos_ has joined #openstack-infra02:47
*** nosnos has quit IRC02:49
*** dims has quit IRC02:51
*** nosnos_ has quit IRC02:55
*** nosnos has joined #openstack-infra02:55
*** anteaya has quit IRC02:58
pleia2oops, missed anteaya by a couple minutes03:01
*** kiall has quit IRC03:07
*** xchu has joined #openstack-infra03:12
*** pcrews has joined #openstack-infra03:13
openstackgerritAlex Gaynor proposed a change to openstack-infra/config: Run the heatclient tests under PyPy  https://review.openstack.org/4499603:17
*** nati_ueno_2 has quit IRC03:25
lifelessclarkb: mordred: how do you assign the permissions for Project Bootstrappers to the group ?03:26
*** nati_ueno has joined #openstack-infra03:26
*** kiall has joined #openstack-infra03:29
*** tian has quit IRC03:34
*** rcleere has quit IRC03:34
lifelessmordred: clarkb: how does the acls described in gerrit.rst get into the gerrit sytem ?03:54
openstackgerritlifeless proposed a change to openstack-infra/config: Gerrit docs improvements - user and groups.  https://review.openstack.org/4500103:59
openstackgerritlifeless proposed a change to openstack-infra/config: Phase 3 infra bootstrap docs: gerrit.  https://review.openstack.org/4497003:59
*** odyi has quit IRC03:59
*** clarkb has quit IRC03:59
*** Guest16331 has quit IRC03:59
*** mikal has quit IRC03:59
*** stevebaker has quit IRC03:59
*** mikal_ has joined #openstack-infra03:59
*** clarkb has joined #openstack-infra03:59
*** lillie has joined #openstack-infra04:00
*** odyi has joined #openstack-infra04:00
*** lillie is now known as Guest7266504:00
lifelessclarkb: https://github.com/saltstack/salt-cloud/pull/68 - no; it was that I hadn't created the account yet.04:01
*** stevebaker has joined #openstack-infra04:01
*** mikal_ is now known as mikal04:03
*** dkliban has quit IRC04:04
fungilifeless... same answer for both--the All-Projects acl gets hand configured through the gerrit webui or a suitable acl config file is pushed through the gerrit ssh interface or committed in ~gerrit2/review_site/git/All-Projects.git/ in refs/meta/config04:09
lifelessfungi: so https://review.testing-cabal.org/gitweb?p=All-Projects.git;a=blob;f=project.config;h=4d301c96c45478a43922a7bcc8b15f0aef15a3dc;hb=f701a9ea071e144dd4b1858f960ab6e835b3f47404:10
lifelessfungi: that looks similar to the syntax in the docs04:10
lifelessfungi: does the one in the docs replace that file ?04:10
*** markmcclain has quit IRC04:11
fungithough if applied directly to the filesystem without going through the gerrit interfaces, it misses out on built-in syntax checking04:11
lifelessfungi: whats the best way? I"m going to write down what you tell me for posterity :)04:12
fungiyeah, you'd update/replace that04:12
fungipushing it through gerrit's ssh interface is probably automation-friendly04:13
*** vogxn has joined #openstack-infra04:13
*** nati_ueno_2 has joined #openstack-infra04:14
fungimanage-projects does similar work for project-specific acls04:14
fungiwe want to puppet it, just haven't found the time, i think (though maybe there are more subtle obstacles to that one i'm overlooking)04:15
*** nati_ueno has quit IRC04:17
openstackgerritDarragh Bailey proposed a change to openstack-infra/jenkins-job-builder: Support use of different git chooser strategies  https://review.openstack.org/4500204:18
fungigroup membership management is a separate puppetry challenge though... they're all kept in mysql tables04:18
pleia2"Your Presentation proposal for linux.conf.au has been accepted" \o/04:20
fungicongrats, pleia2!04:20
pleia2thanks :)04:20
lifelessfungi: I just need a recipe to apply by hand04:21
pleia2I've never been to .au, and first place I get to go is.. Perth? :)04:21
pleia2will have to see about a Sydney stop perhaps04:21
pleia2but yay!04:22
lifelesspleia2: congrats :)04:25
*** SergeyLukjanov has joined #openstack-infra04:25
Alex_Gaynorpleia2: plan an extra few days to visit sydney, when I did that this past year it was awesome04:26
morganfainbergpleia2, nice!04:28
fungilifeless: last time i set up a gerrit i updated those default acls through the webui, but you should be able to push it as your initial administrative user, or possibly authenticating as the builtin 'Gerrit Code Review' account (it's case sensitive) using the gerrit ssh service host key as the account's ssh key04:31
* fungi should afk for the night and try to sleep... stupid jetlag04:33
pleia2Alex_Gaynor: given the timing, I'm thinking new years in sydney would be fun04:36
*** ArxCruz has quit IRC04:37
*** reed has quit IRC04:38
*** vipul is now known as vipul-away04:44
*** yongli has joined #openstack-infra04:44
openstackgerritDarragh Bailey proposed a change to openstack-infra/jenkins-job-builder: Support use of different git chooser strategies  https://review.openstack.org/4500204:44
lifelessfungi: whats the ssh command to do acl updates?04:47
lifeless(or clarkb / mordred / pleia2  :))04:48
*** vipul-away is now known as vipul04:50
*** Ryan_Lane has joined #openstack-infra04:51
*** boris-42 has joined #openstack-infra04:51
*** vogxn has quit IRC04:56
*** nati_ueno has joined #openstack-infra05:02
clarkblifeless: its weird because you are pushing to a special git ref05:02
lifelessclarkb: I've been googling for howtos and docs.05:03
lifelessclarkb: and been overloaded with related-but-not-that stuff05:03
clarkblifeless: I think it was removed from our docs when we reorged them, let me find it in history for you05:03
*** openmike|2 has joined #openstack-infra05:04
*** nati_ueno_2 has quit IRC05:05
clarkblifeless: http://git.openstack.org/cgit/openstack-infra/config/tree/doc/source/gerrit.rst?id=05aaa0b956af5e06b15bf1b760874f99f3d86a79#n83105:06
clarkblifeless: I like to do that in a brand new repo that I git init and not clone05:06
clarkblifeless: that way I don't have to clean out the actual repo contents05:07
lifelessshould I restore those docs?05:09
lifelessclarkb: ^05:09
clarkblifeless: no, they were removed because we rely on manage_projects.py now05:09
clarkblifeless: I think gerrit may document this stuff somewhere too, let me see if I can find it in the gerrit documentation05:10
clarkbmaybe they don't document it in tree05:11
lifelessclarkb: but, this stuff isn't done by manage_projects.05:17
lifelessclarkb: so, it's not redundant05:18
clarkbacl updates are done by manage_projects05:19
lifelessclarkb: for all *other* acls, AIUI.05:19
lifelessclarkb: but not these.05:19
clarkblifeless: which ones?05:20
lifelessclarkb: http://ci.openstack.org/gerrit.html#access-controls05:20
lifelessclarkb: those are the ones I'm asking about05:20
lifelessclarkb: I asked 'how do I give the 'project bootstrappers' group the right permissions05:20
clarkbAll-Projects? we don't currently use manage_projects to manage All-Projects but it can05:20
clarkboh so this is a bootstrapping issue05:21
lifelessclarkb: and 'how do the acls in gerrit.rst get into the system'05:21
lifelessclarkb: and I was told the answer to both questions was the same : do $something_undocumented to gerrit to make it happen.05:21
lifelessclarkb: I'm just trying to get that $documented thing documented.05:21
lifelessclarkb: you seem to be saying that this *deleted* documentation is such documentation, but that you don't want it documented.05:22
lifeless*confused*05:22
clarkbya, I am now currently trying to sort out if there is a sane way to have manage_projects do that for us05:22
clarkblifeless: because gerrit itself should document this05:22
clarkblifeless: and I thought it did, but after some digging I think that I was wrong05:22
lifelessclarkb: it should, but I couldn't find it :(05:22
clarkbya I can't find it either. So some subset of the documentation that was removed that explains how to bootstrap All-Projects for project bootstrappers should probably be added back into gerrit.rst05:23
clarkbor do that bit by hand in the Gerrit UI05:23
lifelessclarkb: I don't know the acl syntax well enough to update the gerrit UI to match05:24
lifelessclarkb: I have an unknown text format on my left, and a similar-but-different web UI on my right.05:24
clarkbI expected https://review.openstack.org/Documentation/project-setup.html or https://review.openstack.org/Documentation/access-control.html to describe how to push into refs/meta/config05:24
clarkbbut neither page does05:25
lifelessclarkb: folk with practice will know, but not newcomers. I'd like to make it just do X, where X is detailed and has no if's, but's or else's in it.05:25
clarkbagreed, I think the steps that explain how to do that in the old docs need to be put back into the existing docs05:25
lifelessok. I shall reinstate them then :)05:26
clarkblifeless: give me a minute I will paste something05:26
lifelessthank you!05:28
lifelesssee, I'm a fumbling newby, which is why I only make progress when nagging one of you lot :)05:28
lifelessI very much doubt I will have jenkins and zuul live and running tests tomorrow :(05:28
lifelessbut, who knows, maybe I will!05:28
*** vipul is now known as vipul-away05:29
*** Adri2000 has joined #openstack-infra05:31
*** Adri2000 has joined #openstack-infra05:31
*** nicedice_ has quit IRC05:31
*** vogxn has joined #openstack-infra05:34
clarkblifeless: http://paste.openstack.org/show/45718/ something like that05:35
lifelessclarkb: will you be up for much longer? must be nearly 11?05:35
clarkbnot much longer05:35
*** openstack has joined #openstack-infra14:53
*** openstackstatus has joined #openstack-infra14:54
fungiand they're back14:54
dizquierdohi clarkb, if you're around we can discuss a bit about https://review.openstack.org/#/c/44057/14:54
anteayayay14:54
anteayathanks14:54
dizquierdofrom our side we're ready :)14:55
anteayamakes reading the backscroll shorter14:55
*** openstackgerrit has joined #openstack-infra14:55
fungistatusbot had stopped completely, meetbot was simply indefinitely disconnected14:55
jeblairdizquierdo: ok, we can approve it now14:55
fungiand there's gerritbot... the gang's all here14:55
*** lcanas has joined #openstack-infra14:55
dizquierdogreat thanks jeblair :)14:55
anteayasorry in advance if I bring up a topic that was discussed in the ensuing 9.5 hour outage14:55
Alex_Gaynormordred: Thinking outloud, one thing I think would go a long way to reducing the frustration people are feeling would be increased visibility to what's going on with the neutron failures. What do we know, how are we looking to fix it, are there reviews I should follow, etc.14:55
jeblairdizquierdo: we just wanted to make sure that you were ready to switch over to using gerrit (so we wouldn't have to try to move more commits over)14:55
dizquierdowe've got a couple of questions (lcanas and me)14:55
dizquierdoregarding the process... we have a bot uploading new datasets, so data keep daily updated14:56
dizquierdobut... not sure how we should proceed now14:56
*** wenlock has joined #openstack-infra14:56
jeblairdizquierdo: you can still have a bot upload new patches (we do that with translations), but you'll need to manually approve them14:56
dizquierdoor, leave datasets in other place, and source code in the gerrit process (perhaps better idea)14:56
dizquierdook, then we can leave datasets automatically updated by the bot and later check if this is scalable :)14:57
mordredAlex_Gaynor: that's a good idea. I'm not sure where the start of that is...14:58
dizquierdolet's go then14:58
jeblairAlex_Gaynor: we could start by talking to markmcclain14:58
mordredmarkmcclain: ^^ who would be a good person on neutron side to ask about?14:58
mordredjeblair: you beat me to it14:58
Alex_Gaynormordred: A single over-arching task to follow on launchpad, instead of a revolving door of random symptoms would be one place14:59
anteayas/ensuing/previous14:59
ttxfungi/jeblair: Looks like there is some shortage in gate-*-python26-able nodes15:00
markmcclainAlex_Gaynor: I've been working to more folks to help fix the random failures15:00
markmcclain*to recruit15:00
sdaguettx: I think it will resolve itself15:00
ttxsdague: ok thx :)15:00
jeblairdizquierdo: i approved the change; it'll probably be a while before it merges because the test system is recovering from a network incident earlier15:00
*** mgagne has joined #openstack-infra15:01
ttxbetter safe than sorry on this day15:01
dizquierdothanks jeblair, let me know any issue you may find :)15:01
sdaguettx: there was the big restart, and py26 jobs are slow15:01
sdaguebut in reality I think they'll catch up past the tempest jobs in another 30 minutes15:01
fungiagreed, we're only starting to see it recently because the tempest jobs are now so much faster the py26 unit tests for some projects are rivalling them for duration now15:02
sdaguecinder py26 jobs are only 5 mins, for instance15:02
Alex_Gaynormarkmcclain: It'd be great to have one over-arching place to track that and get status updates15:02
ttxjeblair: you should tweak the zuul status graphs so that they don't show a drop to 0 on the current hour :)15:02
sdagueheh15:03
markmcclainAlex_Gaynor: I'll work on consolidating the info15:03
fungithat would probably require predictive modelling, or a lag for the sample duration15:03
Alex_Gaynormarkmcclain: a single launchpad issue to track all the downstream manifestations owuld be good I think15:03
jeblairttx: yeah, i'm not sure i found the right graphite function for that yet -- i found one that does a rolling history, but that would make the graph continuously change shape15:03
fungijeblair: spline fitting ;)15:04
jeblairttx: i think what we want is one that scales the most recent value by how complete the hour is15:04
ttxjeblair: and uses a dotted line to show that "prediction"15:04
ttxa bit tricky :)15:05
boris-42fungi hi15:05
fungiboris-42: howdy15:06
boris-42fungi how are you?15:06
sdagueoh man neutron unit tests are longer than tempest tests huh.15:06
sdagueat least on 2615:07
fungiboris-42: caffeinated15:07
boris-42fungi and red eyes?)15:07
fungiboris-42: always, though i think i inherited them15:07
jeblairsdague: congrats! :)15:07
boris-42fungi could I ask about adding new project to stackforge https://review.openstack.org/#/c/44952/ ?)15:07
fungisdague: new target ;)15:07
sdague:)15:07
boris-42fungi it is terrible to work on project without Opnestack CI=)15:08
*** vogxn has quit IRC15:08
fungiboris-42: i agree!15:08
sdagueyeh, I only knew the nova timings off the top of my head, which come in at 20 mins15:08
*** senk has joined #openstack-infra15:08
fungiboris-42: taking a look at the proposal real quick15:08
*** datsun180b_ has joined #openstack-infra15:08
sdagueso actually, given that, we probably could use some more 26 nodes if that's an option15:09
*** datsun180b has quit IRC15:09
*** datsun180b_ is now known as datsun180b15:09
jeblairboris-42: we're happy to have more projects in general.  i will review the proposal during my regular reviews (we are usually pretty good about reviewing all changes to /config)15:10
boris-42jeblair thank you15:10
fungias for network outage correlation, gerritbot (on gerrit) and meetbot (on eavesdrop) both fell off irc at 05:4015:10
boris-42fungi thank you also=)15:10
fungiwhich is around the time of the gaps in cacti graphs as well15:10
jeblairboris-42: you should expect that a core member will have reviewed it within 24-48 hours -- we are very busy so be patient.  :)15:10
fungiand of the various "hung" stale jobs15:11
boris-42jeblair I will be really happy to get reviews is so short itme=)15:11
boris-42if I get*15:11
*** senk1 has joined #openstack-infra15:11
*** hashar has joined #openstack-infra15:11
openstackgerritA change was merged to openstack-infra/config: Addition of the activity-board project to the OpenStack-infra environment  https://review.openstack.org/4405715:12
jeblairsdague: let's keep an eye on it; we bumped the slave counts last week and the current values seemed to be about right (we went from 32->40 precise and 12->14 centos)15:12
sdaguejeblair: ok15:12
*** xchu has joined #openstack-infra15:12
fungiaha! https://status.rackspace.com/ indicates a network maintenance in "DFW Datacenter- September 4th from 12:01 AM to 6:00 AM CDT"15:12
sdaguejeblair: the big issue is neutron actually takes longer on 26 then tempest15:12
fungithat would be... pretty much all our long-lived systems15:12
*** senk has quit IRC15:13
sdagueso a lot of neutron jobs in the queue means that we actually back up on 2615:13
*** reed has joined #openstack-infra15:13
sdagueactually, python 26 neutron is the longest job we have in the queue at all (takes ~ 30 minutes)15:13
jeblairsdague: ok, makes sense.  let's validate that holds up the head of the queue (and not just deep changes) and we can bump it some more.15:15
sdagueyep, sure15:15
*** pcrews has joined #openstack-infra15:17
Alex_Gaynorsdague: clearly we should drop python 2.6 :snrk:15:19
jeblairi have to run an errand; bbiab15:19
fungik15:19
Alex_GaynorSo it looks like a bunch of post- jobs fail, does anyone trac those?15:20
Alex_Gaynortrack*15:20
fungiAlex_Gaynor: not with any organized regularity15:20
fungii think it varies by project15:20
Alex_Gaynorfungi: I wonder if failing post- tests shoudl leave a comment on the review that spawned it, just so people see it15:21
fungiwe talked about that... i'm also not sure people look at reviews any longer once they're merged. they fall off the radar for the most part15:21
Alex_Gaynoryeah, but they'll get an email15:21
sdaguemordred: any idea why the neutron tox.ini definition doesn't actually print out the slowest tests?15:21
Alex_Gaynoror at least if they're like me they'll get an email15:21
mordredsdague: nope. not intentional to best of my knowledge15:22
fungiyeah, i get so many gerrit e-mails any more i have a hard time paying attention to them15:22
Alex_Gaynorfungi: Ah intersting, I use my inbox for tracking "TODO" things15:22
*** kmartin has quit IRC15:22
*** datsun180b has quit IRC15:23
sdaguemordred: it looks like it should15:23
fungii should probably tune my gerrit watches and set up some more fine-grained filtering on my mta for different kinds of messages from gerrit15:23
*** datsun180b has joined #openstack-infra15:23
mordredfungi: enough people seem to use email like Alex_Gaynor does, that perhaps leaving post comments on merged changes would get failed post jobs _some_ attention15:23
sdaguemordred: oh, does it only work when testr passes?15:24
*** kiall has quit IRC15:24
mordredsdague: yes. I believe this is the case15:24
fungimordred: Alex_Gaynor: jeblair said something about getting a better post job result reporting system integrated with zuul soon, so i'm hoping that will be a little better than gerrit comment e-mails anyway15:24
Alex_Gaynorah, cool15:24
jeblairfungi: that was for bitrot15:25
fungioh, for periodics, not posts15:25
fungihrm :/15:25
sdagueok, that's fair15:25
*** dkehn has quit IRC15:25
sdagueI guess it's just that neutron has 15k unit tests15:25
sdaguethe slowest is only 7s15:25
*** gyee has joined #openstack-infra15:25
*** UtahDave has joined #openstack-infra15:26
dstufftAlex_Gaynor: inbox is my TODO list, worst one besides all the other ones :]15:26
jeblairthe post jobs don't know what change they are "for", which makes having them report back difficult15:26
*** Bada has quit IRC15:26
jeblairi have a 90% completed patch to gerrit to add the info we would need to change-merged events to use them instead of ref-updated15:26
jeblairbut i'm not sure we _want_ to use them instead of ref-updated15:27
fungiand having zuul directly e-mail the author or committer e-mail is likely not a great solution either i guess15:27
mordredjeblair: nod. good point15:27
*** nati_ueno has quit IRC15:27
mordredjeblair: and I agree re ref-updated15:27
*** nati_ueno has joined #openstack-infra15:28
*** vogxn has joined #openstack-infra15:28
fungiwe would still need ref-updated to catch tags and new branch creation presumably15:29
fungior is that ref-created15:29
*** vogxn has quit IRC15:29
*** pentameter has joined #openstack-infra15:30
fungiyeah, no ref-created event15:30
fungiso i think ref-updated is the only thing that catches tags and new branches15:31
*** ruhe has joined #openstack-infra15:31
ryanpetrelloso I know that OpenStack aims to support Py3.315:32
*** nati_ueno has quit IRC15:32
ryanpetrellobut for stackforge projects that would like to support 3215:32
ryanpetrelloare there any options?15:33
ryanpetrelloI know we've gotten e.g., pypy working for some projects15:33
fungiryanpetrello: not really, no. we have to keep a bank of dedicated slaves per python version, so offering slaves specifically to support stackforge projects isn't really in the project's best interests resource-wise15:33
*** dkehn has joined #openstack-infra15:34
fungiright now the combination of needing some system-wide dependencies installed via pip and our use of puppet to manage those slaves and the fact that puppet doesn't deal with the concept of multiple pip versions to support parallel installation of multiple python versions...15:34
ryanpetrelloright15:35
ryanpetrellomakes sense15:35
sdagueman neutron unit tests are extra racey today, huh?15:35
fungiin general, puppet in fact doesn't deal with the idea that you may want to install multiple packages of the same name via different mechanisms on one system15:35
markmcclainsdague: yeah… been looking into that15:37
fungiso using pip-2.7 and pip-3.2 to install tox for both python2.7 and python3.2 interpreters on one machine, for example, can't be orchestrated with puppet currently15:37
*** mestery_ has joined #openstack-infra15:37
Alex_Gaynorfungi: hmm, this doesn't sound right, you don't need to have a tox installed per vm, for example I just reused the existing py3 builders for PyPy15:38
fungiAlex_Gaynor: well, tox is probably a bad example15:38
dhellmannhow do we get pip installed for python3.3 and pypy? (those are on the same nodes, right?)15:39
Alex_Gaynordhellmann: we don't have a special pip for pypy, stuff is just installed in the tox venv15:40
Alex_Gaynordhellmann: why would we need a per-pypy pip?15:40
fungiAlex_Gaynor: but in general, we'd need a long-term-stable distribution supporting the system-wide dependencies of sufficient versions for the right python interpreters15:40
mordredso - the tox/python problem actually should go away with latest tox once we put in config file snippets15:40
*** mestery has quit IRC15:40
*** dkehn has quit IRC15:40
mordredthe problem before was the tox used system python, not venv python, to run the sdist/install15:40
mordredwhich meant that setup_requires got angry15:40
mordrednew tox has an option to run setup.py develop in the context of the venv15:41
dhellmannAlex_Gaynor: good point. So, fungi, why do we care about having multiple interpreters installed side-by-side?15:41
mordredwhich means that just using tox will get us much further than previously was possible15:41
*** dkehn has joined #openstack-infra15:41
fungidhellmann: we'd like to install multiple interpreters so we need fewer different systems to manage15:41
* dhellmann is confused15:42
fungidhellmann: but currently the problem is that there are no lts distros with python 3 as their system default python15:42
mordreddhellmann: right now, because multiple interpreters on the same box actually break things in our system15:42
dhellmannah15:42
mordreddhellmann: we have to maintain a different set of slaves for each interp we want15:42
dhellmannso we can't just install 3.2 on a 3.3 node15:42
mordredthat's obviously poop15:42
mordredright15:42
dhellmannk15:42
mordredalthough - I _think_ we can now15:42
mordredwe just haven't tested it yet15:42
mordredbecause,you know, feature freeze15:43
* dhellmann is impatient to get DreamCompute running well enough to offer nodes15:43
*** mestery_ is now known as mestery15:43
fungidhellmann: well, we could install 3.2 on a 3.3 node but we couldn't use puppet to tell pip to install versions of system-wide dependencies for both 3.2 and 3.315:43
mordredfungi: which pip installed system-wide depends do we need on unittest slaves?15:43
dhellmannfungi: what mordred said15:43
mordredfungi: tox is the only one in that context, right?15:43
fungimordred: fewer and fewer... having a look now15:43
*** vipul is now known as vipul-away15:44
fungisetuptools-git currently as well15:44
*** kiall has joined #openstack-infra15:44
fungioh, and python-subunit, git-review...15:45
sdaguehmmm... why did the pending python26 nova jobs get cancelled when something further up the stack in the gate failed? Those shouldn't be linked.15:46
mordredfungi: we do not need setuptools-git15:46
fungivirtualenv too15:46
mordredfungi: we do not need per-interp virtualenv, and we should not need per-interp subunit15:47
fungiokay, so as long as we can install them somewhere the python interpreters we're running can find them15:48
mordredfungi: but that's a great list of things we should go clean up15:48
mordredfungi: for any project that produces subunit output, subunit should be installed into the venv - so we should be able to access it by running things in the context of .tox/py$venv/bin/python15:48
fungiany of that stuff which we can (or nowtimes already do) run from inside a virtualenv instead, ought to get cleaned up15:49
mordredfungi: a global virtualenv is fine for tox to use with all of the pyhton versions15:49
mordredyup15:49
mordredbut first, we need to test that new version of tox works like we expect15:49
*** vipul-away is now known as vipul15:50
fungiand also maybe test some assumptions about whether everyone has upgraded to our current ways of packaging and running tests15:50
openstackgerritA change was merged to openstack-infra/gitdm: Assign Andreas Jaeger to SUSE  https://review.openstack.org/4327315:50
mordredah!15:50
mordredhttps://review.openstack.org/#/c/42178/15:50
mordredfungi: ^^15:50
mordredthat merged15:50
*** yaguang has quit IRC15:50
mordredwhic hmeans it's tested :)15:50
fungianother miracle!15:51
mordredthe above patch should be ported to all of the openstack projects15:51
*** changbl has joined #openstack-infra15:51
mordredoh - actually - heads up everyone15:51
mordredthat patch landed at midnight15:51
fungigood news everyone?15:51
mordredit requires tox 1.6 - which is fine for us15:52
mordredbut it's possible that we might get questions from nova devs15:52
mordredabout why local tox runs stopped working15:52
mordredtox reports that they need to upgrade tox15:52
mordredbut, you know, it's possible they won't read and will ask us15:52
* mordred sends out an email to the list to tell people to upgrade15:53
*** lcanas has quit IRC15:53
*** dhellmann is now known as dhellmann_15:55
fungithanks for the heads up15:55
anteayasdague: are the pending python26 nova jobs you are looking at in the gate queue?15:57
anteayathe ones that got cancelled?15:57
sdagueanteaya: mostly, I think the fact that we've got a bunch of devstack jobs in there queue is mitgating it15:57
sdagueyes15:57
anteayaokay15:58
sdagueI forgot that we reset everything15:58
sdagueeven the non linked jobs15:58
anteayahow zuul deals with jobs running after the failed job is different now15:58
*** vogxn has joined #openstack-infra15:58
anteayaas soon as a patch in the gate has a voting failure all jobs after it cease15:58
sdaguethat might be something to think about as future optimization, especially with unit tests now being on order same length as integration tests15:58
*** vogxn has quit IRC15:58
anteayathe tests that were running used to keep running and they don't now15:59
sdagueok15:59
fungiif nothing else, this has provided a nice burst of job volume to help prove out the most recent round of performance optimizations16:00
anteayaonce jeblair has the chance to document all the details, I recommend it16:00
*** dina_belova has quit IRC16:00
anteayayes it frees up the nodes to run jobs that have a point to finishing16:00
*** tstevenson has joined #openstack-infra16:00
*** vogxn has joined #openstack-infra16:00
fungispiked up to around 700 jobs last hour16:01
*** datsun180b_ has joined #openstack-infra16:01
*** vogxn has quit IRC16:01
*** svarnau has joined #openstack-infra16:01
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add cookiecutter templates repo  https://review.openstack.org/4253016:01
anteayasdague: I don't know if that particular change is covered in this blog post or not: http://amo-probos.org/post/15 it is still on my todo list16:02
mordredmrodden: have you seen https://review.openstack.org/#/c/42530 ?16:02
*** xchu has quit IRC16:02
mordredmrodden: I'm reviewing the run-mirror patch, and I realized I should maybe point you at the cookiecutter stuff in case you wanted to start from a fresh repo16:02
fungianteaya: the blog post is a little higher-level and doesn't go into queue management minutiae quite so much16:03
mordredbut now as I type that, I believe the plan was to use the jeepyb repo as a seed - so nevermind16:03
anteayafungi: ah okay16:03
*** datsun180b has quit IRC16:03
*** datsun180b_ is now known as datsun180b16:03
anteayaso yes, once jeblair can catch his breath, I recommend hearing the details - nodepool, zuul and friends had a fair makeover in the last 2 weeks16:04
anteayaoh and we have 2 check queues/pipelines, which I believe work independently of each other16:04
mroddenmordred: i had not seen it...16:05
anteayaand zuul is more likely to kick out a patch that it can't merge, not because tests failed but because it needs to spend resources on merging patches with a higher probability of getting in16:05
mroddenmordred: we are mostly copying what jeepyb has though, and tailoring it to the new pypi-mirror project16:05
mordredmrodden: yeah. I actually read the change this time :P)16:05
anteayayou will see the rare comment, identifying this with the advice to rebase and try again16:05
mordredjog0: speaking of the above - I think you were out of town when I discovered https://review.openstack.org/4253016:06
openstackgerritA change was merged to openstack-infra/config: Create new pypi-mirror project for run_mirror.py  https://review.openstack.org/3939916:06
*** SergeyLukjanov has quit IRC16:08
*** tstevenson has quit IRC16:08
fungianteaya: yeah, the refusal to test changes which won't merge on top of those ahead of it went in a while back16:09
*** nati_ueno has joined #openstack-infra16:09
*** jpmelos has left #openstack-infra16:09
anteayafungi: ah okay, not new then, new for me16:09
fungii was only really not around for stuff which changed last week16:09
anteayafungi: cool16:09
mordredoh! did my experimental thing land? neat16:10
anteayaforgive me if I have a hard time keeping track and duplicate information16:10
anteayathe last two weeks have been a bit of a blur16:10
fungianteaya: no worries. i think i'm basically caught up on the fundamental changes at this point16:10
anteayayay16:10
anteayaso glad you are back, fungi16:11
anteaya:D16:11
*** vogxn has joined #openstack-infra16:11
fungime too!16:11
*** odyssey4me has quit IRC16:12
anteayayeah, less chance of being allergic to something at home, eh?16:12
mordredfungi: I added a thing that merged while I was on playa that you might find interesting ... https://review.openstack.org/#/c/41954/ (I just noticed because jog0 was using it)16:13
anteayaoh yes the experimental queue has been getting some exercise16:14
*** boris-42 has quit IRC16:14
anteayanot recently, going by its sparkline but last week it did16:15
fungimordred: oh, right. i remember the discussion around that. awesome16:15
*** openstackgerrit has quit IRC16:16
*** openstackgerrit has joined #openstack-infra16:17
*** amotoki has quit IRC16:17
mordredI love the sparklines16:18
ttximpressive list of potential merges in the gate right now for the next 10 min16:18
ttxgone now16:18
openstackgerritIlya Shakhat proposed a change to openstack-infra/config: Add projects of Fuel family to Stackforge  https://review.openstack.org/4504416:19
* ttx pauses16:19
anteayattx do you know how many went in?16:19
*** ruhe has quit IRC16:21
sdaguettx: what caused the reset? I seem to have missed that16:21
ttxsdague: there were like a neat line of 20+ almost merged and then poof16:27
*** svarnau_ has joined #openstack-infra16:27
ttxprobably their success is being queued up to the post pipe16:27
ttxwill be back in 2/3 hours16:28
*** fbo is now known as fbo_away16:28
*** jpich has quit IRC16:29
*** svarnau has quit IRC16:29
*** kiall has quit IRC16:30
*** atiwari has joined #openstack-infra16:33
*** senk1 has quit IRC16:33
zaromorning16:34
clarkbmorning16:35
*** mrmartin has joined #openstack-infra16:35
clarkbmordred: yes experimental pipeline merged. I think it is a big success16:36
clarkbmordred: dkranz is using it to develop heat tempest tests too16:36
*** sridevi has joined #openstack-infra16:36
mordredneat16:36
derekhhi all, would anybody have a chance to look at https://bugs.launchpad.net/openstack-ci/+bug/1217815 please16:37
uvirtbotLaunchpad bug 1217815 in openstack-ci "Tripleo ci service account in gerrit" [Undecided,New]16:37
fungisdague: which reset? the zuul restart i did this morning or a more recent change getting kicked out unleashing the stack behind it for retesting?16:38
clarkbelasticsearch went sideways again16:38
*** dkehn has quit IRC16:38
fungiclarkb: we probably blew its mind with the surge this morning... or did it suffer from the network maintenance?16:39
clarkbfungi: looks like networking issues around 054216:39
clarkber 053816:39
*** nicedice_ has joined #openstack-infra16:39
fungiclarkb: that would be the same outage which killed everything else then16:40
clarkb[elasticsearch] master_left [[elasticsearch5][YcfPnvKYRaOYjCh8zMJQig][inet[/166.78.24.7:9300]]], reason [failed to ping, tried [3] times, each with  maximum [30s] timeout]16:40
clarkbfungi: ok, catching up I take it there was an unplanned network flap?16:40
zaroclarkb, mordred : bad news :(   https://gerrit-review.googlesource.com/#/c/48254/16:40
fungiplanned maintenance rs was doing. i think dfw was down hard for close to 30 minutes16:40
clarkbI am going to restart elasticsearch services so that they rediscover each other16:40
*** kiall has joined #openstack-infra16:41
*** kiall has quit IRC16:41
*** kiall has joined #openstack-infra16:41
*** senk has joined #openstack-infra16:41
mordredzaro: uhm. I confused by his confusion16:42
zaroclarkb, mordred : mfich feels that change owner needs to work with all permissions, not just label.16:42
clarkbnow which side of the split brain do I want to kick16:42
* clarkb picks on semi arbitrarily16:42
mordredzaro: ah. gotcha. so, more work to do then I guess?16:43
zaromordred: i asked him about it, here's the entire discussion if you are interested: http://paste.openstack.org/show/45751/16:43
mordredzaro: will that be hard? or just more work16:43
*** senk1 has joined #openstack-infra16:43
mordredcool16:43
zaromordred: it's more work that i don't know how to do yet.  I mean i don't know how change owner should applies to all of the other permissions.  i would just be taking a guess.16:44
*** senk1 has quit IRC16:44
mordredoy16:45
*** senk has quit IRC16:45
*** jhesketh has quit IRC16:45
zaromordred: mfich suggested that i request suggestions (doing RFC on commit message) to get feedback on how that group should work with all the other permissions.16:46
zaromordred: or do implement it the best i can (don't like this suggestion).16:47
mordredzaro: I thnk that's a good idea. also, jeblair and clarkb may have thoughts - but since that's not a usecase for us, we might not have great suggestions16:47
pleia2anteaya: oh! almost forgot, did you get your ubuntu question answered re: installing packages?16:47
mordredperhaps also send a message to the repo-discuss mailing list asking for opinions?16:47
anteayapleia2: not yet, I went with precise and nothing blew up16:48
clarkbelasticsearch cluster health is now "yellow"... now we wait for it to recover shards and indices16:48
anteayanow I can't get it to work, but that may be for other reasons16:48
zaromordred: yeah, i can do all of that but it would seem like it will probably much more work and take longer to get into core.16:48
zaromordred: what about doing as a plugin?16:48
pleia2anteaya: re: ubuntu and xubuntu, they pull from the exact same repository so almost everything worse, it's desktop-specific stuff that won't (xfce panel stuff won't work in Unity, for example)16:49
pleia2s/worse/work16:49
* pleia2 needs to apply more coffee16:50
mordredzaro: I'm not sure.16:50
*** dkehn has joined #openstack-infra16:50
zaroclarkb, jeblair: your thoughts on implimenting gerrit WIP as a plugin?16:51
*** kiall has quit IRC16:52
*** derekh has quit IRC16:53
anteayapleia2: yeah that is what I figured, it appeared to install okay, I will continue to figure out what else I am doing wrong16:53
anteayahappy coffee16:53
*** svarnau has joined #openstack-infra16:53
pleia2anteaya: anything I can help with?16:53
*** ruhe has joined #openstack-infra16:54
zaroanteaya: happy wifi?16:54
anteayazaro: yes, thank you - I slept so much better last night16:54
*** nati_ueno has quit IRC16:55
*** kiall has joined #openstack-infra16:55
anteayapleia2: probably, let me finish off this task and get refocused and I'll find you after coffee16:55
pleia2hah, ok :)16:55
*** nati_ueno has joined #openstack-infra16:55
*** svarnau_ has quit IRC16:56
fungizaro: writing it as a plugin still leaves us with code to maintain indefinitely. getting the feature integrated upstream in some form usable by us leaves us debt-free in that regard16:56
*** jaypipes has quit IRC16:57
*** nati_ueno has quit IRC16:57
clarkbsdague: I think testr is still counting each test twice. so neutron has ~7.5k tests16:57
*** nati_ueno has joined #openstack-infra16:57
clarkbfungi: after skimming scrollback I see you had a very fun and exciting morning :) thank you for taking care of that16:58
*** vogxn has quit IRC16:58
fungiclarkb: it wasn't that bad, really16:58
clarkbI feel bad because I was going to bed just as things were breaking, but I probably wouldn't have been much use then if I had been paying attention to zuul16:58
*** nati_ueno has quit IRC16:58
*** hashar has quit IRC16:58
*** nati_ueno has joined #openstack-infra16:59
fungii mean, it set back the patches trying to get through for the milestone, but it wasn't really that hard to get things working again16:59
*** olaph has quit IRC16:59
fungiand hopefully it wasn't too severe a setback overall17:00
*** ruhe has quit IRC17:00
*** olaph has joined #openstack-infra17:00
fungialso, i really like that 700jph spike on the graph which resulted (and didn't destroy anything as far as i can tell, so awesome new high water mark?)17:01
clarkbif it isn't a record jph it is near it17:01
clarkbsdague: yes the neutron unit tests need some love. yesterday I got tired of jenkins emailing me about sudo attempts so I dug into their tests and found that `sudo ovs-vsctl` isn't deterministically mocked out depening on test order17:02
clarkbsdague: so be warned if you run the tests with a sudo enabled user :)17:02
zarofungi: yes, fungi i understand.  trade off is that we could get feature we want in faster without having to meet the strict gerrit requirements to imposed by gerrit core.17:02
*** Ryan_Lane has joined #openstack-infra17:03
clarkbzaro: did mfick not offer what the behavior should be for the other permission types?17:03
zarofungi: without doing anymore work as well.17:03
*** Ryan_Lane has quit IRC17:03
*** nati_ueno has quit IRC17:03
zaroclarkb: i asked but he did not.17:03
fungizaro: yep, it is definitely a workload balance question17:04
zaroclarkb: his suggestion was 'do your best'17:04
clarkb:/17:04
zaroyep, double that17:04
zarohe did say that i should wait for other people to provide feedback, but since he's already voted -1 i don't know if anyone else will bother.17:06
openstackgerritA change was merged to openstack-infra/config: Add doc build process into Stackalytics  https://review.openstack.org/4488717:06
anteayapleia2: the task I am working on is standing up owncloud, but if you are available I think we should work on puppet-dashboard first, what do you think?17:06
clarkbsdague: https://review.openstack.org/#/c/43558/ the comments at the end of that review may be useful17:06
pleia2anteaya: ah, I've never done anything with owncloud17:07
anteayayeah, me either17:07
openstackgerritA change was merged to openstack-infra/config: Also install pypy-dev on pypy nodes  https://review.openstack.org/4469017:07
anteayaI think puppet-dashboard is a higher priority right now, what do you think?17:07
pleia2anteaya: I'm kind of on a roll with baremetal stuff, give me an hour or so and then we have a look at puppet-dashboard?17:07
anteayasure17:07
pleia2great17:08
anteayaroll away17:08
pleia2:)17:08
anteaya:D17:08
*** ruhe has joined #openstack-infra17:08
*** boris-42 has joined #openstack-infra17:08
*** senk has joined #openstack-infra17:10
*** mrmartin has quit IRC17:16
*** jaypipes has joined #openstack-infra17:16
clarkbnew review.o.o and wiki mysql dumps look good17:16
clarkbif they rotate properly tonight I will start work on making bup go17:16
*** nati_ueno has joined #openstack-infra17:17
clarkbmordred: fungi: bringing up multiple pythons on a slave again17:19
fungiya17:19
clarkbmordred: fungi: doesn't new tox make the system python's sdist of the thing being tested less painful (or a non issue)? assuming we can remove other global dependencies it should be safe for projects to use python3.2 on precise for example?17:19
clarkbthe one exception to this is nova because libvirt (but they have a fake for libvirt if it isn't available globally so not a major problem)17:20
clarkbfungi: also have you seen https://review.openstack.org/#/c/44378/ ? I can't figure out why Gerrit SSH is so derpy and fails like that17:20
clarkbfungi: happens with our gerrit and gerrit 2.6.X17:21
*** dizquierdo has quit IRC17:22
*** kiall has quit IRC17:23
*** w__ has joined #openstack-infra17:26
*** olaph has quit IRC17:28
fungiclarkb: i think once the tox/virtualenv installs are confirmed to work fine when spawned using a different python interpreter version than is used within the virtualenv, it's probably safe start running tests from multiple pythons side-by-side where we can17:28
fungithough there are also python installability concerns, for example getting python3.2 and python3.3 to install side-by-side on precise may take more packaging work since right now they step on each others package names and paths in some places17:30
clarkbfungi: interesting, so they aren't currently safe to install side by side as on Debian?17:30
funginope17:30
*** kiall_ has joined #openstack-infra17:31
*** kiall_ has quit IRC17:31
*** kiall_ has joined #openstack-infra17:31
funginow, how much packaging work it'll take to get them more debian-like is certainly worth exploring. might not be much17:31
dstufftpackaging is the worst17:32
fungibut also debian's already moved out of the window where i can source 2.6, 2.7, 3.2 and 3.3 from the same reasonably-integrated suites17:32
zaromordred: https://git.openstack.org/cgit/openstack-infra/publications/17:32
fungii have one system basically held in that state now for my own short-term sanity but don't expect to keep it like that too long17:33
zaromordred: ^ how do i get the pubs?17:33
fungiin short, debian/jessie will release with 2.7 and either 3.3 or 3.417:33
clarkbfungi: what about (and tell me if this is just over engineered) we run lxcs on each of our slaves for the different python versions17:33
clarkbfungi: I think that leaves us with needing some way of locking a slave when one lxc is in use17:34
fungithen we have (in effect) mutiple slaves17:34
zaromordred: make-index doesn't work, there are no tags.17:34
clarkbzaro: I have fixed that bug, I think the change merged yesterday17:34
fungiand each lxc container needs to be kept up to date independently as a separate system anyway17:34
* zaro trys again17:34
clarkbzaro: but even then make-index isn't sufficient. Instead you need to look in the non master branches17:34
clarkbzaro: overview for example contains the overview talk, you can just open it in firefox (chrom* doesn't do the zuul animation properly)17:35
fungiclarkb: unless we build lxc containers on the fly like we do with virtualenvs, but then that leaves us maintaining the systems which build multiple different lxc containers if nothing else17:35
clarkbfungi: that is less of an issue with docker and unionfs17:35
clarkbwe could respin the images once a day or so then boot containers on the fly17:36
fungiand at that point, why not just build distinct system images for on-demand consumption as nodepool slaves at that point17:36
clarkbfeels very overengineered for the requirement of "support multiple pythons"17:36
clarkbfungi: biggest reason is xen and kvm booting from glance images is slow17:37
clarkbfungi: if you already have locally cached container filesystems booting should take almost no time17:37
fungiwhat about mordred's dib/takeovernode/kexec work then? will that be close?17:37
clarkbfungi: yeah, similar solutions to different problems17:38
clarkbbut maybe they can be treated as the same problem? kexec a different root fs based on python need?17:38
fungiwell, but if those become the de-facto solution underlying nodepool resources, and we move away from long-running slaves...17:39
*** dkehn has quit IRC17:40
*** dkehn has joined #openstack-infra17:40
zaroclarkb: is there only 1 pub, or are there more?17:40
fungialso, maybe we have a collating job which takes the various dib-created filesystems and makes them different gpt parts on the same block device, then uses that for all unconsumed slaves, we have a local cache of all possible slave versions available to takeovernode17:40
zaroclarkb: i was expecting more.17:41
clarkbzaro: currently I believe there is just overview. pleia2 wants to add her talk. I am going to write up a doc on how to do that when I have a free chunk of time17:41
pleia2clarkb: if you rewind a bit in history we have about 10 or so17:41
fungizaro: if you checkout a ref in master from before everything was deleted (check git log) you can get the old presos17:41
fungizaro: but it made more sense to clean those up before separating them into new branches, so i only initially did overview17:42
fungimostly to act as an example for further reorg work17:43
pleia2once we have instructions, we can go about adding the rest back :)17:43
clarkbpleia2: I am thinking general process will be 1. create new branch for thing (or have someone do it for you if permissions are a problem) 2. push change to update default branch in .gitreview for that branch 3. push commit(s) with new thing in them17:43
fungiwe wanted to polish the overview file layout a bit to decide what the others should end up looking like once split out and cleaned up17:43
pleia2clarkb: yeah, the "create a new branch" thing is where I get stuck, I don't really understand yet how we do that for projects in this infrastructure17:43
clarkbpleia2: typically it requires a person with extra gerrit permissions to click a button in gerrit17:44
zaroohh. i see, it looks like it's just adding slides onto the same deck.17:44
pleia2clarkb: oh good, then I wasn't missing something obvious :)17:44
fungipleia2: but really, decide what branch name you need for a distinct presentation (which isn't just an evolution of an existing presentation which already has a dedicated branch) and i'll be happy to click the button17:45
clarkbpleia2: ya, mordred jeblair and I can do it too17:45
pleia2great17:46
clarkbI do intend on writing a proper howto doc in the master branch or something in the README though17:46
fungiclarkb: also if you can include a basic specification for the minimum requirements and filenames a presentation needs, that would help a ton (also would make for a good technical review checklist, or possible blueprint for future validation tests)17:47
clarkbfungi: ++ things like a README.rst for make-index and so on?17:47
fungidefinitely. that would be great17:47
*** jaypipes has quit IRC17:48
fungiwe also talked about adding a branch for a basically empty template/skeleton presentation (could be just a gutted copy of overview with the theming left intact), which might make the actual instructions a little easier17:49
clarkbelasticsearch has recovered and is now rebalancing17:49
*** jaypipes has joined #openstack-infra17:49
clarkbfungi: good idea. I should probably start with that, put as much boilerplate as possible there and explain how to flesh it out in the howto17:50
fungiidea being for a new presentation, you branch from template and start working there17:50
*** krtaylor has quit IRC17:50
fungii still don't think our plan has a good solution to global theming changes though... maybe we make updates to the template branch and then cherry-pick those to all the others?17:51
clarkbwe could use a submodule >_>17:51
clarkbbut then we have another git repo...17:51
* fungi is not a fan of submodule so far, but the ways he has used it may not be great either17:51
clarkbfungi: I think this is the sort of thing that submodules were created for. They are substitutes for things that should be treated like packages but have no packaging17:52
fungiyeah, i think cherry-picking template updates into other presentation branches would probably be fine as long as we're mindful of making them merge-friendly when we construct them17:52
clarkb++17:52
*** jaypipes has quit IRC17:53
*** yjiang5_away is now known as yjiang517:53
clarkbfungi: https://review.openstack.org/#/c/44378/ do you know what causes ssh clients to complain about a hash mismatch?17:53
fungialso, in the same vein, i think anywhere we reuse images in slides we should try to always keep the same file names and paths for them, so it's easier to update them in all branches as needed17:53
*** ruhe has quit IRC17:53
* fungi looks17:54
clarkbfungi: also if you look at that change you will notice that gerrit 2.4 seems to be more picky about some things than 2.6 by deafult17:55
clarkbfungi: was interesting debugging some of the failures17:55
fungihash mismatch is going to be a difference in the key being verified and the one cached17:55
*** eharney has quit IRC17:55
clarkbfungi: in known_hosts?17:55
clarkbfungi: perhaps we should simply not verify the host keys?17:55
fungiyeah, in *a* known_hosts anyway. there are multiple places ssh can look17:55
*** jaypipes has joined #openstack-infra17:56
fungiwe can probably tune ssh for more specific behaviors in that regard through adjusting the envvar git uses to determine how it's invoked if we want17:56
clarkbit would make the tests a little simpler if we can ignore host key verification as there is a bunch of setupt to make the known_hosts file correct17:57
clarkbor at least attempting to be correct17:57
fungibut basically what that says is that the ssh command as run by git had already seen a key for "localhost" and it didn't match the one served on that port17:57
*** tstevenson has joined #openstack-infra17:57
*** openmike has joined #openstack-infra17:57
clarkbfungi: and that is using the host:port as a key?17:58
fungijust host17:58
clarkbfungi: oh well than that is probably the issue17:58
fungiand yes, if you're going to auto-accept host keys in a script then it really makes just as much sense to ignore them entirely (tofu uses aside)17:58
clarkbfungi: since we are running >1 ssh server17:58
fungione workaround if this were a production problem (which it isn't) would be to use multiple aliases for localhost17:59
clarkbfungi: I will fiddle with not verifying the key17:59
fungifor example, i have several machines behind a many-to-one layer-4 nat at home, with sshd from each of them exposed on different tcp ports at the same global ipv4 address. i need to use distinct names when connecting to them18:00
openstackgerritA change was merged to openstack-infra/jenkins-job-builder: Make references to Jenkins plugins uniform  https://review.openstack.org/4496018:00
clarkbfungi: any first thoughts on whether or not we should be testing with our gerrit vs upstream?18:00
clarkbfungi: I don't like hitting upstream for a dependency, that seems potentially flaky as well. And after realizing the tests needed updating to run against 2.4 I am slightly worried we may end up with git-review that works against upstream but not our gerrit18:01
fungiclarkb: if we don't want to test with more than one gerrit, i think we should probably test with latest upstream release since we're not the only community using git-review any longer18:01
fungibut better would be to test more than one gerrit18:02
*** Ryan_Lane has joined #openstack-infra18:02
fungilike 2.4 (which we use), 2.5 (which mediawiki is using currently?), 2.6 which we're maybe moving to before 2.7 comes out?18:02
*** Ryan_Lane has quit IRC18:03
clarkbfungi: the matrix becomes very large18:03
fungiyeah, it does18:03
clarkbthough the test suite is small enough that we might just bruite force it18:03
*** Ryan_Lane has joined #openstack-infra18:03
fungii honestly don't have a great reason for saying we should test multiple versions. it just feels wrong to me to advertise it as a client for gerrit, in the generic sense, but then only test on our old and hacked-up island18:04
fungimaybe two tests. latest released gerrit and the gerrit run for openstack infra18:04
clarkbthat seems reasonable18:06
fungithat way it's not broken for our community (because we're a special snowflake who happens to be running the tests!) and if it's broken for anyone else then they ought to run a newer gerrit18:06
clarkbor run our gerrit >_>18:07
clarkbso hopeful that I won't be able to say such things in the near future18:07
fungisure, but just "you ought to run openstack's old gerrit fork for your users to take advantage of git-review" by itself is not exactly a great answer18:07
clarkbya18:08
clarkbspeaking of git-review, apparently it doesn't work on windows when the path to git review has spaces in it18:10
*** dina_belova has joined #openstack-infra18:11
*** SergeyLukjanov has joined #openstack-infra18:11
fungiooh, neat. i would consider that worth filing a bug (or did someone already and i missed it?)18:12
fungialso, the GIT_SSH envvar will only take the path to the executable, so you could create a script on the fly which runs ssh -o StrictHostKeyChecking=no "$@" and then point it at that18:14
harlowjaok, qq, whos 'Arx Cruz' (or whats the reference?)18:14
harlowja:-P18:14
openstackgerritJohn Dickinson proposed a change to openstack-infra/reviewstats: added Peter Portante as a core dev  https://review.openstack.org/4508818:14
fungiclarkb: or override it in the .ssh/config for the user running the tests, alternatively18:14
openstackgerritA change was merged to openstack-infra/reviewstats: added Peter Portante as a core dev  https://review.openstack.org/4508818:15
fungiharlowja: i'm guessing it's this guy... https://twitter.com/arxcruz18:15
*** dina_belova has quit IRC18:16
*** melwitt has joined #openstack-infra18:16
harlowjainteresting fungi, idk, whoever it is is starting gating jobs on my reviews, ha18:17
harlowjahttps://review.openstack.org/#/c/44074/ :-P18:17
fungiharlowja: http://www.openstack.org/community/members/profile/1156318:17
harlowjaintersting18:17
harlowjais it a bug that his username is starting the zuul jobs?18:17
harlowja*since my guess is thats an automated thing?18:17
fungiArxCruz seems to be in irc here, so he can likely tell you if that's his own jenkins or something18:17
clarkbfungi: there is a bug for the iwndows thing. lp probably hasn't spoken to your mail server yet18:18
harlowjaah, ArxCruz do u have your own mini-zuul?18:18
clarkbfungi: thanks for the heads up on GIT_SSH. I think we are already doing something of the sort so I can just update that18:18
russellbi came here to ask that same question18:18
ArxCruzharlowja: yes, sorry about that, it's already off line18:18
ArxCruz:(18:18
russellbabout ArxCruz heh18:18
fungiArxCruz: it's the best way to learn!18:19
ArxCruzI've configure with puppet so it started to get everything from gerrit18:19
russellbkinda funny really :-)18:19
ArxCruzI just notice when I start receive emails about bugs being tested18:19
fungii guess it's working ;)18:19
ArxCruzfungi: yeah, now I need to understand how work to just receive the events, not send back information (from now)18:20
ArxCruzfungi: harlowja do I need to take some action ?18:20
clarkbArxCruz: to not send back info you update your pipeline config in layout.yaml18:20
ArxCruzclarkb: which part? hehe, it's huuuuuuuuuuuge18:21
fungiright, zuul-dev's layout has it set as an example, i think18:21
clarkbArxCruz: the pipeline part18:21
anteayaArxCruz: lol18:21
*** Grizzlebee has quit IRC18:21
clarkbthe bits that say success: verify: 118:21
fungias zuul-dev does actually get events and run a subset of tests but doesn't report back to gerrit18:21
clarkbI think you remove those18:21
fungimight make sense to reuse the same layout.yaml zuul-dev does, or even edit that one down further for yours18:22
ArxCruzfungi: okay, I will update my zuul to use layout.yaml from zuul-dev :)18:26
ArxCruzsorry for any trouble that I may have caused18:26
*** nati_ueno has quit IRC18:27
*** nati_ueno has joined #openstack-infra18:27
*** jaypipes has quit IRC18:28
ArxCruzfungi: by the way, I'm trying to configure my own jenkins server too, how can I connect my mini-zuul with my jenkins? is that gearman_workers option ?18:28
clarkbfungi: I have a git-review patch running `test run --parallel --until-failure`. If that doesn't fail for a while I will push it up18:30
clarkbfungi: didn't help18:32
*** mrmartin has joined #openstack-infra18:33
ArxCruzharlowja: fungi I'm using now zuul-dev yaml, please let me know if there's some problem :)18:34
*** nati_ueno has quit IRC18:35
*** kiall_ has quit IRC18:35
*** nati_ueno has joined #openstack-infra18:36
clarkbfungi: going to try it with the managed known hosts file without strict host key checking18:36
clarkbnot that I expect this will help but it will keep the known host keys isolated18:36
*** kiall has joined #openstack-infra18:38
* clarkb abuses 127.0.0.0/8 instead18:39
*** nati_ueno has quit IRC18:40
openstackgerritDavid Lenwell proposed a change to openstack-infra/gitdm: added my self to the piston group and added the launch pad mapping  https://review.openstack.org/4509218:40
*** sarob has joined #openstack-infra18:40
*** jaypipes has joined #openstack-infra18:43
sdaguemarkmcclain: so neutron just reset the gate on unit tests for at least the 4th time since I've been watching, which is killing everyone else's merges18:44
*** dhellmann_ is now known as dhellmann18:46
*** hashar has joined #openstack-infra18:48
markmcclainsdague: yeah saw the same thing18:54
markmcclaingot a proposed fix up for review18:55
*** fbo_away is now known as fbo18:55
*** reed has quit IRC18:55
sdaguemarkmcclain: cool, it would be nice if we didn't push any more neutron patches into the gate before that fix. It's going to be a long time for people watching patches today anyway, and rather not make it longer on them18:58
*** gyee has quit IRC19:00
ttxBOO. pep8 fail causing 2 cancels at gate19:02
anteaya:(19:02
ttxnot exactly sure how adding a README.txt makes a pep8 fail though :)19:03
ttxhah19:04
ttx"git commit title ('This adds a README to brick.') should not end with period"19:04
ttxit's actually a HACKING fail19:04
ttxmordred: looks like people already forgot your good advice to wait until check tests pass before submitting to gate19:04
mordredttx: longer conversation you may not want to get involve in19:04
mordredre HACKING19:05
ttxindeed :)19:05
hasharhey :)  Some people complained a bunch of hours ago that Zuul was stuck not proceeding result19:05
anteayait was19:06
ttxbunch of hours ago it was broken.19:06
anteayait should be fixed now19:06
hasharahhh good :-)19:06
anteaya:D19:06
ttxwell, not Zuul, the gating process was broken.19:06
hasharI could not really help so lamely recommended to .. wait()19:06
ttxdue to some cloud infra fail IIRC19:06
anteayahashar: thanks, that was all I could have done too19:06
anteayaso thanks19:07
*** SergeyLukjanov has quit IRC19:07
anteayarax had an outage on our servers running many important services19:07
anteayalost the bots, eavesdrop, don't know what else19:07
anteayaeverything should be back up now though19:08
hasharand I had no clue who to ping during European morning19:08
anteayanot sure if it was planed maintenance or an unexpected outage19:08
hasharbut hey, I am not that much involved in OpenStack to figure out everything19:08
anteayahashar: yeah, I hear that19:08
anteayaglad the call to the wait() function was able to work19:08
mrmartinmaybe we need an EU infra team also19:09
anteayawell right now we have 4 infra core with root access, and 3 of us who are working towards that19:11
*** dina_belova has joined #openstack-infra19:11
anteayaso until any interested party learns enough about everything about infra to have core status and root access it doesn't much matter where they sleep19:11
anteayathey couldn't restart infra anyway19:12
mrmartinI'll will promote this fantastic opportunity in the local user group, and try to find someone who don't want to sleep during the next few months19:12
*** kiall has quit IRC19:12
hasharyou can still start the bootstrapping process19:12
anteayawell I figure to learn all of infra will take at least 6 months, if they really really pick it up fast - myself I think I will need longer19:12
hashari.e. focus on some european people to have them later become root / whatever privilege19:13
anteayathen they have to be core and root19:13
anteayamrmartin: but by all means, any new folks who want to come along and learn are more than welcome19:13
mrmartinanteaya: I guess it is a normal process, if I hire somebody now to work on openstack it takes the same 6 month to learn the basics19:13
anteayahashar: sure19:13
anteayaall welcome19:13
*** openmike has quit IRC19:14
*** vipul is now known as vipul-away19:14
*** vipul-away is now known as vipul19:14
anteayamrmartin: yes, but yes I think that having capable folks in all time zones would make us all happy19:14
hashara thing that works nice is to pair experimented people with entry level people19:15
anteayayes, mentoring is a good approach19:15
hasharso whenever there is an outage, the newcomer is responsible and the experimented/root is looking over the shoulder19:15
hasharboth could update whatever troubleshooting doc already exist19:15
hasharnext time, the doc will probably be enough for the rookie to sort the issue19:15
hasharand so on19:15
anteayafungi tends to help me since he is in the same time zone, when he has time - this week is a bad time for me to hog his attention19:15
hasharbut that takes a long time19:15
anteayayes19:16
sdaguettx: yeh, these are the times I think we need fast fail in zuul19:16
anteayaand the room for error in infra is small19:16
anteayabut yes, we do what we can and the core/root folks support us a lot19:16
*** dina_belova has quit IRC19:16
anteayathis time frame right now is a poor example of that, since the core/root members are focusing on keeping this working19:17
sdagueI need to figure out the right data to catch to figure out throughput modelling for zuul19:17
anteayaso us 3 non-core are doing work that doesn't require much support from infra-core19:17
anteayawhile trying to do what we can to support the ff tension/rush19:18
sdagueug, and another neutron reset, /me hopes the fix markmcclain has in the merge queue handles it19:18
hasharanteaya: sounds to me like you are greatly offloading root which is a  good start19:18
anteayathanks19:18
anteayadoing my best19:18
*** ryanpetrello has quit IRC19:19
markmcclainsdague: once this merges this should fix the gate failure https://review.openstack.org/#/c/45091/19:19
anteayait's funny, I tell my body to wake me up when I need to be awake19:19
sdaguemarkmcclain: cool19:19
clarkbmarkmcclain: there are other races in the neutron tests19:19
anteayayesterday morning I was up and online around 7:30am my time, this morning I didn't wake up until 10:30am19:20
clarkbmarkmcclain: https://review.openstack.org/#/c/43558/ the comments at the end of that review point out a different set of races  Ithink19:20
anteayaI came online as things that were down were still being discovered19:20
anteayaI couldn't have done anything other than call .wait() either19:20
markmcclainclarkb: looking into that one as well19:21
mordredsdague: jeblair is working on some helpful changes to teh zuul scheduler19:24
sdaguemordred: cool19:24
mordredsdague: he was just catching me up on what I missed19:24
clarkbsdague: it will do one level of branching19:24
mordredsdague: https://review.openstack.org/#/c/44346/19:25
clarkbso that on the first failure we restart tests behind without the failing test, if we fail again we discard the restarted thing and go again19:25
*** pblaho has joined #openstack-infra19:25
clarkbfungi: I think abusing 127.0.0.0/8 may have fixed the problem. I will push that up shortly19:25
clarkbfungi: nope nevermind19:25
clarkbfungi: as soon as I say something we get a failure19:25
sdagueclarkb: sounds great19:27
clarkbfungi: actually, the failure is with scp now19:27
sdaguethe other thing that would be nice to do is have some way to either poke changes out of the queue, or have them promoted on next reset19:27
russellbdon't think it's a problem exactly, but this review has an interesting issue ... look at all the "uploaded patch N" comments at the end - https://review.openstack.org/#/c/37819/19:27
russellbjust fyi i guess19:27
mroddeni think Gerrit is having a rough day ^19:28
*** vipul is now known as vipul-away19:29
sdagueinteresting...19:29
*** ryanpetrello has joined #openstack-infra19:30
anteayaI don't think i have ever seen that before19:30
mordredBobBall: ping19:31
anteayaany opinion of whether this is worthy of a bug report?19:31
*** sdague has left #openstack-infra19:31
mordredrussellb: wow. that's fascinating19:31
russellbmordred: that's kinda what I was thinking :-)19:31
mroddenall of the out of order comments are dated sept 3rd 12:00pm19:32
mordredsdake: what do you mean "have them promoted on next reset"19:32
mordredgah19:32
mordredsdake: the above was meant for sdague19:32
lifelessmorning19:33
*** yjiang5 is now known as yjiang5_away19:33
anteayamorning lifeless19:34
lifelessanteaya: hi thar19:34
lifelessclarkb: so want the bad news ?19:34
jog0mordred: the tox change is awesome!!19:34
clarkblifeless: not really, but ok19:34
mordredjog0: yay!19:34
*** vipul-away is now known as vipul19:34
lifelessI can't get the permissions right :(19:34
lifelessclarkb: the config file review.o.o is running doesn't seem to permit openstack-project-creator to create projects19:35
mordredlifeless: our  manage-projects user is in both Project Bootstrappers and Admins19:35
lifelessclarkb: I fixed that19:35
lifelessclarkb: but I couldn't figure out how to have it push to /refs/meta/config and have it work.19:35
lifelessmordred: ohhoho!19:35
mordredlifeless: I do not know _why_ this is the case, but it is certainly true19:36
*** sdague has joined #openstack-infra19:36
sdagueok, so pushing a rev 2 of a patch will kick it out of the gate queue, right?19:36
fungisdague: yes19:37
sdagueI just did that to the cinder pep8 fail to let stuff behind it make progress19:37
fungithat's how i knocked one out earlier when it was unfortunately necessary19:37
fungiin that case, it had already been reverified once though, and they had a copy of the unit test failures already19:37
*** odyi has quit IRC19:39
openstackgerritDavid Lenwell proposed a change to openstack-infra/gitdm: added my self to the piston group and added the launch pad mapping  https://review.openstack.org/4509219:40
sdagueanother neutron reset coming19:40
*** odyi has joined #openstack-infra19:40
*** odyi has joined #openstack-infra19:40
Ryan_Laneupgrading mediawiki for security patches19:41
mordredRyan_Lane: bah. security is for weenies19:41
EmilienMcould anyone make a last review (and maybe an approval) on https://review.openstack.org/#/c/44032 ?19:41
Ryan_Lane:D19:41
openstackgerritlifeless proposed a change to openstack-infra/config: Gerrit docs improvements - user and groups.  https://review.openstack.org/4500119:42
openstackgerritlifeless proposed a change to openstack-infra/config: Phase 3 infra bootstrap docs: gerrit.  https://review.openstack.org/4497019:42
openstackgerritlifeless proposed a change to openstack-infra/config: Document review.pp parameters a bit.  https://review.openstack.org/4496919:42
openstackgerritlifeless proposed a change to openstack-infra/config: Make gerrit DB setup match actual practice.  https://review.openstack.org/4499319:42
openstackgerritlifeless proposed a change to openstack-infra/config: Document basic admin hints for jeepyb.  https://review.openstack.org/4504319:42
openstackgerritlifeless proposed a change to openstack-infra/config: Non-openstack-ci support for launch/dns.py.  https://review.openstack.org/4498019:42
openstackgerritlifeless proposed a change to openstack-infra/config: Document bootstrapping of Gerrit ACLs.  https://review.openstack.org/4501119:42
pleia2oh, this guy again19:42
pleia2:)19:42
*** kiall has joined #openstack-infra19:43
lifelesswoohoo, manage-projects run succeeded19:43
lifelesswhat do you guys think, zuul after gerrit?19:44
openstackgerritA change was merged to openstack-infra/gitdm: added my self to the piston group and added the launch pad mapping  https://review.openstack.org/4509219:45
clarkblifeless: sure, you can set up a simple gearman worker for testing until you have jenkins19:45
clarkblifeless: or you can do jenkins then zuul. The advantage with this approach is you can use the gerrit jenkins plugin before zuul is running19:46
lifelessclarkb: I worry that what you just said implies running diverged from upstream19:46
markmcclainmaybe I missed it, but is it a known issue that job to propose translations has not run since Aug 30th?19:47
clarkblifeless: it does imply that, I think it is only useful to do that for a short period of time while you bring up zuul19:47
clarkbmarkmcclain: I bet I know what happened19:48
lifelessclarkb: so, that seems like waste - setting up something I would not use for long ?19:48
clarkbmarkmcclain: transifex flipped the world upside down semi recently and I think it may have broken the job, let me check on the transifex side to see if anything is missing19:48
clarkblifeless: setting up jenkins itself is 99% of the battle19:49
mordredlifeless: I'd do zuul first19:49
clarkblifeless: adding a plugin to talk to gerrit is a couple button pushes19:49
mordredlifeless: since a simple throw-away gearman worker is about 4 lines of code19:49
mordredclarkb: it's multiple non-automated button pushes19:49
mordredI'd think gerrit -> zuul -> jenkins -> jjb would be the sequence that leaves you with the most intermediary testable states where you don't need to change the tested state to work on the next one19:50
lifelessclarkb: http://paste.ubuntu.com/6063924/ is the manual patch I have outstanding vs everything :)19:50
lifelessbtw19:51
lifeless(to the floor)19:51
lifelessthe prose in gerrit.rst about API projects19:51
lifelessis that aspirational or legacy?19:51
lifelesssince nova is parented on All projects, not API projects, on review.o.o19:51
jeblairlifeless: https://review.openstack.org/#/admin/projects/openstack/compute-api,access19:52
jeblairlifeless: it is neither aspirational or legacy; it is accurate19:52
mordredlifeless: yeah. it's current and accurate19:52
lifelessoh!19:53
lifelessso whats compute-api vs nova?19:53
jeblairlifeless: api docs19:53
lifelessah!19:53
hasharif a change got two code-review +2, does it need a third person to vote approved  or is one of the CR+2 voter allowed to approve?19:54
lifelesshashar: the second +2 voter should approve19:55
openstackgerritlifeless proposed a change to openstack-infra/config: Explain API projects a little.  https://review.openstack.org/4511119:55
openstackgerritlifeless proposed a change to openstack-infra/config: Phase 3 infra bootstrap docs: gerrit.  https://review.openstack.org/4497019:55
lifelessjeblair: thank you19:55
jeblairhashar: what project?19:55
fungihashar: usually if the cr+2 voter didn't approve it's because they either think additional eyes would be good, or because it's not an ideal time to merge it, or maybe because there was a reviewer from a previous patchset who may still have outstanding questions19:55
hasharjeblair: on JJB :)19:56
hasharlifeless: fungi thanks :)19:56
openstackgerritClark Boylan proposed a change to openstack-infra/git-review: Offset localhost IP address when testing.  https://review.openstack.org/4511219:56
jeblairhashar: ah, then you are probably asking about your own behavior, as a recent addition to core :)19:57
clarkbfungi: ^ so that isn't compeltely working according to my testing, but should give you an idea of what I am trying to do19:57
* fungi checks19:57
hasharjeblair: yeah exactly.  Mathieu Gagné and I both are recent approver of JJB. We both CR+2 but I guess we are both afraid to approve huhu19:58
hasharwill sort that out tomorrow :-)19:58
Ryan_Lanewiki is upgraded19:58
jeblairhashar: i agree with fungi's guidelines -- the second core +2 can also aprv, but it is fine to leave it for others if you feel it would benefit from other core reviews19:58
fungiclarkb: i think struct.pack()/unpack() are what i've used to simplify ipv4 integer conversion in the past, but can't recall if that's py3k compliant19:59
hasharjeblair: yeah that make sense. I have asked the other cr+2 whether he wants a third review. Thx!19:59
*** portante is now known as portante|afk20:00
*** portante|afk is now known as portante20:00
mgagnejeblair: you often have things to add so I kind of always rely on your input before approving20:00
jeblairmgagne: ok, i'll try to be less helpful ;)20:00
clarkbfungi: I wouldn't worry about that too much at least not while the tests still fail occasionally with hash mismathces20:00
fungihashar: also general good hygiene includes not +2'ing your own patches, and if possible commenting as to why you didn't approve it even though there were enough votes in favor (if you have the minute to spare)20:01
clarkbfungi: was hoping you would see something glaringly wrong with what I had done that might explain the failures20:01
fungiclarkb: no, waiting to see what it does20:01
fungisince jenkins is happily testing it anyway20:01
fungiso i didn't bother to run it yet20:01
*** rcleere has joined #openstack-infra20:02
hasharfungi: wikimedia has a similar policy. So I guess I will be a good OpenStack citizen :)20:02
*** gyee has joined #openstack-infra20:02
anteayahashar: since you are core on JJB already you are in a prime position to work toward being infra core/root20:04
anteayaif that is what you want20:04
openstackgerritA change was merged to openstack-infra/jenkins-job-builder: Add IRCbot plugin support  https://review.openstack.org/4403220:04
*** yjiang5 has joined #openstack-infra20:05
clarkbfungi: I have been using `testr run --parallel --until-failure` locally as failure doesn't happen 100% of the time20:05
hasharanteaya: I am already too busy with Wikimedia.  But I am glad to help maintain the tool I am heavily relying on (aka JJB and Zuul).20:05
jeblairclarkb, fungi: what are you working on?20:06
fungiclarkb: oh, right20:06
jeblairscrollback is intimidating20:06
anteayahashar: okay, fair enough - you know your schedule best, just following up on our earlier conversation on getting more infra root/core folks20:06
*** nati_ueno has joined #openstack-infra20:06
fungijeblair: i'l trying to read talk abstracts at the moment. was on the list of things i wanted to get done this morning and now, well, it found its way onto the list of things i wanted to do this afternoon instead20:07
fungier, i'm20:07
clarkbjeblair: flaky git review tests20:07
jeblairah ok20:07
fungiclarkb: is poking at a nondeterministic ssh host key mismatch in the git-review integration test20:07
clarkbjeblair: not a super high priority thing but really annoying20:07
clarkbjeblair: did you see the weird change that russellb linked?20:08
jeblairclarkb, fungi: speaking of which, i do think we should land https://review.openstack.org/#/c/44988/ soon20:08
fungiclarkb: another option you may not have tried... can we just reuse the same host key for multiple gerrits instead?20:08
pleia2anteaya: apologies, "we'll talk in an hour" sailed on past and now I really should grab some lunch, want to chat for 10 minutes about the plan or just wait until I return?20:08
clarkbfungi: ooh good idea, yes I think we can do that20:08
jeblairwe can (a) verify that it works with the publications repo; and (b) it would be good to have the post/release jobs working before we start cutting h3 :)20:08
anteayapleia2: understood20:09
fungijeblair: good idea re testing it with the publications publish jobs20:09
anteayaeat first, stable blood sugar is always a good idea20:09
clarkbjeblair: +2 from me, I thought I had +2'd it yesterday20:09
pleia2anteaya: ok cool, bbs20:09
anteayak20:09
jeblairclarkb: yeah, i assume that weird change is due to gerrit not having enough resolution to sort those patchsets (which i assume really were uploaded)20:09
jeblairclarkb: that's a lot of assumptions though20:09
clarkbjeblair: I wonder if it could possibly be related to mysqldump?20:10
clarkb(I don't have much reason to think so but I am paranoid)20:10
sdaguejeblair: the patches all were much older than those dates20:10
mgagnejeblair: but I learn from your input and attention to details =)20:10
*** sdague has left #openstack-infra20:11
*** sdague has joined #openstack-infra20:11
jeblairsdake: right, but they could still have all been uploaded at once20:11
jeblairsdague: ^20:11
*** dina_belova has joined #openstack-infra20:12
sdaguejeblair: sure.... but how? it's not a series, it's the same patch20:12
hasharjeblair: Ryan told me about you post highlighting zuul+gear at http://amo-probos.org/post/15 . I praise your 3l33t graphivz skills.   You might want to look at pip seqdiag to generate graphs http://blockdiag.com/en/ :]20:12
jeblairhashar: nice, thanks! that's almost as l33t as graphviz :)20:14
fungijeblair: was there a particular publications change you wanted to wait for on 44988, or just manually retrigger a post job on the branch tip?20:14
jeblairfungi: i think there was an outstanding change20:14
* fungi doesn't see one20:14
mgagnehashar: nice find!20:14
clarkbfungi: there should be my change to fix the README.rst title in overview20:14
clarkbunless that already merged20:15
jeblairthat's the one i'm thinking of20:15
clarkbI think it merged20:15
fungiit did20:15
fungibut we can retrigger it20:15
jeblairfungi: it's a race20:15
jeblairfungi: so retriggering won't tell us much, but it will tell us if it works or completely fails20:16
fungiahh, right20:16
comstudHey y'all20:16
comstudi found this 'check experimental'20:16
jeblairsdague: it would be nice if we know what hartsocks saw20:16
comstudthings have been in queue for 50m but it doesn't seem they are running20:16
comstudnot fully implemented or?20:16
hasharmgagne: jeblair: seqdiag syntax is really simple. I am probably going to use it to document Wikimedia CI workflow20:16
jeblaircomstud: the gate has a higher priority20:17
hasharmgagne: jeblair: I will share back here once it is completed.20:17
sdaguejeblair: what's the link again?20:17
*** dina_belova has quit IRC20:17
jeblaircomstud: and is very busy right now so other pipelines are slower20:17
jeblairsdague: https://review.openstack.org/#/c/37819/20:17
comstudjeblair: Ok20:17
fungijeblair: you know what? i believe that was the user i did the gerrit account merge on yesterday. i bet an unseen side effect is that those were possibly uploaded by his old account and jenkins is using a mysql timestamp field on update to those rows to sort them20:17
clarkbfungi: that sounds very plausible20:18
fungis/jenkins/gerrit/20:18
fungitoo many names20:18
mordredfungi: yes. that sounds completely reasonable20:18
jeblairand another reason we should never do that20:19
fungiagreed20:19
*** jaypipes has quit IRC20:19
jeblairi have to get ready to had to sf for the cloudscaling aws api hackathon20:19
jeblairs/had/head/20:19
jeblairwhere i plan to say things like 'add stuff to tempest' and 'if it's in tempest, it can run in the gate'.20:20
*** nati_uen_ has joined #openstack-infra20:20
lifelessjeblair: I was just going to ask what you were going to do there :)20:20
fungibroken record mode: engaged20:20
jeblairlifeless: i'm certainly not going to hack on aws api testing!20:20
clarkbjeblair: there are also boto tests in the unitests (whether or not they should be there is a different problem)20:21
sdaguemordred: so what does the pbr raw install job do?20:21
mordredsdague: it runs through several install permutations with proposed pbr changes on each openstack project20:22
mordredsdague: so, it builds a mirror, then injects proposed pbr into that mirror, then installs and re-installs openstack projects into various virtualenvs20:23
fungiso sounds like the gerrit db schema really should set "DEFAULT CURRENT_TIMESTAMP" on those columns making them only populate on insert and not on update20:23
yjiang520:23
sdagueok, fwiw, it's the longest test we have now but a good chunk20:23
clarkbfungi: so you have confirmed that merging the accounts probably updates those comment timestamps?20:24
mordredsdague: it could actually probably be whittled down20:24
mordredsdague: it's got several permutations that I do not think we need anymore20:24
fungiclarkb: i'm tearing into the current schema now to see20:24
clarkbmordred: it can also do all of those installs in parallel right?20:24
mordredclarkb: I don't know how20:24
clarkbmordred: testr with bash subunit :)20:24
mordredwe _could_ also make it build wheels so that the installs themselves are much faster20:24
mordredclarkb: haha20:24
anteayafungi yes hartsocks was the username hartsock was folded into yesterday20:25
clarkbmordred: http://bazaar.launchpad.net/~subunit/subunit/trunk/view/head:/shell/README20:25
fungiclarkb: ha. it has both on update and default. it seems to sort on the wrong one20:25
fungianteaya: other way around, but yes20:26
hasharhave a good afternoon, bed time on my side of the earth. *wave*20:26
mroddenwatching the zuul queue is awesome today20:26
funginight hashar20:26
mroddenthere are some patches going through with 30 commits merged20:26
anteayafungi: hartsocks is the current username yes, and hartsock was folded into hartsocks was it not?20:26
*** hashar has quit IRC20:26
openstackgerritPeter Liljenberg proposed a change to openstack-infra/jenkins-job-builder: Added support for JaCoCo plugin Publisher  https://review.openstack.org/4470520:27
fungianteaya: er, right. for some reason i misread you above. ignore me ;)20:27
clarkbJaCoCo makes me think of Conan O'Brien20:27
fungiclarkb: i was wrong. that table has only one timestamp field, and it does have the on update property set20:27
* fungi also misread the schema. bad day for trying to read things i guess20:28
*** nati_ue__ has joined #openstack-infra20:28
anteayafungi: no worries, I am often wrong - just not always20:28
anteayano worries20:28
fungiclarkb: so yeah, if it's using that column to determine order in which patchsets were uploaded or comments were added, it really ought to not set that property20:29
*** nati_uen_ has quit IRC20:30
fungiboth the patch_sets and patch_comments tables have the same sort of thing going on. given that gerrit doesn't allow you to replace a patchset or edit a comment, it seems unnecessary to update the timestamp beyond insertion20:31
*** fbo is now known as fbo_away20:31
fungiit's something we could fix if we wanted to, but probably better just to keep it in mind instead20:32
clarkbyeah, fix upstream if it is still an issue otherwise I think just being aware of it locally is sufficient20:32
clarkbmarkmcclain: my hunch about why translations proposals are not ahppening seems to be wrong. I am digging deeper20:35
clarkbmarkmcclain: looks like potentially a different issue related to the transifex changes20:37
pleia2anteaya: ok, having a browse through these files in the etherpad now20:37
anteayak20:37
anteayamaking additions now20:37
*** portante is now known as portante|afk20:39
anteayasorry I am a different colour, I don't know how to get the same colour every time I open an etherpad20:39
morganfainberganteaya, i think you can select a color and it'll persist (cookies?)20:40
pleia2anteaya: if you click on the color next to your name in the list you can change it (it's not a big deal though)20:40
openstackgerritJeremy Stanley proposed a change to openstack-infra/config: Gerrit sysadmin tips for account repairs/renaming  https://review.openstack.org/4491220:41
anteayamorganfainberg: okay I can try20:41
fungiclarkb: ^ that includes the ugly workaround20:41
anteayapleia2: thanks, I never get it exact though, close but not exact20:41
pleia2yeah I change colors depending on the computer I'm working on, so whatever :)20:41
clarkbmarkmcclain: I think I see the problem. Sorting out how to fix now. It actually seems to be related to one of our jenkins job changes that only partially applied20:42
morganfainberganteaya, they should allow you to use hex for colors ;)20:42
anteayapleia2: well there is just the two of us so far, so I'm the other one20:42
anteayamorganfainberg: sure they should, I should, me ... sigh okay I'll add to the list20:43
fungimorganfainberg: the geek in me says they should set your color to a 24-bit hash of your nick ;)20:43
anteayafungi: I like that20:43
morganfainbergfungi, but you might get collisions with only 24 bits20:44
markmcclainclarkb: thanks for digging into it20:44
fungimorganfainberg: clearly we need to switch etherpad to 128-bit color20:44
morganfainbergfungi, YES!20:44
clarkbmarkmcclain: puppet on the slave that runs those jobs had been stuck for a month...20:47
clarkbmarkmcclain: I have kicked it, todays translation jobs should work properly20:47
markmcclainthanks20:47
clarkbmarkmcclain: thank you for letting us know20:48
pleia2anteaya: so does a gemfile with dependencies for puppet-dashboard exist?20:49
anteayayes20:49
pleia2(ruby is not my forte, excuse me if I get all the terms mixed up)20:49
anteayano worries20:49
pleia2ok cool20:49
anteayaruby is my forte, at least in this channel20:49
pleia2:)20:49
* fungi tries to make a habit to look at the stale devices list in the puppet dashboard from time to time, but i guess i hadn't checked it for a while before going out of town20:49
lifelesswill zuul run on a 512M instance, do you think?20:49
*** Ryan_Lane has quit IRC20:49
pleia2anteaya: where is this file in the dashboard source?20:50
fungilifeless: if it's doing basically nothing, probably20:50
*** Ryan_Lane has joined #openstack-infra20:50
anteayahttps://github.com/sodabrew/puppet-dashboard/blob/master/Gemfile20:50
fungilifeless: it and gear are very lightweight20:50
pleia2anteaya: thanks20:50
jeblairlifeless: http://cacti.openstack.org/cacti/graph_view.php?action=tree&tree_id=1&leaf_id=2320:50
jeblairlifeless: do you know about our cacti?20:51
anteayapleia2: the way it works is that once you get a new project you install bundler as a gem, then run `bundle install`20:51
lifelessjeblair: thanks; I kindof did.20:51
jeblairlifeless: you can probably draw some conclusions based on those graphs and what you know about our load20:51
jeblairlifeless: (that would probably be as good as our guesses)20:51
pleia2anteaya: I see, so puppet-bundler enables puppet to consume the gemfiles?20:51
lifeless50G used, hmmm20:51
jeblairlifeless: to that i would only add that until recently we struggled with a 1g node.20:51
anteayabundler reads the Gemfile (it gets worked up about the gem.lock file, for reasons I have never understood) and then downloads the listed gems20:51
*** Ryan_Lane has quit IRC20:51
pleia2anteaya: ok, I see20:51
anteayapleia2: that is my hope20:51
*** Ryan_Lane has joined #openstack-infra20:51
lifelessjeblair: struggled with disk space, or memory/cpu ?20:52
anteayaI think we will need to see it in action before we know for sure20:52
jeblairlifeless: ram20:52
anteayapleia2: the gemfile deals with gem versions too20:52
pleia2anteaya: yeah, I'm thinking we have too many moving pieces to brainstorm for too long before we need to start installing things and kicking tires20:52
jeblairlifeless: my guess is that 1g is still okay for a handful of projects20:52
pleia2anteaya: do you have an hpcloud account?20:52
anteayamordred: do I have an hpcloud account?20:53
lifelessjeblair: interesting - the 50G disk space seems flat20:53
lifelessjeblair: is it proportional to project count? job definitions?20:53
anteayaI'm waiting on approval for something, let's roll the dice and see if I have it yet20:53
*** dims has quit IRC20:53
anteayapleia2: let's go with no for now and work on yours20:53
pleia2anteaya: you can set one up (free for 3 months) and then mordred helps get your account upgraded to employee20:53
anteayapleia2: yeah, it won't without a phone number20:54
pleia2but ok, I can toss up an instance on my hpcloud account and give you access to the shell for playing20:54
pleia2ah, goodie20:54
anteayaand I have had enough spam on my private telephone number20:54
anteayathat is what I am waiting for20:54
anteayapleia2: sounds like our smoothest way forward20:54
openstackgerritEmilien Macchi proposed a change to openstack-infra/jenkins-job-builder: Add Plot plugin support  https://review.openstack.org/4368520:54
*** dims has joined #openstack-infra20:55
*** nati_ue__ has quit IRC20:55
pleia2anteaya: have your ssh public key handy?20:55
*** nati_uen_ has joined #openstack-infra20:55
anteayapm'd20:56
*** rcleere has quit IRC20:56
clarkbjeblair: interesting observation of the nodepool node graph, we don't seem capable of using all 296 nodes with the shorter test times20:56
clarkbjeblair: and if you look at the gate queue right now you will see that we occasionally don't start jobs in order20:57
jeblairclarkb: i have an idea of how to get nodepool spinning up nodes faster (though keep in mind, gate resets may reduce the actual used capacity)20:58
* jeblair -> sf20:59
jeblairclarkb: if you can figure out why those jobs are starting out of order, that would be very useful21:01
clarkbjeblair: ok21:01
lifelesshow far out of order?21:02
lifelesslike, could it be message bus non-order guarantees?21:03
clarkblifeless: not terrible http://status.openstack.org/zuul/ 44501 is the first case of it21:03
clarkb*4405121:03
clarkblifeless: geard should hand out jobs in order though21:03
clarkblifeless: it is one of the reasons we are using geard and not gearman proper21:03
*** dprince has quit IRC21:03
clarkbthough maybe, zuul is placing the jobs on the bus in a different order than I expect21:04
mordredclarkb: hand out jobs in order does not mean start in order21:04
mordredclarkb: a loaded jenkins could receive the event and then not kick the job that instant21:04
mordredperhaps?21:04
anteayafungi: going to take my first run at standing up the sodabrew puppet-dashboard, and am selected an initial ruby verision, you had mentioned you had some experience with 1.8/1.9 incompatibility on Fedora 18 puppet21:04
anteayado you have those notes handy/21:04
anteaya?21:04
*** ArxCruz has quit IRC21:05
anteayawhen working with other puppet services using 1.821:05
clarkbmordred: the jenkins executor worker threads should only grab work when they are able to perform work21:05
mordredclarkb: right - but able to perform work doesn't mean that java won't decided to do something weird in the next second21:06
*** pcm_ has quit IRC21:06
clarkbmordred: possibly21:06
mordredclarkb: it'd be a tiny race, but you never know21:06
anteayas/selected/selecting21:06
clarkbmordred: I think the behavior we are seeing according to the status page indicates a larger race21:07
*** svarnau has quit IRC21:07
clarkbmordred: because there are many jobs that have started instead that could have run the jobs that are queued instead21:07
*** kiall has quit IRC21:07
clarkbby many I mean >521:08
mordredclarkb: ah. interesting21:08
fungianteaya: gimme a sec and i'll dig those links up21:08
anteayafungi: thank you21:09
fungianteaya: though what i found was an inability to run puppet 2.7 on ruby 1.9.3 because it broke puppet report (among other bits)21:09
anteayaokay, good to know21:09
* mordred is happy for anteaya to look at ruby things21:09
anteayaI do think the consensus was to start on ruby 1.8.721:09
fungiit may be that puppet dashboard is new enough to not suffer similar problems, and capable of collecting reports from puppet 2.7 machines?21:10
anteayaso I think I will start there, but i do need to know what I am trying to avoid/work with21:10
*** Ryan_Lane has quit IRC21:10
fungibut yes, if it'll run on ubuntu precise's default ruby, then all the better21:10
*** Ryan_Lane has joined #openstack-infra21:10
* anteaya knows ruby is loathed in here, so trying hard to be an seen as an expert in ruby21:10
anteaya_not_ to be seen, _not_21:10
anteayaI can't type21:10
lifelessanteaya: too late.21:11
lifelessanteaya: we heard you loud and clear; ruby expert - check.21:11
anteayayou are so going to regret that21:11
anteayaI know so little21:11
lifelessI will21:11
anteayaha ha ha21:11
lifelesswhen I'm asking you ruby questions :P21:11
anteayayup21:11
anteayaabout that time21:11
anteayafungi: I would like to keep that hope alive as long as possible21:12
*** dina_belova has joined #openstack-infra21:12
anteayaI wonder for my first pass if I try to push it to 1.9 and then see what breaks when I try to consume other puppety things?21:12
anteayaI might try that21:13
anteayaby push it to I mean use 1.921:13
anteayaWednesday is a great day to break stuff, I think I will go that route21:14
*** NobodyCam_ has joined #openstack-infra21:14
*** NobodyCam_ has quit IRC21:14
*** dina_belova has quit IRC21:17
anteayaso if I apt-cache ruby1.9.1 it actually gives me ruby 1.9.3: 1.9.3.0-1ubuntu2.4 yay!21:17
*** Ryan_Lane has quit IRC21:17
*** Ryan_Lane1 has joined #openstack-infra21:17
*** marun has quit IRC21:17
*** svarnau has joined #openstack-infra21:19
*** Ryan_Lane1 is now known as Ryan_Lane21:20
*** Ryan_Lane has quit IRC21:20
*** Ryan_Lane has joined #openstack-infra21:20
*** lcestari has quit IRC21:20
openstackgerritRyan Petrello proposed a change to openstack-infra/config: Provide a more generic run-tox.sh.  https://review.openstack.org/4314521:21
clarkbI think it might be the order that zuul is putting them in the queue21:22
*** marun has joined #openstack-infra21:23
ryanpetrellomordred: re: 43145, I went ahead and removed the comments and that distribute workaround21:23
jeblairclarkb: why?21:25
clarkbjeblair: grepping through the logs indicates the launch order may be funny. I am about to paste some of what I have found21:25
clarkbjeblair: http://paste.openstack.org/show/45780/21:28
mordredryanpetrello: woot! thanks21:29
clarkbjeblair: found that grepping for 44051,1 since that is at the base of the problem.21:30
clarkbit is possible I missed something as a result. Looking more closely now that I have more info21:30
anteaya16 patches potentially ready to pass the gate21:31
anteayathey look so pretty all lined up like that21:31
clarkbjeblair: now that I know what I am looking for I still see launches for earlier changes happening after the most recent launches for newer changes21:33
notmynameany ideas why tox -epep8 passes but a local invocation of pep8 fails? any hints on what to look for?21:34
*** sarob has quit IRC21:34
notmynameor more specifically, there seem to be real pep8 issues, just that some aren't found by tox21:34
mordrednotmyname: hrm.21:34
clarkbnotmyname: because the pep8 job probably doesn't actuall run pep8 instead it runs flake821:34
*** sarob has joined #openstack-infra21:35
mordrednotmyname: what clarkb said - did you run flake8?21:35
openstackgerritA change was merged to openstack-dev/pbr: Add pypy to tox.ini  https://review.openstack.org/4405121:35
notmynameclarkb: mordred: good point, but I think I found the issue (pep8 1.4.5 vs pep8 1.4.6)21:36
mordrednotmyname: ah yes. we do our best to pin at the beginning of the cycle21:37
jeblairclarkb: im on bart so my debugging is limited.  are the log msgs lying?21:37
notmynamemordred: is that why it's at 1.4.5? because 1.4.6 came out after havana was well underway?21:38
mordrednotmyname: yes21:38
clarkbjeblair: not sure yet, I don't expect so as the time difference is large and it seems to be missing entries that I would expect21:38
notmynamemordred: by implication, should I expect that icehouse will bump it and cause new pep8 failures?21:38
mordrednotmyname: and we've been bitten in the past by sudden pep8 version bumps21:38
fungilifeless: not sure if anyone got back to you on our zuul disk usage, but 90% of it appears to be /var/log/zuul (there was a while where the jenkins-gearman plugin was very noisy)21:38
notmynamemordred: right21:38
mordrednotmyname: potentially - but we're going to try to figure out a good way to manage that21:38
mordredso that it doesn't screw yoy21:39
mordredyou21:39
clarkbfungi: it is still very noisy :)21:39
notmynamemordred: don't worry. you'll make somebody mad ;-)21:39
notmynamemordred: actually, I can guess who that will be ;-)21:39
*** sarob has quit IRC21:39
anteayasdague markmcclain so keystone patch 44509 failed on tempest-neutron: https://jenkins01.openstack.org/job/gate-tempest-devstack-vm-neutron/9040/console thought you might want to know21:39
notmynamemordred: jeblair: clarkb: in other news, I just clicked "approve" on a patch that will start gating all swift tests on pep821:40
mordrednotmyname: woot21:40
*** portante|afk is now known as portante21:40
alexpilottihi guys, I have a patch that is unable to merge since a lot of hours21:40
alexpilottihttps://review.openstack.org/#/c/38791/21:40
*** kiall has joined #openstack-infra21:40
alexpilottibeside "reverify no bug", is there anything I can do?21:41
alexpilottiI have another 2 approved patches that depend on this one21:41
openstackgerritEmilien Macchi proposed a change to openstack-infra/jenkins-job-builder: Add Plot plugin support  https://review.openstack.org/4368521:42
anteayaalexpilotti: it is in the gate pipeline21:42
anteayaalexpilotti: don't do anything more, it will take you out of the gate queue21:42
alexpilottiok, do you know how can I estimate when it'll run?21:43
*** weshay has quit IRC21:43
*** thomasm has quit IRC21:43
markmcclainanteaya: looking21:44
anteayaalexpilotti: sure, go to this page: http://status.openstack.org/zuul/21:45
anteayalook down the middle column - that is the gate queue21:46
alexpilottianteaya: tx!21:46
anteayafind your patch number and if the time is known it will appear in the top right corner of the window with your patch21:46
anteayaalexpilotti: np, hope it merges21:46
anteayamarkmcclain: thanks, it might be a legitimate failure, I just know you and sdague were working on this earlier, thought this might help21:47
clarkbjeblair: http://paste.openstack.org/show/45784/ I think I figured it out. This is happening when jobs are restarted if the job result is None21:49
fungianteaya: these are things fixed in puppet 3.0 but never backported to 2.x... http://projects.puppetlabs.com/issues/15190 http://projects.puppetlabs.com/issues/897421:49
clarkbjeblair: so I think we are ok, there may be a better way to handle this though, perhaps using high priority for job restarts like that and normal for gate?21:49
anteayafungi thanks, what is the tl;dr version of what our plan is for going to puppet 3.0, if it is anything other than the time it takes to upgrade?21:50
clarkbmordred: lifeless ^ the reason the tests appear to start out of order is we are working around Jenkins failures by restarting jobs. The restart goes at the end of the queue21:50
alexpilottianteaya: being today the last day for H3, when is the time limit to submit for review?21:51
*** ewindisch has joined #openstack-infra21:51
fungianteaya: i think it's a matter of having a second puppet master and migrating systems from old to new incrementally... i had gotten the impression that you can't mix old and new puppet on old and new ruby in the same master, but i could be wrong21:51
*** ewindisch is now known as ericw21:51
anteayattx ^21:52
clarkbfungi: second master is the way to go21:52
*** mrodden has quit IRC21:52
jog0jeblair: ping21:52
*** ericw is now known as ewindisch21:52
anteayabet he is asleep though21:52
fungianteaya: also the puppet 3.2.0 release notes claim that the ruby 1.9.3 p0 carried in ubuntu precise is unsuitable, so it may be necessary to wait until $next_lts21:52
anteayaalexpilotti: keep submitting until someone tells you to stop21:52
*** portante is now known as portante|afk21:52
clarkbalexpilotti: I think ttx operates on the before I wake up rule but I am not 100% sure21:52
anteayaalexpilotti: I don't know, so just keep working21:52
yjiang5anything wrong in gate? Seems a patch has been paused for a long time.21:52
anteayaah okay, so let's not wake him up21:52
clarkbyjiang5: nothing wrong, it had a job restarted which slowed that particular one down21:52
ewindischjog0: hopefully, jblair is on his way to the AWS hackathon ;-)21:53
yjiang5clarkb: aha, got it.21:53
*** shardy is now known as shardy_afk21:53
clarkbyjiang5: oh actually21:53
*** ewindisch is now known as ewindisch-21:53
clarkbhmm21:53
alexpilottianteaya clarkb hehehe I like this approach :-)21:53
jog0ewindisch: I will be heading there fora bit myself ;)21:53
anteayago alexpilotti go21:53
ewindisch-jog0: cool21:53
ewindisch-wedgwood should be showing up, too. I know you miss him.21:53
clarkbyjiang5: that particular test has failed (looking at the console log) I wonder if that has mad ethings go sideways21:53
pleia2ewindisch-: you in town this week?21:54
*** datsun180b has quit IRC21:54
*** sdake_ has quit IRC21:54
jog0clarkb: yeah its hanging21:54
openstackgerritA change was merged to openstack-infra/jenkins-job-builder: Add Plot plugin support  https://review.openstack.org/4368521:54
jog0https://jenkins02.openstack.org/job/gate-tempest-devstack-vm-postgres-full/7811/console21:54
ewindisch-pleia2: yes. We're doing an AWS + tempest hackathon at evault right now (3rd & Howard)21:54
anteayafungi: arrrr - okay so waiting for the next lts release since I know there is an aversion to using rubies through rvm rather than the distributed versions21:54
clarkbsdague: jog0: safe to manually kill that job so that the gate keeps moving?21:54
jog0clarkb: kill it21:54
pleia2ewindisch-: ah yes, I've been there a few times :)21:55
pleia2(busy tonight and tomorrow though, alas)21:55
clarkbjeblair: you might also mention that doing a hackathon during the day of feature freeze isn't so great :)21:55
fungianteaya: does rvm automagically update on your machine to apply security fixes?21:55
anteayafungi: yeah the migration of systems from old to new is going to be fun21:55
jog0its a doc patch21:55
openstackgerritTobias Stevenson proposed a change to openstack-infra/gerritbot: Fix comment event reporting in Gerritbot  https://review.openstack.org/4491321:55
yjiang5clarkb: really strange for that simple patch (change HACKING.RST)21:55
anteayafungi: I don't think so, I think you have to tell it to update21:55
anteayamanually21:55
clarkbyjiang5: I think flaky tests did it in, not the actual change21:55
clarkbjog0: done21:55
jog0clarkb: https://review.openstack.org/#/c/42296/21:55
jog0clarkb: looks like all dependant patches have to rerun now though sigh21:56
anteayarvm won't tell you when you need to upgrade, just that if you select an older patch version, it will tell you a newer one is available21:56
clarkbjog0: yes, that is how zuul works :)21:56
jog0clarkb: it makes sense just frustrating21:56
fungianteaya: then not suitable for us, unfortunately. same reason we don't like installing things from pip either... it's not a ruby vs python thing21:56
clarkbjog0: and why aborting the change now instead of waiting is advantageous21:56
anteayafungi: yeah, I hear that and makes so much sense21:56
anteaya*she said while railing against the limitations of the box*21:57
*** mrmartin has quit IRC21:57
fungiat $oldjob we had an aversion to auto-updating servers, but we also had a team of a dozen people handling the semi-automated security updating we performed21:57
openstackgerritTobias Stevenson proposed a change to openstack-infra/gerritbot: Fix comment event reporting in Gerritbot  https://review.openstack.org/4491321:58
jog0clarkb: it would be nifty if zuul could detect if a unittest ased job is failing and mark it as failed for zuuls status keeping while it finishes running to report to the user21:58
jog0that would have made this issue not exist21:59
clarkbjog0: I am so happy you mentioned that. So one of the potentially super awesome things testr + subunit allows us to do is stream the subunit back to zuul22:00
clarkbjog0: zuul could then use that stream to do exactly what you have described22:00
anteayafungi: ah yes, well considering the size of the group we have available to manually update security issues, the approach infra takes is the most stable22:00
clarkbjog0: but that requires getting everyone on testr which hasn't quite happened yet22:00
anteayaI've never accepted limitation well, glad I work remotely22:00
clarkbjog0: and also potentially needing bigger pipes. Not sure what the bandwidth and processing requirements are for 350 subunit streams22:01
jeblairjog0: yes, we definitely want to do that; also -- tempest uses testr now so we can benefit from that on those tests22:01
anteayagetting horizon on testr is going to be a job22:02
jog0clarkb jeblair:cool.  the subunit stream bandwidth issue could be fun :)22:02
fungii wonder if a slave-side subunit processing tool dropping a message on a queue to say "this job is going to fail" as soon as it knows that to be the case would be lighter-weight for zuul22:02
anteayamordred: so I should be going to ruby events, yeah?22:03
clarkbfungi: thats a good idea. I think jeblair wants to do more with the subunit streams though22:03
fungiahh22:03
clarkbfungi: but that may be a good place to start22:03
anteayaI need to find something to propose to a ruby conference that would be a good talk22:03
jeblairclarkb: aha! (catching up on the out-of-order thing)22:03
clarkbwhy you should use zuul even though it is written in python22:03
clarkbanteaya: ^22:03
anteayagreat22:04
jeblairclarkb, fungi: yeah, i was kind of thinking something on the jenkins-side; but i only have vague ideas at this point22:04
anteayaI will do the reading of the jeblair blog and zuul notes and ask many silly questions as I compose slides22:04
anteayathanks for the idea, clarkb22:04
jeblairclarkb, fungi: all we really need is something that can cause gearman-plugin to send a work_warning packet22:04
jeblairclarkb, fungi: though we could pipe all the data back if we wanted22:05
*** zeus has quit IRC22:05
fungiseeing how large the subunit captures are from current unit test jobs makes me worry that it would be a firehose streaming them all at zuul during peak activity22:05
clarkbjeblair: fungi: sending work warning packets shouldn't be hard22:05
clarkbI think the trickiest bit might be getting subunit into jenkins somehow22:05
jeblairso then the question is -- what can we reasonably shim in to jenkins22:06
jeblairclarkb: yeah22:06
*** pcrews has quit IRC22:06
jeblairneeds some brainstorming.  :)22:06
clarkbthis might be a good case for brainstorming non jenkins gearman workers22:06
clarkbthough the investment there is potentially very high22:06
jeblairclarkb: yeah, though i think devstack workers are at the bottom of the list of likely non-jenkins workers at the moment (that's the hardest problem to solve)22:07
fungii can see how it would work in the non-jenkins future, but don't know enough about what kind of real-time feedback jenkins gets from slaves besides the obvious console stream and the end-of-job and slave status details22:07
jeblairclarkb: (by contrast, privileged slaves are the easiest)22:07
*** pcrews has joined #openstack-infra22:08
* anteaya goes for a walk22:08
*** dolphm has joined #openstack-infra22:09
jeblairhttps://etherpad.openstack.org/hackathon-aws-compat22:10
jeblairfor folks curious about the aws api hackathon ^22:10
SpamapSwtf.. why does the pypi yaml module not just install libyaml support by default if libyaml-dev is available?22:11
*** svarnau_ has joined #openstack-infra22:11
clarkbahahahahahaha22:12
ewindisch-ty jeblair22:12
clarkbso I just looked into the jenkins slave protocol and now see why there are security concerns22:13
SpamapSclarkb: no one can be TOLD what the jenkins matrix is...22:13
*** dina_belova has joined #openstack-infra22:13
fungiclarkb: sounds like it should be easy then! ;)22:13
clarkb"Once connected, remote slave agents can send in commands to be executed on the master, so in a way this is like an rsh service."22:13
clarkbcomment from the code22:13
clarkbbut yes, this may make it easier to do what we want22:14
fungigreeeaaat. that basically parrots what we heard then22:14
clarkbthe slave side could run the subunit filter, then request the master to pass the work status packet up to zuul22:14
clarkbstill digging in22:14
lifelessfungi: thanks22:14
*** svarnau has quit IRC22:15
*** tstevenson has quit IRC22:16
fungifrom a zuul status ui perspective, i suppose we could change the color of the progress bar for failing but not yet completed jobs22:16
fungibut then in zuul treat that the same as it currently does a job failure from a queue management perspective22:16
clarkbI wonder if the ssh protocol is very different as that is in a plugin I think22:17
*** dina_belova has quit IRC22:18
*** boris-42 has quit IRC22:19
clarkbI think ssh is just a tunnel so probably not22:19
*** boris-42 has joined #openstack-infra22:19
*** ryanpetrello has quit IRC22:21
*** dkliban has quit IRC22:23
*** burt has quit IRC22:25
*** sarob has joined #openstack-infra22:25
*** changbl has quit IRC22:27
*** sarob has quit IRC22:30
*** prad_ has quit IRC22:31
*** jhesketh has joined #openstack-infra22:32
*** jhesketh__ has joined #openstack-infra22:32
*** thedodd has quit IRC22:32
*** sarob has joined #openstack-infra22:33
*** pblaho has quit IRC22:34
*** atiwari has quit IRC22:38
clarkbhttps://github.com/jenkinsci/remoting appears to be the slave agent code22:38
clarkbor at least makes up a significant portion of the agent22:40
*** sarob has quit IRC22:41
*** sarob has joined #openstack-infra22:41
*** dhellmann is now known as dhellmann_22:43
*** nati_ueno has quit IRC22:44
*** sarob has quit IRC22:45
clarkbthe more I read the more I think the ssh slave agents are safe (or at least not outright allowing the slave to do whatever)22:47
ewindisch-jeblair: a recorded version of this for new developers would be awesome22:48
*** ryanpetrello has joined #openstack-infra22:50
clarkbreading remoting it appears to be fairly synchronous, master sends slave a command to execute over a channel, command is executed, results are returned22:51
fungiclarkb: it looks like the agent runs as the jenkins user on our slaves, so in theory anything else running as the jenkins user could subvert the agent to do anything the master's protocol handler allows22:52
*** sarob has joined #openstack-infra22:53
fungino real privsep between the agent and things the agent is running22:53
*** gordc has quit IRC22:54
*** sarob_ has joined #openstack-infra22:56
*** sdake_ has joined #openstack-infra22:56
clarkbfungi: right, but I don't think our ssh slaves are using the jnlp protocol22:57
fungiahh! right, okay22:57
clarkbfungi: instead they just stream stdout back to jenkins22:57
clarkbwhich should make it fairly safe22:57
fungibut also means limited in-job signaling back to the mothership22:58
clarkbright22:58
fungiso we could stick something identifiable in-stream on the console and scrape that in a plugin on the master, but that would be extremely hackish22:59
*** sarob has quit IRC22:59
clarkbright, there are "Listeners" on the agent side. trying to deduce if they do anything interesting23:00
fungissh protocol has a signaling channel, but whether the agent and master support nuances of ssh is unlikely23:00
alexpilottiI'm looking at at patch on zuul since a while and after executing tasks, it gets eventually back to having all tasks marked as "queued"23:01
fungihttp://www.ietf.org/rfc/rfc4254.txt section 6.9 (page 14)23:01
alexpilottiit's the first time that I take a look at zuul's behaviour23:01
*** sarob_ is now known as sarob23:02
alexpilottiis this something that I can consider normal and simply wait or should I start thinking about something? :-)23:02
fungialexpilotti: is this an approved change in the gate? if so, there are probably changes in line ahead of it failing and getting kicked out, which means yours has to be retested without those in the mix23:02
alexpilottifungi: yes it is23:02
clarkbfungi: jeblair: I am beginning to wonder if mayber the jenkins slaves should be gearman clients and talk to zuul out of bad that way23:03
clarkbs/bad/band/23:03
lifelessclarkb: out of bad is entirely appropriate23:03
*** fbo_away is now known as fbo23:03
fungialexpilotti: eventually when your change has only passing changes ahead of it, it won't get its jobs reset any longer23:03
lifelessclarkb: You *have* looked at the jenkins internals, right?23:03
fungialexpilotti: and once jobs complete for all the changes ahead of it, they will merge and yours will too23:03
clarkblifeless: I have, I am looking at them more now, this is leading me towards wanting to make jenkins slaves gearman clients :)23:03
alexpilottifungi: ok, there's quite an impressive list of 15 of them in front23:04
lifelessclarkb: why jenkins at all at that point?23:05
fungiclarkb: or zmq or something if making them talk gearman turns out to be less ideal23:05
alexpilottifungi: if I understand right: http://status.openstack.org/zuul/23:05
clarkblifeless: earlier I suggested this being a reason to use non jenkins workers. Jeblair indicates doing so for devstack/tempest tests will be a lot of work23:05
clarkblifeless: trying to find a path of least resistance23:05
lifelessclarkb: ah23:06
lifelessclarkb: I am now curious what features of the jenkins slave that devstack/tempest use23:06
clarkblifeless: initially thought it might be possible to abuse jenkins insecurities to do this but I don't think that is possible anymore23:06
*** reed has joined #openstack-infra23:07
lifelessclarkb: plugin code can get remoted to the slave side23:07
lifelessclarkb: jenkins would still need to kick the slave off23:08
reedthis looks weird: https://review.openstack.org/#/c/24184/  uploaded in July, merged in March?23:08
clarkblifeless: we need asynchronous callbacks into the master or similar23:08
clarkblifeless: to tell jenkins a test will fail but to continue running the job23:08
clarkbfungi: is reeds change another potential gerrit DB weirdness?23:09
clarkbI am going to walk home now. I have managed to neglect lunch and need to scrounge up food23:11
clarkbBack in a bit23:11
lifelessanother puppet question - where does23:12
lifeless$openstack_project::jenkins_ssh_key23:12
lifelessget set?23:12
fungiclarkb: reed: yes, i bet this happened when we ran update queries to change s/quantum/neutron/ (did we touch the changes table?)23:12
lifelessah, init.pp nvm23:12
*** dina_belova has joined #openstack-infra23:13
clarkblifeless: that is a bit of a hack...23:14
clarkblifeless: things that use it inherit the base class which typically you avoid in puppet iirc23:14
lifelessI can't see where status.openstack.org is defined23:14
clarkblifeless: it is a static.openstack.org vhost23:14
*** fbo is now known as fbo_away23:15
lifelessclarkb: oh, so /zuul is all static js pulling from zuul.o.o ?23:16
clarkbyup23:16
clarkbok really heading home now23:16
reedwe have a spammer on the #meeting channel23:16
anteayahe left23:17
anteayauser Hoangg for those with blocking abilities23:17
*** dina_belova has quit IRC23:18
lifelessdoes the gerrit user for zuul need to be 'jenkins' or could they be separate role accounts?23:19
lifelesswhat groups is the jenkins user in, in gerrit.o.o ?23:19
anteayaalexpilotti: the heat patch 4 in front of yours failed so the test jobs on your patch have cancelled, once the patches in front of the heat patch finish (and if none of them have a failure) the passing patches will merge, the heat patch will be removed from the queue and your patch will be fourth in line after the gate resets23:21
anteayaso the earliest it will merge is in about 50 minutes23:22
alexpilottianteaya: tx for the update23:22
anteayanp23:22
alexpilottianteaya: what happens if it fails and it's marked as failed in gerrit?23:22
alexpilottianteaya: I mean, I normally would issue a reverify no bug23:23
anteayathen you have to address the message in gerrit and take action based upon what you find23:23
alexpilottianteaya: in that case it goes back in the queue and I have to wait.. another 10 hours? :-)23:23
anteayawell hopefully before you do reverify no bug, you take a look at the output from the logs23:23
anteayasince something may have changed, you might need to rebase23:23
alexpilottianteaya: sure, I mean, in cases in which a totally unrelated failure happens23:24
anteayaif you just reverify no bug and there is a legitamate failure in the logs you are wasting your own time23:24
anteayaalexpilotti: occasionally the tests will pass but it won't merge due to a merge conflict and you will be advised to rebase and go again23:24
alexpilottianteaya: yeah, but in case (as it happens most of the time) in which there is no legitimate failure23:24
*** sdake_ has quit IRC23:24
alexpilottianteaya: I know :-)23:24
anteayaokay well the gate queue can only move as fast as the patches in front of it23:25
alexpilottianteaya: I'm referring to a situation in which it has nothing to do with the patch23:25
anteayaso yes, if you have to queue again, you have to line up23:25
jeblairlifeless: user can be anything; ours is called jenkins for historical consistency23:25
anteayaI have no ability to speed things up in the queue23:25
fungilifeless: we put it in the "Continuous Integration Tools23:25
fungilifeless: " group23:25
fungi(yay newlines)23:26
mordredlifeless: what fungi said23:26
lifelessjeblair: fungi: mordred: thanks.23:26
lifelessI'll write up calling it zuul then.23:26
alexpilottianteaya: for example, last time this one failed: http://logs.openstack.org/91/38791/11/gate/gate-tempest-devstack-vm-full/238672e/23:26
alexpilottianteaya: while all the rest was ok. Tempest has nothing to do with my patch (as I'm doing Hyper-V) :-)23:27
alexpilottianteaya: so in a case like this one, reverify no bug is the only chance?23:28
mordredhttp://www.youtube.com/watch?v=ejuK8_12Fmg&feature=youtu.be23:28
anteayayes, if it is the case that the test failure was unrelated to your patch, ensure the project that is responsible for the failed service knows or a bug is filed, then requeue23:28
anteayaalexpilotti: yex23:28
anteayayes23:28
jeblairalexpilotti: 'reverify bug ####' would be better23:28
alexpilottianteaya: ok, how do I find out which bug #### should I address?23:29
jeblairalexpilotti: it helps track nondeterministic failures for the people who are working on fixing those23:29
*** dims has quit IRC23:29
anteayaalexpilotti: start here: http://status.openstack.org/rechecks/23:29
*** nicedice has joined #openstack-infra23:29
*** nicedice_ has quit IRC23:29
*** hemna is now known as hemnafk23:30
alexpilottijeblair: ok thanks :-)23:30
alexpilottiI wanted to be sure that I was doing everything in my power to keep things on track23:30
anteayaalexpilotti: yes, thank you for asking23:31
anteayait is hard for us to know what people already know and what is new information for them23:31
anteayaI'm glad you are learning the wonders of status.openstack.org and the zuul and recheck options23:32
anteayaalexpilotti: looking good for you atm23:34
alexpilottianteaya: tx, I have another 2 patches waiting after that one23:34
anteayaokay23:35
alexpilottianteaya: my only concern is that they make it before dawn here in Europe ;-)23:35
*** UtahDave has quit IRC23:35
*** pentameter has quit IRC23:36
reedalexpilotti, stop the word!23:36
reeddamn typo23:36
*** nicedice_ has joined #openstack-infra23:36
anteayathat works too23:36
reedworld, silly fingers, worLd23:36
alexpilottiI was actually wondering :-)23:36
*** nicedice has quit IRC23:37
reedmordred, squirrel23:37
anteayaalexpilotti: yeah, well if ttx tries to freeze anything before your patches merge I will point him to the log23:37
anteayahow's that23:37
alexpilottianteaya: you're my hero :-D23:37
lifelessis zuul stateless? That is, does it need backing up or will it regenerate everything out of config + gerrit if rebuilt?23:37
anteayathanks23:37
anteaya:D23:37
reedanteaya doesn't sleep23:37
reedand I'll go silent23:38
reedbyez23:38
anteayawell I don't know about that, not quite moving into the land of no sleep like mordred and fungi23:38
anteayaalways nice to see you reed23:38
anteaya:D23:38
jeblairlifeless: stateless23:38
*** michchap has joined #openstack-infra23:40
*** nicedice_ has quit IRC23:40
*** nicedice has joined #openstack-infra23:40
anteayaalexpilotti: what are the next two patch numbers you need to merge?23:41
anteayalet's get them logged23:41
fungiclarkb: yeah, so just noticed that we probably should start setting created_on=created_on in our update queries to the changes table in our project renaming recipe. seems that field is also timestamp type with on update set23:42
alexpilottihttps://review.openstack.org/#/c/40076/23:42
alexpilottihttps://review.openstack.org/#/c/42623/23:42
fungiclarkb: i'll update the documentation for that momentarily23:42
jeblairfungi: nice catch23:42
jeblairalso, evil.23:43
jeblairi mean, maybe gerrit should just be implemented as a series of sql triggers while they're at it23:43
anteayaalexpilotti: great, 11 patches ahead of you right now, let's see what happens in 32 minutes23:43
fungijeblair: yes, gerrit really, really doesn't look like it needs on update set on any of its timestamp fields (and probably should use a more normal datatype for them anyway, but that's another ball of yarn)23:43
anteayathere is a chance you might make this one23:43
alexpilottianteaya: there shouldn't be rebase issues, I chained them for this purpose, but seeing them will be relieving :-)23:43
*** jhesketh has quit IRC23:44
anteayaalexpilotti: if you are asked to rebase now it would be due to the patches that have merged recently23:44
alexpilottias in seeing them in the tree, ahem23:44
anteayano way of knowing until you get a message on the patch23:44
alexpilottityep, that's the reason for the "relieving" part in the previous sentence23:44
anteayawell it will be relieveing that is for sure23:45
alexpilottilol23:45
*** nicedice has quit IRC23:45
*** ryanpetrello has quit IRC23:45
fungihowever, if zuul isn't going to be able to merge your change on top of the changes ahead of it, you'll find out pretty much right away because it won't leave it in the pipeline any more (as of recently)23:45
anteayawell that is good to know23:46
anteayayes sorry that was what we were talking about earlier today23:46
*** dims has joined #openstack-infra23:46
fungieven this morning after the restart when the gate pipeline was really huge, i reverified a change which wouldn't be able to merge and the gerrit change got a rejection from "jenkins" in less than a minute23:46
* anteaya shakes her head23:46
anteayahelpful23:47
clarkbfungi: looking at the changes merged graph after that point we merged a bunch of stuff but it has been slow since. I wonder if one of those things introduced more flakyness?23:47
clarkbfungi: also yay on gerrit db :/23:47
*** nicedice has joined #openstack-infra23:51

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