19:03:01 <fungi> #startmeeting infra
19:03:01 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:04 <openstack> The meeting name has been set to 'infra'
19:03:07 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:03:13 <fungi> #topic Announcements
19:03:20 <fungi> #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 <fungi> #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07&fingerprint=on OpenStack Infra (Ocata Cycle) <infra-root@openstack.org>
19:03:34 <fungi> #link http://docs.openstack.org/infra/system-config/signing.html#attestation Attestation process
19:03:47 <fungi> as always, feel free to hit me up with announcements you want included in future meetings
19:03:49 <SotK> o/
19:04:01 <fungi> #topic Actions from last meeting
19:04:07 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-11-01-19.03.html
19:04:12 <fungi> fungi send summit session summary to infra ml
19:04:16 <fungi> your terrible ptl is backlogged, but it is at least in the process of being drafted
19:04:23 <fungi> #action fungi send summit session summary to infra ml
19:04:34 <fungi> pabelanger announce upcoming wheel-less pep8 job transition to openstack-dev ml
19:04:36 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106668.html important changes to pep8 python jobs
19:04:42 <fungi> thanks pabelanger! you want to do the follow-up one next week as well?
19:04:57 <pabelanger> fungi: Yup, I was going to send that out later today
19:05:00 <fungi> #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> fungi generate and sign ocata cycle signing key
19:05:24 <fungi> that's done (see above link in this week's announcements)
19:05:36 <fungi> #topic Specs approval
19:05:44 <fungi> #info APPROVED "Neutral governance website" spec
19:05:51 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/neutral-governance-website.html "Neutral governance website" spec
19:06:04 <fungi> ttx: ^ in case you missed that it merged
19:06:19 <fungi> #topic Specs approval: PROPOSED "Automate Creating Branches" spec (dhellmann)
19:06:25 <fungi> #link https://review.openstack.org/369643 "Automate Creating Branches" spec review
19:06:31 <dhellmann> hi!
19:06:53 <fungi> looks like you and jhesketh have given it a council thumbs-up already
19:06:55 <zaro> o/
19:06:57 <dhellmann> so far the comments on this look positive, so I would like to start working on implementation
19:07:21 <dhellmann> before I do, I wanted to get the official sign-off
19:07:23 <fungi> oh, that was tonyb and jhesketh who have it a council thumbs-up actually
19:07:33 <fungi> dhellmann: yep, sounds good!
19:07:45 <fungi> #info The "Automate Creating Branches" spec is open for Infra Council vote until 19:00 UTC Thursday, November 10.
19:07:55 <dhellmann> cool, thanks
19:08:03 <jeblair> dhellmann: are you thinking about automating deletion?
19:08:20 <dhellmann> jeblair : not in this go-round, but eventually tonyb wants to automate the eol process
19:08:38 <fungi> yeah, we talked about it on summit friday, in the release management room i think
19:08:44 <jeblair> cool.  i think the baby steps approach is good.  just wondering if it was a twinkle in your eye.
19:08:48 <jeblair> glad to hear it is :)
19:08:49 <fungi> seemed there was general agreement on the idea
19:09:01 <fungi> it would be a big help both to stable maint and infra
19:09:02 <dhellmann> I'm not sure about "delete" but definitely "eol"
19:09:26 <dhellmann> something like a feature branch might have a different process for "delete", I guess
19:09:30 <fungi> right, generally we "delete" branches by eol'ing them, so that sounds like enough of what we want
19:09:36 <dhellmann> anyway, yes, baby steps :-)
19:09:49 <jeblair> ++
19:09:51 <dhellmann> ok, that would cover both cases then
19:10:06 <fungi> but as you say, that's a topic for another day! ;)
19:10:19 <dhellmann> and tonyb volunteered, so he owns that ;-)
19:10:36 <fungi> heh, perfect
19:10:38 <fungi> anything else you need to squeeze in about this spec before we move on to other meeting topics?
19:10:51 <dhellmann> that's it from me. I'll look for questions on the review.
19:10:59 <fungi> thanks!
19:11:05 <fungi> #topic Priority Efforts
19:11:05 <dhellmann> thank you!
19:11:26 <fungi> 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 <fungi> and have removed it from the priority efforts subtopics on our weekly meeting agenda as well
19:11:47 <clarkb> fungi: did the zanata change to make that implemented get pushed/merged too?
19:12:01 <fungi> clarkb: ooh, i think? lemme check real fast
19:12:52 <fungi> oh, i think it already was in implemented
19:13:00 <fungi> at any rate, it's there now
19:13:11 <clarkb> ah ok ianychoi mentioned that we needed to update it but I didn't check if it was already done
19:13:57 <fungi> 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 <clarkb> gotcha
19:14:15 <fungi> also asselin has one up to mark the openstackci spec as implemented
19:14:28 <fungi> #link https://review.openstack.org/393492 Mark openstackci spec as complete
19:14:44 <fungi> looks like that's been up for almost a week
19:15:06 <pabelanger> +1
19:15:32 <rcarrillocruz> ++
19:15:55 <fungi> if anybody objects that it's complete, say so on the review, otherwise i'll merge it on thursday as well
19:16:32 <asselin> ++ thanks!
19:16:35 <fungi> #topic Ensuring projects adhere to the Consistent Testing Interface (fungi)
19:16:50 <fungi> #link https://review.openstack.org/394620 Make sure opportunistic DB use in unit tests works
19:17:15 <fungi> i was collaborating with notmyname on a change to get an xfs tempdir available in swift unit test jobs
19:17:48 <fungi> 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 <fungi> 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 <jeblair> fungi: oh, i thought the swift thing was for a new job
19:19:36 <jeblair> it's meant to replace the existing py27 job?
19:19:40 <fungi> 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 <fungi> 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 <jeblair> gotcha
19:21:01 <fungi> they only made it a separate, additional job because concerns were voiced that doing otherwise may violate the cti
19:21:20 <fungi> but if it does, then probably so do all these unit tests that only get run with special db configs present
19:21:28 <ianw> 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 <clarkb> fungi: I had previously used the database example for why I thought swifts thing was fine...
19:21:45 <fungi> 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 <jeblair> well, the *intent* of the pti was so that we are able to maintain the roughly 5000 standardized jobs
19:22:07 <jeblair> it's not to be arbitrary -- it's just to set a standard
19:23:28 <jeblair> 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 <jeblair> (perhaps modularity and reuse of jjb builder macros -- in the way that notmyname was constructing that job -- would solve those problems)
19:24:25 <fungi> 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 <fungi> that does teh xfs setup step
19:25:22 <jeblair> 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 <fungi> 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 <fungi> #link http://governance.openstack.org/reference/cti/python_cti.html#specific-commands Consistent Testing Interface: Python (Specific commands)
19:26:32 <mordred> I tihnk those are fine in the way described above - where the actual invocation of the CTI portion is unchanged
19:27:15 <fungi> 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 <jeblair> i don't disagree.  i think clarifying it would be fine though.
19:28:00 <clarkb> fungi: I don't think they are as long as the test suite can still run on my laptop without root
19:28:09 <clarkb> so swift should handle the no xfs case and nova should handle the no db case
19:28:14 <jeblair> ya
19:28:16 <clarkb> I know nova does this, I dunno if swift does
19:28:27 <fungi> if that's the case, do we need to _test_ that upstream?
19:28:48 <clarkb> 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 <fungi> that's what the current swift job addition and my db jobs change linked above would do
19:28:57 <jeblair> clarkb: well, i disagree that projects need to test the null case.
19:29:14 <jeblair> clarkb: we can talk about that if you want, however, it's not at issue here, so we could skip it.  :)
19:29:20 <clarkb> ok :)
19:30:37 <jeblair> i don't think we need to run the tests twice, without the db.
19:30:57 <clarkb> ya it hasn't been an issue so far in the few years we have only tested with the db
19:31:05 <mordred> ++
19:31:21 <fungi> #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 <fungi> i struggled at finding a less-wordy distillation of the position there
19:31:44 <fungi> anyone have suggestions?
19:32:08 <jeblair> well, i still disagree with the last part.
19:32:16 <fungi> #undo
19:32:16 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x7fac55465ed0>
19:32:44 <jeblair> 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 <fungi> okay, so we should test that they're runnable even without te db setup or filesystem mounted?
19:32:57 <fungi> aha, so other way around
19:33:10 <jeblair> fungi: right -- other way around :)
19:33:11 <fungi> and yes, it sounds like it's pretty close to that in the swift case
19:33:19 <persia> 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 <fungi> basically their advanced attribute support only works on xfs
19:33:35 <jeblair> also, i think it's insane that nova tests with sqlite (it has caused *no end* of problems over the years)
19:33:42 <clarkb> jeblair: oh swift doesn't only support xfs
19:33:48 <clarkb> which is why I think their tests should still work on ext4 for example
19:33:50 <clarkb> or btrfs
19:34:01 <jeblair> clarkb: agreed.  i was postulating a hypothetical
19:34:04 <clarkb> gotcha
19:34:28 <jeblair> to illustrate why i think it's okay for unit/function tests to, in some cases, require this kind of setup
19:34:47 <fungi> #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 <fungi> better?
19:35:56 <jeblair> 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 <jeblair> fungi: agreed
19:36:44 <clarkb> jeblair: +1
19:36:45 <fungi> 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 <jeblair> "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 <fungi> so, for example, packages need installing with root access... a bindep.txt and readme paragraph satisfies that
19:38:01 <fungi> that is a case we've heavily automated because it's a shared divergence across many/most projects
19:38:24 <jeblair> fungi: ++
19:38:51 <fungi> things like database and filesystem setup are just slightly less common prerequisites root has to satisfy
19:39:08 <fungi> thanks, that gets me a good place to start from, i think
19:39:13 <fungi> #action fungi propose clarification about project-specific test preconditions (databases, filesystems) for cti
19:39:44 <fungi> i'm tapped out on this topic, thanks for entertaining my existentialist whims here
19:40:16 <fungi> #topic Open discussion
19:40:22 <fungi> anything else?
19:40:28 <fungi> we have 20 minutes left over for a change
19:40:39 <jeblair> i promise i haven't forgotten about the zuulv3 spec updates
19:40:46 <clarkb> today is election day, does that make tomorrow an unofficial recovery holiday?
19:40:54 <fungi> hangover day?
19:41:02 <clarkb> fungi: tahts the more direct way of putting it :)
19:41:06 <ianw> pholio is up ... fungi did you look into removing the other hosts i mentioned?
19:41:15 <fungi> ianw: yep, those are cleaned up
19:41:23 <zaro> 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 <clarkb> zaro: lets
19:41:30 <fungi> i have not purchased a cert for pholio.o.o though
19:41:33 <ianw> fungi: thanks
19:41:43 <fungi> #action fungi purchase cert for pholio.openstack.org
19:41:48 <jeblair> 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 <fungi> 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 <fungi> it may have a baked-in assumption that the vhost name is ==$::fqdn
19:42:31 <jeblair> 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 <jeblair> that needs to be approved and we need a zuul-launcher restart
19:42:52 <ianw> fungi: ahh, ok, i have not.  i think it idoes
19:43:04 <fungi> jeblair: the pycrypto vs pyca/cryptography thread on the -dev ml might also be relevant to that spec addition
19:43:28 <jeblair> fungi: ah thanks, i'll take a look.
19:43:37 <clarkb> I sent the first You need to use Xenial email
19:43:42 <pabelanger> I've started taking a stab at fixing our abort loop issue with zuul, 395056. Looking for some initial feedback.
19:43:46 <clarkb> intend to send one every monday until our switchover
19:44:00 <fungi> 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 <clarkb> fungi: already does
19:44:40 <fungi> oh, in that case we may want to strongly prefer pyca/cryptography
19:44:41 <clarkb> I had to update the devstack gate reproduce.sh header to reflect that
19:45:24 <fungi> the implementation rcarrillocruz was looking into though (pkcs#1 with oaep) would still be effectively the same
19:46:01 <fungi> there's methods to supply that in cryptography, and it also lacks pkcs#7 support just like pycrypto
19:46:33 <rcarrillocruz> good call, thanks
19:46:45 <fungi> difference would be that it would be handled by libssl directly rather than custom forks/backports of rsa code in pycrypto
19:47:24 <mordred> I like things when libssl handles them
19:47:25 <jeblair> fungi: wow.  don't oversell it.  :)
19:47:40 <fungi> heh
19:47:55 <jeblair> fungi: 'local, hand-made, artisnal backports'
19:48:15 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106827.html pycrypto vs cryptography
19:48:22 <fungi> that's teh start of the thread
19:48:37 <mordred> jeblair: I think you just gave someone a business idea ...
19:49:02 <jeblair> mordred: was it you?
19:49:10 <bkero> mordred: I believe some of our employers are already in that racket.
19:49:14 <mordred> jeblair: oh golly no
19:49:16 * bkero looks at his kernel.
19:49:18 <fungi> touché
19:49:39 <mordred> if I were starting this business, it would not include "hand-made" anywhere in its remit
19:50:04 <fungi> my hands are too delicate for hand-rolled crypto
19:51:03 <fungi> 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 <fungi> which is not the sort of thing you want in a security-sensitive library
19:51:42 <jeblair> yeah, so maybe i'll throw the words "python" "crytpography" and "library" into that spec update too.
19:51:46 <jeblair> possibly in that order.
19:52:53 <flaper87> o/
19:53:01 <fungi> seems like we've even run out of open discussion. i give you all 7 minutes of your week back
19:53:09 <flaper87> quick one
19:53:11 <flaper87> https://review.openstack.org/#/c/391588/
19:53:12 <fungi> oh!
19:53:30 <flaper87> I thought I'd give a quick update on the badges thing I brought up 3 weeks ago
19:53:35 <fungi> please do!
19:53:49 <flaper87> I've implemented the badges generation as part of the governance repo CI jobs
19:53:59 <flaper87> no need to host another service or doing other changes
19:54:06 <fungi> yeah, i looked at one of the rendered svg images. neat stuff
19:54:16 <flaper87> I just have one question
19:54:35 <jeblair> nice!
19:54:37 <flaper87> it'd be great if we could make the 404 response for the `/badges/` subdir a badge
19:55:06 <fungi> 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 <flaper87> 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 <clarkb> flaper87: we should be able to configure the web server to do that
19:55:24 <flaper87> would that be possible ?
19:55:27 <flaper87> awesome
19:55:27 <mordred> yah. good old apache
19:55:29 <fungi> flaper87: a custom 404 page would probably be able to do that? or we could just to a pattern-based redirect
19:55:48 <fungi> er, just do a
19:55:58 <flaper87> we might want to just do this for the /badges/ subdir/path
19:56:17 <fungi> right, i think either method should be able to be restricted by location
19:56:24 <mordred> all 404s across all of infra should become the unofficial badge ;)
19:56:37 <flaper87> I'll add the 404 badge generation to this sphinx plugin too
19:56:43 <flaper87> mordred: :D
19:56:50 <fungi> 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 <ianw> flaper87: .htaccess might work?
19:57:06 <flaper87> fungi: yes, point me at it
19:57:29 <flaper87> ianw: it might, I just didn't know if we were using apache
19:57:47 <clarkb> we are apacheing
19:58:14 <fungi> #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 <fungi> flaper87: ^
19:58:23 <flaper87> I'll optimize the badges layout next but that doesn't impact any of this work
19:58:25 <ianw> we are, so it might make sense to keep in the repo.  anyway, plenty of options
19:58:26 <flaper87> fungi: awesome, thanks
19:58:54 <flaper87> I'll try with .htaccess first. if it doesn't work, I'll change apache's config
19:59:13 <fungi> flaper87: thanks for using up our otherwise wasted last 7 minutes!
19:59:14 <jeblair> if we want to use htaccess, we may need to allow setting the 404 page
19:59:28 <flaper87> :D
19:59:46 <fungi> we're out of time--thanks everyone!
19:59:51 <flaper87> 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 <jeblair> flaper87: thanks!
19:59:59 <fungi> #endmeeting