18:00:05 <frickler> #startmeeting tc
18:00:05 <opendevmeet> Meeting started Tue Aug 20 18:00:05 2024 UTC and is due to finish in 60 minutes.  The chair is frickler. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:05 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:05 <opendevmeet> The meeting name has been set to 'tc'
18:00:22 <frickler> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct
18:00:37 <frickler> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
18:00:48 <frickler> #topic Roll Call
18:00:51 <JayF> o/
18:00:51 <slaweq> o/
18:00:52 <gtema> o/
18:00:58 <gmann> o/
18:01:04 <kevko> \o/
18:01:20 <frickler> noted absence: n o o n e d e a d p u n k   g o u t h a m r
18:01:35 * frickler likes the idea to mention ppl without highlighting them
18:01:50 <JayF> I noticed that last meeting and appreciate it too
18:03:02 <dansmith> @kaso/
18:03:10 <dansmith> oops, but.. I'm here :)
18:03:23 <frickler> courtesy ping: spotz[m]
18:03:49 <spotz[m]> o/:)
18:04:10 <frickler> that's everyone accounted for unless I'm mistaken
18:04:32 <frickler> (note this is the first time I'm chairing, please bear with me if something goes wrong)
18:04:41 <frickler> #topic Action Items from last week
18:04:54 <frickler> there was an AI regarding Rocky Linux mirrors; not sure from last week's log if we should continue tracking this?
18:05:38 <frickler> I also didn't see any other AIs, anything to mention here? except for the upcoming big topic
18:06:18 <fungi> from opendev's perspective the outstanding question for now is what the current problem observed with rocky jobs is and does it imply an immediate need for package mirrors in ci
18:06:59 <fungi> but community members with a vested interest in that can engage outside this meeting through the tact sig
18:07:26 <clarkb> ya I wrote down a list of steps for that first was determine if package mirrors are expected to help address an observed problem. If so then determine the size of the mirrored content. Check that size against available disk space in afs and mirror if there is room. Else make room then mirror
18:07:28 <frickler> I'm not aware of any specific issues, in my understanding this is more of following the general idea of having mirrors in place to avoid potential issues
18:08:35 <frickler> but yes, let's follow up in either #opendev or #openstack-infra then
18:09:27 <frickler> seems there is nothing else, so ...
18:09:28 <frickler> #topic Implications of testing/shipping non-OSI licensed software within OpenStack
18:09:40 <frickler> first subtopic: support of consul within the kolla project, related mailing-list thread:
18:09:43 <frickler> #link https://lists.openstack.org/archives/list/legal-discuss@lists.openstack.org/thread/IEGARFPOGX6QZAHMKIP4AG5MXEM7WVIO/ (LICENSE question - Openstack Masakari)
18:09:46 <frickler> related TC resolution:
18:09:48 <frickler> #link https://governance.openstack.org/tc/resolutions/20170530-binary-artifacts.html (TC Guidelines for Managing Releases of Binary Artifacts)
18:10:13 <frickler> kevko is the person who started the thread, do you want to add something?
18:11:05 <kevko> I can add something if there's someone here who doesn't know what it's about.
18:11:27 <JayF> My reading of both the thread and the resolution implies that team is free to do what they want, yes?
18:11:33 <spotz[m]> If anything you’re adding for anyone reading the log too
18:11:37 <JayF> Unless the TC takes action to write a new resolution to remove it?
18:12:25 <frickler> in the kolla channel earlier today fungi summarized with these questions:
18:12:29 <frickler> likely policy questions for the tc members to tackle are: 1. should the current guidance on distribution of binary artifacts be extended to require that they contain only open source software?
18:12:30 <spotz[m]> Even if we write a new resolution this would fall on the current and then would require removal?
18:12:57 <frickler> 2. is it okay for an openstack project to add a new testdependency which is not open source? 3. if a test dependency switches to a non-open-source license, what actions is openstack expected totake? (pin to the last open source version, switch to an open source fork, remove upstream testing of the integration...)
18:13:13 <fungi> i mainly just want to make sure that the tc decides intentionally what its policy is on having non-open-source (non-osi-approved/non-dfsg-compliant) licensed software as test dependencies and/or distributed within binary artifacts
18:13:41 <gmann> I also think same, we should write policy/new resolution to explicitly mention about it otherwise yes project team are allowed to do that
18:14:51 <gmann> if I am not wring, this is the first case of request/using non-oss deps right?
18:14:54 <fungi> the tc does maintain a licensing document currently which has an explicit carve-out to request approval for adding "[A]GPL libraries used during validation or testing phases of development" but says nothing on the topic of non-open-source software
18:15:06 <clarkb> not to open a whole can of worms here, but a while back there was a whole effort to explicitly make etcd a running cloud dependency. It is a bti odd to me that we would elect to use dependencies that are not open that solve similar problems
18:15:09 <fungi> #link https://governance.openstack.org/tc/reference/licensing.html "Licensing requirements"
18:15:26 <clarkb> I think that is a separate issue to the BSL question though. More of a "why did we go through all this effort for etcd if we are just going to ignore it" qusetion
18:15:50 <frickler> there were similar situations iiuc with hashicorp vault and elasticsearch
18:16:13 <JayF> clarkb: etcd is used in several jobs and projects unrelated to masakari, including Ironic Networking-Generic-Switch fwiw.
18:16:23 <kevko> and redis will be the next
18:16:31 <fungi> yes, in those cases they were open source at the time support was added and switched licenses later, but also open source drop-in replacements/forks are also available which could be used instead
18:17:00 <gmann> yeah
18:17:12 <gtema> valkey explicitly states it is started as a fork but may/would deviate sooned or later
18:17:18 <clarkb> JayF: cool, that doesn't justify masakari seemingly ignoring it though
18:17:43 <JayF> I am not sure we should put more restrictions in; my expectation would be the masakari developers would not suggest use of Consul if etcd did the job.
18:17:49 <kevko> main point is that BSL allows usage in infra IF it's not sold as some solution in other words .. API of BSL software is not provided to end user ...
18:18:26 <kevko> masakari has no support for etcd ..
18:18:45 <JayF> I think the question, from Clark, kevko, is why was consul selected instead of other more open solutions in that spec
18:18:48 <JayF> **space
18:19:02 <clarkb> well and specifically the one we've already stated we expect openstack projects to use
18:19:14 <fungi> yeah, i think the question is why does masakari not support etcd but instead focused energy on supporting a non-open-source option (and it's possible there are technical reasons for that decision)
18:19:15 <clarkb> but yes why not use an open source tool and why not use the one we've already said you should use
18:19:35 <kevko> for example in our next deployment for new customer the problem is that corosync-pacemaker is limited up to 32 hosts
18:20:02 <clarkb> kevko: I don't think direct api access is necessary to trigger the BSL
18:20:26 <fungi> competing with hashicorp in any way they decide constitutes competition immediately terminates the license
18:20:27 <clarkb> but also different BSL licenses have different exclusion clauses for what tehy care about so it is a bit messy
18:20:29 <JayF> kevko: is that a licensing limitation new to consul (I know hashicorp has been doing license changes) or  a technical limitation of etcd?
18:21:00 <fungi> it's the same bsl license that vault is under
18:21:39 <fungi> #link https://www.hashicorp.com/bsl "Business Source License"
18:21:41 <kevko> clarkb: https://github.com/hashicorp/consul/blob/0e47b380b2b86ab1c232dcd19e7c116e85ed6d69/LICENSE#L9-L13
18:22:14 <clarkb> ok so they seem to have a specific carve out in the consul case
18:22:24 <kevko> clarkb: https://github.com/hashicorp/consul/blob/0e47b380b2b86ab1c232dcd19e7c116e85ed6d69/LICENSE#L57
18:22:33 <clarkb> but in the general BSL case I don't think you can make this assumption as that is under the additional use grants
18:22:42 <kevko> BSL can have "Additional Use Grant"
18:22:57 <clarkb> yes that is the point I'm trying to make. Each BSL license is different due to that
18:23:07 <clarkb> which makes it messy and you often have to consider things on a case by case basis
18:23:14 <fungi> from an upstream perspective the license doesn't seem to pose any legal risks for openstack as a project, according to openinfra foundation legal cousel
18:23:35 <frickler> ianal but a scenario like openmetal provisions a cloud using consul which is then operated by opendev seems to me like a grey area for that license
18:23:45 <kevko> and I don't think this is the question ...as from legal-discuss i have this answer
18:23:46 <kevko> After consulting foundation legal counsel, this type of integration should not be a problem from a licensing perspective as long as no BSL licensed code is added into OpenStack code and as long as use of the HashiCorp product remains optional.
18:23:56 <clarkb> frickler: ya but that would be openmetal's problem not oepnstack's
18:24:23 <fungi> so it's more of a general question of whether the tc is okay with bsl test dependencies and distributing copies of bsl software in container images
18:25:04 <gtema> there is another aspect into the story, if SW (OpenStack service) communicates with Hashi software using i.e. python hvac lib  - there is no issue at all since it is under Apache license
18:25:19 <fungi> and from a consistency standpoint it seems odd that openstack cares enough to warn about use of gpl and agpl test dependencies, but doesn't need to supply guidance about non-open-source licenses like bsl
18:26:20 <JayF> Honestly I went into this discussion thinking we should stay outta masakari's way, but now I'm concerned that BSL software could be toxic in the same way AGPL can be
18:26:28 <slaweq> what about packaging for distros, could it impact e.g. debian packages if some openstack service will have non open source (test) dependencies?
18:26:45 <JayF> Can we pose that specific question, re if it would put OpenDev or the donor clouds in any kind of jeopardy?
18:26:47 <clarkb> slaweq: gtema that is why the "remain optional" portion of the statement is important aiui
18:27:13 <clarkb> if you have a hard dependency that can't be avoided on smething that isn't open source then you aren't really open (and we already have policies that should prevent this)
18:27:17 <kevko> JayF: This is not about masakari but for example also about barbican ... they have also support for hashicorp vault as a backend
18:27:36 <gtema> correct clarkb, I would be against of forbidding our services to have support for optional non opensource drives
18:27:46 <fungi> clarkb: debian dropped their consul package after bullseye (oldstable) related to the license change
18:27:48 <JayF> kevko: interesting point, I wonder if they test/install it on our donor clouds already...
18:28:07 <clarkb> fungi: right and masakari packaging in debian would depend on an open source alternative
18:28:24 <kevko> JayF: also kolla is testing vault integration in CI  - https://github.com/openstack/kolla-ansible/blob/master/tests/test-hashicorp-vault-passwords.sh
18:28:37 <slaweq> IMHO our software should be fully open and depend only on the opensource software, and any driver or something like that for non opensource soulution should be part of some 3rd party solution
18:29:00 <JayF> kevko: so interestingly, it seems like frickler's license concern -- that we may be putting our donor clouds into a grey area -- may already be happening
18:29:05 <slaweq> in upstream we should have in such case some kind of reference implementation based on the opensource solution
18:29:28 <slaweq> even if it has some limitations as in the kevko's case IIUC
18:29:34 <fungi> we definitely have a lot of cases where openstack has drivers for proprietary systems like network and storage devices, so i think having this kind of integration is fairly typical, but in the majority of those cases the people supporting the proprietary system drivers are expected to do their own external testing rather than testing upstream
18:29:46 <JayF> slaweq: I think the only reason I'm hesitant to have a hard stance of that nature is actually due to the Hashicorp situation: if a previously open backend closes, it may generate a crisis for that project whereby they don't have the resources to stay alive :(
18:29:46 <spotz[m]> I’m with slaweq though I know it’s getting hard with the changing licenses
18:31:33 <spotz[m]> In theory if an open source project sprouted from a changed license could our stuff switch?
18:31:43 <fungi> maybe reversing the order of my questions in the kolla channel, is keeping test dependencies and distributing newer copies of software that switches from an open source license to a source-available license okay or do projects need to work to remove them once that happens, and particularly if the latter then is adding new instances of the same acceptable?
18:31:48 <JayF> spotz[m]: that's basically my question
18:32:24 <JayF> fungi: Does the foundation care at all, at that level?
18:33:00 <fungi> the foundation (legally speaking, as an organization) doesn't have an opinion, other than stating it doesn't present any obvious legal risk either way
18:33:11 <frickler> ok, I'd like to avoid filling the whole meeting with this topic, so maybe let's phrase this the other way around: does anyone think that the TC needs to come up with a new resolution regarding this topic? is there a volunteer to propose something?
18:33:38 <frickler> otherwise let's timebox this at say 18:40
18:34:29 <fungi> as far as tc guidance is concerned, i'll note that those proposing the consul integration found and followed the tc's documented recommendation for handling of (a)gpl test dependencies because there was no guidance on non-open-source test dependencies
18:34:31 <spotz[m]> Sounds like this would be a good forum session but that’s 2 months away
18:34:55 <fungi> two weeks away
18:34:55 <JayF> frickler: kevko: if the masakari team is not held up too much by waiting, this seems like *prime* fodder for a TC PTG session
18:34:56 <spotz[m]> Forum or PTG I should say
18:35:01 <JayF> == spotz[m] yep exactly
18:35:50 <frickler> iiuc this isn't about masakari, but about kolla implementing consul support for masakari
18:36:03 <kevko> yep
18:36:15 <JayF> similar question then, directed towards the correct team :)
18:36:31 <frickler> but evaluating whether bringing other options like etcd into masakari would be possible does also sound interesting
18:36:48 <kevko> if kolla and kolla-ansible can provide the way to user to install those BSL backends to be used by openstack service which already supports it
18:36:57 <frickler> kevko: how urgent is this topic for you?
18:37:36 <kevko> well, sometimes I am backporting my patchsets from gerrit for several releases until they are merged ...
18:38:15 <fungi> kevko: is kolla able to support that integration without testing it upstream (letting people who care about it run a third-party ci) and avoid building images that contain copies of consul? then it would be no different from other proprietary systems integration openstack supports
18:38:41 <JayF> that's a very good suggestion, especially if it buys enough time to get to the PTG for a long-form discussion
18:38:41 <gmann> I think kolla release is after PTG for D right? maybe it will give some time to kolla even we discuss it in PTG?
18:38:56 <kevko> but I have better feeling if i know it will be in master and freezed as some released version in future ... otherwise i will be backporting those stuff forever in my downstream git ...  but i like do upstream work and don't want to implement everything in my downstream gits
18:39:04 <frickler> kolla is cycle-trailing, yes
18:39:23 <JayF> kevko++ thank you for that
18:39:45 <fungi> in theory expecting users to build the images for consul or get them elsewhere shouldn't be a significant burden since the tc already says that binary artifacts like container images published by openstack teams should be clearly marked as not for production use, and that end consumers are expected to build their own anyway to take on that liability
18:40:12 <JayF> absolutely
18:40:29 <kevko> yep
18:40:56 <frickler> ok, so I'd suggest we stop here and take this topic to the PTG, any final words?
18:41:43 <kevko> kolla  is just bunch of python and jinja code ...we don't need to build them ...but user can ... for kolla-ansible ..the same ..it can be turned off by default ...but there can be an option to orchestrate those images if user will build them
18:41:59 <spotz[m]> If anyone wants to discuss in Suwon let me know, this could get added as a session still at NA but that’s a week before the PTG
18:42:21 <frickler> there is a second subtopic added in the wiki but I think we wait until noonedeadpunk is back with that, regarding ansible-collections-openstack
18:42:41 <frickler> #topic A check on gate health
18:42:48 <kevko> in fact ..kolla just provides Dockerfiles and kolla-ansible just ansible orchestration .... kolla don't need to provide container images ... it can be marked as BSL third party and needed to build by users
18:42:57 <frickler> gmann: any update on the adoption of latest oslo.policy? is there a chance that this will be release critical?
18:43:07 <frickler> #link https://review.opendev.org/c/openstack/requirements/+/925464
18:43:32 <gmann> frickler: there are few projects still not fixed, tacker fix is up but not merged and barbican I need to push today
18:44:14 <gmann> other than than one designate-neutron job failing which I continue to debug as root cause is not known
18:44:27 <frickler> gmann: I'm just worried that in the end we need to revert some oslo changes, like we had to do for db and others in the last cycles
18:44:43 <gmann> neutron-tempest-plugin-designate-scenario fail, slaweq I will try to catch you on this after meeting or sometime tomorrow
18:45:29 <gmann> frickler: It should not be at that level. there are config default value change and easy fix is to disable them at service level. But I am trying some test fix as per new version
18:45:58 <gmann> I think I will push all by today and ask team to merge those (if test cannot be fixed then just continue disable the new RBAC for those services)
18:46:28 <frickler> ok, sounds like a plan. anything else gate-y?
18:46:40 <gmann> my target is to merge the requirement u-c max by this week
18:46:43 <slaweq> gmann: I will be afk today just after this meeting but please write on the neutron channel, I will check tomorrow morning
18:46:50 <gmann> slaweq: ack
18:47:01 <frickler> gmann: +1
18:48:01 <gmann> nothing else on gate specific from my side
18:48:21 <frickler> #topic 2024.2 TC Tracker
18:48:24 <frickler> #link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker)
18:48:53 <frickler> anything that needs to be brought up here?
18:50:38 <frickler> I did look at the update for monasca that was mentioned last week, and I'm not convinced that it is on a path towards a healthy project, but open to hear other opinions
18:50:48 <frickler> #link https://review.opendev.org/c/openstack/governance/+/923919 (Inactive state extensions: Monasca)
18:52:20 <kevko> just for record - current limitation in kolla, kolla-ansible for masakari and corosync-pacemaker implementation
18:52:38 <gmann> I will say, let's give the extension and see in next cycle how it goes
18:52:44 <kevko> https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Remote/html/intro.html#overview  <<
18:53:11 <kevko> In a basic Pacemaker high-availability cluster [1] each node runs the full cluster stack of Corosync and all Pacemaker components. This allows great flexibility but limits scalability to around 32 nodes. <<
18:53:22 <kevko> Thanks to all
18:53:49 <frickler> so this kind of melts into ...
18:53:50 <frickler> #topic Open Discussion and Reviews
18:54:21 <JayF> If you are running for TC or PTL this cycle; you're running out of time to do the nomination.
18:54:23 <gmann> I have couple of reviews request
18:54:31 <frickler> please check open governance and other reviews, I didn't prepare a specific list
18:54:31 <gmann> #link https://review.opendev.org/c/openstack/governance/+/925926
18:54:32 <gmann> ^^ this has been open for couple of week, please review
18:54:49 <gmann> and testing runtime is also ready to review
18:54:50 <gmann> #link https://review.opendev.org/c/openstack/governance/+/926150
18:57:23 <frickler> thx gmann. anything else to mention?
18:58:16 <frickler> thank you all for attending this meeting
18:58:16 <frickler> see you here again next week or feel free to ping tc-members anytime you need our attention \o/
18:58:22 <frickler> #endmeeting