| opendevreview | Merged openstack/ci-log-processing master: Check memory consumption if its not to high in performance.json file https://review.opendev.org/c/openstack/ci-log-processing/+/882243 | 06:52 |
|---|---|---|
| opendevreview | Merged openstack/ci-log-processing master: Change OpenSearch services version for CI tests https://review.opendev.org/c/openstack/ci-log-processing/+/879434 | 06:54 |
| sean-k-mooney | clarkb: fungi: looping back too the topic of rhel images for the first party ci | 11:40 |
| sean-k-mooney | the folks that run the rhosi program got back to me today and said they have complete there preliminary internal work and wanted to know who to talk to in the foundation/infra teams about next steps | 11:41 |
| sean-k-mooney | if i start an email thread with you and them would that work for ye or shoudl i include someone else | 11:41 |
| sean-k-mooney | clarkb: fungi: also followup question if i include ye in the thread do you have a prefered eamil i shoudl use | 11:44 |
| fungi | sean-k-mooney: i guess it's a question of what next steps would be needed, but probably we'd need to talk through implementation details in order to find out whether our technical limitations will prevent effective use of the offer (similar to how we had to confirm canonical were okay with the fact that we have no real way to prevent license activation keys from being retrieved by | 11:50 |
| fungi | particularly determined members of the public) | 11:50 |
| fungi | i guess starting with me and clarkb would work, and then if there are questions or contracts that need foundation executive management or legal counsel we can add more people to the conversation | 11:51 |
| sean-k-mooney | ya so that is bascially the next step to have the peopel how actully know how that works in detail expalin that becasue while i gave a very hihgh level overview i didnt go into any of the details in depth | 11:52 |
| sean-k-mooney | i expalined breicly that oure ci system invovles building a vm image from a base (in this case a rhel 9 base) which i s publicly hosted and uploaded to a cloud provider | 11:53 |
| sean-k-mooney | that is then use to lauch tempory vms that are used ot execute tests | 11:53 |
| sean-k-mooney | so at a high level that shoudl eb workable | 11:53 |
| sean-k-mooney | but its the details that will matter in the end | 11:54 |
| fungi | but basically, if there is a "secret key" that test systems will need to use to be able to download packages in jobs, we can't thoroughly secure that. our testing platform was designed around publicly available operating systems so trying to restrict access would necessitate some significant redesign work unlikely to be offset by the convenience of having actual rhel testing available | 11:54 |
| fungi | instead of relying on centos/rocky/alma/euler | 11:54 |
| sean-k-mooney | ya i think they were oke with that. or saw a way to mitgatwe that like roating the shared key perioicly | 11:55 |
| sean-k-mooney | as long as the subscription key is not backed into the image and added in the job | 11:55 |
| sean-k-mooney | i think that will be workable | 11:56 |
| sean-k-mooney | which i belive you said is done for the ubuntu fips jobs | 11:56 |
| sean-k-mooney | we have a no cost self service/no supprot susbcription key that cannonical has provided correct | 11:57 |
| fungi | yes, that's the case for the ubuntu ua subscription we're using for fips testing (it's also scoped specifically to just granting access to fips enablement packages) | 11:58 |
| fungi | i suppose something similar could be done for rhel in two phases: when we build our rhel images we use the subscription key but then strip it out before finalizing the image. later when we boot the image for a job, a rhel base job could install the license key from a zuul secret and activate the system prior to the job downloading additional packages | 12:00 |
| fungi | if someone pushes a change for, say, devstack which cats the license from disk out to the job log though, they can theoretically reuse it on other systems | 12:01 |
| fungi | keep in mind, the goal of this discussion (for me at least) will be to 1. find out what the limitations are, and 2. determine whether the effort involved will be small enough that it can be offset by the convenience of having actual rhel test systems available | 12:04 |
| fungi | if making rhel available is a lot of work or the demand for it from our user is fairly low compared to other platforms we already have, then there may be little point in exploring further | 12:05 |
| sean-k-mooney | the base image partly by design have minimal packages instealled right | 12:06 |
| sean-k-mooney | so that might be in the ubi set which does not need a key | 12:07 |
| sean-k-mooney | but ya so shall i inclue you in the thread im startign and with what email | 12:07 |
| fungi | injecting the secret that early in pre-run is probably going to require additions to our base job (very risky to increase complexity there) or a separate forked configuration for any job that wants to inherit rhel setup | 12:07 |
| fungi | but yes, if some packages can be installed or a base image bootstrapped without a license, then that simplifies the image builds at least | 12:08 |
| sean-k-mooney | i wouuld proably add a rhel-base just for this | 12:08 |
| sean-k-mooney | and not touch the exsithg base just inherit | 12:08 |
| fungi | that's doable, but like i said, you'll have a completely separate tree of job definitions to be able to inherit from that | 12:08 |
| jrosser | sean-k-mooney: it would also be interesting to understand how i would locally reproduce a RHEL job which is pretty inevitable for anything involved, the individual developer subscription doesnt seem to allow me to do that as part of $day-job | 12:09 |
| sean-k-mooney | jrosser: you can use the rhel developer subsciription ot get a entilement as an indivual | 12:09 |
| sean-k-mooney | so you would jsut use your own subscription key | 12:09 |
| fungi | i think the concern is that doesn't allow use for when you're being paid by a company to do that work? | 12:09 |
| jrosser | you might want to clarify "The Red Hat Developer Subscription for Individuals is still only available to individuals, not organizations or teams, and is designed for personal servers, home labs, and small open source communities." then | 12:09 |
| sean-k-mooney | for what its worht i do all my upstream work on ubuntu vms and ocationall centos | 12:10 |
| sean-k-mooney | i tought it did | 12:10 |
| sean-k-mooney | allow use if your are contibuting to opensource | 12:10 |
| sean-k-mooney | honestly im not sure | 12:11 |
| sean-k-mooney | i do not use rhel in my day job even when workign on redhat openstack so have never had to figure that out | 12:11 |
| jrosser | well you can understand that for a deploy tool that might be important | 12:11 |
| sean-k-mooney | yep i would hope the developer subscriotn woudl count | 12:12 |
| sean-k-mooney | i knwo that covers things like runing openshfit on your laptop to develop applcation that run on openshift | 12:12 |
| sean-k-mooney | the production openshfit still need s diffent sku | 12:13 |
| sean-k-mooney | btu thte dev activty is coverd by the develop subscription | 12:13 |
| jrosser | ffs i cant even read the T&C without logging in | 12:13 |
| sean-k-mooney | so i woudl think that the develope subscription woudl cover developing supprort for rhel in devstack or kolla or osa | 12:13 |
| sean-k-mooney | ya i hate when things like that are behind a login | 12:14 |
| jrosser | anyway - thats a concern for me as licence compliance is something i'd be quite concerned about | 12:15 |
| sean-k-mooney | its somethign that should adress in the mail thread i think | 12:15 |
| sean-k-mooney | we can explcitly ask how you would repoduce the ci env to develop/debug it as a normal memember | 12:16 |
| jrosser | sure, that would be helpful | 12:16 |
| sean-k-mooney | and if the rhel indivugal developer subscirption can be used for that | 12:16 |
| jrosser | ^ the T&C would need to be worded such that a lawyer would agree, rather than just a ML reply | 12:17 |
| sean-k-mooney | well we woudl get redhat leagal to confrim | 12:18 |
| sean-k-mooney | jrosser: https://paste.opendev.org/show/b1Rj9Jfv6HnXPWLI1UBk/ those are teh terms | 12:22 |
| sean-k-mooney | “Individual Development Use” means one individual working independently (with their own installation of Red Hat Software) to | 12:23 |
| sean-k-mooney | develop software (including open source software), perform prototyping or quality assurance testing and/or for demonstration | 12:23 |
| sean-k-mooney | purposes. | 12:23 |
| fungi | i guess that will still need some legal definition of terms like "working independently" (are you still working inependently when being paid by a company to do that work?) | 12:24 |
| sean-k-mooney | i think this is refering to not sharing the rhel instace with another user | 12:25 |
| jrosser | to me it looks pretty problematic | 12:25 |
| sean-k-mooney | i.e. not creatign a rhel server and haveing multipel pople sharing it | 12:25 |
| fungi | maybe the parenthetical "with their own installation of Red Hat Software" is meant to be a definition of the term "working independently" | 12:25 |
| sean-k-mooney | ok to mean that seam pretty broad | 12:25 |
| sean-k-mooney | we can certenly ask for clarity on that | 12:26 |
| sean-k-mooney | but what i have alwasy been told is the developer subsction allows you to develop and test software for rhel even for commeial uses | 12:27 |
| fungi | i know legal documents often use parentheticals for defining terms, but they'll usually explicitly call it out with phrases like "hereafter referred to as..." | 12:27 |
| sean-k-mooney | it just does not allow you to run any production workload under that developer subscription | 12:27 |
| jrosser | "you are acting on your own personal behalf and not as a representative or on behalf of an entity" i wonder how that stacks up as using it as part of regular employment | 12:28 |
| sean-k-mooney | i feel like ensuring that we can repoduce the ci envionment woudl be a requiremetn for this to move forward | 12:28 |
| sean-k-mooney | ill ask about this exiplcitly internally but lets cover it in the new thread to | 12:29 |
| jrosser | fwiw i have previously looked at the individual subscription and decided i can't use it | 12:29 |
| jrosser | but i have not taken formal advice on that from work | 12:29 |
| sean-k-mooney | i think the developer subsctiption would be very limited | 12:30 |
| sean-k-mooney | if it could not be used in a commerial context | 12:30 |
| sean-k-mooney | but your right to raisse this concern | 12:30 |
| sean-k-mooney | i have forwared this question to them internally | 12:44 |
| sean-k-mooney | we can likely ask for a witten statement that can be shared/hosted publicly to cover this if we proceed | 12:45 |
| sean-k-mooney | "as a continutor to openstack,(not a foundaton employee) if i am paid to work on openstack | 12:46 |
| sean-k-mooney | by my employer and a rhel based job fails. can i use the redhat indiviual developer subsctiption | 12:46 |
| sean-k-mooney | to repodcue the ci issues or is that not covered by the terms of teh developer subsctiption." | 12:46 |
| sean-k-mooney | i would proably follow up with a second user case | 12:46 |
| jrosser | i think my concern is around the picture painted here https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux not entirely matching up with the actual text in the T&C | 12:47 |
| sean-k-mooney | "as a contobutior workign on an installer for openstack can i use the developer subscription to develop supprot for rhel if i am paied to work on openstack" | 12:47 |
| jrosser | but thats my reading of the T&C, not a legal one | 12:47 |
| jrosser | and it would be the T&C text i would have to get internal legal review of | 12:48 |
| sean-k-mooney | so i dont think having rhel aviablie in the ci impleis not also having centos9stream or rocky | 12:49 |
| sean-k-mooney | it shoudl not force you to ues it but allow you to if you saw value | 12:49 |
| sean-k-mooney | i would expect use to keep most if not all nova jobs on ubuntu | 12:49 |
| sean-k-mooney | but i could see us having one job on rhel | 12:50 |
| sean-k-mooney | for exampel to test with a diffent python version and libvirt/qemu | 12:50 |
| sean-k-mooney | what i was thingink we woudl evovle to using centos stream for testing what comign next for rhel like distors | 12:53 |
| sean-k-mooney | and then rhel for some voting jobs for statble branches | 12:53 |
| sean-k-mooney | if we decied that after reviewing the usefullnes and complexity of having rhel in the ci it does not add enouch value then thats fine too | 12:54 |
| *** gboutry[m] is now known as gboutry | 13:12 | |
| *** thelounge553 is now known as thelounge55 | 13:18 | |
| fungi | yeah, i mean, we have rocky and openeuler already for near-rhel testing, and centos stream for future-rhel testing. adding actual rhel could be a lot of complexity to implement and maintain for measurably little benefit | 13:24 |
| fungi | but i'm open to discussing what it would entail in order to determine that | 13:25 |
| *** thelounge551 is now known as thelounge55 | 13:26 | |
| *** d34dh0r5| is now known as d34dh0r53 | 13:35 | |
| clarkb | sean-k-mooney: fungi: I'll be honest my current interest in devoting time to make rhel happen is very low. We have alternative(s) that appear to be working already and from a personal motivation standpoint I don't run any software on red hat distros. I think we'd be happy to guide people sorting it out otherwise but I can't be expected to make it happen | 15:07 |
| clarkb | I think historically this has been a major time sink with zero beneift to show afterwards so I'm extra wary too | 15:08 |
| sean-k-mooney | i think the expectaion is if redhat want to try enabling thi its on use to have people to do that work | 15:11 |
| sean-k-mooney | that would like be some of our upstream rdo folks | 15:12 |
| clarkb | right so I would expect to be engaged when people are starting to do that work to provide guidance on how and where to integrate. I'm not sure I need to be involved from a "is this even legally possible" standpoint? | 15:12 |
| sean-k-mooney | and then if say the nova team enabel d job we would be on the hook to keep it working in devstack ecta | 15:12 |
| sean-k-mooney | if the upstream feedback is this is too much work im happy to drop it | 15:14 |
| clarkb | I'm not trying to say that either. I'm saying please don't involve me until you know it is something that legal is ko with and have a volunteer to drive | 15:14 |
| sean-k-mooney | but it would be good to at lest follwo up on is this possibel first | 15:14 |
| sean-k-mooney | ack | 15:14 |
| sean-k-mooney | fungi: are you still ok to be an intital contact for that first discussion | 15:15 |
| sean-k-mooney | clarkb: i held of creating the email thread until you responded to give you the change to opt out exactly as you have | 15:15 |
| sean-k-mooney | so no worries | 15:15 |
| clarkb | my main concern is I have a million things demanding my attention right now and this feels like a very low priority due to the laternatives we have in place and the historical inability to make it happen | 15:16 |
| fungi | sean-k-mooney: sure. like clarkb i can't promise that i'll be able to put any time into it, but i can probably try to answer direct technical questions and also find the right people for legal topics | 15:26 |
| sean-k-mooney | thanks | 15:36 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Switch from deprecated require-approval to require https://review.opendev.org/c/openstack/project-config/+/883431 | 17:40 |
| opendevreview | Jeremy Stanley proposed openstack/project-config master: Switch from deprecated require-approval to require https://review.opendev.org/c/openstack/project-config/+/883431 | 19:15 |
| *** elodilles is now known as elodilles_ooo | 19:42 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!