18:00:05 #startmeeting tc 18:00:05 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:05 The meeting name has been set to 'tc' 18:00:22 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 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:00:48 #topic Roll Call 18:00:51 o/ 18:00:51 o/ 18:00:52 o/ 18:00:58 o/ 18:01:04 \o/ 18:01:20 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 I noticed that last meeting and appreciate it too 18:03:02 @kaso/ 18:03:10 oops, but.. I'm here :) 18:03:23 courtesy ping: spotz[m] 18:03:49 o/:) 18:04:10 that's everyone accounted for unless I'm mistaken 18:04:32 (note this is the first time I'm chairing, please bear with me if something goes wrong) 18:04:41 #topic Action Items from last week 18:04:54 there was an AI regarding Rocky Linux mirrors; not sure from last week's log if we should continue tracking this? 18:05:38 I also didn't see any other AIs, anything to mention here? except for the upcoming big topic 18:06:18 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 but community members with a vested interest in that can engage outside this meeting through the tact sig 18:07:26 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 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 but yes, let's follow up in either #opendev or #openstack-infra then 18:09:27 seems there is nothing else, so ... 18:09:28 #topic Implications of testing/shipping non-OSI licensed software within OpenStack 18:09:40 first subtopic: support of consul within the kolla project, related mailing-list thread: 18:09:43 #link https://lists.openstack.org/archives/list/legal-discuss@lists.openstack.org/thread/IEGARFPOGX6QZAHMKIP4AG5MXEM7WVIO/ (LICENSE question - Openstack Masakari) 18:09:46 related TC resolution: 18:09:48 #link https://governance.openstack.org/tc/resolutions/20170530-binary-artifacts.html (TC Guidelines for Managing Releases of Binary Artifacts) 18:10:13 kevko is the person who started the thread, do you want to add something? 18:11:05 I can add something if there's someone here who doesn't know what it's about. 18:11:27 My reading of both the thread and the resolution implies that team is free to do what they want, yes? 18:11:33 If anything you’re adding for anyone reading the log too 18:11:37 Unless the TC takes action to write a new resolution to remove it? 18:12:25 in the kolla channel earlier today fungi summarized with these questions: 18:12:29 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 Even if we write a new resolution this would fall on the current and then would require removal? 18:12:57 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 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 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 if I am not wring, this is the first case of request/using non-oss deps right? 18:14:54 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 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 #link https://governance.openstack.org/tc/reference/licensing.html "Licensing requirements" 18:15:26 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 there were similar situations iiuc with hashicorp vault and elasticsearch 18:16:13 clarkb: etcd is used in several jobs and projects unrelated to masakari, including Ironic Networking-Generic-Switch fwiw. 18:16:23 and redis will be the next 18:16:31 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 yeah 18:17:12 valkey explicitly states it is started as a fork but may/would deviate sooned or later 18:17:18 JayF: cool, that doesn't justify masakari seemingly ignoring it though 18:17:43 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 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 masakari has no support for etcd .. 18:18:45 I think the question, from Clark, kevko, is why was consul selected instead of other more open solutions in that spec 18:18:48 **space 18:19:02 well and specifically the one we've already stated we expect openstack projects to use 18:19:14 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 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 for example in our next deployment for new customer the problem is that corosync-pacemaker is limited up to 32 hosts 18:20:02 kevko: I don't think direct api access is necessary to trigger the BSL 18:20:26 competing with hashicorp in any way they decide constitutes competition immediately terminates the license 18:20:27 but also different BSL licenses have different exclusion clauses for what tehy care about so it is a bit messy 18:20:29 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 it's the same bsl license that vault is under 18:21:39 #link https://www.hashicorp.com/bsl "Business Source License" 18:21:41 clarkb: https://github.com/hashicorp/consul/blob/0e47b380b2b86ab1c232dcd19e7c116e85ed6d69/LICENSE#L9-L13 18:22:14 ok so they seem to have a specific carve out in the consul case 18:22:24 clarkb: https://github.com/hashicorp/consul/blob/0e47b380b2b86ab1c232dcd19e7c116e85ed6d69/LICENSE#L57 18:22:33 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 BSL can have "Additional Use Grant" 18:22:57 yes that is the point I'm trying to make. Each BSL license is different due to that 18:23:07 which makes it messy and you often have to consider things on a case by case basis 18:23:14 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 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 and I don't think this is the question ...as from legal-discuss i have this answer 18:23:46 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 frickler: ya but that would be openmetal's problem not oepnstack's 18:24:23 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 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 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 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 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 Can we pose that specific question, re if it would put OpenDev or the donor clouds in any kind of jeopardy? 18:26:47 slaweq: gtema that is why the "remain optional" portion of the statement is important aiui 18:27:13 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 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 correct clarkb, I would be against of forbidding our services to have support for optional non opensource drives 18:27:46 clarkb: debian dropped their consul package after bullseye (oldstable) related to the license change 18:27:48 kevko: interesting point, I wonder if they test/install it on our donor clouds already... 18:28:07 fungi: right and masakari packaging in debian would depend on an open source alternative 18:28:24 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 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 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 in upstream we should have in such case some kind of reference implementation based on the opensource solution 18:29:28 even if it has some limitations as in the kevko's case IIUC 18:29:34 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 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 I’m with slaweq though I know it’s getting hard with the changing licenses 18:31:33 In theory if an open source project sprouted from a changed license could our stuff switch? 18:31:43 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 spotz[m]: that's basically my question 18:32:24 fungi: Does the foundation care at all, at that level? 18:33:00 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 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 otherwise let's timebox this at say 18:40 18:34:29 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 Sounds like this would be a good forum session but that’s 2 months away 18:34:55 two weeks away 18:34:55 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 Forum or PTG I should say 18:35:01 == spotz[m] yep exactly 18:35:50 iiuc this isn't about masakari, but about kolla implementing consul support for masakari 18:36:03 yep 18:36:15 similar question then, directed towards the correct team :) 18:36:31 but evaluating whether bringing other options like etcd into masakari would be possible does also sound interesting 18:36:48 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 kevko: how urgent is this topic for you? 18:37:36 well, sometimes I am backporting my patchsets from gerrit for several releases until they are merged ... 18:38:15 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 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 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 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 kolla is cycle-trailing, yes 18:39:23 kevko++ thank you for that 18:39:45 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 absolutely 18:40:29 yep 18:40:56 ok, so I'd suggest we stop here and take this topic to the PTG, any final words? 18:41:43 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 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 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 #topic A check on gate health 18:42:48 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 gmann: any update on the adoption of latest oslo.policy? is there a chance that this will be release critical? 18:43:07 #link https://review.opendev.org/c/openstack/requirements/+/925464 18:43:32 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 other than than one designate-neutron job failing which I continue to debug as root cause is not known 18:44:27 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 neutron-tempest-plugin-designate-scenario fail, slaweq I will try to catch you on this after meeting or sometime tomorrow 18:45:29 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 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 ok, sounds like a plan. anything else gate-y? 18:46:40 my target is to merge the requirement u-c max by this week 18:46:43 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 slaweq: ack 18:47:01 gmann: +1 18:48:01 nothing else on gate specific from my side 18:48:21 #topic 2024.2 TC Tracker 18:48:24 #link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker) 18:48:53 anything that needs to be brought up here? 18:50:38 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 #link https://review.opendev.org/c/openstack/governance/+/923919 (Inactive state extensions: Monasca) 18:52:20 just for record - current limitation in kolla, kolla-ansible for masakari and corosync-pacemaker implementation 18:52:38 I will say, let's give the extension and see in next cycle how it goes 18:52:44 https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Remote/html/intro.html#overview << 18:53:11 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 Thanks to all 18:53:49 so this kind of melts into ... 18:53:50 #topic Open Discussion and Reviews 18:54:21 If you are running for TC or PTL this cycle; you're running out of time to do the nomination. 18:54:23 I have couple of reviews request 18:54:31 please check open governance and other reviews, I didn't prepare a specific list 18:54:31 #link https://review.opendev.org/c/openstack/governance/+/925926 18:54:32 ^^ this has been open for couple of week, please review 18:54:49 and testing runtime is also ready to review 18:54:50 #link https://review.opendev.org/c/openstack/governance/+/926150 18:57:23 thx gmann. anything else to mention? 18:58:16 thank you all for attending this meeting 18:58:16 see you here again next week or feel free to ping tc-members anytime you need our attention \o/ 18:58:22 #endmeeting