07:02:27 <tobberydberg> #startmeeting publiccloud_sig
07:02:27 <opendevmeet> Meeting started Wed Jul  5 07:02:27 2023 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:02:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:02:28 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
07:03:13 <tobberydberg> Kick it off or hold a few minutes if people join late?
07:03:49 <puck> Wait till 5 minutes past?
07:04:16 <tobberydberg> +1
07:05:41 <puck> ding dsing
07:06:00 <tobberydberg> 1. (fkr) Quick re-cap of discussion regarding domain admin role that happened on Monday 5th June, 2023
07:06:17 <fkr> that was from two weeks ago ;)
07:06:24 <fkr> (the agenda item)
07:06:33 <puck> 4 weeks ago.
07:06:42 * fkr scratches his head
07:06:44 <tobberydberg> Aha :-)
07:06:54 <puck> I renamed the June 7th meeting to July 5th.
07:07:13 <tobberydberg> Ok ok
07:08:11 <fkr> I'm working in my head to summarize it
07:08:14 <tobberydberg> So, start with recap from Vancouver?
07:08:16 <puck> ha
07:08:23 <tobberydberg> hehe
07:08:32 <puck> I believe there was a post to openstack-discuss about it
07:09:09 <fkr> - for once while everyone (= CSPs) said domain admin role is useful, it was apparent that there are quite a few things that CSPs don't want customers to be doing (even with domain admin)
07:09:42 <fkr> - partially due to being afraid of side-effects (in the example of purging stuff that is not properly purged)
07:10:18 * puck nods
07:10:38 <fkr> - as such the understanding of 'domain admin' is something that would need proper definition and to assure (upfront) a common understanding
07:11:25 <fkr> - on the long run (done properly) it would ease a lot of things (especially for newcomers to the CSP landscape that do not yet have their own tooling around it)
07:11:55 <fkr> - Cleura, OTC and PlusServer were there CSPs that took part in the discussion
07:12:16 <tobberydberg> This was discussed in Vancouver as well, just to have that said
07:12:18 <fkr> - we want to schedule a follow-up session that is set at a time that suits catalyst cloud
07:12:36 <fkr> tobberydberg: and there I'd be really interested in the results
07:12:38 <fkr> :)
07:12:51 <tobberydberg> Trying to find the etherpad...
07:13:36 <tobberydberg> But I don't at this point
07:13:54 <puck> Cool. Thank you for that. One of my colleagues has prepared some policies that will implement domain admin in a way that we think will work - we're called it organisations. I need to finish a security review of it, because, yeah, that's critical for this kind of thing.
07:14:09 <fkr> :)
07:14:28 <tobberydberg> In general, they are dropping the "different scope thing" from what I understood, or at least that is the plan
07:14:35 <puck> I guess in some respects "domain admin" will mean different things to different clouds.
07:14:43 <fkr> puck: exactly
07:15:04 <puck> We think that policies will actually allow it.
07:15:20 <tobberydberg> Had some discussions about alternate plans, for example a role that can only do "domain admin stuff", that in that case only need to exist in keystone
07:15:23 <puck> But, yet to follow prove that!
07:15:56 <puck> Another alternate plan is to make more use of Adjutant to provide "admin" workflows.
07:16:17 <tobberydberg> That would simplify it quite a bit, even though "domain scope" would have taken that further
07:16:58 <tobberydberg> I have too little knowledge about Adjutant. Is it still an "active official openstack project" puck?
07:17:11 <puck> We currently use Adjutant for signups, inviting new/existing users to a project, quota adjustments.
07:17:25 <puck> Hmm... I think it is.
07:18:06 <puck> Hmm, looks like last release was Zed. Arse.
07:19:19 <puck> I expect that even with "domain admin", we'd still use Adjutant, because "domain admin" doesn't solve everything.
07:19:42 <puck> That's a great recap fkr, sounds like there is interest for it, but more discussion required.
07:20:17 <tobberydberg> Indeed
07:20:28 <puck> Oh, ordering on https://releases.openstack.org/teams/adjutant.html is confusing. There is an Antelope release of Adjutant.
07:20:45 <tobberydberg> To be frank, not sure what the best way forward is, especially if they drop the domain/system scope thing
07:21:32 <tobberydberg> Yea, the ordering becomes strange there indeed
07:21:35 <puck> Domains might be dropped?! Hmm...  We had planned on allowing customers to back their own auth source to their domains to allow AD/LDAP integration for customers.
07:21:47 <tobberydberg> domain-scope-thing
07:21:56 <tobberydberg> not domains per se :-)
07:22:01 <puck> Ah, huh
07:22:03 <puck> Ah ha
07:22:05 <puck> (typo)
07:24:16 <tobberydberg> https://docs.openstack.org/keystone/rocky/admin/identity-tokens.html
07:24:17 <tobberydberg> That is how I understood it at least
07:24:41 <tobberydberg> https://etherpad.opendev.org/p/rbac-operator-feedback-vancouver2023
07:24:59 <fkr> ah
07:25:01 <fkr> thanks
07:25:16 <puck> I would have joined some of those meetings, but the timezone delta sucked for us.
07:25:26 <tobberydberg> It was touched in that session, but mostly discussions around project reader role
07:25:31 <puck> And I had my kids that week, so getting up in the middle of the night wasn't an option.
07:25:48 <fkr> puck: I was not aware that those sessions were remotely available
07:26:06 <puck> Ha, actually, neither here. I didn't bother looking! :)
07:26:25 <tobberydberg> No they were not unfortunate
07:26:52 <fkr> shall I see to organize a follow up videocall session for us?
07:27:13 <puck> I'm keen.
07:27:19 <fkr> this would actually lead also to the next point on the agenda (how to get more people active here)
07:27:38 <fkr> tobberydberg, OK to jump to next item on the agenda as well?
07:28:16 <tobberydberg> for sure
07:28:17 <tobberydberg> Yes
07:28:19 <tobberydberg> 2. (fkr) Further ways and ideas to get more people involved in the public cloud SIG
07:29:16 <fkr> in the SCS world I organize some regular formats for SCS Operators (for example a monthly lean coffee where problems / hurdles are discussed) and I wondered wether a format in the OpenInfra Public Cloud SIG scope would be nice
07:29:49 <fkr> for bringing together OpenStack Operators from here to discuss things as technical hurdles, exchange ideas
07:30:04 <fkr> i do think it is different than pure textual format
07:30:39 <tobberydberg> It sure is, and becomes more effective and fruitful discussions
07:30:56 <puck> Catalyst Cloud occasionally, should be more regular, chats directly with an Australian OpenStack cloud.
07:31:06 <tobberydberg> I'm totally fine with that. We could use this slit for it potentially?
07:31:16 <fkr> tobberydberg: +1
07:31:32 <puck> I can certainly check and see if they're aware of it.
07:31:40 <fkr> I'd be open to facilitate / moderate it
07:31:58 <fkr> (actually, I'd like to do that :)
07:32:09 <puck> (hah, cross conversation, but my statement still holds about the Aussies)
07:32:23 <fkr> sorry
07:32:24 <fkr> :)
07:32:35 <tobberydberg> +1
07:33:06 <puck> Could OpenInfra reach out to the public clouds that are members and make sure they know about this SIG?
07:33:07 <fkr> puck: please do get them in the loop!
07:33:21 <fkr> puck: I can reach out to OpenInfra
07:33:23 <tobberydberg> Should we do it asap, lets say next meeting in 2 weeks, or hold off until after summer in Europe?
07:33:49 <fkr> tobberydberg: in two weeks works fine for me
07:33:58 <tobberydberg> puck They do that to every new member of the foundation that are a public cloud
07:34:17 <puck> cool
07:34:21 <fkr> puck: the "please do get them in the loop" was in regards to the australian cloud
07:34:29 <puck> Yup, that's how I took it
07:34:40 <tobberydberg> BUT ... I actually think that if we put something together that can be mentioned in a newsletter or something, that can be valuable as well
07:34:46 <fkr> tobberydberg: +1
07:34:47 <tobberydberg> good idea actually
07:35:20 <tobberydberg> We can look for a even more directed message to all public openstack clouds as well...
07:36:11 <puck> I guess something there is, being listed as a public cloud with OpenInfra, the required membership fee is a barrier...
07:38:09 <tobberydberg> Yea it is
07:38:57 <puck> Looking at https://www.openstack.org/marketplace/public-clouds/ , I know there are more public clouds that are using OpenStack.
07:39:56 <fkr> that is a short list
07:40:05 <fkr> i'm surprised about its shortness
07:40:15 <tobberydberg> Yea, lets think a bit about how we can reach out there for more exposure. Could be something like a section on one of those pages mentioning the group etc
07:40:30 <tobberydberg> As puck said, you need to be a member
07:40:49 <tobberydberg> I think that some outreach in the SCS world might be another way as well?
07:41:20 <fkr> tobberydberg: yes (that is also the reason why frosty-geek is in this room)
07:41:33 <fkr> :)
07:42:12 <tobberydberg> +1
07:44:16 <tobberydberg> Wrote a few notes in the etherpad about this
07:44:17 <tobberydberg> 3. (puck) Community support for users
07:44:22 <tobberydberg> lets take the next topic ... soon out of time :-)
07:45:08 <puck> Cool. This came up as some feedback from one of our customers something like "finding how to do this on AWS is easy, lots of places to find help". The options for OpenStack are limited, and kinda suck.
07:45:35 <puck> I listed the recommedations on the agenda, which is just stackoverflow for users.
07:45:47 <puck> I don't think emailing openstack-discuss is a valid suggestion.
07:46:11 <puck> Is this something that others are seeing as a problem?
07:46:22 <tobberydberg> Totally agree that email list isn't the best way for users...
07:46:39 <tobberydberg> Yes, I see that as an issue
07:46:43 <puck> That is listed on https://ask.openstack.org/
07:47:02 <puck> Which is a shit suggestion for users. :)
07:47:19 <tobberydberg> the hard part of it is that all openstack clouds work different when it comes to details, compared to AWS for example
07:47:44 <puck> Agreed, but the general concepts are the same. Mostly APIs, cloud-init, Terraform etc.
07:48:08 <puck> We do have our own docs (and we know some other clouds have forked them!), but we can't cover everything.
07:48:17 <tobberydberg> Yes, it would make it soooo much better than nothing :-)
07:48:30 <tobberydberg> We have started our "journey" of a docs site as well
07:48:47 <tobberydberg> But, to be frank, I've used your docs from time to time as well :-)
07:48:52 <fkr> tobberydberg: in detail yes (which is why "we" (scs) think that it is worthwhile to have something like SCS) - but the concepts are the same and just as in teaching, it is needed to teach users about the concepts then
07:48:54 <puck> https://github.com/catalyst-cloud/catalystcloud-docs BTW
07:49:00 <puck> ha, awesome. :)
07:49:22 <tobberydberg> One example: Try to find the way how you get the openstack client working on windows out there :-)
07:49:48 <tobberydberg> Not that I ever recommend that, but we do have customers that don't know anything else than that
07:50:13 <puck> https://docs.catalystcloud.nz/sdks-and-toolkits/windows-cli.html :)
07:50:18 <fkr> :)
07:50:45 <puck> And yeah, understood.
07:50:49 <fkr> just to better understand:
07:51:00 <fkr> puck: could this also be a 'problem' of the right content for the right people?
07:51:04 <fkr> see https://diataxis.fr/
07:51:20 <fkr> diataxis basically divides documentation into different types of documentation
07:51:32 <fkr> tutorials is something different than a reference guide
07:51:50 <puck> fkr, yup, totally, and yes, completely right. And Youtube videos != documentation.
07:51:52 <fkr> and often users are looking much for tutorial than reference guide
07:52:19 <puck> We try to provide both, but tutorials need to be refreshed.
07:53:18 <puck> So, I'm not sure on the best way forward here, but I was wondering if others are finding this a problem (the answer appears to be "yes"), and what others might be doing to try and resolve it.
07:53:36 <tobberydberg> yes
07:54:11 <tobberydberg> I would assume that the "right way" would be have the documentation on docs.openstack.org
07:54:19 <puck> Yes.
07:54:21 <puck> Oh.
07:54:36 <puck> And also, oh my goodness, having docs missing from the latest release sucks.
07:54:44 <tobberydberg> yes
07:54:52 <puck> That sucks so so so much
07:55:03 <tobberydberg> That is the hard part about that, keeping it up to date for all releases etc etc
07:55:16 <tobberydberg> https://docs.openstack.org/operations-guide/
07:55:34 <puck> Better to have it, even if people find it is incorrect than to require users/admins to go back through each version to find the last documentation.
07:56:15 <tobberydberg> You have the operator guide that is a little bit different
07:56:16 <tobberydberg> That is not "release cycle dependent"
07:56:19 <tobberydberg> But it sucks so much that there are no "User Guide" in the same sense
07:57:01 <tobberydberg> It is more detailed with each and every project
07:57:40 <puck> But look at https://docs.openstack.org/2023.1/user/ it is missing Neutron!
07:57:41 <tobberydberg> and plenty of guides for projects are missing
07:57:47 <tobberydberg> exactly
07:58:00 <puck> Like, WRD?
07:58:03 <puck> er, WTF?
07:58:09 <tobberydberg> I would assume due to the fact of not up to date with last release
07:58:23 <puck> Have the projects really changed that much? No.
07:59:12 <tobberydberg> The guides that exist are actually good and detailed, some better than other, but just the fact that its hard to find if it isn't updated with the last release sucks
08:00:05 <puck> Any ideas on how we get those pulled through?
08:00:16 <tobberydberg> AND ... I think something more "generic" or "use case focused" would be needed
08:00:20 <tobberydberg> Like docs.catalystcloud.nz or docs.cleura.cloud is
08:00:26 <fkr> I'll move my attention to the IaaS call @ SCS now
08:00:29 <puck> Agreed, that's why we wrote our own docs.
08:00:37 <fkr> thanks for this nice and lively discussion today :)
08:00:44 <puck> Okay, outta time. Good meeting! :)
08:00:55 <tobberydberg> exactly the same here ... and it also becomes more "single cloud focused" ... illing and what not...
08:02:01 <tobberydberg> Yes, lets think about if that is something for this group to "take on" or make suggestions for ... I guess it will be talking to TC to get it in place, if that is what we think is the right approach
08:02:15 <puck> aye
08:02:24 <tobberydberg> Thanks for a good meeting and have a great day or a good sleep ;-)
08:02:34 <tobberydberg> #endmeeting