Tuesday, 2017-08-22

*** xinliang has quit IRC03:07
*** amoralej|off is now known as amoralej07:29
*** isaacb has joined #zuul07:49
*** tflink has quit IRC07:53
*** tflink_ has joined #zuul07:54
*** electrofelix has joined #zuul09:03
*** jkilpatr has quit IRC10:48
*** smyers has quit IRC10:53
*** eventingmonkey has quit IRC11:00
*** smyers has joined #zuul11:01
*** rcarrillocruz has quit IRC11:01
*** tobiash has quit IRC11:01
*** leifmadsen has quit IRC11:01
*** toabctl has quit IRC11:01
*** eventingmonkey has joined #zuul11:02
*** tobiash has joined #zuul11:03
*** toabctl has joined #zuul11:04
*** rcarrillocruz has joined #zuul11:06
*** leifmadsen has joined #zuul11:06
*** jkilpatr has joined #zuul11:07
*** olaph has quit IRC12:08
*** amoralej is now known as amoralej|lunch12:14
*** olaph has joined #zuul12:26
Shrewspabelanger: jeblair: is this enough to eliminate py2 for nodepool? https://review.openstack.org/492629  I'm not sure what version of python the coverage test uses, but I'm guessing py2? If so, not sure what to do about that one.13:19
leifmadsenjeblair: mordred: what is your availability like for a workshop on zuul v3 / github / bootstrap this week?13:22
leifmadsenCC Shrews13:22
*** tflink_ is now known as tflink13:29
*** dkranz has joined #zuul13:35
*** amoralej|lunch is now known as amoralej13:36
Shrewsleifmadsen: not sure how useful i'd be for that conversation, but thursday is likely the only day i have. you might want jlk for the github things13:59
leifmadsenShrews: all good, just keeping you in the loop in case you wanted to listen in13:59
leifmadsenI'll ping you once I get enough material to review and we can banter back and forth :)13:59
Shrewsyeah, i would like to13:59
Shrewstomorrow is the Ansible gathering that I know mordred is attending and i *might* partially attend14:00
jeblairleifmadsen: thurs or fri are good for me14:21
jeblairShrews: lgtm.  the coverage job should use the python specified in tox.ini i think.  so just changing that on the v3 branch should work i think.14:25
leifmadsenjeblair: Friday is best for me, maybe around 11am EDT? (or after lunch)14:25
leifmadsenjeblair: what is your timezone?14:29
jeblairleifmadsen: 11am edt wfm; i'm in pdt.14:29
leifmadsenah ok, just tried to schedule for 1pm EDT, and it says your working hours are 3am to 12pm :)14:30
leifmadsensent out, not sure we'll use the whole time, but I blocked it off just in case14:31
openstackgerritDavid Shrewsbury proposed openstack-infra/nodepool feature/zuulv3: Set base environment as python3  https://review.openstack.org/49625114:34
Shrewsugh, why is the14:39
Shrewsgate-dsvm-nodepool job running?14:39
Shrewsoh, i bet i needed to wait for puppet things14:40
*** isaacb has quit IRC14:48
jeblairmordred: devstack-gate has a playbooks/plugins/callback/devstack.py file.... i think that's going to cause problems for us the first time we try to use a playbook in playbooks ?16:00
SpamapS'morning zuulians16:18
SpamapSI've called playbooks with playbooks before.16:18
jlko/16:18
SpamapSBut maybe the zuul restrictions on playbooks will interfere?16:18
jeblairSpamapS: i mean there's a plugin, which we disallow in untrusted repos16:19
jlkAre we... New Zuulians?16:19
jlkslaying dragons and whatnot?16:19
jlkjeblair: hrm. Does that get called on the executor, or on the first node of the set?16:20
jeblairjlk: the current plugin?  it's used from command-line ansible in the devstack-gate project16:20
jeblairit is not related to zuulv3.  it will, i believe, prohibit us from running any zuulv3 playbooks out of that directory of the devstack-gate repo as long as it's there.16:21
jlkJust trying to map it in my head.16:22
jlkI think you're right.16:23
SpamapSjeblair: OOOOOOHHHHHHH16:26
mordredjeblair: we actually do not need that plugin once we've in v316:26
mordredjeblair: so let's move it to a different directory so it doesn't conflict16:26
mordredjeblair: we write out an ansible.cfg with paths in devstack-vm-gate-wrap.sh anyway, so it being adjacent to the playbooks dir is not necessary16:27
jeblairmordred: ya.  i'll put in a change to move it as part of my series16:27
jlk++16:29
pabelangeropenstack-infra related, but adds publish-openstack-python-branch-tarball job: https://review.openstack.org/494672/ would love some reviews16:29
jeblairmordred, jlk, SpamapS: oh, hrm, we actually only blacklist *_plugins directories.... maybe we don't need to change anything?16:32
jeblairie, playbooks/callback_plugins/foo would be bad, but playbooks/plugins/callback/foo (which is what's there) is okay?16:33
jlkso devstack-gate is already using a non-standard path, set by ansible.cfg in-repo?16:33
jlkIf ansible picks up that plugin without configuring the path, we need to update our blacklist routines :/16:34
jeblairjlk: correct, it writes an ansible.cfg16:34
jlkdoes the presence of an ansible.cfg file run afoul of our protections, should the playbook be ran from that directory?16:38
jlk(in v3)16:38
mordredit shouldn't - but also the ansible.cfg file shouldn't get written out by the v3 version of the job16:39
jlkah okay16:39
mordredthe only purpose of the ansible.cfg in that dir is to set up logging stuff appropriately - which we have already handled so yay!16:39
jlkAnything up for urgent review?16:48
jlketherpads are somewhat difficult to follow16:50
jeblairmordred, clarkb: i just found that most of the use of the local_conf jjb macro is actually to do this: enable_plugin {project-repo} git://git.openstack.org/{project-repo}16:53
jlkmordred: Is there anything I can help out on today / this morning?16:53
jeblairwhich of course, is not a key/value pair.  so i think we'll want a special 'enabled_plugins' zuul job variable or something similar16:54
jeblairthat may mean the devstack_localrc module i just wrote goes on the shelf for a while16:54
mordredjlk: I'd say one of two things - depending on which seems like a thing you can dive in to more readily ...16:55
mordredjlk: either helping with the devstack-gate -> ansible conversion, which might be fun because ansible but also might be opaque because devstack-gate16:56
mordredjlk: (that's the more important topic, but also the one that it's possible might be a brick wall)16:57
jlkbrick wall you say...16:58
jlkIs there an active checklist / punchlist for the devstack gate things? I can at least try one or two before giving up16:59
jlk(and do we have a good way of testing WIP?)16:59
mordredjlk: or, if that's too much infra-specific learning curve, getting the github driver webhook migrated to zuul-web is bound to be fun - it's definitely lower priority fun though16:59
jlkoh that thing. Zuul-web is live now?16:59
mordredjlk: https://etherpad.openstack.org/p/AIFz4wRKQm is the etherpad we made the other day in prep for devstack-gate conversion16:59
jlkokay I have that one open17:00
jlkand that TODO block is current?17:00
mordredjlk: I believe our idea for testing is to make a nice new job that first just emits the files we expect so we don't have to run devstack itself - and then work up the chain from there17:00
mordredlooking17:01
mordredjlk: I think so - although from digging in a little over the weekend I think we might need to revise that list as we wor17:03
mordredwork17:03
mordredjeblair: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/shade.yaml#n4 is an example of slightly more than that, should you need an example of more complex localrc usage17:03
mordredjeblair: it's worth noting that http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/shade.yaml#n39 then does some editing that obviously would be done differently if devstack_localrc existed17:04
jeblairmordred: yeah i saw that.  it's the only job in the entire system that does anything like that.  i suspect that job will just end up with its own playbook.17:09
jeblairor jobs, rather17:09
mordredjeblair: ah - ok. I'm fine making it be its own thing17:10
jeblairbut yeah, in general, the localconf stuff is unstructured enough that i think we just need to have the v3 version of it behave more or less like the v2 version.  i'll make a var so jobs can automatically splat some stuff into /tmp/dg-local.conf.17:11
mordredjeblair: may be worth checking in with AJaeger/sdague about plans - my understanding is that they were trying to get more people to use local_conf so that people would do less scripts setting env vars and whatnot17:11
mordredjeblair: cool17:11
jeblairmordred: i think that's what i just said?17:12
jeblairmordred: was that an irc lag issue?17:12
mordredyah17:12
jeblaircool17:12
*** electrofelix has quit IRC17:12
jeblairmordred, clarkb: the only issue i can see with this is that it is less amenable to inheritance.  so if you have a devstack-foo job which splats some localconf, and you inherit from it, you will need to duplicate the parent's localconf if you want to add your own localconf.17:13
mordredyah - I mean, I liked the localconf thing we sketched out - even if the shade jobs woudl be the only jobs using it17:14
mordredjeblair: perhaps we should just start out using what you wrote in shade and see how well it works, and if it's good we can point people to it as a way to do more complex stuff just with local.conf and with less env-var logic?17:15
jeblairmordred: the thing that is unique to the shade jobs is that they run sed on dg-local.conf17:15
jeblairmordred: the thing i wrote was when i thought local.conf was variables.  it's not; it's commands as well.17:16
mordredyah. that puts a big crimp in the idea17:16
SpamapScould we fix that in shade?17:16
SpamapSdo other projects do that?17:16
mordredjust shade17:16
mordredI guess I'm the only one who found copying 15 lines of localrc more distateful than three sed lines17:17
jeblairor the only one who didn't read the "private interface" line :)17:17
mordred:)17:17
mordredI mean - actually ... for shade, I could just skip local_conf and do a normal ansible template file with jinja for the logic to write out the local.conf file17:18
jeblairi toyed with the idea of converting the 'enable_service' command into a variable, but it can have 2, 3, or 4 arguments, and there's a 'disable_service' command too.  so the whole thing starts to look pretty procedural (because it is -- it's a bash script) and it gets harder and harder to think about it as variables.17:21
jeblairmordred: but maybe we can combine the approaches17:22
jeblairmaybe we can have a variable to "throw this blob into dg-local.conf", but also a "merge these variables through job inheritance and write them to dg-local.conf"17:22
jeblairand maybe we can even rethink enabling services -- if we can simplify or standardize the most common forms of the enable_service command, we might be able to do that as a boolean dict: services: {ceilometer-api: True}17:25
jeblairi think those may be best thought of as 3 layered approaches, with increasing complexity.  and maybe i should just focus on the first to facilitate the most straightforward devstack-gate conversion.17:27
openstackgerritAndreas Jaeger proposed openstack-infra/zuul master: Add link to Infra Manual  https://review.openstack.org/49632917:28
mordredjeblair: ++17:31
mordredjeblair: I think your suggestion is awesome - but since shade is the only current user that 'needs' it, and the current hack shade is doing is fine, we can defer that to post-ptg17:32
jeblairmordred: yeah; i suspect that will let us simplify a lot of other jobs, but yes, that's not something we'd plan on doing pre-ptg anyway.17:33
mordredpabelanger: heya - so - your twine patches inspired me in some ways and I wrote followup patches (which seemed to me to be the easiest way to discuss the thoughts I had instead of review comments)17:33
mordredjeblair: ++17:33
mordredpabelanger: I shall now push them up - but feel free to tell me I'm dumb/wrong/a-bad-person or whatnot17:34
jeblair17:34 < openstackgerrit> James E. Blair proposed openstack-infra/devstack-gate master: Zuul v3: add a simple devstack job  https://review.openstack.org/49633017:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename upload-twine to upload-pypi  https://review.openstack.org/49633117:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack python tarball creation job  https://review.openstack.org/49633217:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633317:35
jeblairdevstack-lxc                              ERROR No valid playbook found17:37
jeblairthat was helpful! ^ :)17:37
mordredjeblair: yay!17:37
mordredpabelanger, jeblair: https://review.openstack.org/#/q/topic:upload-python includes pabelanger and my changes - I put up the two 'Add non-OpenStack' patches to show how I thought the abstraction could be used17:38
jlkokay I'm looking at one of the TODO items ont eh devstack-gate list, add-sshkey-to-root role, which I think is creating an SSH key on each node in the set for the root user, and distributing it around.17:40
jlkand setting known_hosts accordingly17:40
jlkDoes that match other people's understandings?17:40
jlkalthough looking at the setup_ssh function, it seems to be using a singluar /etc/nodepool/id_rsa.pub file. So maybe I'm wrong? Is this using just a single ssh key file?17:41
jeblairjlk: look at SpamapS's work, i think he may have found that the known_hosts bit should happen in that role.  and you should be able to re-use the key we're using to log in as the zuul user too (it doesn't need to be a different key for root afaik)17:42
mordredjlk: SpamapS has most of that one done although it needs review17:42
mordredwhat jeblair said17:42
mordreddo we actually do keys for root?17:42
jlkyeah I reviewed it, but it seemed to be a different work item17:43
jeblairSpamapS's task was the add the private keys for zuul on all hosts, jlk's as add keys for root17:43
jeblairmordred: for nova migration17:43
SpamapSI am not 100% sure of the actual role and playbook I did that in btw.17:43
jlkoh this is for nova?17:43
jlkahhh17:43
mordredah - gotcha.17:43
SpamapSFeels very broad in scope..17:43
mordredso - overall we have 2 different needs:17:44
SpamapSBut at the same time, I kind of like having that as a basic assumption if you're using zuul-jobs17:44
SpamapS"all your nodes start out being able to SSH to each other"17:44
jeblairSpamapS: yes, i think having the private key on all hosts is universally applicable17:44
mordred- users need to be able to ssh between test nodes as zuul17:44
mordred- users need to be able to ssh between test nodes as root17:44
jlkif it's for nova, then yeah, each node needs a private key and each other node needs to accept that private key17:44
SpamapSok so I just needed encouragement that there was already agreement on that :)17:44
jlkmordred: I'd challenge that second one, not - users, instead - nova17:44
mordredyah. there needs to be the ability a job can opt-in to to have a user be able to ssh to other nodes as root17:45
jlkSpamapS: so your change takes a single build private key and puts it as zuul's private key?17:45
SpamapSjlk: it does17:45
SpamapSthey all end up with the same key17:45
SpamapSwhich is specific to the build17:45
jlkis there any reason do not expand that to do it as root too?17:45
SpamapSwhich I think is a nice feature... single use key for all17:45
jlkor nova? What user is nova going to be running as in devstack?17:46
mordredstack?17:46
SpamapSjlk: no I think adding it to root is a good iea17:46
SpamapSidea17:46
SpamapSI also wonder about using /etc/ssh/known_hosts instead of ~/.ssh/known_hosts17:46
jlkAt blue box we ran as the "nova" user, and thus I made: https://github.com/blueboxgroup/ursula/blob/master/roles/nova-data/tasks/ssh.yml17:46
mordredoh - that might be nice for this17:46
SpamapSCan't see any problem with making all the other test nodes part of the global known_hosts.17:46
* SpamapS is reminded that there is feedback on the ssh key type PR/bug that needs responding17:47
mordredSpamapS: we could then always populate /etc/ssh/known_hosts in base - but make "authorize connection to user" a role people use on demand17:47
SpamapSmordred: right17:47
SpamapSAlso, consider that the other thing we might want to do is just set StricHostKeyChecking to "no"17:48
SpamapSwas that considered?17:48
mordredso in a the devstack-gate base job we could have "- {'role': 'authorize-ssh-connection', 'user': 'zuul'}\n- {'role': 'authorize-ssh-connection', 'user': 'root'}"17:49
SpamapSmight cause issues for jobs that want to ssh to places safely I suppose17:49
mordredSpamapS: well - we HAVE the host keys, so if we set them, maybe it catches things attempting to connect to the wrong thing?17:49
SpamapSyeah17:49
SpamapSn/m on that17:49
SpamapSjust recoiling in horror at the ansible module I wrote ;)17:49
SpamapSOh also, modules don't automatically get fed hostvars right?17:50
* SpamapS just realized he assumed that17:50
jlkargh, wtf.17:51
jlkIn ursula, we're dealing with both "nova" user ssh things, and root (because of libvirt)17:51
jlkI think I remember some of that, nova does some things with ssh directly, and libvirt does some as well17:51
jlk(if libvirt is configured to use ssh to connect to other remote libvirts).17:51
jlkHow is it configured in devstack?17:52
clarkbnova itself doesn't iirc, its just libvirt17:52
clarkband it ssh's as root in devstack setups17:52
jlkare you sure about that? I thought nova did to transport images17:52
clarkbjlk: thats all http to glance17:52
jlkone sec17:52
clarkbin devstack-gate we set up /etc/hosts for dns resolution because libvirt uses hostnames adn then also add the nodes to known_hosts and add the ssh key to the root user authorized keys17:53
openstackgerritClint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Install build private key too  https://review.openstack.org/49430217:53
openstackgerritClint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add known_hosts generation for multiple nodes  https://review.openstack.org/49470017:53
* SpamapS rebased17:53
clarkband yes the user all openstack services run under in devstack is 'stack'17:54
clarkbwe don't set up ssh things for stack, just root17:54
jlkdammit I know there was a reason nova was sshing as nova17:56
jlkhttps://docs.openstack.org/nova/latest/admin/ssh-configuration.html is still live17:56
clarkbI think that may be if you want libvirt to talk as the nova user17:57
clarkbbut the default is root iirc17:57
jlkno it's the resize code path instead of the migration code path. It's a different thing I think. Digging more17:58
clarkbwe test both with tempest and there is no nova user17:58
clarkbhttps://docs.openstack.org/nova/latest/admin/configuring-migrations.html#kvm-libvirt18:00
jlkagain that's live migration, different from resize.18:01
clarkbright but we test both is what I'm saying and only use the live migration libvirt config18:01
clarkbmakes me wonder if that is just stale docs18:01
clarkbsince a resize is performed as a libvirt migration aiui18:01
* clarkb asks nova channel18:02
jlkhttps://docs.openstack.org/ocata/config-reference/compute/resize.html18:02
jlk(for some reason the pike doc set is missing nova)18:02
jlkAt least in newton era nova was sshing as itself over to other compute hosts18:03
jlkand it used the address from the service record18:03
clarkbya the address from the service record is also what libvirt uses so we need the /etc/hosts stuff either way. I haev asked nova channel for clarification on the nova user stuff18:04
dmsimardI have some time set aside to help upstream/infra for the foreseeable future, I hear v3 migration is where help is needed most. Do we have a list of todos ?18:08
clarkbdmsimard: https://etherpad.openstack.org/p/AIFz4wRKQm has a big list related to the devstack-gate items18:09
dmsimardclarkb: okay, I'll look if there's anything in there I can work on, thanks.18:10
clarkbjlk: ok based on mriedems email I have learned things. https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate.sh#n181 line 182 there is stealth mode setup for the stack user. Then 183 we set up the root user, and its the root user that we may not actually use but looks like mriedem wants to invert things so probably best to set up both for time being?18:10
clarkbwe may want to rewrite that as setup_ssh ~stack/.ssh18:11
dmsimardI can probably hack on "split devstack-vm-gate-wrap into two main parts", anyone working on that right now ?18:12
dmsimardok, putting my name on there.18:15
jeblairthe multinode role needs to be finished as well: https://review.openstack.org/#/c/435933/18:20
dmsimardclarkb: where does the bindep for devstack/devstack-gate live ?18:25
dmsimardOr is it assumed that the necessary things are embedded through nodepool elements instead ?18:25
clarkbdmsimard: we don't really bindep in them. There are a handful of things we install but most are installed into a virtualenv iirc. Then devstack has its own package listing system that does the rest18:25
clarkbthe idea is that the two tools bootstrap themselves off a fairly minimal base image18:26
clarkbthere has been talk of converting devstack to using bindep for its package listing and installing but that hasn't happened yet as far as I know18:26
clarkbbut that way instead of listing all the things noav needs for example it can just install what nova's bindep file says it needs18:26
dmsimardclarkb: ah, looks like http://git.openstack.org/cgit/openstack-dev/devstack/tree/files/rpms/general for example18:27
*** amoralej is now known as amoralej|off18:27
clarkbya18:27
dmsimardto put myself into perspective, the installation of those packages occurs *after* devstack-gate has run, correct ?18:28
mordredyah - devstack-gate's job is mostly just to prepare for a devstack run and then to run devstack18:29
dmsimardright, okay, thanks18:29
jlkclarkb: that call to $BASE/new/.ssh is confusing. What is $BASE? Is this where it's setting things up for the stack user?18:32
clarkbjlk: $BASE/new is the stack user's home dir18:33
clarkband $BASE is the base location for devstack-gate filesystem writing18:33
clarkbwhcih is why making it setup_ssh ~stack/.ssh would be clearer18:34
jlkgotcha.18:34
jlkSo it sounds like we need to build on SpamapS's role, which appears to be doing everything as the zuul user, we'll want to duplicate those ssh keys and such for a set of users. root and "stack" to start with.18:35
jlkeither build on it, or add an adjacent role that runs after his18:36
SpamapSCould we do the same role, but with "become" set?18:36
clarkbor user argument, since you may want to run as root in all cases (to update /etc/hosts if necessary?)18:37
jlkhrm.18:37
jlkso if we change his role to adjust /etc/ssh instead of ~/.ssh for things like known_hosts, then all the subsequent role would need to do is distribute authorized_keys and priv/pub keys to the appropriate users18:38
jlkoh his role doesn't touch known_hosts does it18:39
jlkbut yeah I think we want it all to be done as the root user, just setting ownership on the files where appropriate18:40
* jlk afk for lunch and such18:42
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633318:49
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack python tarball creation job  https://review.openstack.org/49633218:49
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename upload-twine to upload-pypi  https://review.openstack.org/49633118:49
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename tox/tarball-post to python/tarball-post  https://review.openstack.org/49636418:49
dmsimardmordred: ah, bummer, you were already working on splitting the ansible stuff out of devstack-gate wrap ? Your name wasn't on the pad so I started looking at it. I'll review your stuff18:49
pabelangermordred: sure, looking at the patches now19:04
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename tox/tarball-post to python/tarball-post  https://review.openstack.org/49636419:07
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633319:07
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack python tarball creation job  https://review.openstack.org/49633219:07
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename upload-twine to upload-pypi  https://review.openstack.org/49633119:07
mordreddmsimard: my stuff may be completely bong - feel free to ignore it19:09
mordreddmsimard: that was more me exploring/noodling19:09
mordredpabelanger: (sorry, just did one last update)19:09
dmsimardmordred: you're okay if I pick it up ?19:10
dmsimardI planned on cleaning some stuff and then doing the split afterwards19:10
dmsimardSo worst case there's bound to be a good amount of merge conflicts19:11
pabelangermordred: ack19:11
mordreddmsimard: please do!19:12
mordreddmsimard: and please bring any sanity to that you can :)19:12
dmsimardmordred: ack19:12
mordredjeblair: remind me again ... are playbooks defined in one repo available to jobs in a different repo?19:13
mordredjeblair: actually -nevermind19:13
jlkso playbook locations19:16
jlkthis role setting up ssh users, that's done in a base/pre.yaml job. The thing to make nova/libvirt work will be done as part of the devstack playbook, right? It can assume that base/pre.yaml has been completed?19:16
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Split ensuring tox is installed into a role  https://review.openstack.org/49637519:19
mordredjlk: yes. base/pre will run before anything else19:21
jlkokay I'm going to make this a separate role, since not everything in zuul-job may want the keys spread around like this19:22
pabelangerjeblair: mordred: http://zuulv3-dev.openstack.org/logs/sandbox/ publish-openstack-python-branch-tarball worked!19:23
mordredpabelanger: woot!19:24
pabelangerthat was run from post pipeline19:24
mordredjlk: ++19:28
mordredpabelanger: that's super exciting19:29
openstackgerritPaul Belanger proposed openstack-infra/zuul feature/zuulv3: Add publish-openstack-python-branch-tarball post job  https://review.openstack.org/49638019:30
pabelangermordred: ya, I'll propose an update to switch to using tarballs.o.o too19:30
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename tox/tarball-post to python/tarball-post  https://review.openstack.org/49636419:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633319:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack python tarball creation job  https://review.openstack.org/49633219:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename upload-twine to upload-pypi  https://review.openstack.org/49633119:35
mordredpabelanger: woot19:35
mordredpabelanger: also - linter job actually helped :)19:35
pabelanger:)19:35
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633319:37
mordredpabelanger: do we have anything consuming tox-tarball atm?19:41
mordredpabelanger: I don't see anything19:41
pabelangermordred: no, I think we agreed to delete it?19:42
jeblairdmsimard, mordred, jlk: if you propose any patches to devstack-gate, would you mind setting the topic to zuulv3 ?  (devstack-gate has something like 90 open changes)19:44
jlkokay19:44
mordredjeblair: ++19:44
dmsimardjeblair: will do19:44
mordredpabelanger: yah - although if someone wants a build tarball job in their gate - should we put a build-openstack-tarball in openstack-zuul-jobs using the roles we've got?19:44
pabelangermordred: ya, that might make sense19:46
jeblairdmsimard: i notice your changs look like they are heading in the direction of updating the current v2 usage -- in our etherpad brainstorming, we agreed it would be better to go ahead and cut ties with the v2 jobs.  we're close enough to the cutover that we can just fork/copy the things we need and generally leave v2 alone.  (we may need to make some changes, such as splitting out parts of shell scripts, but we should keep those minimal)19:46
jeblair(it takes a really long time to land changes to devstack-gate)19:47
jlkwhat's a good hostgroup to loop over to get all the nodes of a set?19:48
jeblairjlk: 'all'?19:49
jlkWe're not explicitly inserting localhost into the inventory are we?19:49
dmsimardjeblair: I was taking an approach to iteratively clean up what was there right now and then split things off which mordred started in https://review.openstack.org/#/c/495927/19:49
jeblairjlk: correct, we're not (partially to avoid that problem)19:50
jlkcool19:50
dmsimardjeblair: This also gives me the opportunity to learn how things work since I'm admittedly not that familiar with devstack/devstack gate19:50
dmsimardjeblair: I'd like to take the split off of mordred's hands so he can work on other stuff since I have some time to invest and help19:50
jeblairdmsimard: thanks.  i'd suggest keeping changes to the running system to a minimum.  i don't see why we should upgrade ansible or move the devstack-gate ansible configuration around.19:51
dmsimardfair19:53
jeblairdmsimard: (we're not going to be running ansible inside of devstack-gate any more, so that's all dead code)19:53
dmsimardjeblair: do we have a "picture" of what we'd like things to look like on v3 ? perhaps that's what I'm missing19:54
dmsimardlike, are we moving the devstack-gate roles out of devstack-gate for example ?19:54
*** jkilpatr has quit IRC19:55
jeblairdmsimard: closest thing is in the etherpad.19:55
dmsimardjeblair: this one ? https://etherpad.openstack.org/p/AIFz4wRKQm19:56
jeblairdmsimard: yep19:56
dmsimardokay.19:56
jeblairdmsimard: the thing you're working on came from mordred's head, so maybe he can flesh it out a bit more19:56
jeblairwe're still lacking the overlay network role, which is a well-defined task if anyone wants to finish that up:  https://review.openstack.org/#/c/435933/19:57
mordredjeblair, dmsimard: that was mostly me thinking about ways to make small changes to existing d-g so that we could write new v3 d-g jobs that potentially called some of the same shell scripts - but it's much  more likely that the whole chunk of that from my brain should be ignored19:58
jeblairmordred: yeah.  i get the idea.  i suspect we will have to do some of that.  i don't personally know yet what would be useful.20:00
jeblairi'm starting to suspect that a lot of the localrc stuff will be.20:00
jeblairbut i can only see as far as i've started working.  :)20:00
mordredyah20:03
mordredpabelanger: fwiw - when we have a role in a repo (like zuul-jobs) but no playbook in that repo that uses it, our ansible lint checks don't actually check anything so far20:05
mordredpabelanger: we may want to consider adding some test playbooks just to get the linting checks for some of them20:06
pabelangermordred: yes! I think I'm going to write a zuulv3 ansible-lint job which runs across all 4 repos20:06
mordredI am noticing this because I added a job to zuul-jobs that uses a role that was defined a few commits before, and the linter doesn't pick up the issues until the patch with the job20:06
mordredpabelanger: ++20:06
pabelangerbecause we have 1 way testing in some cases20:06
mordredyup20:06
pabelangerI hope to get to that once publishing works today20:07
mordredpabelanger: other than things where I'm still fixing it actually working - you ok with my followons to your patches?20:07
pabelangermordred: ya, so far looks good. I should un WIP the base. Or you can20:07
mordredcool - I'll squash those real quick20:07
pabelangergreat20:08
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Rename tox/tarball-post to python/tarball-post  https://review.openstack.org/49636420:10
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633320:10
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add non-OpenStack python tarball creation job  https://review.openstack.org/49633220:10
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add upload-pypi role  https://review.openstack.org/49597220:10
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Remove tox-tarball job  https://review.openstack.org/49639520:10
jlkare there zuul inventory variables for node ssh hostkeys?20:13
pabelangerno, but ansible provides them via facts20:13
jlkI was looking for that variable but wasn't succeeding what's the fact variable?20:14
pabelanger~/.ssh/known_hosts on executor will have them also20:14
pabelangeransible_ssh_host_key_rsa_public for example20:15
pabelangerhttp://logs.openstack.org/89/489689/18/check/tox-pep8/bfa7f32/zuul-info/host-info.ubuntu-xenial.yaml20:15
jlkhost_keys20:15
*** jkilpatr has joined #zuul20:15
pabelangersorry, not following20:16
jlkAh I was looking at the zuul code that populates known_hosts file, it grabs node['host_keys']20:16
jlkugh, the fact isn't in a direct format that the known_hosts module uses.20:17
jlkthe value of the fact is the key without the type info20:17
mordredjlk: SpamapS wrote some pyhton for this that might be helpful20:17
mordredjlk: https://review.openstack.org/#/c/494700/20:17
jlkah that's exactly what I need, and I don't have to write it into my role20:18
jlkJust need to get this review merged20:18
mordred\o/20:19
mordredpabelanger, jeblair, jlk: https://review.openstack.org/#/q/status:open+topic:upload-python is ready for review20:21
jeblairmordred: all lgtm20:26
dmsimardjeblair: I've dropped the ansible.cfg directory review, can we compromise on the other 3 to unpin paramiko, update ansible and centralize config options in ansible.cfg ? I can squash them if necessary. Just feels like a low hanging fruit worth doing :)20:27
dmsimardansible and paramiko have passed check gate already20:28
dmsimardUpdating ansible seemed worthwhile (and taking out the paramiko pin) as zuul uses ansible>=2.3.0.0 unless mistaken20:29
mordreddmsimard: first two look fine to me- the third one increased forks from 5 to 2520:30
dmsimardmordred: right, I can take that out entirely.. ansible defaults forks to 5 so I figured the intention was to raise it20:31
jeblairdmsimard: i'm sorry, i can't review that.20:31
jeblairdmsimard: if we succeed, that code has 3 weeks of life left.20:32
jlkWhat is our current strategy with variable naming for in-role variables?20:32
jlklike an option passed to the role?20:32
mordredjlk: I've been trying to prefix them with something sensible20:32
jeblairjlk: try to have a name that's unique to the role.. ya ^20:32
dmsimardjeblair: it makes the devstack-gate roles and playbooks run with the same version of ansible zuul is running, we're otherwise exposing ourselves to regressions we could have otherwise caught IMO20:33
jeblairlike i'm using "devstack_foo" on the stuff i'm writing20:33
jeblairdmsimard: we've moved almost all the interesting playbooks out of devstack-gate already20:33
jeblairmost of the host setup stuff is now in the base job20:34
dmsimard¯\_(ツ)_/¯20:36
openstackgerritMerged openstack-infra/zuul-jobs master: Add upload-pypi role  https://review.openstack.org/49597220:37
openstackgerritMerged openstack-infra/zuul-jobs master: Rename tox/tarball-post to python/tarball-post  https://review.openstack.org/49636420:37
openstackgerritMerged openstack-infra/zuul-jobs master: Add non-OpenStack python tarball creation job  https://review.openstack.org/49633220:37
openstackgerritMerged openstack-infra/zuul-jobs master: Add non-OpenStack PyPI upload job  https://review.openstack.org/49633320:38
openstackgerritMerged openstack-infra/zuul-jobs master: Remove tox-tarball job  https://review.openstack.org/49639520:38
pabelangerdo we know why webstream is not working?20:39
pabelangerfollow up question, could somebody with HTML skills add a URL for finger:// too?20:40
pabelangerblam! http://tarballs.openstack.org/sandbox/20:40
pabelangernew tar.gz and .whl uploaded20:40
mordredpabelanger: oh - we need to restart ze01 now that hostname is set properly20:40
pabelangermordred: okay, cool. I can look into that in a moment20:41
jeblairdmsimard: unless mordred can articulate a concrete split task, i think the most useful thing to work on would be to finish the overlay network role:  https://review.openstack.org/#/c/435933/20:42
pabelangerjeblair: mordred: publish-openstack-python-branch-tarball comlpete!20:42
pabelangerlooking at twine stuff now20:42
dmsimardjeblair: I'll have a look20:43
pabelangermordred: jeblair: https://review.openstack.org/496380/ could use a +3 to start publishing branch tarballs for zuul20:43
mordredpabelanger, jeblair: could y'all look at https://review.openstack.org/#/c/496375/ real quick? - I've got a couple other jobs thatuse it20:44
pabelangerlooking20:44
pabelangermordred: So, +2, but I'd really like to bikeshed more about that maybe at PTG. I have some existing roles that do the same, and could be good to standardize them20:45
mordredpabelanger: ++20:45
pabelangermordred: okay, going to start looking at twine role for openstack-dev/sandbox20:46
pabelangerstart testing with testpypi20:46
mordredpabelanger: you should just need a job and secret, right?20:46
pabelangermordred: and release pipeline for tagging20:47
mordredpabelanger: like, add release-openstack-python to openstack-dev/sandbox to release pipeline20:47
mordredcool20:47
pabelanger++20:47
openstackgerritMerged openstack-infra/zuul-jobs master: Split ensuring tox is installed into a role  https://review.openstack.org/49637520:47
openstackgerritJesse Keating proposed openstack-infra/zuul-jobs master: Role to copy the build ssh key to other users  https://review.openstack.org/49641320:51
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add publish-openstack-python-branch-tarball post job  https://review.openstack.org/49638020:52
openstackgerritMonty Taylor proposed openstack-infra/zuul feature/zuulv3: Add build-openstack-python-tarball to check and gate  https://review.openstack.org/49641620:53
mordredpabelanger: that ^^ should exercise the build tarball job too20:54
*** dkranz has quit IRC20:54
jlkFinally taking my lunch break. Will review things after.20:55
pabelangermordred: good idea20:55
openstackgerritClint 'SpamapS' Byrum proposed openstack-infra/zuul-jobs master: Add known_hosts generation for multiple nodes  https://review.openstack.org/49470020:56
SpamapSjlk:  ^linters fixed20:56
pabelangercool, zuul-feature-zuulv3.whl http://tarballs.openstack.org/zuul/20:57
mordredpabelanger: woot20:57
pabelangermordred: so, we need to reboot whole server or just a service on ze01?20:58
mordredpabelanger: just the service- the hostname is already correct20:58
mordredpabelanger: the problem is that the last time ze01 started it thought its hostname was just ze01 - so that's what it's adding to the links it sends to the scheduler20:59
pabelangerk21:00
mordredjeblair, pabelanger: three more https://review.openstack.org/#/q/topic:upload-python+status:open and then the current set is in and landed and we'll just be missing pabelanger's upcoming testpypi job on sandbox21:10
pabelanger+221:11
pabelangerze01 has also been restarted21:11
mordredoh - and gpg signing21:11
pabelangerYa21:11
ShrewsSo, if we were to add the finger gateway to zuul-web (where we have most of the code to handle that already), that would imply that for that to work, zuul-web would need to be accessible to the users (not firewalled off). And it would also have to be started as root (to grab the finger port) and drop privileges. Would those changes be acceptable? Or should we plan to have a separate executable for that?21:11
mordredShrews: we could probably just do a separate binary but use the same consume-remote-finger-stream code that's in zuul-web to avoid the root/drop-privs for zuul-web ... but also I do think we would prefer zuul-web to not be firewalled off from folks21:13
mordredjeblair: ^^ thoughts?21:13
jeblairmordred, Shrews: yeah that's the way i'm leaning too.21:13
Shrewsthat was my inclination as well. i could probably pound out the code for that before ptg, if we want it21:14
clarkbpeople have already built third party job tracking and info gathering tools around the existing simple zuul api. ++ to not firewalling it off21:14
jeblairthey are likely on different scale-out axes21:14
mordredpabelanger: you want me to take gpg signing and you do the testpypi bits? also - we do not seem to be currently signing the tarballs we upload to tarballs.o.o21:14
pabelangermordred: sure. Ya, I think we should start signing them to tarballs.o.o too21:15
mordredoh -nevermind - I see the sigs now21:15
jeblairis there an ansible variable that roughly corresponds to 'name of current host' ?21:15
mordredinventory_hostname21:16
jeblairmordred: thanks21:16
SpamapSNote that that specifically is the hostname you gave in inventory. It is not the one that `hostname` returns.21:18
SpamapSansible_hostname is that21:19
SpamapS(if you've collected facts)21:19
jeblairSpamapS: thanks -- the one in the inventory is the one i want (i'm putting the logs into directories named as in the inventory)21:20
jeblair(i expect we'll need to make some changes to the log processor to account for that)21:21
pabelangerjeblair: did you want to look at https://review.openstack.org/495973 adds upload-pypi role to our release-openstack-python21:23
jeblairpabelanger: lgtm, +221:24
pabelangerthanks21:24
jeblairpabelanger, mordred, dmsimard: can you look at the diff between patchsets 3 and 4 on 496412 ?21:32
jeblairthe output from ps3 was http://logs.openstack.org/12/496412/3/check/devstack-lxc/b9e9cbc/job-output.txt.gz21:32
jeblairwhich made me think i needed to add ".path"21:32
jeblairi was patterning that off of https://review.openstack.org/495972 -- does it need a similar fix (assuming that is correct)?21:33
* dmsimard looksa21:34
jeblairalso, we've broken log uploads: 2017-08-22 21:34:32,212 DEBUG zuul.AnsibleJob: [build: 2b330c84dd04497bad8c5fa9bbb1855e] Ansible output: b"Can't mkdir /var/lib/zuul/builds/2b330c84dd04497bad8c5fa9bbb1855e/ansible/post_playbook_2/secrets: Read-only file system"21:35
pabelangerHmm, I did just restart ze0121:36
jeblairi'll turn on verbose and keep21:37
dmsimardjeblair: added a comment in 49641221:37
dmsimardlooking at 49597221:38
dmsimardyeah I'm not sure 495972 would work, it's passing off the entire dict21:40
jeblairwow, even with -vvv there's nothing more than 2017-08-22 21:41:35,467 DEBUG zuul.AnsibleJob: [build: 018219a924dd47398896d3801258f923] Ansible output: b"Can't mkdir /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1/secrets: Read-only file system"21:41
jeblairi have no idea why ansible is trying to mkdir there21:42
mordredjeblair: I also do not understand why it's trying to mkdir there21:45
mordredjeblair: that's the first time we restarted ze01 since landing the secrets naming patch - maybe there was an executor-side bug in that?21:46
mordred(although that would certainly e weird)21:46
dmsimardhttps://github.com/openstack-infra/zuul/commit/d6a71ca2b45b56d28f0518d67564f973805e0b34 landed recently enough21:47
jeblairdmsimard: yeah, that's why it's failing to write there; though i don't know why it's attempting to write there21:47
jeblairzuul-bwrap seems broken as well on ze01: Can't find source path None: No such file or directory21:50
jeblairthat doesn't happen for me locally21:50
mordredjeblair: I cannot see anywhere in the new code that should cause that mkdir21:51
jeblairmordred: well that's ansible trying to mkdir21:51
mordredright21:51
jeblairi really want to strace it, but i can't without zuul-bwrap21:52
jeblairah that's the auth sock21:58
mordredah. that makes sense why it works locally but not there :)21:59
jeblairyeah, if i start ssh-agent it works22:00
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add role to GPG sign artifacts in a directory  https://review.openstack.org/49642622:02
mordredjeblair: (btw, I'm assuming you're looking at the ze01 issue so I'm not poking at anything, please let me know if you want another set of eyes)22:05
jeblairwill do22:06
dmsimardI'm trying to look too, trying to figure out where it's from :(22:06
mordreddmsimard: unfortunately this is an error you have to be root to see22:06
mordreddmsimard: (when the logging system breaks...)22:07
dmsimardmordred: oh, yeah, ofc .. but looking at the recent commits and keeping an eye out if I see something wrong22:09
dmsimardit's also a way for me to familiarize with the code base :p22:09
mordreddmsimard: ++22:12
jeblairit doesn't seem to behave the same way22:18
jeblairit's acturally trying to ssh22:18
jeblairin production, it immediately errors22:18
mordredjeblair: that's exceptionally yuck22:19
jeblairi'm open to suggestions.22:20
jeblairbasically, ansible is emitting an error and i have no idea where it's coming from.22:21
dmsimardtrace AnsibleJob and go step by step? :/22:21
dmsimardas in, insert a pdb.set_trace22:21
mordredjeblair: in the log, it looks like it's happening in /var/lib/zuul/builds/30ff4836f886475cbbbe5bd0d87ceca2/trusted/project_0/git.openstack.org/openstack-infra/project-config/playbooks/base/post-ssh.yaml right?22:21
jeblairmordred: yep22:22
pabelangerYum, I think I see a security issue22:22
jeblairdmsimard: the error is emitted by the ansible-playbook process22:22
pabelangershould I talk here or PM?22:22
pabelangerjeblair: mordred ^22:23
jeblairpabelanger: if it's exploitable, pm might be best.  if it's "stop debug logging the gearman job arguments" we're probably okay to talk about it here.22:23
dmsimardpabelanger: believe all hands are on fixing the broken executor right now :p22:23
mordredjeblair: I'm poking a smidge22:24
pabelangerokay, I just PM'd jeblair22:24
jeblairpabelanger: you need to be authenticated to nickserv to pm me22:24
pabelangerah22:25
pabelanger1 sec22:25
*** pabelanger has quit IRC22:25
*** pabelanger has joined #zuul22:25
mordredjeblair: look in  /var/lib/zuul/builds/30ff4836f886475cbbbe5bd0d87ceca2/work/logs/job-output.txt22:25
jeblairmordred: that's confusing22:26
mordredjeblair: yah - that's not the same error I see in the zuul log22:26
jeblairmordred: that's probably an error that happened before the error in the log22:28
jeblairmordred: since that looks related to unittest post playbook rather than base job ssh post playbook22:28
jeblairor post-logs or whatever it was22:28
mordredyah22:28
pabelangerk, just to confirm we are trying to debug the read-only files system error right?22:29
mordredyah. which may or may not be a read-only file system error :)22:30
pabelangerk, I see --tmpfs /var/lib/zuul/builds/8a68a873fc004d99936f5b35622cf349/ansible/post_playbook_2/secrets22:31
pabelangerbut I don't actually see use creating the secrets folder anyplace22:31
jeblairi wonder if the error is coming from bwrap22:31
pabelangerI think we need to ensure the folder exists first before having bwrap us it22:32
mordredjeblair: oh - right. because "Ansible output" is just us reporting stdout22:32
mordredfrom the execution22:32
jeblairright, and the bwrap command would be included in that22:32
mordredyah22:32
jeblairso of course my zuul-bwrap command would be wrong22:32
jeblairlemme retry that22:32
dmsimardmordred: bingo, that's a bubblewrap exception https://github.com/projectatomic/bubblewrap/blob/5276f816eacc1dc655833d5603556ed64c9d48c5/bubblewrap.c#L97822:33
dmsimardnot an ansible exception22:33
mordredthat definitely looks like that error22:33
jeblairit's possible that the tests of the new tmpfs stuff only overlaid a secrets over a rwbind, and this is the first time we've overlaid them on a ro bind22:33
mordredso - bubblewrap will make a dir to mount a tmpfs on if the dir doesn't exist- but it can't here22:34
mordredjeblair: ++22:34
pabelangermordred: ya22:34
pabelangerokay, going to look at gearman debug thing22:35
jeblairhrm, i'm still no able to reproduce with  zuul-bwrap --ro-paths=/var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1 --secret=/var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1/secrets/secrets.yaml=foo:bar  /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ /bin/bash22:39
mordredpabelanger: I'm gonna go ahead and add the test job to sandbox to do pypi release22:39
jeblairthat results in: --ro-bind /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1 /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1 --tmpfs /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1/secrets --file 5 /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1/secrets/secrets.yaml22:39
pabelangermordred: https://review.openstack.org/496421/22:40
jeblairwhich should be file on tmpfs on ro filesystem22:40
mordredjeblair: root@ze01:~# ls /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1/secrets/22:41
mordredjeblair: shows nothing22:41
jeblairmordred: right -- the content is only there inside the bwrap22:41
mordredjeblair: is it possible /var/lib/zuul/builds/018219a924dd47398896d3801258f923/ansible/post_playbook_1/secrets/ got created in one of the previous invocations?22:41
mordredlike- maybe let's try deleting the secrets dir and making sure that the behavior is the same?22:42
mordredpabelanger: oh neat22:43
jeblairmordred: ah yeah, that may be experimental error22:43
jeblairmordred: so we probably need to create the mountpoint in the executor22:44
mordredjeblair: ++22:45
pabelanger++22:45
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Create secrets dir in bwrap  https://review.openstack.org/49643222:46
jeblairmordred, dmsimard, pabelanger: ^  i'm running the full test suite locally on that since we may need to force-merge it22:47
mordredjeblair: kk22:47
mordredjeblair: I'm ok force-merging that22:47
pabelangerjeblair: mordred: left quick question22:48
jeblair  py35: commands succeeded22:49
jeblair  congratulations :)22:49
mordredjeblair: woot22:49
jeblairit also passed pep822:49
jeblairpabelanger: replied22:50
mordredjeblair: ok. I'm gonna force-merge22:51
pabelanger++22:51
jeblairmordred: thanks22:51
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Create secrets dir in bwrap  https://review.openstack.org/49643222:52
mordredpabelanger: ok - I +A'd the sandbox change22:57
mordredjeblair: sandbox change uploaded logs - so that fixed it22:57
pabelangermordred: great!22:57
mordredpabelanger: I have https://review.openstack.org/#/c/496428 and https://review.openstack.org/#/c/496426/ for your reading pleasure22:58
jeblairmordred, pabelanger: did both of you see my conversation with dmsimard earlier about item.path?22:59
mordrednope!22:59
* mordred goes to look23:00
pabelangerlooking for it now23:00
jeblair21:32 < jeblair> pabelanger, mordred, dmsimard: can you look at the diff between patchsets 3 and 4 on 496412 ?23:00
jeblairstarts there ^23:00
mordredoh! oy23:01
jeblairmordred, pabelanger: one of you on fixing that?23:02
mordredI'm on it23:02
pabelangerokay, still trying to understand :)23:03
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add role to GPG sign artifacts in a directory  https://review.openstack.org/49642623:03
mordredpabelanger: I made bad patches23:03
jeblairpabelanger: the upload role needs to use item.path, not just item, because item is a dictionary when you use the results from find23:03
pabelangerokay, ya. I see the issue now23:03
pabelangerjeblair: yes, that is correct23:03
mordredgah23:04
jeblairor does it need to use item['path'] ?23:04
jeblairdmsimard suggested that ^23:04
jeblairi thought jinja let us use either23:04
mordredI thnk jinja does dict lookups with . - lemme test real quick23:04
pabelangerplaybooks/python/tarball-post.yaml has the right syntax for find23:04
pabelanger{{ item.path }} is correct23:05
mordredlet me not do that in that one patch real quick ...23:06
jeblairmordred: when you're done with that, i have another thing -- it looks like the callback plugin is omitting some error information. see: http://logs.openstack.org/12/496412/4/check/devstack-lxc/b5e5437/job-output.txt.gz#_2017-08-22_22_58_02_59539023:07
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Use item.path not item on results of find  https://review.openstack.org/49643623:07
jeblairmordred: that failed because zuul doesn't have permission to write to the destination directory.  i found the error by using ara [dmsimard will be happy to know :)] (where it was reported in the json).23:07
mordredjeblair: cool - I'll add that to the list to investigate/fix23:08
pabelangermordred: twine upload *.tar.gz should work too right?23:08
jeblairmordred: the error is also in the callback json23:08
mordredjeblair: yah - I imagine it's generally speaking in item processing23:08
jeblairmordred: shows up as stdout --23:08
jeblair"stdout": "mv: cannot move 'src/git.openstack.org/openstack-infra/devstack-gate' to '/opt/stack/devstack-gate': Permission denied",23:08
jeblairpabelanger: are you working on the gearman job debug cleanups or should i do that?23:09
mordredpabelanger: instead of item.path? yes - but I did the find so that the upload would work if you only did sdist and didn't do bdist_wheel23:09
mordredpabelanger: (or vice versa)23:09
pabelangerjeblair: it might be faster if you do it, but happy to do it if you tell me where I need to look23:09
jeblairpabelanger: k, i'll do it23:10
pabelangermordred: ++23:10
mordredjeblair: if you get a sec, would you look at the gpg sign job to make sure the direction looks ok?23:10
pabelangermordred: k, once we land that, I'll try tagging 0.0.6 for openstack-dev/sandbox23:11
mordredjeblair: https://review.openstack.org/#/c/496426/ and https://review.openstack.org/#/c/49642823:11
mordredjeblair: perhaps we should shred the keyring files after signing?23:11
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Stop logging executor job args  https://review.openstack.org/49643723:12
jeblairmordred: probably.  can you stick a TODO to switch those to using stdin when we upgrade to ansible 2.4 ?23:13
jeblairmordred: though, tbh, i don't know if that's possible with gpg23:13
jeblairmaybe we should add a tmpfs to the jobdir for this use?23:14
jeblairlike work/tmpfs23:14
mordredjeblair: ++23:16
mordredjeblair: I'll add a TODO to use such a thing when it exists23:17
pabelangerisn't /tmp inside bwrap already tmpfs. I guess the concern is that is 777 inside bwrap?23:17
jeblairpabelanger: oh you're right.  we could use /tmp23:18
mordredeither of you happen to know off the top of your head how to tell gpg to use a keyring that isn't in ~/.gnupg ?23:19
jeblairi think the right thing to do would be to securely make a tmpdir in /tmp, register that as the gpg path, and then write things out there23:19
jeblairmordred: i think it's in the system-config docs23:19
mordredya - I think you're right23:19
openstackgerritMerged openstack-infra/zuul-jobs master: Use item.path not item on results of find  https://review.openstack.org/49643623:19
mordredah - --homedir23:19
jeblairyep!23:19
jeblairmordred: what do you think of going ahead and doing the tmpdir thing ^?23:20
mordredyup. on it23:20
pabelangermordred: do we want to try a twine upload without gpg first?23:20
jeblaircool; i'll swing back around tomorrow to do that for ssh-add too, since we can do it without waiting for ansible 2.423:20
jeblairwe'll make fungi happy :)23:20
pabelangerjeblair: do you have gpgsign = true in your .gitconfig file?23:22
pabelangerreason I ask, if I have it enabled, zuul unitests fail because it will use ~/.gitconfig and not have access to my ssh-agent session23:22
jeblairpabelanger: i don't23:23
pabelangerthanks23:24
* fungi is always happy, but that's cool!23:24
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add role to GPG sign artifacts in a directory  https://review.openstack.org/49642623:24
mordredjeblair, pabelanger, fungi ^^ how's that?23:24
jeblairmordred: dig it23:26
mordredwoot23:26
mordredjeblair: while I've got you: https://review.openstack.org/#/c/496390/ and https://review.openstack.org/#/c/49641623:26
pabelangermordred: when would be delete the tempfile, on bwrap tear down?23:28
mordredyah23:28
mordredwhich happens as soon as the playbook exits23:29
mordredpabelanger: do you think we should delete the dir anyway?23:29
jeblairmordred: doesn't the pep8 job have the side effect of testing tarball builds?23:29
mordredjeblair: not if skip-sdist is true23:30
jeblair:(23:30
mordredjeblair: (I'm not sure we actually need that gate job in zuul - that's more to verify that the job itself works)23:30
pabelangermordred: maybe, just to be extra paranoid23:31
pabelanger+2 not to block23:31
jeblairmordred: yeah, but the reason for the job is to add that to every project in openstack, yeah?  that will be a bunch of new jobs.23:31
*** robled has quit IRC23:31
fungimordred: 496426 patchset 3 using a tempfile causes it to end up on a tmpfs in our default deployment, per the discussion last week?23:31
*** robled has joined #zuul23:32
pabelangermordred: going to try twine sans gpg key. Just to keep parellel testing23:32
mordredjeblair: oh - no - the reason for the new job is just to make sure there was a job related to tarball building that didn't necessarily upload it - we can also land neither of those23:32
jeblairmordred: i'm find landing both then removing from zuul23:33
openstackgerritJesse Keating proposed openstack-infra/zuul-jobs master: Role to copy the build ssh key to other users  https://review.openstack.org/49641323:33
jeblairmordred: though i have a -1 on the first23:33
mordredjeblair: cool23:34
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Delete keyring dir when we're done  https://review.openstack.org/49644023:34
mordredjeblair: I don't think we need to land then remove to zuul - we got to see the job work properly via depends on23:36
openstackgerritMerged openstack-infra/zuul-jobs master: Add role to GPG sign artifacts in a directory  https://review.openstack.org/49642623:37
jeblairmordred: okay, you mant want to abandon the second one then since it's been approved23:37
mordredyup23:37
mordredsweet. mr. jlk - wanna nudge https://review.openstack.org/#/c/496390 in ?23:38
pabelangerokay, zuulv3 seen the tag of sandbox23:39
pabelangerbut didn't run the job as expected23:39
mordredwompwomp23:40
* jlk looks23:41
SpamapSjlk: oh neat, I never knew about block:23:42
jeblairmordred: when you have a minute, the series starting at https://review.openstack.org/496330 can start going in23:42
jlkit's a 2.x thing23:42
jeblairzuul v2.5 uses it extensively23:43
pabelanger2017-08-22 23:35:11,259 DEBUG zuul.IndependentPipelineManager: No jobs for change <Tag 0x7f8a0b2bb320 creates refs/tags/0.0.6 on 32e8ddc3ed4326bdb3406ddb20a07fd4d49ef733>23:43
jlkhuh23:43
jeblair(in the crazy autogenerated playbook)23:43
pabelangerjeblair: do you mind looking at zuul debug.log on zuulv3.o.o23:43
jeblairpabelanger: on it23:44
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Stop logging executor job args  https://review.openstack.org/49643723:44
jlkI'm not core in openstack-infra/openstack-zuul-jobs23:44
mordredjeblair: this: https://review.openstack.org/#/c/496412/6/roles/setup-devstack-source-dirs/tasks/main.yaml is SO MUCH MORE SIMPLER than my brain was making it23:44
jeblairmordred: it needs to be a teensy bit more complicated for grenade later on23:45
pabelangerOh23:45
pabelangerI see it now23:45
jeblairjlk: i bet we can change that; wanna be?23:45
jlkSure, I know a few ansible things :D23:45
pabelangersorry23:45
jeblairpabelanger: ok.  standing down.  :)23:45
pabelangerno, I got too excited23:45
pabelangerjeblair: please look again23:45
jeblairokay, standing up23:45
pabelangerconfused it with post pipeline23:45
pabelanger+3 on 49639023:47
mordredjeblair: yah - but ... it's still super nice and understandable23:47
openstackgerritMerged openstack-infra/zuul-jobs master: Delete keyring dir when we're done  https://review.openstack.org/49644023:47
jlkwhat's this "urldefense.proofpoint.com" stuff?23:48
jeblairjlk: context?23:48
jlkI'm seeing it in my emails from zuul23:48
jlk- openstack-doc-build https://urldefense.proofpoint.com/v2/url?u=http-3A__logs.openstack.org_13_496413_2_check_openstack-2Ddoc-2Dbuild_20d1e75_html_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=2-RoMLt9561c-QFVUQD1hdw_pcUzCKx9dE1pPx90bnc&m=61V_3686Rn5fSpYrn6qOzto5KT43gaoagNQJ2ijAnlM&s=j6sE801e2k4GgU7Km_OHa305xaCSAI6OOlnluI6Lheg&e=  : SUCCESS in 2m 03s23:48
pabelangero.023:49
jlkI'm not sure if that's something our zuul has done, or if IBM is fucking with my email.23:49
mordredI believe someone is interecepting and rewriting that email23:49
mordredso I'm gonna go with IBM23:49
jlkle sigh23:49
jeblairjlk: that'll be your mailserver's spam filter altering your email23:49
jlkgood thing it's not gpg signed...23:49
mordred"Proofpoint Delivers on Gartner's23:49
mordredSecure Email Gateway Recommendations23:49
mordred"23:49
mordred1) break the ability to gpg sign and verify emails by manipulating them in-flight23:50
mordredok. I'm going to go eat the foods23:51
mordredjeblair: oh - interesting ...23:52
mordredjeblair: the error from zuul: https://review.openstack.org/#/c/49642823:52
mordredjeblair: so - I think maybe the way to deal with that is just to encrypt the pubring in the secret23:53
jeblairmordred: two other choices:  b64 encode it, or add support for binary.  we'll need to b64encode it internally in zuul to get it into json to go over the wire, but we should be able to swing that.23:55
jeblairmordred: i do agree that your idea gets us moving the quickest.23:55
jeblairpabelanger: i'm thinking that the implied branch matcher that came along with adding the job in the .zuul.yaml file in the repo is keeping this from working.23:56
pabelangerjeblair: okay23:57
jeblairpabelanger: the easiest way to get things moving would be to add the publish job in project-config.  other solutions will take some thought.23:57
pabelangerjeblair: k, I'll do that then23:57
pabelangerthank you23:57
*** SpamapS has quit IRC23:59
*** SpamapS has joined #zuul23:59
mordredjeblair: oh! fascinating (implied branch matcher)23:59

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