15:00:25 <mnasiadka> #startmeeting kolla
15:00:25 <opendevmeet> Meeting started Wed Sep 15 15:00:25 2021 UTC and is due to finish in 60 minutes.  The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:25 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:25 <opendevmeet> The meeting name has been set to 'kolla'
15:00:45 <mnasiadka> Good afternoon, sorry for the lack of pre-meeting notification, but was busy in a customer workshop.
15:00:52 <mnasiadka> #topic rollcall
15:01:29 <mnasiadka> mgoddard mnasiadka hrw egonzalez yoctozepto rafaelweingartne cosmicsound osmanlicilegi bbezak parallax Fl1nt - meeting in progress
15:01:36 <mgoddard> \o
15:02:24 <priteau> o/
15:02:32 <mnasiadka> o/
15:03:15 <parallax> \o/
15:05:42 <mnasiadka> #topic rollcall
15:05:48 <mnasiadka> ups
15:05:50 <mnasiadka> #topic agenda
15:06:00 <mnasiadka> * Announcements
15:06:00 <mnasiadka> * Review action items from the last meeting
15:06:00 <mnasiadka> * CI status
15:06:00 <mnasiadka> * Should we actually backport https://review.opendev.org/c/openstack/kolla-ansible/+/805449 ?
15:06:00 <mnasiadka> * Discuss https://review.opendev.org/c/openstack/kolla-ansible/+/692179/
15:06:02 <mnasiadka> * Release tasks
15:06:02 <mnasiadka> * Xena cycle planning
15:06:04 <mnasiadka> * Yoga PTG planning
15:06:04 <mnasiadka> * Open discussion
15:07:07 <mnasiadka> #topic Announcements
15:07:12 <mnasiadka> I have no announcements, and don't know about any other announcements to make. Let's move on.
15:07:22 <mnasiadka> #topic Review action items from the last meeting
15:07:36 * mnasiadka yoctozepto to point all deployments to quay.io
15:08:32 <mnasiadka> change in review - so let's say it's done.
15:08:40 <yoctozepto> ++
15:08:56 <mnasiadka> I haven't done my actions, so let me add them once again
15:09:10 <mnasiadka> #action mnasiadka to update docs encouraging to build your own containers and run your own registry
15:09:21 <mnasiadka> #action mnasiadka to create pull-retag-push blueprint based on kayobe RFE: https://storyboard.openstack.org/#!/story/2007731
15:09:36 <mnasiadka> #topic CI status
15:09:47 <mnasiadka> No new breakages I assume? ;-)
15:10:24 <mnasiadka> Kayobe has some issues with disk space on stable branches
15:10:38 <mnasiadka> Is there anybody handling that?
15:11:15 <priteau> Not yet. I've just updated the white board
15:11:49 <priteau> I was first thinking of adding some code looking for where disk space is used in the post-job role
15:11:50 <mgoddard> I don't think it happens every time, does it?
15:12:03 <priteau> Not every time, but quite often in upgrade jobs
15:12:37 <priteau> e.g. https://zuul.opendev.org/t/openstack/builds?job_name=kayobe-overcloud-upgrade-centos8s&project=openstack%2Fkayobe&branch=stable%2Fwallaby
15:12:46 <mgoddard> I have a patch for the monasca CI job: https://review.opendev.org/c/openstack/kolla-ansible/+/807689
15:12:53 <mnasiadka> priteau: if Zuul is reporting DISK_FULL - then it's on the executor and there's a limit, if it's in the job output itself - then it's in a different place.
15:14:01 <mgoddard> priteau: one major difference with kayobe vs kolla upgrade jobs is kayobe does baremetal testing
15:14:12 <mgoddard> maybe those disks push it over the limit
15:14:41 <mgoddard> +1 to checking usage
15:15:23 <mnasiadka> infra has a way of checking what was the real disk usage in zuul logs (on the executor after a job has failed) - might just ask
15:16:16 <mnasiadka> ok, I think it has enough traction - we just need to look into that
15:16:30 <mnasiadka> #topic Should we actually backport https://review.opendev.org/c/openstack/kolla-ansible/+/805449 ?
15:18:06 <mnasiadka> Should we? Actually it's not good that we're automatically assuming docker-registry is insecure - but that's sort of a breaking change for users.
15:19:42 <yoctozepto> it's kind of prereq to switching to quay.io
15:19:57 <yoctozepto> due to the logic that will get triggered otherwise
15:20:15 <yoctozepto> but then again, we might only switch to quay.io xena+
15:20:21 <mgoddard> that suggests to me we can't backport quay
15:20:30 <yoctozepto> mhm
15:20:40 <priteau> I am worried that it could break some people who actually have a secure deployment already, for example because their registry is on an internal network only
15:20:43 <mnasiadka> why prereq? we've been using docker hub as insecure? ;-)
15:21:00 <yoctozepto> mnasiadka: dockerhub is not set as registry; it's builtin
15:21:05 <yoctozepto> ;-)
15:21:24 <mnasiadka> oh boy
15:21:50 <mnasiadka> I wouldn't like to be surprised as a user with that
15:22:22 <yoctozepto> I guess me neither; perhaps let's do both on xena only?
15:22:32 <opendevreview> Pierre Riteau proposed openstack/kayobe master: CI: Log disk usage details  https://review.opendev.org/c/openstack/kayobe/+/809209
15:22:53 <mnasiadka> I agree, mgoddard seems to agree, yoctozepto seems to agree
15:23:26 * yoctozepto always agrees to have less work
15:23:33 <mnasiadka> anybody disagrees?
15:24:08 <parallax> no :)
15:24:12 <mnasiadka> #agreed Not to backport change 805449 - quay.io will be default only on Xena+
15:24:30 <mnasiadka> #topic Discuss https://review.opendev.org/c/openstack/kolla-ansible/+/692179/
15:24:39 <mgoddard> 1 sec
15:24:49 <mgoddard> seems we forgot to update this: https://docs.openstack.org/kolla-ansible/latest/user/multinode.html
15:25:19 <mnasiadka> right
15:25:23 <mnasiadka> yoctozepto: keen to follow up?
15:25:25 <mgoddard> users now need to set insecure if they run a registry
15:25:35 <mnasiadka> or have a secure registry
15:25:51 <opendevreview> Pierre Riteau proposed openstack/kayobe stable/victoria: CI: build CentOS Stream deployment images  https://review.opendev.org/c/openstack/kayobe/+/809164
15:26:18 <mgoddard> yes
15:26:26 <mnasiadka> Maybe a hacky guide how to do docker-registry with lets encrypt certs?
15:26:27 <mgoddard> I meant if they follow those instructions
15:26:54 <mgoddard> would rather say nothing that provide a hacky guide :)
15:27:06 <mnasiadka> So no guide then
15:27:12 <mnasiadka> But docs update needed
15:27:37 <yoctozepto> mnasiadka: what followup?
15:27:39 <mgoddard> including insecure health warning
15:28:03 <mnasiadka> yoctozepto: docs, see ^^
15:28:14 <yoctozepto> read, got it
15:28:24 <yoctozepto> but it gets changed with quay
15:28:33 <yoctozepto> so I'm not doing a noop change inbetween
15:28:36 <priteau> Let's Encrypt only makes sense if you use a public domain name, right? I assume many places would have a local registry on a private network
15:28:36 <yoctozepto> ;p
15:28:48 <yoctozepto> see https://review.opendev.org/c/openstack/kolla-ansible/+/808486
15:29:04 <yoctozepto> I will fix it in there
15:29:25 <mnasiadka> that's the spirit
15:30:31 <mnasiadka> #action yoctozepto to fix multinode docs after defaulting to secure registry
15:31:02 <mnasiadka> So, let's get to the actual topic - which is the Keystone scoped auth
15:31:33 <mnasiadka> who is the actual owner of that change? I see 4 names in owner/uploader/committer/author
15:31:50 <headphoneJames> let's say it is me
15:32:33 <mgoddard> headphoneJames is currently in scope
15:32:57 <headphoneJames> I am the one driving this one forward during our current cycle
15:33:20 <mnasiadka> ok, I see that a split to smaller changes has been agreed
15:33:25 <mgoddard> but who is driving this conversation? :)
15:33:45 <headphoneJames> I understand we need to break this into smaller chunks, mgoddard has proposed a sensible approach
15:34:43 <mnasiadka> Fantastic, two weeks to feature freeze - what is realistic to merge?
15:34:58 <mgoddard> first chunk
15:35:07 <headphoneJames> yup
15:35:16 <headphoneJames> it's a pretty small chunk
15:35:48 <headphoneJames> just to use system scope for the keystone admin user
15:36:58 <mgoddard> I'm away next week
15:36:59 <mnasiadka> Ok then, so let's start with that
15:37:18 <headphoneJames> For the second chunk, I need to go through the service user roles and  determine if they should have project scopes roles versus system scoped.
15:37:20 <mgoddard> so merging more might be difficult, unless others want to weigh in
15:37:36 <headphoneJames> I am not sure how to do that
15:37:50 <mgoddard> Yes. All roles are assigned in register.yml files
15:38:03 <mgoddard> mostly using the service-ks-register role
15:38:37 <mgoddard> so you can check *_ks_users and *_ks_user_roles
15:39:12 <mgoddard> mostly this is just 'add <project, e.g. nova> user in service project with admin role'
15:39:12 <headphoneJames> I don't know which users require project scoped roles
15:39:26 <mgoddard> those ones should be system scoped
15:39:51 <mgoddard> anything that veers away from that may be worth raising
15:40:18 <mnasiadka> Maybe let's start with the obvious ones, and keep discussing in the change about the ,,unsure'' ones?
15:40:25 <headphoneJames> almost every *_ks_users have a service project defined
15:41:12 <mgoddard> yes
15:42:11 <mgoddard> should we have a period where we assign roles with both system and project scope?
15:42:23 <mnasiadka> Probably that would be the safest choice.
15:43:11 <headphoneJames> That is simple enough for the second chunk.
15:44:41 <mnasiadka> Ok, so when the first and second chunk would be ready for initial reviews? Is it possible this week for chunk #1? (so mgoddard can lay out his thoughts before vacation)
15:45:17 <headphoneJames> I can get the first one done this week. I will try to have it for you tomorrow
15:45:33 <headphoneJames> if not, I'll just focus the efforts in the next release
15:45:41 <mgoddard> that would be great, as friday is usually busy for me
15:45:56 <mgoddard> although I suppose your tomorrow is my friday
15:46:03 <mnasiadka> friday before vacation is always busy :)
15:46:55 <headphoneJames> It can get pushed to the next release if you don't have time on Friday
15:47:42 <mnasiadka> Surely some parts will get pushed to next release, but let's try to get something in.
15:49:07 <mnasiadka> Ok then, let's continue
15:49:22 <mnasiadka> #topic Release tasks
15:49:31 <mnasiadka> None according to Kolla's release calendar.
15:49:39 <mnasiadka> #topic Xena cycle planning
15:50:18 <mnasiadka> Let's try to look into the whiteboard if anything got merged.
15:50:57 <mnasiadka> Ansible - there are still two changes to merge - https://review.opendev.org/c/openstack/kolla-ansible/+/796758 and https://review.opendev.org/c/openstack/kolla/+/807279 - probably waiting for yoctozepto
15:53:21 <mnasiadka> Swift role looks like it's ready for reviews - https://review.opendev.org/c/openstack/kolla-ansible/+/797498
15:53:31 <mnasiadka> mgoddard: do you think you can look into this tomorrow/Friday?
15:53:42 <mgoddard> will try
15:54:48 <mnasiadka> kevko's proxysql topic seems to not get traction, I doubt we'll get it in this cycle...
15:55:13 <mnasiadka> I need to look into Kayobe reviews, will try tomorrow.
15:55:55 <mnasiadka> Let's move to Yoga
15:56:01 <mnasiadka> #topic Yoga PTG planning
15:56:40 <mnasiadka> mgoddard: do we need to do anything? Send a mail to ML about planned sessions and etherpad link?
15:57:11 <mgoddard> I'm not sure if I sent one before, but it wouldn't hurt to remind if so
15:57:14 <mgoddard> #link https://etherpad.opendev.org/p/kolla-yoga-ptg
15:57:37 <mnasiadka> #action mnasiadka to send a mail to ML about Kolla PTG
15:57:57 <mgoddard> are there any 'standard' topics to add?
15:58:03 <mgoddard> e.g. core team cleanup
15:58:15 <mnasiadka> I'll add organizational topics, was thinking about that today.
15:59:06 <mnasiadka> ok then
15:59:09 <mnasiadka> #topic Open discussion
15:59:14 <mnasiadka> one minute left :)
15:59:53 <mnasiadka> Anybody has anything to discuss?
16:01:00 <mnasiadka> ok, time to wrap up
16:01:03 <mnasiadka> #endmeeting kolla