| frickler | gtema: o.k., that's a step forward at least. one down, two to go ;) https://zuul.opendev.org/t/openstack/build/4e67f635ac524001a010ef2fa4d46ef7 | 05:03 |
|---|---|---|
| opendevreview | Merged openstack/openstacksdk master: Add support for fault object per Server API https://review.opendev.org/c/openstack/openstacksdk/+/853703 | 07:12 |
| Daviey | (Thanks gtema!) | 07:19 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Initialize tests of real clouds https://review.opendev.org/c/openstack/openstacksdk/+/859026 | 08:20 |
| opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Force major version bump in pbr https://review.opendev.org/c/openstack/ansible-collections-openstack/+/859053 | 08:47 |
| gtema | @frickler you are in the infra team, aren't you? | 08:57 |
| frickler | gtema: pleading guilty | 09:01 |
| gtema | so, back from meeting | 09:14 |
| gtema | I am working on the concept of running sdk/osc functional tests against real clouds | 09:15 |
| gtema | I have now creds for Cleura | 09:15 |
| gtema | and I want to make non voting jobs for running those | 09:15 |
| gtema | now the point (we did it in our zuul this way) | 09:16 |
| gtema | in order to run this tests in check I need to define jobs in config project (meaning project-config) | 09:16 |
| gtema | here I would need to put credentials of the clouds, define jobs that prepare clouds.yaml for sdk/osc (and I do this with token and not pwd to reduce chance of leak) and revokation of the token afterwards | 09:17 |
| gtema | would this be accepted by infra (to put such jobs into the project-config) or we should better consider setting up a 3rdparty CI for all of that? | 09:18 |
| gtema | frickler: https://review.opendev.org/c/openstack/project-config/+/859060 + https://review.opendev.org/c/openstack/openstacksdk/+/859026 are wips for that | 09:34 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Initialize tests of real clouds https://review.opendev.org/c/openstack/openstacksdk/+/859026 | 09:54 |
| frickler | gtema: you could put the secrets into the sdk repo, too, I'm not sure that project-config is needed for that. but I'm not sure how to circumvent the restriction that secrets can only be used in post-merge jobs | 09:55 |
| frickler | also, do we need to serialize jobs? or could multiple jobs run with the same credentials in parallel? | 09:56 |
| gtema | by placing them in the project-config repo, this is for sure. That way sdk would be able to use those jobs in check | 09:56 |
| gtema | parallelization is a bit different question where I have no answer yet. cleanup is the similar one | 09:56 |
| gtema | but first we should have some base for running them at all | 09:57 |
| gtema | for the reference how we do it in our setup: | 09:57 |
| gtema | https://github.com/opentelekomcloud-infra/zuul-project-config/blob/master/zuul.d/jobs.yaml#L72 | 09:57 |
| gtema | and used i.e. here: https://github.com/opentelekomcloud/python-otcextensions/blob/master/.zuul.yaml#L40 | 09:58 |
| gtema | in our setup zuul-project-config is also a config repo. And jobs with secrets defined in a config repo can be used in non post-review pipelines | 09:59 |
| frickler | o.k., I'll have a look later. what I've done in a similar situation is use a static node that gets pre-configured with the credentials out-of-band | 09:59 |
| gtema | https://zuul-ci.org/docs/zuul/latest/config/secret.html describes this | 09:59 |
| gtema | Since it works for us I know for sure this way works. I am not so relaxed at placing those jobs into project-config though | 10:00 |
| gtema | at minimum we would need to limit projects which can use those jobs | 10:00 |
| gtema | but maintaining it this way can get out of control | 10:01 |
| opendevreview | Takashi Natsume proposed openstack/python-openstackclient master: Fix wrong assertion methods https://review.opendev.org/c/openstack/python-openstackclient/+/857046 | 10:49 |
| opendevreview | Merged openstack/ansible-collections-openstack master: Force major version bump in pbr https://review.opendev.org/c/openstack/ansible-collections-openstack/+/859053 | 12:25 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Extend project cleanup https://review.opendev.org/c/openstack/openstacksdk/+/859087 | 13:33 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Extend project cleanup https://review.opendev.org/c/openstack/openstacksdk/+/859087 | 13:44 |
| jm1 | gtema: oh nice, you got access to another cloud?! Never heard of Cleura before though 😅 | 14:07 |
| gtema | citycloud | 14:07 |
| jm1 | gtema: but i guess you still need access to rackspace, ovh and vexxhost for testing the floating ip stuff? | 14:08 |
| gtema | and this uncovers quite a mess in sdk | 14:08 |
| gtema | making func tests to work on various clouds is going to be a challenge | 14:08 |
| gtema | but side effect is that tests and code will be improved to beter detect features of the cloud | 14:09 |
| jm1 | gtema: but i guess you still need access to rackspace, ovh and vexxhost for testing the floating ip stuff? | 14:12 |
| gtema | yes | 14:12 |
| jm1 | we could ping fungi and ask nicely whether he would give us access to rackspace or ovh or vexxhost tenants. then we would be able to fix openstacksdk and they could remove the 0.61.0 pin.. | 14:14 |
| fungi | it would need new tenants | 14:14 |
| jm1 | fungi: hello fungi :) maybe you know how to get new tenants? or maybe an inofficial access for quick and dirty tests? | 14:15 |
| gtema | fungi, btw any structural objections of going https://review.opendev.org/c/openstack/project-config/+/859060 way for testing? | 14:15 |
| opendevreview | OpenStack Release Bot proposed openstack/python-openstackclient stable/zed: Update .gitreview for stable/zed https://review.opendev.org/c/openstack/python-openstackclient/+/859099 | 14:15 |
| opendevreview | OpenStack Release Bot proposed openstack/python-openstackclient stable/zed: Update TOX_CONSTRAINTS_FILE for stable/zed https://review.opendev.org/c/openstack/python-openstackclient/+/859100 | 14:15 |
| opendevreview | OpenStack Release Bot proposed openstack/python-openstackclient master: Update master for stable/zed https://review.opendev.org/c/openstack/python-openstackclient/+/859101 | 14:15 |
| fungi | we already use multiple tenants to securely separate our control plane from our test nodes since different systems need automated access. we definitely wouldn't give jobs access to those, for security reasons | 14:15 |
| opendevreview | OpenStack Release Bot proposed openstack/python-openstackclient master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/python-openstackclient/+/859102 | 14:15 |
| fungi | but we could facilitate discussion with the current donor providers about getting additional tenants for sdk testing | 14:16 |
| gtema | that is clear, but maybe there are some spare tenants | 14:16 |
| fungi | mordred used to do that for shade, though he was manually testing it | 14:16 |
| gtema | correct. We can still have this form of manual tests in particular clouds, but I would like to establish non voting jobs for various clouds | 14:17 |
| jm1 | fungi: that would be awesome! we really would like to get sdk fixed :D how and where to approach them? | 14:17 |
| gtema | this brings benefits to everybody | 14:17 |
| jm1 | fungi: do you know people inside ovh or vexxhost or rackspace? i have really no idea of openinfra's internals so i would need some guidance here but iam willing to help :) | 14:19 |
| jm1 | fungi: we need something playground for gtema before he gets bored and runs away 🙊😋 | 14:20 |
| gtema | who can be bored in this world ;-) | 14:21 |
| jm1 | gtema: i would get you access to our cloud if that would help. but rdo is so close to upstream that devstack jobs usually keep us happy 🤷 | 14:26 |
| gtema | well, everybody is close to devstack and still we have so many issues | 14:26 |
| fungi | we have a "council" which includes representatives from some of those providers, yes: https://docs.opendev.org/opendev/system-config/latest/project.html#governance | 14:26 |
| jm1 | fungi: nice! you are talking about "OpenDev Council"? | 14:29 |
| jm1 | gtema: you are not part of the council, are you? | 14:30 |
| gtema | nope | 14:30 |
| gtema | while according to the spec I should have a seat there (if I read it right) | 14:31 |
| jm1 | fungi: do you and the council meet periodically? maybe gtema and i could join one time and we could discuss cloud access with providers? (in case that would be within scope of your meetings) | 14:32 |
| fungi | there's no formal meeting of the council, it's more "people who self-identify as representatives of hosted projects and service donors" and the point of contact is the service-discuss@lists.opendev.org mailing list | 14:34 |
| fungi | i'm officially on the council since our governance says it expressly includes "members of any OpenDev project core team" | 14:35 |
| fungi | (and as a root sysadmin for the opendev collaboratory i'm also a core reviewer for most of the opendev projects) | 14:36 |
| fungi | though if you're looking for a singular point of contact for the collaboratory, clarkb is our current service coordinator | 14:36 |
| jm1 | fungi := root, nice :) maybe we should write a mail to that service-discuss list and ask for access, gtema? | 14:37 |
| jm1 | gtema: or did you contact clarkb in the past? | 14:38 |
| gtema | fungi - is your suggestion to write mail to the above address? | 14:38 |
| fungi | yep | 14:38 |
| gtema | cause I was already trying to talk to some donors directly, asking Clark, asking Jimmy | 14:38 |
| gtema | okay, will do so. Thanks | 14:39 |
| fungi | from different providers, these days probably mnaser (vexxhost), amorin (ovh), and mgagne (iweb) are the most responsive | 14:39 |
| gtema | great, thanks | 14:39 |
| gtema | what about rax, anobody there? | 14:39 |
| gtema | this is the most challenging cloud | 14:39 |
| fungi | not really, no. we have an internal advocate who basically "pays" the rackspace bill for us | 14:40 |
| gtema | sad | 14:40 |
| fungi | but there aren't a lot of rackers heavily involved in openstack these days | 14:40 |
| fungi | also, iweb probably isn't a useful target for sdk testing since they're not really in the business of running an openstack public cloud any longer (their new parent company is more focused on cloudstack) | 14:41 |
| jm1 | fungi: cloudstack, wow, havent heard that name in a while. did not know anybody is still using that 🙊 | 14:42 |
| fungi | yep, apparently it's one of the apache foundation's flagship projects | 14:43 |
| fungi | anyway, what you probably really need is someone doing what mordred did before, reaching out directly to cloud providers and asking for accounts in order to do sdk testing. then you could put the credentials for those into zuul secrets to be used by jobs | 14:44 |
| gtema | but how should I reach rax? | 14:45 |
| fungi | but the providers involved in the opendev council are probably a good place to start, since that will allow you to prove out the model for the test job with a public cloud or two | 14:45 |
| fungi | probably our best approach for rackspace will be to try to find someone there who is still involved upstream. i can look at the affiliations for the zed contributors list to get some idea | 14:46 |
| gtema | ok | 14:46 |
| fungi | having someone who is active in the project (even if just barely) who we can get to argue the request internally on our behalf | 14:46 |
| fungi | we can try to do it from the foundation side instead, but we really have very little leverage with rackspace | 14:47 |
| gtema | I feel some problem here, if rax is not so interested in offering modern OpenStack chances are too low. But since infra runs on Rax we need to test SDK just for our internal tooling | 14:48 |
| jm1 | gtema: vexxhost, ovh and iweb would be a good start, woulnd it? rax could come later | 14:49 |
| gtema | sure, but afaik rax is the only real reason for the sdk pin in zuul/nodepool | 14:49 |
| gtema | and I can't verify behaviour there | 14:50 |
| gtema | anyway - we definitely need to address those folks | 14:50 |
| jm1 | gtema: mail to service-discuss would be a good start. maybe some rax folks jumps onto it | 14:51 |
| jm1 | fungi: is service-discuss internal? its not listed at https://lists.openstack.org/cgi-bin/mailman/listinfo | 14:52 |
| fungi | jm1: you want lists.opendev.org | 14:53 |
| fungi | lists.openstack.org is for the openstack project | 14:53 |
| fungi | lists.opendev.org is for the opendev collaboratory | 14:54 |
| jm1 | fungi: omg, true 🙈 sorry | 14:54 |
| fungi | no problem | 14:54 |
| jm1 | fungi, gtema: so we have a plan :D Thank you, fungi, for your help on that! Hopefully we get some access soon and can finally fix the sdk :) | 14:57 |
| fungi | james denton has rackspace listed as a current affiliation in a foundation profile, and seems to be recently active in osa: https://review.opendev.org/857507 | 15:15 |
| fungi | of course it's possible that profile is outdated and that's on behalf of a new employer, i really can't know | 15:15 |
| gtema | sure, thanks anyway | 15:15 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Rework network functional tests https://review.opendev.org/c/openstack/openstacksdk/+/859114 | 15:54 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Extend project cleanup https://review.opendev.org/c/openstack/openstacksdk/+/859087 | 15:54 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Initialize tests of real clouds https://review.opendev.org/c/openstack/openstacksdk/+/859026 | 15:55 |
| opendevreview | Artem Goncharov proposed openstack/openstacksdk master: Rework network functional tests https://review.opendev.org/c/openstack/openstacksdk/+/859114 | 15:56 |
| opendevreview | Rafael Castillo proposed openstack/ansible-collections-openstack master: Updates server_volume for 2.0.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/858834 | 18:38 |
| opendevreview | Merged openstack/python-openstackclient stable/zed: Update .gitreview for stable/zed https://review.opendev.org/c/openstack/python-openstackclient/+/859099 | 18:49 |
| opendevreview | Merged openstack/python-openstackclient stable/zed: Update TOX_CONSTRAINTS_FILE for stable/zed https://review.opendev.org/c/openstack/python-openstackclient/+/859100 | 18:49 |
| opendevreview | Merged openstack/python-openstackclient master: Update master for stable/zed https://review.opendev.org/c/openstack/python-openstackclient/+/859101 | 19:45 |
| opendevreview | Merged openstack/python-openstackclient master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/python-openstackclient/+/859102 | 19:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!