15:02:14 <mgoddard> #startmeeting kolla
15:02:15 <openstack> Meeting started Wed Oct 14 15:02:14 2020 UTC and is due to finish in 60 minutes.  The chair is mgoddard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:18 <openstack> The meeting name has been set to 'kolla'
15:02:20 <mgoddard> #topic rollcall
15:02:21 <yoctozepto> o/
15:02:25 <mgoddard> \o
15:02:27 <rafaelweingartne> \o
15:02:31 <yoctozepto> \o/
15:02:51 <engel75> \o
15:03:03 <priteau> o/
15:03:12 <wuchunyang> \o
15:04:32 <mgoddard> #topic agenda
15:04:44 <mgoddard> * Roll-call
15:04:46 <mgoddard> * Announcements
15:04:48 <mgoddard> ** OpenStack Victoria released
15:04:50 <mgoddard> ** Kolla now in feature freeze
15:04:52 <mgoddard> ** Submit Virtual PTG topic proposals: https://etherpad.opendev.org/p/kolla-wallaby-ptg
15:04:54 <mgoddard> * Review action items from the last meeting
15:04:56 <mgoddard> * CI status
15:04:58 <mgoddard> * DNS-based endpoint naming https://review.opendev.org/#/c/757847/
15:04:58 <patchbot> patch 757847 - kolla-ansible - Feature to manage public endpoints via DNS names - 4 patch sets
15:05:00 <mgoddard> * Victoria release planning
15:05:02 <mgoddard> ** Review deprecations and other planned removals
15:05:04 <mgoddard> * Wallaby PTG planning
15:05:39 <mgoddard> #topic announcements
15:05:48 <mgoddard> #info OpenStack Victoria released
15:06:12 <mgoddard> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-October/017959.html
15:06:23 <mgoddard> #info Kolla now in feature freeze
15:06:30 <mgoddard> #info Submit Virtual PTG topic proposals
15:06:36 <mgoddard> #link https://etherpad.opendev.org/p/kolla-wallaby-ptg
15:06:39 <mgoddard> Any others?
15:07:03 <yoctozepto> na-ah
15:07:39 <mgoddard> #topic Review action items from the last meeting
15:07:54 <mgoddard> mgoddard get octavia CI job passing in order to merge patches
15:07:59 <mgoddard> done
15:09:01 <mgoddard> #topic CI status
15:09:23 <mgoddard> kolla
15:09:30 <mgoddard> NFV job broken due to lack of Aodh for Tacker/Heat
15:09:40 <mgoddard> I wonder if its as simple as enabling aodh
15:09:57 <mgoddard> anyone care to try?
15:11:01 <mgoddard> ok
15:11:25 <mgoddard> Bifrost should be fixed on stein once we merge https://review.opendev.org/757566
15:11:25 <patchbot> patch 757566 - kolla (stable/stein) - Bump versions for Stein - 3 patch sets
15:11:39 <mgoddard> Rocky is probably a no go
15:12:26 <mgoddard> Kolla Ansible
15:12:26 <yoctozepto> rocky is em
15:12:31 <yoctozepto> no care
15:12:33 <mgoddard> claims to be AMBER, but I can't see why
15:12:40 <yoctozepto> lemme seeeee
15:13:39 <yoctozepto> noo, it's GREEEN
15:14:02 <mgoddard> good
15:14:06 <mgoddard> kayobe is also green
15:14:20 <mgoddard> #topic DNS-based endpoint naming https://review.opendev.org/#/c/757847/
15:14:20 <patchbot> patch 757847 - kolla-ansible - Feature to manage public endpoints via DNS names - 4 patch sets
15:14:36 <mgoddard> rafaelweingartne proposed this patch
15:14:40 <rafaelweingartne> yes
15:14:57 <mgoddard> could you give a quick overview?
15:15:37 <rafaelweingartne> yes, this is a second step of a series of proposals that we have prepared. I guess you remember we did a major review of the URLs in Kolla-ansible, to normalize their uses
15:16:01 <yoctozepto> yes
15:16:09 <yoctozepto> unforgettable
15:16:12 <yoctozepto> :-)
15:16:14 <rafaelweingartne> :)
15:16:16 <rafaelweingartne> for me too
15:16:25 <rafaelweingartne> The idea is to allow/enable operators to configure URLs/endpoints that are standard from a user perspective
15:16:35 <rafaelweingartne> by standard here, I mean, using standard ports 80/443
15:17:02 <rafaelweingartne> Therefore, to deal with that, we need to execute redirects/forward HTTP requests based on DNS names of the components/services
15:17:18 <yoctozepto> oh, that would be awesome
15:17:21 <yoctozepto> yeah, proxy them
15:17:30 <rafaelweingartne> We all of this working internally, but to avoid the nightmare of another mega huge patch
15:17:38 <rafaelweingartne> we will be introducing bit by bit
15:18:04 <rafaelweingartne> the first step if to enable us to generate/configure public endpoints based on a basic company DNS name
15:18:10 <rafaelweingartne> that is what this patch is introducing
15:18:31 <rafaelweingartne> of course, the patchset is not self contained, as it would depend on an operator to configure a proxy to handle the names
15:19:02 <rafaelweingartne> but, after we introduce mechanisms  to handle the URL/endpoints generation, we can introduce a role to do exactly that
15:19:10 <rafaelweingartne> with HAproxy or some other web proxy
15:19:49 <rafaelweingartne> "We all of this working internally" -> "We already have this working internally"
15:20:05 <yoctozepto> hmm, hmm; would not it be better to expose these on different paths though
15:20:48 <yoctozepto> but yeah, names are acceptable too
15:20:51 <mgoddard> so that question is why I wanted to discuss this here
15:21:06 <yoctozepto> web-wise names are better separation
15:21:11 <rafaelweingartne> that is a good question, for us, it felt more natural to use the server name instead of query paths
15:21:12 <mgoddard> there are various ways this could be done
15:21:21 <yoctozepto> but these are not really strictly web services
15:21:29 <yoctozepto> so paths are just as fine
15:21:39 <yoctozepto> and probably easier in regular maintenance
15:21:43 <yoctozepto> (and also to implement)
15:21:45 <yoctozepto> devstack does paths
15:21:55 <yoctozepto> we should encourage the move away from magic ports, yes
15:22:00 <mgoddard> my feeling is we should expose the variables to be able to do this in various ways
15:22:05 <yoctozepto> +2
15:22:35 <mgoddard> the current patch looks to me like it forces quite a specific pattern, and adds quite a lot of overhead to do so
15:22:48 <engel75> a flexible solution sounds good
15:22:58 <rafaelweingartne> yes, it forces that pattern of server names
15:23:03 <mgoddard> the alternative would require more work for the operator, as they would need to override more variables
15:23:03 <engel75> kolla-ansible is already ver flexible
15:23:07 <mgoddard> but would be more flexible
15:23:43 <mgoddard> if we could easily specify the FQDN, port and path per-service, would that be enough?
15:23:59 <mgoddard> do your later patches depend on a specific format?
15:24:26 <rafaelweingartne> yes, everything we did so far is based on server names
15:25:30 <mgoddard> while its nice to have bite sized things to review, in terms of a design it would help if we could see the big picture in more detail
15:26:02 <mgoddard> "bite sized" for anyone who reviewed the last patch :D
15:26:19 <rafaelweingartne> I am looking at the patch now, and we already extracted the URLs, with the first patch we introduced "<component>_<interface>_base_endpoint"
15:26:53 <rafaelweingartne> therefore, it is already possible to override them
15:27:07 <mgoddard> right
15:27:27 <rafaelweingartne> The only said thing is that the person doing the job would have to do it manually (either for server name or context path)
15:27:33 <rafaelweingartne> sad*
15:28:14 <mgoddard> if we can come up with a nice pattern, it could be documented
15:28:58 <mgoddard> I think in order to change my mind I'd want to see a few people saying yes, I want to deploy OpenStack this way, and I'd like it to be really easy to do
15:29:08 <priteau> I've done customisation of URLs in this pattern a while ago for a deployment, as early as Queens
15:29:33 <mgoddard> (of course my opinion is just one of many)
15:29:37 <priteau> It was customising the HAProxy template which was the more complex part, not customising endpoint variables
15:29:42 <rafaelweingartne> at least now, it is easier to work with these URLs, as we are consistently using the same variables around the code
15:29:58 <mgoddard> right
15:30:51 <rafaelweingartne> What if we only document the way we manage these URLs for the endpoints, and then we introduce a variable to indicate for kolla-ansible what is the configurations we want in the proxy
15:30:55 <mgoddard> if we don't have this patch, and just set the URLs, is it possible to do what you want with HAProxy, to avoid the issue priteau had?
15:31:37 <rafaelweingartne> then, we would have something like "server_name_based_proxy: true" or "context_path_redirects: true" or something similar
15:31:46 <rafaelweingartne> mgoddard: yes, it is
15:32:25 <rafaelweingartne> I just wanted to facilitate the URLs generation, but as long as they are already externalized, if we document it, it is easy to work with it
15:32:36 <mgoddard> would it have to dissect the URL to determine the FQDN/path to match on?
15:33:39 <rafaelweingartne> Kolla-ansible no, basically, we would just register the URLs as it is done already, and then we need a new role to configure the proxy server
15:33:48 <rafaelweingartne> that would either work with server names or context paths
15:34:24 <mgoddard> what proxy server would be used?
15:34:49 <rafaelweingartne> we are using HAproxy, but I guess we can use any one of the available out there
15:35:09 <rafaelweingartne> in the containers we already use HTTPD, but Kolla-ansible has a role for HAproxy
15:35:27 <priteau> I don't understand what role plays a new proxy in this. Why can't this be integrated directly in the HAProxy external API config?
15:35:55 <engel75> it should be possible to deploy a 2nd proxy
15:36:32 <rafaelweingartne> priteau: are you asking about the current HAproxy role?
15:36:37 <mgoddard> I think this needs a write up
15:36:47 <rafaelweingartne> yes, that might be a good idea
15:36:49 <engel75> from a security perspective it is good practice to run that "external" proxy in a DMZ
15:37:00 <priteau> I meant role not in an Ansible way.
15:37:41 <mgoddard> could you write up an overview of the changes you'd like to make, and how you see the feature working overall?
15:37:52 <rafaelweingartne> engel75: you mean, placing the proxy out of the control nodes, but we could do that right now? couldn't we? If we define a custom set of hosts for that role
15:38:02 <mgoddard> it doesn't need to be a full spec, just enough to let us see what you are aiming for
15:38:04 <rafaelweingartne> mgoddard: yes, I can
15:38:36 <rafaelweingartne> I will prepare a brief spec, and then we can move on from there
15:38:55 <mgoddard> thanks
15:39:07 <mgoddard> if we have it in time for the PTG, we can discuss it there
15:39:16 <mgoddard> I'll add it to the agenda
15:39:51 <engel75> rafaelweingartne yes but if a FW is sitting in between  access from all those services to the Haproxy would be blocked
15:40:11 <rafaelweingartne> mgoddard: Sure, I guess, it is possible.
15:40:13 <engel75> so I would like to be able to deploy two haproxys
15:41:13 <mgoddard> I think we should move on
15:41:21 <engel75> ok
15:41:22 <mgoddard> thanks for discussing this, we can take it to the PTG
15:41:24 <rafaelweingartne> sure
15:41:42 <mgoddard> engel75: feel free to add your thoughts to the item in https://etherpad.opendev.org/p/kolla-wallaby-ptg
15:42:13 <mgoddard> #topic Victoria release planning
15:42:20 <mgoddard> Subtopic Review deprecations and other planned removals
15:43:32 <mgoddard> I guess this was yoctozepto?
15:43:43 <yoctozepto> yesss
15:43:57 <mgoddard> #link https://docs.openstack.org/releasenotes/kolla/ussuri.html
15:44:02 <mgoddard> start will kolla
15:44:03 <yoctozepto> I noticed we have the vmware revert proposed
15:44:05 <mgoddard> *with
15:44:16 <yoctozepto> I mean vmware deprececation reno*
15:44:49 <alistarle> Hi
15:45:11 <mgoddard> #link https://review.opendev.org/747512
15:45:12 <patchbot> patch 747512 - kolla-ansible - Revert VMware deprecated note - 1 patch set
15:45:21 <mgoddard> hi alistarle, we're just in a meeting currently
15:45:25 <mgoddard> finished in 15
15:45:51 <alistarle> Yup no problem, it was just for discussing about the VMware deprecation if it is needed
15:45:58 <alistarle> as you mention in the patch set
15:46:05 <mgoddard> oh right, cool
15:46:31 <mgoddard> so, we have 3 options
15:46:36 <mgoddard> 1. remove vmware support
15:46:58 <mgoddard> 2. keep vmware support deprecated and wait for $something
15:47:03 <mgoddard> 3. undeprecate vmware
15:47:22 <mgoddard> anyone have strong feelings?
15:47:53 <yoctozepto> only weak
15:48:20 <alistarle> On our side, we already have KVM-based deployment and we need to expose vmware services too, that's why we wanted to continue using Openstack and kolla
15:49:05 <alistarle> we are currently building the platform using vmware in kolla but it still require more effort our side to fully open in production, but it looks very promising
15:49:47 <alistarle> we until here only see two little bugs, one is already merged and the other will be submitted soon (and it concern all non-OVS deployment actually)
15:50:08 <mgoddard> my opinion is that vmware support does not require much maintenance from us, and if it is useful to someone then we should keep it
15:50:32 <wuchunyang> agree
15:50:52 <mgoddard> was there some discussion about nova dropping vmware support, or have I made that up?
15:51:27 <alistarle> vmware itself propose an openstack distribution, which is not even deprecated, so I think it is still up to date
15:51:39 <yoctozepto> mgoddard: there was
15:51:53 <yoctozepto> not remember what the decision was
15:52:00 <mgoddard> ok
15:52:10 <mgoddard> well I suppose that would be out of our hands
15:52:15 <alistarle> Latest version from VMware is from July, based on train : https://docs.vmware.com/en/VMware-Integrated-OpenStack/7.0/rn/VMware-Integrated-OpenStack-70-Release-Notes.html
15:52:49 <yoctozepto> https://etherpad.opendev.org/p/nova-victoria-ptg
15:52:51 <yoctozepto> line 388
15:53:11 <yoctozepto> AGREED: enahnce the deprecation signal to say it is not just deprecated but it is also marked for deletion in a coming cycle. Ask the VMware folks to make the 3pp CI working. gibi will start the communication.
15:54:46 <mgoddard> seems like they are pushing vmware to fix the CI
15:55:30 <yoctozepto> might be
15:55:44 <yoctozepto> so undeprecate? rephrase?
15:56:08 <mgoddard> nova v renos: VMWare virt driver is now supported again in Victoria after being deprecated during the Ussuri release, as testing issues have been addressed.
15:56:13 <mgoddard> https://docs.openstack.org/releasenotes/nova/victoria.html
15:56:27 <mgoddard> their plan worked
15:56:43 <mgoddard> any objections to kolla undeprecating VMWare support?
15:57:19 <openstackgerrit> Pierre Riteau proposed openstack/kayobe master: Fix "Wait for the ironic node to be inspected" task  https://review.opendev.org/758202
15:58:02 <yoctozepto> none, it's low maintenance, and if we break anything, then, well, that's life on the edge of no testing coverage :-)
15:58:07 <mgoddard> #action undeprecate VMware
15:58:25 <mgoddard> #topic Wallaby PTG
15:58:32 <mgoddard> Please add topics https://etherpad.opendev.org/p/kolla-wallaby-ptg
15:58:37 <mgoddard> #topic Open discussion
15:58:56 <mgoddard> Does anyone have anything else to discuss?
15:59:15 <priteau> What is the plan for https://review.opendev.org/#/c/751795/
15:59:16 <patchbot> patch 751795 - kolla-ansible - Disable Docker iptables and bridge networking by d... - 2 patch sets
15:59:37 <priteau> I believe we have in-tree some warnings about default behaviour change in Victoria
15:59:52 <priteau> And some release notes of course
15:59:55 <mgoddard> it didn't work for me in CI: https://review.opendev.org/751982
15:59:56 <patchbot> patch 751982 - kolla-ansible - DNM: test kolla build without iptables or bridge - 3 patch sets
16:00:33 <priteau> And that's with host networking?
16:00:37 <mgoddard> yes
16:00:43 <mgoddard> CI always uses host networking
16:00:47 <priteau> I'll give it a try in a local env
16:01:15 <priteau> Should we revert the mentions of behaviour change in Victoria then?
16:01:27 <priteau> And leave it to Wallaby when more tested
16:02:01 <mgoddard> yes, we should revert mentions of behaviour change, and add them tohttps://review.opendev.org/#/c/751795/
16:02:01 <patchbot> patch 751795 - kolla-ansible - Disable Docker iptables and bridge networking by d... - 2 patch sets
16:02:36 <mgoddard> (or work out why that doesn't pass, fix it, then merge)
16:03:12 <priteau> Even if we fixed the issue in the coming days, it could be too close to release?
16:03:42 <mgoddard> possibly
16:03:51 <mgoddard> the issue is quite annoying though
16:04:38 <mgoddard> ok, let's leave it there
16:04:40 <mgoddard> Thanks all
16:04:43 <mgoddard> #endmeeting