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