Thursday, 2019-10-03

*** jamesmcarthur has joined #openstack-tc00:09
*** ianychoi has quit IRC00:12
*** tetsuro has joined #openstack-tc00:15
*** ianychoi has joined #openstack-tc00:15
*** jamesmcarthur has quit IRC00:24
*** tetsuro has quit IRC00:29
*** tetsuro has joined #openstack-tc00:29
*** ianychoi has quit IRC00:32
*** jamesmcarthur has joined #openstack-tc00:35
*** ianychoi has joined #openstack-tc00:48
*** jamesmcarthur has quit IRC00:49
*** jamesmcarthur has joined #openstack-tc00:51
*** jamesmcarthur has quit IRC00:54
*** jamesmcarthur has joined #openstack-tc00:55
*** tetsuro has quit IRC01:06
*** jamesmcarthur has quit IRC01:07
*** tetsuro has joined #openstack-tc01:39
*** tetsuro has quit IRC01:44
*** tetsuro has joined #openstack-tc02:17
*** jamesmcarthur has joined #openstack-tc02:18
*** tetsuro has quit IRC02:21
*** nicolasbock has quit IRC02:31
*** jamesmcarthur has quit IRC02:56
*** jamesmcarthur has joined #openstack-tc02:58
*** markvoelker has joined #openstack-tc03:07
*** markvoelker has quit IRC03:11
*** markvoelker has joined #openstack-tc03:21
*** markvoelker has quit IRC03:24
*** markvoelker has joined #openstack-tc03:30
*** markvoelker has quit IRC03:32
*** markvoelker has joined #openstack-tc03:32
*** markvoelker has quit IRC03:37
*** jamesmcarthur has quit IRC03:45
*** jamesmcarthur has joined #openstack-tc03:47
*** jamesmcarthur has quit IRC03:57
*** jamesmcarthur has joined #openstack-tc03:57
*** jamesmcarthur has quit IRC04:02
*** markvoelker has joined #openstack-tc04:07
*** jamesmcarthur has joined #openstack-tc04:33
*** markvoelker has quit IRC04:37
*** jamesmcarthur has quit IRC04:40
*** markvoelker has joined #openstack-tc05:01
*** spsurya has joined #openstack-tc05:04
*** markvoelker has quit IRC05:06
*** markvoelker has joined #openstack-tc05:11
*** markvoelker has quit IRC05:15
*** jamesmcarthur has joined #openstack-tc05:17
*** markvoelker has joined #openstack-tc05:20
*** jamesmcarthur has quit IRC05:23
*** markvoelker has quit IRC05:24
*** markvoelker has joined #openstack-tc05:29
*** markvoelker has quit IRC05:34
*** markvoelker has joined #openstack-tc05:38
*** markvoelker has quit IRC05:43
*** markvoelker has joined #openstack-tc05:47
*** markvoelker has quit IRC05:52
*** markvoelker has joined #openstack-tc05:57
*** markvoelker has quit IRC06:02
*** lpetrut has joined #openstack-tc06:02
*** lpetrut has quit IRC06:03
*** lpetrut has joined #openstack-tc06:03
*** markvoelker has joined #openstack-tc06:06
*** markvoelker has quit IRC06:10
*** markvoelker has joined #openstack-tc06:15
*** jamesmcarthur has joined #openstack-tc06:19
*** markvoelker has quit IRC06:20
*** ianychoi has quit IRC06:20
*** jaosorior has joined #openstack-tc06:21
*** ianychoi has joined #openstack-tc06:23
*** markvoelker has joined #openstack-tc06:24
*** markvoelker has quit IRC06:29
*** ianychoi has quit IRC06:29
*** jamesmcarthur has quit IRC06:30
*** ianychoi has joined #openstack-tc06:31
*** markvoelker has joined #openstack-tc06:33
*** markvoelker has quit IRC06:38
*** markvoelker has joined #openstack-tc06:43
*** markvoelker has quit IRC06:47
*** jamesmcarthur has joined #openstack-tc06:49
*** markvoelker has joined #openstack-tc06:52
*** markvoelker has quit IRC06:57
*** jamesmcarthur has quit IRC06:58
*** lpetrut has quit IRC06:59
*** lpetrut has joined #openstack-tc07:00
*** jamesmcarthur has joined #openstack-tc07:01
*** markvoelker has joined #openstack-tc07:01
*** markvoelker has quit IRC07:05
*** markvoelker has joined #openstack-tc07:10
*** markvoelker has quit IRC07:15
*** tosky has joined #openstack-tc07:16
*** markvoelker has joined #openstack-tc07:19
*** markvoelker has quit IRC07:24
*** markvoelker has joined #openstack-tc07:29
*** markvoelker has quit IRC07:34
*** markvoelker has joined #openstack-tc07:38
*** iurygregory has quit IRC07:39
*** markvoelker has quit IRC07:43
*** ianychoi has quit IRC07:45
*** markvoelker has joined #openstack-tc07:47
*** lpetrut has quit IRC07:48
*** lpetrut has joined #openstack-tc07:49
*** markvoelker has quit IRC07:52
*** e0ne has joined #openstack-tc07:52
*** e0ne has quit IRC07:53
*** markvoelker has joined #openstack-tc08:06
*** markvoelker has quit IRC08:11
*** markvoelker has joined #openstack-tc08:15
*** jamesmcarthur has quit IRC08:17
*** jaosorior has quit IRC08:19
*** markvoelker has quit IRC08:20
*** iurygregory has joined #openstack-tc08:21
*** markvoelker has joined #openstack-tc08:24
*** markvoelker has quit IRC08:29
*** markvoelker has joined #openstack-tc08:34
*** markvoelker has quit IRC08:39
*** e0ne has joined #openstack-tc08:49
*** markvoelker has joined #openstack-tc08:52
*** tetsuro has joined #openstack-tc08:55
*** markvoelker has quit IRC08:57
*** markvoelker has joined #openstack-tc09:01
*** markvoelker has quit IRC09:06
*** markvoelker has joined #openstack-tc09:10
*** jamesmcarthur has joined #openstack-tc09:14
*** markvoelker has quit IRC09:15
*** ricolin has quit IRC09:15
*** diablo_rojo has joined #openstack-tc09:17
*** jamesmcarthur has quit IRC09:18
*** markvoelker has joined #openstack-tc09:20
*** diablo_rojo has quit IRC09:24
*** markvoelker has quit IRC09:25
*** markvoelker has joined #openstack-tc09:29
*** markvoelker has quit IRC09:34
*** markvoelker has joined #openstack-tc09:38
openstackgerritAlexandra Settle proposed openstack/governance master: Finalise the transition of the docs team to a SIG  https://review.opendev.org/65714209:39
asettleo/09:41
*** markvoelker has quit IRC09:43
*** markvoelker has joined #openstack-tc09:48
openstackgerritAlexandra Settle proposed openstack/governance master: Finalise the transition of the docs team to a SIG  https://review.opendev.org/65714209:50
openstackgerritAlexandra Settle proposed openstack/governance master: Finalise the transition of the docs team to a SIG  https://review.opendev.org/65714209:51
*** markvoelker has quit IRC09:52
openstackgerritAlexandra Settle proposed openstack/governance master: Finalise the transition of the docs team to a SIG  https://review.opendev.org/65714209:52
*** markvoelker has joined #openstack-tc09:57
*** jaosorior has joined #openstack-tc09:59
*** markvoelker has quit IRC10:01
*** markvoelker has joined #openstack-tc10:06
*** jaosorior has quit IRC10:06
*** markvoelker has quit IRC10:11
*** tetsuro has quit IRC10:14
*** jamesmcarthur has joined #openstack-tc10:15
*** markvoelker has joined #openstack-tc10:15
*** diablo_rojo has joined #openstack-tc10:16
*** jamesmcarthur has quit IRC10:19
*** markvoelker has quit IRC10:20
*** jaosorior has joined #openstack-tc10:24
*** markvoelker has joined #openstack-tc10:24
*** markvoelker has quit IRC10:29
*** markvoelker has joined #openstack-tc10:34
*** markvoelker has quit IRC10:38
*** diablo_rojo has quit IRC10:40
*** markvoelker has joined #openstack-tc10:43
*** markvoelker has quit IRC10:47
*** tetsuro has joined #openstack-tc10:48
*** jaosorior has quit IRC10:51
*** markvoelker has joined #openstack-tc10:52
*** tetsuro has quit IRC10:54
*** markvoelker has quit IRC10:57
*** markvoelker has joined #openstack-tc11:01
*** markvoelker has quit IRC11:06
*** nicolasbock has joined #openstack-tc11:07
*** markvoelker has joined #openstack-tc11:10
*** markvoelker has quit IRC11:15
*** jamesmcarthur has joined #openstack-tc11:16
*** markvoelker has joined #openstack-tc11:20
*** jamesmcarthur has quit IRC11:20
*** tetsuro has joined #openstack-tc11:24
*** markvoelker has quit IRC11:24
evrardjpthanks ttx on following up on the Shanghai organization of the meet the leaders :)11:25
*** jamesmcarthur has joined #openstack-tc11:26
*** tetsuro has quit IRC11:28
*** markvoelker has joined #openstack-tc11:29
*** markvoelker has quit IRC11:34
*** jamesmcarthur has quit IRC11:35
*** jamesmcarthur has joined #openstack-tc11:37
*** markvoelker has joined #openstack-tc11:38
njohnstono/11:40
*** markvoelker has quit IRC11:42
*** tosky_ has joined #openstack-tc11:44
*** tosky has quit IRC11:46
*** markvoelker has joined #openstack-tc11:47
*** jamesmcarthur has quit IRC11:51
*** markvoelker has quit IRC11:52
*** jamesmcarthur has joined #openstack-tc11:52
*** markvoelker has joined #openstack-tc11:57
*** jamesmcarthur has quit IRC11:59
*** markvoelker has quit IRC12:01
*** tosky_ is now known as tosky12:01
*** markvoelker has joined #openstack-tc12:05
*** jamesmcarthur has joined #openstack-tc12:07
*** markvoelker has quit IRC12:17
*** markvoelker has joined #openstack-tc12:17
*** markvoelker has quit IRC12:19
*** jamesmcarthur has quit IRC12:19
*** jamesmcarthur has joined #openstack-tc12:20
*** jamesmcarthur has quit IRC12:33
*** jamesmcarthur has joined #openstack-tc12:52
*** markvoelker has joined #openstack-tc13:01
*** mriedem has joined #openstack-tc13:22
*** jamesmcarthur has quit IRC13:40
*** jeremyfreudberg has joined #openstack-tc13:52
*** david-lyle has quit IRC13:55
*** david-lyle has joined #openstack-tc13:55
*** njohnston has quit IRC14:12
*** njohnston has joined #openstack-tc14:12
njohnstontc-members, is my ZNC broken or is this the time for the Technical Committee Meeting?14:13
mnasernjohnston: i believe the meeting was moved off to the 10th14:13
mnaserdue to timezone and availablities14:13
jungleboyjmnaser: ++14:13
njohnstonAh, understood.  Thanks!14:13
*** jamesmcarthur has joined #openstack-tc14:14
*** lpetrut has quit IRC14:16
*** ricolin has joined #openstack-tc14:17
evrardjpit was indeed. It was send through email14:24
*** jeremyfreudberg has quit IRC14:33
*** jamesmcarthur has quit IRC14:35
*** jamesmcarthur has joined #openstack-tc14:40
*** jamesmcarthur has quit IRC14:41
*** jamesmcarthur has joined #openstack-tc14:44
gmanno/14:52
*** dhellmann_ has joined #openstack-tc14:52
*** iurygregory_ has joined #openstack-tc14:52
*** dhellmann has quit IRC14:52
*** dhellmann_ is now known as dhellmann14:52
*** iurygregory has quit IRC14:54
*** jamesmcarthur has quit IRC14:57
*** tetsuro has joined #openstack-tc15:00
ricolino/15:00
*** jamesmcarthur has joined #openstack-tc15:00
zanebo/15:00
jungleboyjo/15:00
njohnstono/15:01
fungijust a reminder if some folks didn't see scrollback from wednesday office hour, the opendev infrastructure sysadmins are looking for input on and assistance with this spec for updating our static content hosting platform: http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-10-02.log.html#t2019-10-02T01:02:1115:02
fungiclarkb is indisposed today, but i'm happy to answer questions15:03
*** tetsuro has quit IRC15:04
evrardjpthanks for the reminder fungi15:04
evrardjpI know an ansible project that would benefit from having a generic haproxy role worked all together :)15:05
fungii think the haproxy bits in there are more of an implementation detail15:06
fungiit's specifically a suggestion for being able to host an http redirector15:06
evrardjpindeed. it was a  side note.15:06
fungiwhich we currently already do with apache vhosts, so may just wind up continuing to do that part the same way instead15:06
evrardjpI am not too familiar with our AFS process, but for static hosting, would it make sense to use swift more?15:08
evrardjpjust curious15:08
evrardjpI am also very curious about why the governance website weights 200 mbs on afs15:10
ricolinfungi, Do we know when will forum schedule released by now?15:10
evrardjpdarn you opened a pandora box :)15:10
ricolinevrardjp, would like to see what's been proposed. maybe some good one for U/V cycle goal?:)15:11
evrardjpoh you mean the official acceptance of each of the sessions we proposed for the forum?15:12
ricolinyes15:13
evrardjpI haven't received any feedback yet. It's on the agenda for next meeting, but any update is welcomed indeed :)15:13
evrardjpI would also encourage people to update the agenda, as I will send it to the Ml today15:13
fungiricolin: i'm not sure, but jamesmcarthur may have some idea15:17
fungievrardjp: if the governance site were already in afs, you could browse all the files for it as a network filesystem on a local mountpoint, but i can probably get you a summary in a moment15:19
jamesmcarthurhi - I'll be publishing the schedule for review later today15:19
evrardjpthanks jamesmcarthur15:19
jamesmcarthurI'll put out a mock schedule in a spreadsheet sooner rather than later and then also add it to the web/app schedule while we're waiting for approval15:19
ricolinthanks jamesmcarthur for the hard works!15:20
fungievrardjp: as for afs over swift, it's hard to set up replication between different swift deployments in different service providers, whereas afs can be distributed and replicated between any providers where we set up a backend for that afs cell. also we can set up frontends in as many providers as we like for increased cross-provider redundancy15:20
evrardjpthanks for the info. Sad to hear it though, but pragmatic wins the day here15:21
*** jamesmcarthur has quit IRC15:21
fungievrardjp: but also you gain the ability to browse all that content locally as /afs/openstack.org/...15:22
fungi(there is a built-in afs client in newer linux kernels called kafs, or you can just install the openafs kernel module)15:22
fungisimple example for anonymous read-only access: https://docs.openstack.org/infra/system-config/afs.html#client-configuration15:23
evrardjpfungi: oh really?15:23
evrardjpTIL15:23
fungiit's super handy. docs.openstack.org is there already at /afs/openstack.org/docs/15:24
evrardjpI should mount that once, and happy browse/send my stats toolings there15:25
fungiso we're basically proposing moving our other sites to use the same file management and jobs as the openstack docs site15:25
*** jamesmcarthur has joined #openstack-tc15:30
evrardjpI am not sure what's the impact for the TC (except a downtime during the migration)15:32
evrardjpand for others15:32
fungiwell, we tried to expand on that question during wednesday office hour if you read that discussion15:32
evrardjpCould you clarify the required input from the TC?15:32
evrardjp0k let me re-read this I have missed it15:32
fungithe summary, to quote my last comment there, is "we're hoping to 1. get input on the plan presented there, and 2. see if there are some folks willing to help with the publication job updates, but also 3. maybe think about ways we could compromise on simplifying all this current site sprawl"15:33
mnaseri wonder if running a stateless service that fetches things from different object storages might make our life easy15:35
evrardjpok let me rephrase my question then. Does raising this during the office hours is for the 3 elements at the same time, or do you want us to focus on one of those points, like the 3rd?15:35
evrardjpI am fine with raising the 3 elements here, too :)15:36
fungimnaser: if there's already a tool to be able to fetch or direct requests for specific files to different object stores, that could solve the provider redundancy use case. but also afs has existed for a very, very long time and seems to work really well for this so not sure why there's any need to reinvent that wheel15:38
fungievrardjp: in my opinion those three points were more or less in priority order. to rephrase 1. opendev seeks input from the projects it's hosting on major infrastructure changes, 2. opendev works best when it receives assistance from the projects it's hosting in making major infrastructure changes, and 3. opendev appreciates if projects it's hosting can evaluate the demands they represent on the15:41
fungiinfrastructure and sysadmin contributors and finds ways to reduce their workload15:41
mnaserfungi: oh gotcha, i thought afs was a painpoint in all of this15:41
mnaserfair enough :)15:41
evrardjpfungi: got it15:41
fungimnaser: nope, afs is what we're moving toward. the pain point is a single webserver with a bunch of cinder volumes attached to it15:42
mnaserlets move to a single web server with one cinder volume attached to it instead (kidding, kidding)15:42
fungiheh. you joke, but that has been discussed in the past ;)15:42
evrardjp:)15:42
mnaserpersonally i trust the opendev team to know what's best, but we do have a bunch of websites, but i dont think the overhead of it seems too wild15:42
mnaseri dont know if restructuring our content is a good thing right now, heck, i'm annoyed by how hard it is to find _recent_ documentation these days15:43
mnaser99% of search results are juno and mitaka15:43
evrardjpmnaser: I think that's why fungi raised the multiple elements here. It's not only enough to trust them, we should help them :)15:43
evrardjpmnaser: god yes15:43
mnaseri can volunteer some time if necessary to help the openstack side of things in doing all of this if needed15:44
evrardjpbut that's SEO of our website and refactoring the search, not really refactoring the infra15:44
fungiwell, one of the main painpoints, and where significant compromise could be considered, is the shared jurisdiction between the openstack infrastructure team and the osf web dev team over the openstack.org domain. but yes i understand that moving things to other domains or trying to combine existing subdomains into fewer subdomains is a challenge in more ways than one15:44
mnaseri'm torn on that one15:44
mnaseri like the fact we are under openstack.org (and i think corvus mentioned that the zone can be co-managed together with the infra team)15:45
mnaserbut what could be the alternative is having authoritative subdomains per 'opendev tenant'15:45
mnaseri.e.: *.openstack.opendev.org and then we can just point CNAMEs to things15:46
fungiopendev has a robust dns management implementation backed by revision control, code review and continuous integration/deployment. the management workflow for that works really well for the opendev sysadmins (and is how opendev.org and zuul-ci.org are hosted now)15:46
mnaseri assume because of cloudflare openstack.org is a little harder to manage there.15:46
mnaserwhich has good and bad (it'll be pretty helpful for shanghai for example)15:46
fungibut asking the web devs and designers at osf to submit to code review workflows for things hasn't gotten much traction in the past15:46
fungiso we end up with openstack.org locked up in rackspace's proprietary dns hosting platform behind a terrible webui and proprietary rest api15:47
mnaseri think openstack.org might be on cloudflare now15:47
fungithat's another risk, yes15:47
mnasernope its not15:47
fungiwell, it is and it isn't15:47
fungiosf has authorized a *.opendev.org wildcard cert for cloudflare, so cf can in theory impersonate any of the services opendev is hosting in the openstack.org domain currently15:48
fungier, i mean *.openstack.org15:48
mnaseri think cf could also theoritically impersonate a big part of the internet these days =P15:48
fungiopendev.org ssl certs are managed via letsencrypt/acme automation15:48
mnaserwith osf.dev becoming more of a thing, we (openstack) can start managing openstack.org a bit more.  so we can take the initiative of moving it over (and i think we make far more dns modifications than osf does)15:49
mnaserand i can def pick that up, if i convince the right people that they wont have to do anything :)15:49
mnaserthat way openstack.org will live under opendev's dns15:49
fungiyeah, it would be great if osf eventually agreed to hand management of the openstack.org dns over to opendev completely, but that's probably still a long way off because of their investment in a lot of web properties important to them on subdomains they want to change dns records for regularly15:50
mnaseris each zone in opendev managed in an individual repo?15:50
fungiyes15:50
fungiwell, to an extent. for example zuul-ci.org and zuulci.org are both in the same opendev/zone-zuul-ci.org repo15:51
mnaserso technically we can have osf staff as cores there15:51
mnaseri mean i guess fungi has a lot more context for this conversation than i ever will :)15:51
fungiyes, i think the bigger challenge is they want to be able to make ~immediate dns changes and don't necessarily want to put that through code review15:52
evrardjpI appreciate the ~ before immediate :p15:52
mnaserright, i mean nothing stops them from +W their own changes15:53
mnaseri think.. we can trust them :)15:53
fungiwell, nothing about dns is ever *truly* immediate ;)15:53
mnaserbut i can imagine a few reasons where it might make sense that they dont want this type of thing15:53
evrardjpfungi: exactly :p15:53
mnasereg: creating shanghai-summit.openstack.org and not wanting folks to know about it15:53
mnasercause that wasnt announced yet or something15:54
fungievrardjp: i think it's that there are a number of stakeholders in osf who would like to be able to make dns changes directly without having to learn non-webgui tools to be able to do that enbd-to-end15:54
evrardjpfungi: yes that's what I understood from the convo. Not sure if that message was for me :p15:54
evrardjpThanks for sharing this topic again15:55
fungilearning git can be a stumbling block, and also a frustration for, say, an executive who wants to make an emergency dns change and can't afford to spend 15-30 minutes (or more) to set up a dev environment and refamiliarize themselves with the tools15:55
fungievrardjp: er, yeah i think i meant to respond to mnaser15:56
evrardjpfungi: are you in fungi timezone again? :)15:56
fungii'm always in my timezone15:56
evrardjpif you spend more than 5 seconds to respond yes, it definitely reached its intent15:57
evrardjphahaha15:57
jungleboyjWhen is an executive making changes?15:57
fungijungleboyj: in a very small nonprofit organization with lots of stakeholders who all have the keys to everything15:57
jungleboyjfungi:  Ah, fair enough.15:57
jamesmcarthuryeah, it happens more often than you'd think15:58
fungithat can present its own change tracking challenges of course15:58
jamesmcarthurIf our servers go down or we have to switch something out on the fly for whatever reason.15:58
jamesmcarthurat the end of the day, there are a handful of us, but we sometimes need critical changes made in 5 minutes15:59
evrardjpI love swift/s3 for static hosting.15:59
evrardjpI won't bring that again, promise15:59
evrardjpahem15:59
fungievrardjp: i think the www.openstack.org site is actually using swift for a lot of that content16:00
fungibut yeah, to recap, basically managing sites in openstack.org is an additional level of burden for the opendev sysamdmins because they're unable to use their preferred tooling/automation for dns and ssl cert management, so reducing (if not eliminating) the number of such sites helps their efficiency tremendously16:00
njohnstonSounds convincing to me16:01
mnaserdoes openstack.org use letsencrypt?16:01
jamesmcarthurwe do16:01
fungiin some places, yeah. also cloudflare in some i think?16:01
mnaseris there a way for opendev.org to use the same letsencrypt keys so it can automagically do ssl things16:02
mnaseresp that wildcards with dns verification is possible16:02
mnaserso once infra has the right keys they can gnerate certs to *.openstack.org16:03
fungithe automation opendev uses for letsencrypt is designed to be able to create certificates before the server which would host the site even exists, so does it through dns validation16:04
fungithis would basically require that automation to grow integration into rackspace's proprietary dns management rest api, and we're pretty set on sticking to apis for open-source software instead16:04
jamesmcarthurwe already have automation set up for letsencrypt on openstack.org16:04
mnaserright but you dont need to do automation for specific domains16:05
mnasermy idea is adding support for *.openstack.org via dns16:05
mnaserand then you can just use that to generate as much certs as you want16:05
fungiyes, we basically don't want our cert management automation dependent on proprietary dns hosting16:06
fungiso for now plan to stick to automating cert generation/distribution for domains hosted in opendev16:07
*** iurygregory_ has quit IRC16:07
mnaserok but you dont have to add support for properitary dns hosting16:08
mnaserwe literally ask the osf to add one record and then we can generate as much wildcard certs as we want/need16:08
fungiin principle that still relies on the domain which is being hosted in a proprietary platform16:08
fungithe (fuzzy) division of responsibility we've established is that work being done under the opendev name should work toward independence from proprietary software and services16:09
mnaserok but cant we just reach a middle-man comprimise ?16:09
mnaserid rather see security.openstack.org instead of security.openstack.opendev.org or whatever alternative we have16:09
fungithe middle-man compromise at this point is that work which touches proprietary systems is being done by the openstack infrastructure team, not the opendev sysadmins (even though many of them are the same people)16:09
mnaserso if someone from the openstack community was to volunteer their time to make this work, would this be accepted by opendev?16:10
corvusthe dns records from the hosts still won't be managed by our tooling either -- so if we move a fileserver, someone has to go click in the web interface.  we can't just grep for all the records that point to it.16:10
jamesmcarthurftr - I believe there are legal reasons as well that the foundation controls that openstack.org domain16:10
mnasercorvus: right, but we can workaround that with CNAMEs16:10
mnasersecurity.openstack.org CNAME's to security.opendev.openstack.org16:10
jamesmcarthurjbryce: is not able to jump on now, but he has offered to answer any questions along those lines via email (he's currently in Sweden at dinner)16:11
fungireducing the number of subdomains would be a good start as well. so while docs.opendev.org/openstack/security would be an ideal place for security.openstack.org, docs.openstack.org/security would still be an improvement to reduce the subdomain sprawl16:11
corvusjamesmcarthur: i don't think we've ever proposed changing who 'controls' the domain, just what tools we use to work together to manage it16:11
jamesmcarthuryep, just offering some additional clarification about why it's on rackspace16:11
corvuswe tried to design the system we're using for opendev as a model for how multiple groups of people can work together to manage zones16:12
jamesmcarthur+1 to fungi's proposal on docs.opendevorg/openstack ... but keep in mind there are big SEO hits there16:13
corvuswe'd never suggest changing the domain ownership or contacts.  just the delegated dns servers16:13
fungi(and management interface of course)16:13
jamesmcarthurcorvus: thanks for the clarification. I'm jumping in a bit late to the discussion :)16:13
corvusme too :)16:13
corvusmnaser: i'd like to understand more about your LE delegation ida -- can you spell that out in a little more detail?16:14
corvusida/idea16:14
mnasercorvus: right, so when you issue a cert, you are given a challenge and you have to create a dns record (dns01) or http page (http01) -- dns01 verification supports wildcard certs, so we can make a request for *.openstack.org (inside opendev.org), grab the challenge, give it to osf to add to the dns, and then grab ourselves an ssl cert for *.openstack.org that we can leverage across all other domains afterwards16:16
mnaserso the only manual step is the dns record creation16:16
mnaseranother idea is16:17
mnaserwe can delegate _acme-challenge subdomain to opendev.org16:17
mnaserso we get a one time delegation of _acme-challenge.openstack.org to the opendev nameservers, and control that zone with all of our automation that we need16:18
mnaserthe only hard thing is that if osf relies on letsencrypt too, we might have to see how we can coordinate that part.. but perhaps that might be an easier thing to solve16:18
fungiianw has a proposal to do basically that, but we're doing our best not to tie opendev automation to proprietary services and attempting to continue moving more things away from them where they do have any lingering ties16:18
mnaserif delegatin the subdomain is still conisdered being tied to a proprietary service16:20
mnaseri feel like that a bit too much16:20
corvusmnaser: can we individually delegate, say "_acme-challenge.docs.openstack.org IN CNAME acme.opendev.org" ?16:22
corvus(er, add a trailing '.' there of course :)16:22
mnasercorvus: yes!16:23
mnaserhttps://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation under "Separate and Limited Privileges"16:23
mnaser"Let's Encrypt follows the chain of CNAME records and will resolve the challenge validation token from the last record in the chain."16:23
corvusso, to construct a strawman proposal here: we could, for every foo.openstack.org host, add two cnames: one for the server and one for acme.  that would limit the openstack.org dns interaction to the following cases: 1) creating or deleting a "virtual webserver"; 2) changing the name of the target cname (eg files.opendev.org)16:25
corvusdoes that sound about right?16:25
mnasercorvus: actually looking there too, the strategy in "Use a "Throwaway" Validation Domain" makes sense too16:26
corvusmnaser: fwiw, we use the acme cname delegation already in opendev -- it was unclear to me whether that would work across the second-level domain boundaries: https://opendev.org/opendev/zone-opendev.org/src/branch/master/zones/opendev.org/zone.db16:26
mnaseroh gotcha16:27
mnaseryes, it seems like it would16:27
fungiseems like it should16:27
mnaserand yes, i think what you suggest would work, it might be a little more work on the osf but i think they'd be okay with that (and being able to have the ability to make quick changes)16:28
mnaseri would even go for 'project' specific target cname's, just to give us more control long term (i.e. static.openstack.org points to files.openstack.opendev.org points to files.opendev.org)16:29
mnaserbut thats just details :)16:29
corvusokay, i think we should consider that proposal.  i would love for us to all work together on automating all the things, and still hold out hope that we can do that with dns at some point.  it would let us create a more flexible infrastructure where we're able to easily and automatically let anyone from the openstack project create any openstack.org site (with proper collaboration and approval).  but16:32
corvusif we (as a big wide community that involves opendev, tc, osf) aren't ready to work together on that, then this system where we have specific arms-length interaction on certain websites does seem like it may be workable from my perspective, and i think it's worth consideration.16:32
jamesmcarthurcan you all write up a proposal for this and send it to Jonathan and cc me?16:34
mnaserjamesmcarthur: you're thinking proposal for the moving all dns (or the strawman of leaving openstack.org at rax but with ability to let infra generate certs and all)16:34
jamesmcarthurthe strawman16:35
mnaseri can help out with that if someone is interested :)16:35
corvusi'd be happy to write up my happy-hippy proposal for dns love.  i think the strawman would be pretty brief.  it's "infra does even less with openstack.org dns than they already do".  someone else can write that up.  :)16:36
corvusbut maybe do that after the next infra team meeting16:36
*** e0ne has quit IRC16:36
fungiyeah, there's not much to say about that16:37
fungibasically creating some additional acme validation cnames for names of sites served from services infra is already managing16:38
fungie.g. docs.openstack.org and the like16:38
fungidocs.starlingx.io is another good non-openstack example suppose16:39
*** david-lyle has quit IRC16:44
*** david-lyle has joined #openstack-tc16:45
*** david-lyle has quit IRC16:45
*** dklyle has joined #openstack-tc16:46
*** jbryce has joined #openstack-tc16:49
mnaserfungi, corvus, jamesmcarthur: https://etherpad.openstack.org/p/openstack-org-dns i just wrote this up16:51
jamesmcarthurthanks!16:51
mnaserhappy to get feedback :)16:51
corvusmnaser: that matches my understanding of the strawman, thx16:53
corvuslet's put that on the next infra meeting agenda16:54
* corvus edits wiki16:54
corvushttps://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting updated16:55
fungii've added a couple of minor clarifications to the pad17:02
fungiindicating why the scope of work for osf staff will be small and should also decrease over time17:03
* mnaser feels like the lack of authoritative domains for openstack content isn't the most ideal17:13
mnaserbut we can discuss that when the time comes17:13
*** tosky has quit IRC17:14
fungiyeah, as i said, having something like docs.openstack.org/governance/tc and docs.openstack.org/security and docs.openstack.org/releases and so on, all on the same subdomain instead of scattered across lots of them would be nicer to users, in my opinion17:16
fungiand that would also reduce the number of ssl certs needed17:17
fungiand simplify publication jobs even more17:17
fungithe reason why we ended up with so many from the outset is that the osf controlled www.openstack.org so we couldn't easily publish to it with automation, the docs team was originally *very* concerned about any content not controlled by them getting published to docs.openstack.org (and also it was hosted on rackspace cloudfiles for a very long time), so there was no great place for different teams to17:18
fungipublish content of their own17:18
*** jamesmcarthur has quit IRC17:18
*** jamesmcarthur has joined #openstack-tc17:19
mnaseryeah but that'll cause a lot of seo related issues17:19
mnaserand its not like our docs arent confusing on their own17:19
fungithe www.o.o challenge still remains, but with the decentralization of docs management in more recent years we could at least put more there if we want17:20
fungianother alternative would be hosting all the non-docs stuff somewhere like project.openstack.org (similar to how the apache project coexists with their foundation)17:20
*** openstackgerrit has quit IRC17:21
mnaseri think the only way i'd be okay with us doing that is if we put a serious effort into redirects17:22
mnaser(like the type of effort we did with gitea for example)17:22
fungiwell, if we don't alter the structure within those trees, redirects are simple (and i would consider redirecting a necessary component of any consolidation like that regardless)17:23
fungiit wouldn't need to be anywhere near as complex as the cgit->gitea redirects. that was essentially mapping a web application to another web application17:24
fungiin contrast, content redirection for this wouldn't need more than a rule or two per site17:24
fungiredirecting all the content of security.openstack.org to docs.openstack.org/security would only need a single rule17:26
mnaser++17:33
*** ricolin has quit IRC17:35
*** jamesmcarthur has quit IRC17:51
*** jamesmcarthur has joined #openstack-tc17:51
*** jamesmcarthur has quit IRC17:52
*** e0ne has joined #openstack-tc17:59
*** e0ne has quit IRC18:06
*** spsurya has quit IRC18:07
*** jamesmcarthur has joined #openstack-tc18:47
zanebI agree that it shouldn't be as complicated as gitea, but we don't have a great track record of redirecting deep links in general18:53
*** lpetrut has joined #openstack-tc18:58
*** lpetrut has quit IRC18:59
*** lpetrut has joined #openstack-tc19:00
fungiagreed, but site moves/aggregation don't really change that. has more to do with becoming diligent about updating redirect hints every time we do a git mv19:03
fungiand reviewing with that in mind19:04
zanebI'm talking about the fact we have done complete site moves and only put in shallow redirects in the past19:08
zanebyou can check it out by visiting https://api.openstack.org/ right now :(19:10
*** lbragstad has quit IRC19:11
fungii think that was an ancient redirect set up in cloudfiles, which has now been sold to liquidweb19:16
fungiif memory serves, cloudfiles redirect sites didn't provide much flexibility in that regard19:16
fungiwe could easily set a more proper redirect for it on servers we control since docs.o.o/developer.o.o moved off cloudfiles ages ago19:17
fungiif anyone sees value in trying to resurrect api.openstack.org urls it wouldn't be hard at all19:18
*** lpetrut has quit IRC19:41
*** gmann is now known as gmann_afk19:52
*** jamesmcarthur has quit IRC20:21
*** lbragstad has joined #openstack-tc20:29
*** tosky has joined #openstack-tc20:50
*** camelCaser has quit IRC21:28
*** camelCaser has joined #openstack-tc21:28
*** markvoelker has quit IRC22:30
*** jamesmcarthur has joined #openstack-tc23:23
*** tosky has quit IRC23:23
*** jamesmcarthur has quit IRC23:24
*** mriedem has quit IRC23:26

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