19:03:01 #startmeeting infra 19:03:01 Meeting started Tue Nov 8 19:03:01 2016 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:04 The meeting name has been set to 'infra' 19:03:07 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:13 #topic Announcements 19:03:20 #info Our "Ocata Cycle" [2048R/0x8B1B03FD54E2AC07] signing key has been generated; infra-root admins are requested to follow our attestation process as soon as possible. 19:03:28 #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07&fingerprint=on OpenStack Infra (Ocata Cycle) 19:03:34 #link http://docs.openstack.org/infra/system-config/signing.html#attestation Attestation process 19:03:47 as always, feel free to hit me up with announcements you want included in future meetings 19:03:49 o/ 19:04:01 #topic Actions from last meeting 19:04:07 #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-11-01-19.03.html 19:04:12 fungi send summit session summary to infra ml 19:04:16 your terrible ptl is backlogged, but it is at least in the process of being drafted 19:04:23 #action fungi send summit session summary to infra ml 19:04:34 pabelanger announce upcoming wheel-less pep8 job transition to openstack-dev ml 19:04:36 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106668.html important changes to pep8 python jobs 19:04:42 thanks pabelanger! you want to do the follow-up one next week as well? 19:04:57 fungi: Yup, I was going to send that out later today 19:05:00 #action pabelanger send followup announcement for wheel-less pep8 job transition 19:05:10 * fungi predicted that response, being all prescient and ptl-like 19:05:22 fungi generate and sign ocata cycle signing key 19:05:24 that's done (see above link in this week's announcements) 19:05:36 #topic Specs approval 19:05:44 #info APPROVED "Neutral governance website" spec 19:05:51 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/neutral-governance-website.html "Neutral governance website" spec 19:06:04 ttx: ^ in case you missed that it merged 19:06:19 #topic Specs approval: PROPOSED "Automate Creating Branches" spec (dhellmann) 19:06:25 #link https://review.openstack.org/369643 "Automate Creating Branches" spec review 19:06:31 hi! 19:06:53 looks like you and jhesketh have given it a council thumbs-up already 19:06:55 o/ 19:06:57 so far the comments on this look positive, so I would like to start working on implementation 19:07:21 before I do, I wanted to get the official sign-off 19:07:23 oh, that was tonyb and jhesketh who have it a council thumbs-up actually 19:07:33 dhellmann: yep, sounds good! 19:07:45 #info The "Automate Creating Branches" spec is open for Infra Council vote until 19:00 UTC Thursday, November 10. 19:07:55 cool, thanks 19:08:03 dhellmann: are you thinking about automating deletion? 19:08:20 jeblair : not in this go-round, but eventually tonyb wants to automate the eol process 19:08:38 yeah, we talked about it on summit friday, in the release management room i think 19:08:44 cool. i think the baby steps approach is good. just wondering if it was a twinkle in your eye. 19:08:48 glad to hear it is :) 19:08:49 seemed there was general agreement on the idea 19:09:01 it would be a big help both to stable maint and infra 19:09:02 I'm not sure about "delete" but definitely "eol" 19:09:26 something like a feature branch might have a different process for "delete", I guess 19:09:30 right, generally we "delete" branches by eol'ing them, so that sounds like enough of what we want 19:09:36 anyway, yes, baby steps :-) 19:09:49 ++ 19:09:51 ok, that would cover both cases then 19:10:06 but as you say, that's a topic for another day! ;) 19:10:19 and tonyb volunteered, so he owns that ;-) 19:10:36 heh, perfect 19:10:38 anything else you need to squeeze in about this spec before we move on to other meeting topics? 19:10:51 that's it from me. I'll look for questions on the review. 19:10:59 thanks! 19:11:05 #topic Priority Efforts 19:11:05 thank you! 19:11:26 nothing is called out on the agenda this week, but i did approve rcarrillocruz's change to move infra-cloud to implemented 19:11:42 and have removed it from the priority efforts subtopics on our weekly meeting agenda as well 19:11:47 fungi: did the zanata change to make that implemented get pushed/merged too? 19:12:01 clarkb: ooh, i think? lemme check real fast 19:12:52 oh, i think it already was in implemented 19:13:00 at any rate, it's there now 19:13:11 ah ok ianychoi mentioned that we needed to update it but I didn't check if it was already done 19:13:57 if memory served, the upshot was that he was confused by the fact that it was still in the index, but turned out it was in the implemented section of the index 19:14:08 gotcha 19:14:15 also asselin has one up to mark the openstackci spec as implemented 19:14:28 #link https://review.openstack.org/393492 Mark openstackci spec as complete 19:14:44 looks like that's been up for almost a week 19:15:06 +1 19:15:32 ++ 19:15:55 if anybody objects that it's complete, say so on the review, otherwise i'll merge it on thursday as well 19:16:32 ++ thanks! 19:16:35 #topic Ensuring projects adhere to the Consistent Testing Interface (fungi) 19:16:50 #link https://review.openstack.org/394620 Make sure opportunistic DB use in unit tests works 19:17:15 i was collaborating with notmyname on a change to get an xfs tempdir available in swift unit test jobs 19:17:48 there had been pushback against them only running their unit tests like that, concerned that it might violate the consistent testing interface mandated by the tc 19:18:30 when looking for examples to follow there, it dawned on me that this is already exactly the case for projects whose unit tests are only run with special mysql and postgres databases prevonfigured 19:19:26 fungi: oh, i thought the swift thing was for a new job 19:19:36 it's meant to replace the existing py27 job? 19:19:40 so i pushed this up as a sort of straw-man for whether we think this is equivalent, and whether it's something we think needs to be done as well, or whether i should put forward an amendment to the cti that would make deviations like these acceptable 19:20:30 in swift's case they're adding an xfs variant of their unit test job, but they'd rather just run it with xfs available because the only difference is that without an xfs filesystem to use a subset of their unit tests are disabled 19:20:39 gotcha 19:21:01 they only made it a separate, additional job because concerns were voiced that doing otherwise may violate the cti 19:21:20 but if it does, then probably so do all these unit tests that only get run with special db configs present 19:21:28 sorry if this sounds silly, but why would we run with preconfigured databases at all then? shouldn't every test know how to set itself up? 19:21:37 fungi: I had previously used the database example for why I thought swifts thing was fine... 19:21:45 for example, we don't test that nova's unit test jobs work without mysql and postgres databases set up for them in advance 19:21:54 well, the *intent* of the pti was so that we are able to maintain the roughly 5000 standardized jobs 19:22:07 it's not to be arbitrary -- it's just to set a standard 19:23:28 so i think if we need to adjust it to accomodate a more flexible idea of preconfiguration, that's fine. but it probably should entail some thinking about how that would look in the project-config repo. because if the outcome is that every project has their own py27 variant and they don't share builders, etc, then we've lost our ability to do things like "change run-tox.sh" or "upgrade os distros" 19:24:08 (perhaps modularity and reuse of jjb builder macros -- in the way that notmyname was constructing that job -- would solve those problems) 19:24:25 yeah, in the swift xfs case, it would just have been a separate job template basically identical to the python27 one except adding a builder immediately before revoke-sudo 19:24:48 that does teh xfs setup step 19:25:22 that seems like a sensible way to approach it. it stays out of the way of the parts of the interface we need to make assumptions about. 19:25:54 so i guess the first question, does anybody feel like custom job templates that add some database permissions or mount a special filesystem before running, say, `tox -e py27` is out of line with the cti? 19:26:20 #link http://governance.openstack.org/reference/cti/python_cti.html#specific-commands Consistent Testing Interface: Python (Specific commands) 19:26:32 I tihnk those are fine in the way described above - where the actual invocation of the CTI portion is unchanged 19:27:15 if there's no general disagreement on that point, then we can probably forego amending the cti in governance unless it becomes more contentious 19:27:41 i don't disagree. i think clarifying it would be fine though. 19:28:00 fungi: I don't think they are as long as the test suite can still run on my laptop without root 19:28:09 so swift should handle the no xfs case and nova should handle the no db case 19:28:14 ya 19:28:16 I know nova does this, I dunno if swift does 19:28:27 if that's the case, do we need to _test_ that upstream? 19:28:48 we haven't had to test it upstream so far because enough people seem to run the tests locally that this is covered 19:28:52 that's what the current swift job addition and my db jobs change linked above would do 19:28:57 clarkb: well, i disagree that projects need to test the null case. 19:29:14 clarkb: we can talk about that if you want, however, it's not at issue here, so we could skip it. :) 19:29:20 ok :) 19:30:37 i don't think we need to run the tests twice, without the db. 19:30:57 ya it hasn't been an issue so far in the few years we have only tested with the db 19:31:05 ++ 19:31:21 #agreed Infra consensus is that jobs adding custom database configuration or special filesystems prior to running CTI-mandated test commands do not necessarily violate the CTI as worded; clarification in the CTI on this point and that projects should try to make some of their tests viable even without such setup (even if that case is not tested upstream) would be a welcome addition. 19:31:37 i struggled at finding a less-wordy distillation of the position there 19:31:44 anyone have suggestions? 19:32:08 well, i still disagree with the last part. 19:32:16 #undo 19:32:16 Removing item from minutes: 19:32:44 if swift, hypothetically, chose *only* to support xfs, i don't think it would be sensible for us to say that its unit tests must work without it 19:32:45 okay, so we should test that they're runnable even without te db setup or filesystem mounted? 19:32:57 aha, so other way around 19:33:10 fungi: right -- other way around :) 19:33:11 and yes, it sounds like it's pretty close to that in the swift case 19:33:19 To help express complex cases in policy, the use of a Statement; Rationale; Implications structure (as in https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles) can be useful. Note that this doesn't help the wording above unless someone wants to redraft everything. 19:33:26 basically their advanced attribute support only works on xfs 19:33:35 also, i think it's insane that nova tests with sqlite (it has caused *no end* of problems over the years) 19:33:42 jeblair: oh swift doesn't only support xfs 19:33:48 which is why I think their tests should still work on ext4 for example 19:33:50 or btrfs 19:34:01 clarkb: agreed. i was postulating a hypothetical 19:34:04 gotcha 19:34:28 to illustrate why i think it's okay for unit/function tests to, in some cases, require this kind of setup 19:34:47 #agreed Infra consensus is that jobs adding custom database configuration or special filesystems prior to running CTI-mandated test commands do not necessarily violate the CTI as worded; clarification in the CTI on this point would be a welcome addition. 19:34:50 better? 19:35:56 basically, i think we need to not let the tail wag the dog here -- we should test what makes sense for the project and developers. but we should push back on projects that go overboard in their tests and require crazy things (like root). 19:36:18 fungi: agreed 19:36:44 jeblair: +1 19:36:45 yeah, i think a fundamental element here may be that the prerequisite steps requiring root access be clearly defined somewhere by the project 19:37:13 "this project is useless without a database" okay, install the db. "this project can do cool stuff with a giant ceph cluster" maybe don't require that for the unit tests. :) 19:37:16 so, for example, packages need installing with root access... a bindep.txt and readme paragraph satisfies that 19:38:01 that is a case we've heavily automated because it's a shared divergence across many/most projects 19:38:24 fungi: ++ 19:38:51 things like database and filesystem setup are just slightly less common prerequisites root has to satisfy 19:39:08 thanks, that gets me a good place to start from, i think 19:39:13 #action fungi propose clarification about project-specific test preconditions (databases, filesystems) for cti 19:39:44 i'm tapped out on this topic, thanks for entertaining my existentialist whims here 19:40:16 #topic Open discussion 19:40:22 anything else? 19:40:28 we have 20 minutes left over for a change 19:40:39 i promise i haven't forgotten about the zuulv3 spec updates 19:40:46 today is election day, does that make tomorrow an unofficial recovery holiday? 19:40:54 hangover day? 19:41:02 fungi: tahts the more direct way of putting it :) 19:41:06 pholio is up ... fungi did you look into removing the other hosts i mentioned? 19:41:15 ianw: yep, those are cleaned up 19:41:23 i forgot to set topic for gerrit upgrade, a spec is in review. #link https://review.openstack.org/#/c/388190/ should we go over it next week? 19:41:30 zaro: lets 19:41:30 i have not purchased a cert for pholio.o.o though 19:41:33 fungi: thanks 19:41:43 #action fungi purchase cert for pholio.openstack.org 19:41:48 i have a bunch of notes on the 'secrets' one. when i type that up, i'll ask folks to take another look. 19:42:09 ianw: also i spotted that the vhost seems to think it's pholio01.o.o, have you adjusted that in puppet yet? 19:42:29 it may have a baked-in assumption that the vhost name is ==$::fqdn 19:42:31 on the afs-docs thing, i hope that https://review.openstack.org/394658 will correct the problems we saw with some jobs publishing 19:42:40 that needs to be approved and we need a zuul-launcher restart 19:42:52 fungi: ahh, ok, i have not. i think it idoes 19:43:04 jeblair: the pycrypto vs pyca/cryptography thread on the -dev ml might also be relevant to that spec addition 19:43:28 fungi: ah thanks, i'll take a look. 19:43:37 I sent the first You need to use Xenial email 19:43:42 I've started taking a stab at fixing our abort loop issue with zuul, 395056. Looking for some initial feedback. 19:43:46 intend to send one every monday until our switchover 19:44:00 a lot of openstack is switching functions over to use the cryptography lib, though that would cause zuul sdist installs to need to link against openssl-dev headers 19:44:24 fungi: already does 19:44:40 oh, in that case we may want to strongly prefer pyca/cryptography 19:44:41 I had to update the devstack gate reproduce.sh header to reflect that 19:45:24 the implementation rcarrillocruz was looking into though (pkcs#1 with oaep) would still be effectively the same 19:46:01 there's methods to supply that in cryptography, and it also lacks pkcs#7 support just like pycrypto 19:46:33 good call, thanks 19:46:45 difference would be that it would be handled by libssl directly rather than custom forks/backports of rsa code in pycrypto 19:47:24 I like things when libssl handles them 19:47:25 fungi: wow. don't oversell it. :) 19:47:40 heh 19:47:55 fungi: 'local, hand-made, artisnal backports' 19:48:15 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106827.html pycrypto vs cryptography 19:48:22 that's teh start of the thread 19:48:37 jeblair: I think you just gave someone a business idea ... 19:49:02 mordred: was it you? 19:49:10 mordred: I believe some of our employers are already in that racket. 19:49:14 jeblair: oh golly no 19:49:16 * bkero looks at his kernel. 19:49:18 touché 19:49:39 if I were starting this business, it would not include "hand-made" anywhere in its remit 19:50:04 my hands are too delicate for hand-rolled crypto 19:51:03 anyway, as is pointed out in that thread, a good reason to consider dropping pycrypto is that it's been effectively dead upstream for 2-3 years 19:51:15 which is not the sort of thing you want in a security-sensitive library 19:51:42 yeah, so maybe i'll throw the words "python" "crytpography" and "library" into that spec update too. 19:51:46 possibly in that order. 19:52:53 o/ 19:53:01 seems like we've even run out of open discussion. i give you all 7 minutes of your week back 19:53:09 quick one 19:53:11 https://review.openstack.org/#/c/391588/ 19:53:12 oh! 19:53:30 I thought I'd give a quick update on the badges thing I brought up 3 weeks ago 19:53:35 please do! 19:53:49 I've implemented the badges generation as part of the governance repo CI jobs 19:53:59 no need to host another service or doing other changes 19:54:06 yeah, i looked at one of the rendered svg images. neat stuff 19:54:16 I just have one question 19:54:35 nice! 19:54:37 it'd be great if we could make the 404 response for the `/badges/` subdir a badge 19:55:06 i was trying to figure out if there's a good way to overlay those on the git.o.o webui (maybe some javascript tricks) without getting in the way too much 19:55:08 That is, if someone tries to load a badge for a non-official project, the response will be 404 and I'd like to return a "project: unofficial" badge along with that response 19:55:21 flaper87: we should be able to configure the web server to do that 19:55:24 would that be possible ? 19:55:27 awesome 19:55:27 yah. good old apache 19:55:29 flaper87: a custom 404 page would probably be able to do that? or we could just to a pattern-based redirect 19:55:48 er, just do a 19:55:58 we might want to just do this for the /badges/ subdir/path 19:56:17 right, i think either method should be able to be restricted by location 19:56:24 all 404s across all of infra should become the unofficial badge ;) 19:56:37 I'll add the 404 badge generation to this sphinx plugin too 19:56:43 mordred: :D 19:56:50 will need to play around with it a little. if you have time to fiddle with apache configuration locally and work out the syntax, i'm happy to point you at where we would need to add it 19:57:01 flaper87: .htaccess might work? 19:57:06 fungi: yes, point me at it 19:57:29 ianw: it might, I just didn't know if we were using apache 19:57:47 we are apacheing 19:58:14 #link http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/templates/static-governance.vhost.erb erb template for governance.o.o site 19:58:17 flaper87: ^ 19:58:23 I'll optimize the badges layout next but that doesn't impact any of this work 19:58:25 we are, so it might make sense to keep in the repo. anyway, plenty of options 19:58:26 fungi: awesome, thanks 19:58:54 I'll try with .htaccess first. if it doesn't work, I'll change apache's config 19:59:13 flaper87: thanks for using up our otherwise wasted last 7 minutes! 19:59:14 if we want to use htaccess, we may need to allow setting the 404 page 19:59:28 :D 19:59:46 we're out of time--thanks everyone! 19:59:51 I think htaccess would be better in this case because it isolates the work in one place 19:59:54 * flaper87 stfu 19:59:54 flaper87: thanks! 19:59:59 #endmeeting