08:01:21 <tobberydberg> #startmeeting publiccloud_sig
08:01:21 <opendevmeet> Meeting started Wed Mar 15 08:01:21 2023 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:21 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:01:28 <fkr> I've re-used the agenda from last time
08:01:36 <tobberydberg> Perfect!
08:01:48 <fkr> since from what I gathered, nothing in depth was discussed due to low attendance
08:01:55 <tobberydberg> At least we are 3 this morning :-)
08:02:05 <gtema> morning guys
08:02:56 <tobberydberg> Exactly
08:02:57 <tobberydberg> Morning!
08:02:59 <tobberydberg> Lets kick it off
08:03:00 <tobberydberg> Agenda here: #link https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:03:12 <tobberydberg> Please put your name in there as well
08:03:34 <tobberydberg> #topic 1. Support in 3rd party tools that support specific clouds. (Pick up the discussion from last time, when we ran out of time)
08:03:51 <tobberydberg> To be honest, not really sure where we left that...
08:04:01 <puck> I don't think we reached it.
08:04:56 <tobberydberg> Then I can stop looking for that discussion then ;-)
08:05:03 <gtema> me neither, can't really get what exactly it is about. At least partially it may be to "let's run some form of acceptance tests with SDK/OSC and give soft of verified label for them"
08:05:05 <puck> I've used a couple of tools that are either OpenStack compatible or S3 compatible, and they'll sometimes have preconfiguration for OpenStack based clouds. I was wondering about how we can make this easier for public clouds.
08:05:33 <puck> s/preconfiguration for/preconfiguration for some"
08:05:45 <gtema> problem with all those tools and public clouds is that they all have different configurations and expectations
08:05:57 <puck> aye
08:06:11 <gtema> i.e. openshift installer is assuming networking resources are having tags - but this is not necessarily the case
08:06:31 <gtema> and not every tool is doing proper validation or discovery of facts and capabilities of the cloud
08:06:48 <puck> microversion support can be intersting as well
08:06:53 <gtema> I can understand those however - mostly this is a relatively unknown info
08:06:55 <tobberydberg> A little bit like the work in SDK where we try to deal and abstract the complexity
08:07:32 <puck> aye
08:07:42 <gtema> yes, SDK target is exactly to get rid of this whole complexity and based on discovery do one thing or another thing, or just return exception - sorry, not possible
08:08:11 <gtema> amount of code right now in sdk is pretty much loudly describes this complexity - 150k+ loc
08:08:31 <gtema> so it is no surprise others are eventually not doing things right
08:08:56 <tobberydberg> yea, that is a hard nut to crack indeed
08:09:42 <tobberydberg> Are private cloud "configurations" considered in the SDK work as well, or only focus on public clouds?
08:10:12 <gtema> well, focus is on the capability of the cloud to let info be discoverable
08:10:36 <gtema> so in reality there is absolutely nothing what would prohibit it running well for private clouds, assuming they do things right
08:10:48 <puck> I think private clouds should certainly be supported, however I'm sure a number won't want their details leaked. So if configuration files, or discoverability can be used, that'd be best.
08:10:56 <tobberydberg> ok ok
08:10:58 <tobberydberg> right
08:11:04 <gtema> in reality we are running sdk in the backend of our cloud with custom profiles and hacks - so it works. You just need to know how to cook it
08:12:33 <puck> Okay, so this is kinda "hmmm, they should use the SDK if possible", although not all the tools are Python, so, <shrug>.
08:13:37 <gtema> yes, we spent really hell amount of effort to switch OSC/Ansible/Zuul/... towards using SDK. So this is definitely what everybody in the py world should do once trying to work with any OpenStack based cloud
08:14:56 <tobberydberg> Basically it comes down to the discoverability that is lacking information?
08:15:09 <tobberydberg> Or just that OpenStack can be configures in millions of ways so it is impossible to actually make everything discoverable
08:16:03 <gtema> both statements are correct
08:16:20 <puck> Maybe. Some of the tools will have drop downs with a list of pre-known clouds that include URLS or required tweaks.
08:16:47 <gtema> that is precisely the point why interop tests in current form are currently telling nothing about real interoperability for users
08:17:07 <puck> +1
08:17:33 <gtema> puck: knowing URLs is not a point here - it's more that once you know identity endpoint of the cloud everything else must be discoverable
08:17:40 <puck> So, I guess this loops make to the verification tools we're talking about.
08:17:44 <fkr> gtema: +1
08:18:09 <gtema> for that I am currently working on reforming SDK tests so that they can be executed against any cloud (public or private)
08:18:17 <puck> nice
08:18:49 <gtema> and that would then tell: if those tests are fine chances are great that SDK/OSC/Ansible/.. will work fine on this cloud for user (not for admin)
08:18:57 <tobberydberg> Yea, I assume that is the way to go to make that real, probably not super easy but having "real" interop test is a must have as a starting point...
08:19:12 <tobberydberg> exactly
08:19:45 <tobberydberg> BTW ... do you have what you need for that work to continue gtema or can we helt or assist in any way?
08:20:49 <gtema> so far I run those tests for Cloudera and still [ :-( ] wait for other clouds. But in reality we should consider how to treat those results
08:20:55 <tobberydberg> Credentials to clouds or what not
08:21:07 <gtema> that was the point for the forum discussion - discuss further items on that
08:21:28 <tobberydberg> yeps, which is a super good topic
08:21:58 <puck> I'm happy to facilitate some access to Catalyst Cloud as a test target.
08:22:55 <tobberydberg> so, jumping to next topic here...
08:22:56 <tobberydberg> #topic 2. How to proceed with the starters in https://etherpad.opendev.org/p/publiccloud-sig-specs
08:23:01 <fkr> gtema: i think, i did point you towards https://github.com/SovereignCloudStack/docs/blob/main/community/cloud-resources/cloud-resources.md - that way we can hook you up with access to the clouds we have at hand there
08:23:22 <gtema> great
08:23:24 <tobberydberg> I said I would give it a stab ... haven't been able to find the time unfortunate
08:23:54 <gtema> fkr - right. But I was sofar not able to proceed on that
08:25:36 <fkr> tobberydberg: is that something where pairing would help?
08:25:46 <frosty-geek> aye should be no issue to get you an account on scs1
08:26:03 <frosty-geek> s/scs1/gx-scs
08:26:08 <fkr> tobberydberg: I'd be up for that, likely I'm not able to assist you with knowledge, but it would help me ;) and it might help you allocating the time :)
08:26:56 <tobberydberg> In general for the spec ... good goal to have a first version submitted before the Summit and have a forum session about it?
08:26:58 <tobberydberg> hahaha, good point fkr, and maybe just what is needed :-)
08:27:42 <tobberydberg> I'm totally up for that, lets se if we can find a time in the upcoming weeks
08:28:01 <fkr> +1
08:29:08 <fkr> would it make sense to have a session during the upcoming virtual ptg on that as well?
08:31:15 <fkr> (did I break the conversation? :)
08:31:31 <gtema> no, everyone is thinking ;-)
08:31:36 <gtema> for my pov - +1
08:32:56 <tobberydberg> +1
08:32:58 <tobberydberg> Lets have that as one focused session for a start
08:32:59 <tobberydberg> With that said, we need to book some time for that as well
08:33:58 <tobberydberg> But that is the next topic. Lets leave this topic as is and plan for a focused session around this at the PTG
08:34:10 <fkr> how does that work?
08:34:10 <fkr> (booking the slot during ptg)
08:34:56 <tobberydberg> #topic 3. Anything to prep for PTG session?
08:34:57 <tobberydberg> Yea, saw some email about that... Will see if I can find it
08:35:01 <tobberydberg> using PTG bot it seams like
08:37:02 <puck> Is the session scheduled now? I don't see a time.
08:37:14 <tobberydberg> https://ptg.opendev.org/ptg.html
08:37:26 <tobberydberg> If we decide on time I can make sure to book
08:38:22 <fkr> we can pick the day as well? (sorry, stupid first timers questions...)
08:38:58 <tobberydberg> MONDAY, TUESDAY 1300 UTC ?
08:39:09 <fkr> sweet
08:39:27 <fkr> Monday > tuesday
08:40:00 <tobberydberg> Can we solve this without a poll? ;-)
08:40:09 <puck> Just do it. ;)
08:40:15 <fkr> +1
08:40:26 <puck> I might be able to attend, unsure, I'll have my kids that week.
08:41:06 <tobberydberg> Monday 1300 and then 3h?, so 13-16 UTC
08:41:33 <fkr> +1
08:42:56 <tobberydberg> Can't SDK team in there yet, was trying to find if that clashed with your team gtema
08:43:08 <tobberydberg> But I'll book that for now and we hope for the best
08:45:09 <gtema> sorry, was afk - I have not booked anything for SDK yet
08:45:13 <tobberydberg> Done ... except ptg-bot hanged on my last request
08:45:15 <gtema> so feel free to pick suitable time
08:45:21 <tobberydberg> +1
08:45:29 <fkr> tobberydberg: thanks for taking care of that
08:45:50 <tobberydberg> Now it is booked and PTG bot woke up again :-)
08:47:48 <puck> heh
08:51:15 <puck> Okay, anything else today?
08:51:33 <gtema> nothing from my side
08:52:16 <fkr> not from my pov
08:52:36 <puck> Possibly of interest to folks here: https://www.politico.com/news/2023/03/10/white-house-cloud-overhaul-00086595
08:54:06 <gtema> lol
08:57:38 <fkr> guess we can close it then?
08:57:42 <puck> Okay, sounds like we're done then.
08:58:05 <gtema> yup, have a nice day folks
08:58:07 <frosty-geek> \o
08:58:41 <puck> \o
08:58:50 <tobberydberg> Yes
08:58:54 * puck heads home from the office, 21:58 here
08:59:26 <fkr> \o
08:59:50 <tobberydberg> got disconneced here...
08:59:51 <tobberydberg> Thanks for today and have a great day!
08:59:52 <tobberydberg> #endmeeting