15:00:12 #startmeeting kolla 15:00:13 Meeting started Wed Feb 24 15:00:12 2021 UTC and is due to finish in 60 minutes. The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:17 The meeting name has been set to 'kolla' 15:00:19 #topic rollcall 15:00:23 \o 15:00:33 o/ 15:00:47 \o 15:03:02 \o/ 15:03:17 ]o[ 15:03:48 #topic agenda 15:03:59 hi :P 15:04:03 * Roll-call 15:04:04 * Announcements 15:04:06 * Review action items from the last meeting 15:04:08 * CI status 15:04:10 * Review requests 15:04:12 * yoctozepto: Stop caring about NTP/chrony 15:04:14 * Wallaby release planning 15:04:16 #topic announcements 15:04:19 None from me 15:04:22 Anyone else? 15:04:57 no 15:05:11 #topic Review action items from the last meeting 15:05:15 There were none 15:05:23 #topic CI status 15:07:14 Kolla Train still broken 15:07:25 just rechecked https://review.opendev.org/c/openstack/kolla/+/774602 15:08:19 uf. it was just pull limit 15:09:14 yeah 15:09:25 I've seen multiple occurences of jobs where one of the hosts fail on "Failed to connect to the host via ssh", but that's independent from us... 15:10:01 I started this to track mounting kayobe CI failures: https://etherpad.opendev.org/p/kayobe-ci-failures 15:10:03 do we have ssh retries configured in Ansible? 15:10:36 Seems not really, I'll submit a patch 15:11:17 mnasiadka: is it zuul's ansible or ours? 15:12:24 Hi all, I would like to ask if there are some plans to support Podman instead of Docker in case of kolla and kolla-ansible. Do community want to support it in future? 15:14:33 ohorecny2: hi, we are currently in a meeting 15:14:49 mgoddard: it's ours, during deploy 15:15:07 ohorecny2: there is interest in the community for podman, but no one has started work on it yet. You might want to talk to Fl1nt about it 15:15:28 ohorecny2: I also made a small PoC: https://github.com/stackhpc/kolla-ansible/commit/e44d4b028e3aa24955dd12271783287ae43a5603 15:15:45 mnasiadka: we could try adding retries 15:15:59 mgoddard: that's what I said - will raise a patch :) 15:16:08 mnasiadka: I was agreeing 15:16:43 mgoddard: In darkest corners of my brain I couldn't see a situation somebody would disagree :) 15:16:55 But thank you for agreeing :) 15:17:28 it will only help if the network issues are temporary 15:19:02 #topic Review requests 15:19:11 Does anyone have a patch they would like to be reviewer 15:19:15 *reviewed 15:19:32 https://review.opendev.org/c/openstack/kolla-ansible/+/741340 15:19:47 all WIP 15:20:03 The Lets Encrypt patch is ready, still putting the test together 15:20:45 Michal Nasiadka proposed openstack/kolla-ansible master: CI: Add ssh retries and disable group names validation https://review.opendev.org/c/openstack/kolla-ansible/+/777402 15:21:14 what 's the plan of the octavia management network patch ? i have raised it to email . but no help for me. 15:22:07 @mgoddard: thank you for reply, I will contact @Fl1nt 15:22:11 wuchunyang: bbezak has been investigating 15:22:46 wuchunyang: will see if he's available to discuss 15:22:54 headphoneJames: I'll add RP+1 15:23:41 seems like bbezak is busy 15:23:59 mgoddard: yes, i want to review , but you know :) ..just joking 15:24:03 ok, BTW, who is bbezak . sorry i don't know him. 15:24:06 wuchunyang: bbezak found that qemu-kvm package is the cause. 15:24:09 I've been investigating with him 15:24:18 ok, mnasiadka can update 15:24:33 nice. that's enough to me.. haha 15:24:34 wuchunyang: bbezak is my colleague, Bartosz Bezak 15:24:46 thanks very much. 15:24:59 qemu-kvm 5.1 brings the issue, but it seems it's only problematic if the VM is Ubuntu and the flavor is like 1vcpu 2-4G RAM 15:25:08 on octavia CentOS 8 test image it works properly 15:25:30 on bigger flavors it also works with Ubuntu 15:25:47 and the issue is crashing the VM while adding second port (for vrrp) 15:26:23 bbezak will raise a bug in Nova/qemu, and do a followup on the mailing list 15:26:37 in the meantime, we could pin qemu-kvm to 4.2 in CentOS images 15:26:57 wuchunyang/mgoddard: do we have the same problem on Ubuntu hypervisors? 15:27:06 no 15:27:09 just centos 8 15:27:31 Sorry I'afk. Will update this change and reply to openstack discuss group 15:27:43 I'm afk 15:27:52 bbezak: that's what I wanted to write, that you'll also update the change :) 15:28:38 you said if i use centos image. it should work around this problem. right ? 15:28:46 yes 15:29:19 nice. Let's work around for CI first. 15:30:00 ok 15:30:17 thanks for mgoddard mgoddard mgoddard 15:30:38 mgoddard^3 15:30:58 #topic yoctozepto: Stop caring about NTP/chrony 15:31:07 yoctozepto stopped caring about time 15:31:29 yup 15:31:35 that's the plan 15:31:38 8-) 15:31:54 you mean finally deprecate chrony container? :) 15:31:59 joking aside, this is what we have planned 15:32:02 yes, mnasiadka :P 15:32:12 we are moving this cycle-cycle 15:32:21 time to enact :D 15:32:22 thank to gods of total time chaos 15:33:20 it is time to drop time 15:33:58 seriously though, what is the plan? 15:38:01 yoctozepto? 15:38:48 anyone? 15:39:48 ? 15:40:10 seems like we have lost the leader of this discussion. Let's come back to it later 15:40:28 #topic Wallaby release planning 15:40:48 Friendly reminder: Kolla feature freeze: Mar 29 - Apr 02 15:41:09 mgoddard: sorry, yes, funky connection 15:41:33 you can't see me gone because of my bouncer 15:41:46 anyhow 15:41:49 ok 15:41:51 #undo 15:41:52 Removing item from minutes: #topic Wallaby release planning 15:42:02 thanks 15:42:06 so 15:42:21 afair, kayobe handles ntp on the host side 15:42:41 and any default install configures ntp nowadays 15:42:45 for a myriad of reasons 15:43:19 poor man's option is to recommend an ansible module to manage ntp 15:43:36 (I guess kayobe uses one already, can go with it) 15:43:54 luxurious option would be to integrate it with kolla-ansible 15:43:58 but it is blurry 15:44:08 and I think it belongs to the level of tools like kayobe 15:45:15 kayobe actually removed support for NTP config since CentOS 8 15:45:16 we have timesync prechecks in already 15:45:26 and relies on Kolla Ansible :) 15:45:39 mgoddard: oh gosh 15:45:44 however, we'll probably change change approach 15:46:14 and configure chrony on CentOS, possibly systemd-resolved or chrony on Ubuntu 15:46:31 Marcin Juszkiewicz proposed openstack/kolla master: switch to CentOS 8 Stream https://review.opendev.org/c/openstack/kolla/+/772841 15:46:41 why not systemd-resolved on all distros? 15:46:45 so I don't think it affects this discussion 15:46:56 hrw: chrony is standard out of the box on centos 15:47:14 hold on 15:47:26 sorry, systemd-timesyncd 15:47:36 I'm in sorry ^^ 15:47:45 too many systemd-*d in ubuntu :) 15:47:49 yup 15:48:00 all right then 15:48:20 so we have the timesync prechecks since victoria 15:48:22 https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html 15:48:24 as I mentioned 15:48:38 so the sanity checks are there in case users want to go rogue 8-) 15:48:50 I suppose my only concern is for non-kayobe users who want more than the out of the box NTP config 15:48:52 we can adapt docs 15:48:54 slap renos 15:48:55 go ml 15:49:10 yeah, we would point them to ansible roles for that 15:49:30 galaxy should have something nice 15:49:39 fwiw, I have this part in puppet 15:49:43 15:50:20 systemd-*d are not too many as it is a way to address concerns to people that can't stop complaining that systemd is a monolithic monster that isn't respecting unix principles :p 15:50:21 we have *not* officially deprecated chrony 15:50:28 so we should do a deprec this cycle 15:50:56 which alternative would you like to use? 15:51:14 deprec on both kolla and k-a 15:51:18 and with recommendations 15:51:37 Fl1nt: give recommendations and leave it to the users 15:52:17 ntp is nothing extraordinary nowadays 15:52:26 you mean, we let it free for user as we're now relying on hosts right? 15:53:40 mgoddard, I synced with ohorecny2 about podman btw 15:54:10 Fl1nt: ok, we can discuss in a min if you want 15:54:30 does anyone have opinions on the proposed approach to NTP? 15:54:39 TBN: as we talk about wallaby, in order for me to work on SAML2 keystone SSO, I need the OIDC patch to be merged on master if everything is fine as I'll base my patch on it. 15:54:39 Fl1nt: what hosts? 15:54:48 Fl1nt: we are talking time synchronization 15:54:51 yes 15:54:52 Fl1nt: it's merged 15:55:04 mgoddard, oooh sweet, perfect! 15:55:22 mgoddard: do you have any opinions? 15:55:47 yoctozepto, HW host that provide time to containers services? 15:56:08 yoctozepto: I gave one 15:56:35 yoctozepto: I think we should solicit feedback from the community 15:56:52 personally I can use chrony or systemd-timesyncd no issue as long as it works ^^ 15:56:59 mgoddard: ack 15:57:10 Fl1nt: leaving ntp to users 15:57:16 yes 15:57:56 an NTP client isn't difficult to setup, but it might be a bit annoying for users currently relying on k-a for it 15:58:21 can I just ask why you want to remove chrony/ntp from kolla ? 15:58:32 but if there are no strong objections from the community then I'm fine with it 15:58:37 good question kevko_ :) 15:58:43 :D 15:59:37 so, what is the answer ? :) 15:59:56 honestly, I don't have strong opinion on this one, leave it or remove it I don't really care as long as services are able to get time, personnally all my hosts are ansible bootstraped using chrony for now but don't really care. 16:00:20 to switch to something else 16:00:46 kevko_: mostly because we are forced to handle whatever the host throws at us 16:00:53 and it's extra code to maintain 16:00:58 for no real benefit 16:01:08 it's not like kolla-ansible brings new ntp features to the table :-) 16:01:30 good reason, if it doesn't add any feature or advantage, just remove it. 16:01:43 well hold on 16:01:59 kolla-ansible is about automation, not augmenting network time protocols 16:02:10 yes 16:02:26 well, I don't thing that especially some small chrony image (and k-a part) is difficult to maintain 16:02:46 not to throw a log on the fire, but doesn't k-a still need to do routine checks on ntpd's on system before relying on the hosts either way? k-a is dependant on synced time, laying this out on the enduser could backfire, right? 16:02:51 but the point is, time is already automated pretty much everywhere in enterprise by either the provisioning service or another bootstrap/base ansible internal playbook or puppet or whatever 16:02:52 so if installing and configuring an NTP client makes users lives easier then that is arguably beneficial 16:03:33 rockey: we did add a check that time is synced 16:03:43 are you talking about the chrony container or the host bootstrap configuration task ? 16:03:48 ansible/roles/prechecks/tasks/timesync_checks.yml 16:04:05 Fl1nt: probably both 16:04:16 yeah, the point is that most hosts come with some ntp daemon running 16:04:30 I think for various reasons, we can probably agree that running chrony in a container isn't a great idea 16:04:40 and we spend time fixing bugs on detecting those or adapting security profiles 16:04:42 but mainly what because yoctozepto just said 16:04:51 and it's a very basic service nowadays 16:04:56 yeah, mgoddard 16:05:09 agree, I also added some patch .. 16:05:13 so I'm definitely +1 to removing the container 16:05:17 so, remember 16:05:18 container is probably too much, automate the ntp configuration at task level can still be let as is using chrony or up to the user as long as the appropriate binding is made within services containers. 16:05:32 the question for me is whether it is useful to manage a service on the host 16:05:42 the main use case being to use a custom NTP server 16:05:57 mgoddard: yup, that's what the recommendations would be for 16:06:09 do note k-a never configured a server 16:06:15 so users had to do it elsewhere 16:06:32 I mean, configure the client to use a custom NTP server 16:07:08 that was possible with the chrony container 16:07:19 that only make sense as you pointed out, if kolla/k-a is providing with a ntp server for the cluster, but it's highly unlikely that anyone on enterprise side of things will base their cluster on it as most of ITs or new installation do it on auxilliary/commander/bastion/whatever its named server. 16:07:42 yes, my point is that such users are already knowledgeable enough to do it with any ntp role :-) 16:08:01 mgoddard: well then, as a happy user, i'd +1 the removal too, mostly due to "that most hosts come with some ntp daemon running" statement from yoctozepto 16:08:14 ayeee, we are past time 16:08:17 indeed 16:08:18 action this on me 16:08:24 and let's close 16:08:29 sorry for taking so much time 16:08:37 #action yoctozepto to ask openstack-discuss about NTP 16:08:40 Thanks all 16:08:45 #endmeeting