08:03:51 <tobberydberg> #startmeeting publiccloud_sig
08:03:51 <opendevmeet> Meeting started Wed Feb 15 08:03:51 2023 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:03:51 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:03:51 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:04:13 <tobberydberg> #link https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:04:25 <tobberydberg> As usual, please put your name in there
08:05:01 <tobberydberg> Awesome that somebody stepped up and created the agenda - puck?
08:05:19 <puck> Yeah, guilty as charged.
08:05:29 <tobberydberg> Thank you :-)
08:05:32 <puck> np
08:05:50 <puck> I also started putting some content into the spec.
08:06:01 <puck> (but only a little bit)
08:06:02 <tobberydberg> #topic 1. How to continue the "standard set of properties" work
08:06:13 <tobberydberg> I saw that, great!
08:07:38 <puck> I'm thinking that the spec probably needs detail on what each of the properties are about.
08:07:55 <tobberydberg> Looking at that it seams to have the decided additions and looks correct
08:07:59 <tobberydberg> +1
08:11:51 <tobberydberg> I guess we will have to structure it and outline it towards a template...
08:12:16 <puck> Agreed
08:13:25 <fkr> aye
08:13:41 <tobberydberg> Not really sure if there exists a template somewhere to look at ... was trying to find that...
08:16:05 <puck> I can't even think of where one would be.
08:16:15 <puck> Withing OpenStack that is.
08:16:56 <tobberydberg> I mean, we can look at specs from other teams etc
08:16:59 <tobberydberg> https://specs.openstack.org/openstack/cinder-specs/specs/2023.1/extend-volume-completion-action.html
08:17:02 <tobberydberg> for example
08:17:53 <fkr> seems legit to follow that (from quickly eyeballing it)
08:18:14 <puck> Yeah, fair enough.
08:19:50 <tobberydberg> Have been scrolling through a bunch of specs form various teams....This is a more "top level spec" that will (hopefully) result in specs in various teams...
08:20:27 <fkr> I wanted to suggest ADR style in the beginning
08:20:42 <fkr> (however I lack in-depth knowledge how this is usually done within openstack)
08:21:19 <fkr> however ADR-style would offer a 'high-level spec' from which in-depth specs for the teams can be done/can come
08:21:30 <gtema> ADRs are too "new" for OpenStack to start adopting
08:21:41 <gtema> but I would agree it is a pretty good usecase
08:24:23 <tobberydberg> ok. I guess dependencies is needed in there as well
08:25:40 <tobberydberg> To be successful we have dependencies towards nova, glance, sdk at least, right?
08:26:49 <tobberydberg> Implementation specifics seams pretty far off for us to go into here ...
08:27:27 <gtema> dependency on SDK is totally different to nova/glance, but yes
08:27:39 <gtema> same way also ansible-collections-openstack would be one
08:28:09 <puck> yup, object storage (although should be agnostic between swift and radosgw)
08:28:53 <tobberydberg> Yea, indeed
08:32:30 <tobberydberg> So I guess next step is to drafting some text here as well. I will try to find some time to give it a stab until next meeting.
08:34:30 <puck> Cool
08:35:49 <tobberydberg> Should we spend a few minutes on the rest of the topics on the agenda?
08:36:25 <gtema> +1
08:37:14 <fkr> +1
08:37:36 <tobberydberg> #topic 2. A number of distros publish images directly to the big cloud providers, can we facilitate this for OpenStack public clouds? (puck)
08:38:05 <tobberydberg> I leave the word a little bit to you puck here :-)
08:38:27 <gtema> I do not think this will/can ever happen. At least on our side we prepare all images to include supplementary HW drivers and do some other "security" related changes
08:38:58 <gtema> therefore those bare images are not really working properly in our cloud (only on few basic flavors)
08:39:06 <puck> Interesting, we just publish the vendor images. I'd like us to customise some, but it hasn't happened yet.
08:39:30 <puck> Especially Ubuntu, since we aren't paying them the license fees, we can't modify them.
08:40:10 <gtema> this is not our case and we are also obliged (in front of customers) to do additional security hardenings
08:40:19 <tobberydberg> But you all allow users to "bring your own image", right?
08:40:25 <gtema> yes
08:40:30 <puck> Yes, we allow customers to bring their own image.
08:41:09 <puck> It is a bit annoying to see the distros uploading their images for the big three and officially publishing them. I was just wondering if there is anything we can do to help get the smaller players recognised.
08:41:24 <tobberydberg> So, I like the idea of having a central local for "openstack ready images" ... but I agree that there will be hard to get all public clouds to actually use them
08:41:47 <puck> Even finding those images for some distros is hard!
08:41:57 <tobberydberg> exactly that puck I agree to
08:41:58 <gtema> I can't even also imagine i.e. Fedora pushing their build to 100 other OpenStack based clouds
08:42:24 <tobberydberg> Not sure how to address the issue though
08:42:41 <gtema> also from security pov giving somebody from outside write permissions for public images is definitely not going to work on our side
08:43:16 <puck> Unfortunately I have no idea, which is why I wanted to table it. ;) Perhaps a central location within OpenStack that points to where distro images are available from?
08:43:38 <puck> Public cloud providers could indicate which images they make available and whether they're vanilla, or modified?
08:43:49 <tobberydberg> Well, we could potentially have one central "for OpenStack"
08:44:05 <gtema> I can imagine building some sort of portal for the OS based clouds from where they can do something like: "import latest Fedora/Ubuntu image into my cloud"
08:44:28 <gtema> but the biggest question for me - why
08:44:29 <gtema> what should this actually address
08:44:43 <fkr> how is the security aspect handled with the "big clouds"? I meant, I suspect that they will analyze the images that are pushed by the distros before releasing them to their customers
08:44:58 <puck> I don't think that happens for the Debian images.
08:45:53 <fkr> interesting. since the notion feels different between "pulling the image from the distro and offering it customers" to "having the distro directly push it" even though, there is not really a difference ;)
08:46:08 <frickler> for the SCS project we have https://github.com/osism/openstack-image-manager which tries to keep track of the various upstream sources
08:46:30 <fkr> good point frickler
08:46:36 <gtema> cool, I meant exactly something like that
08:46:43 <puck> Subtle difference, we smoke screen the images before we make them public. (Spin up an instance, make sure we can ssh in and ping out.) That process is automated.
08:46:53 <frickler> we could try to move that into a more general upstream location
08:47:49 <tobberydberg> That is what I meant as well :-)
08:47:58 <tobberydberg> That would make a lot of sense imo frickler
08:48:50 <frickler> so would this fit as repo owned by this sig? or do you see a different entity?
08:49:13 <frickler> (pending discussion within the scs community of course)
08:50:14 <tobberydberg> That is a good question...I don't see that it doesn't fit, but maybe where are even better suited location?
08:52:04 <tobberydberg> Some tests etc can be done towards multiple clouds for each image ... potentially each cloud is able to sign up for verification of image in there cloud...
08:52:19 <frickler> maybe we could then get vendors to contribute by updating information about their images in that repo
08:52:42 <fkr> frickler: +1
08:52:57 <frickler> the verification could maybe be combined with what gtema is building for SDK/OSC
08:53:03 <tobberydberg> "Image Ubuntu XX.XX is proven to work fine on these clouds" kind of thing
08:53:20 <frickler> in terms of access to clouds being needed
08:53:48 <fkr> frickler: i can take the discussion into team iaas @ scs for 'upstreaming' the image manager, since we have the discussion on long-term maintainence anyways
08:53:49 <frickler> but I'm not sure if the sdk project would be a good home for this. otoh maybe why not
08:54:01 <gtema> yes, this sounds feasible. Some sort of sdk/osc driven verification for that is possible
08:54:33 <gtema> most likely not the SDK itself, but something like a new redesigned "certification" platform
08:55:48 <tobberydberg> Yea ... like the one for "external tempest testing"
08:55:49 <frickler> I was just talking in terms of openstack governance where the openstack-image-manager might be homed
08:56:23 <tobberydberg> So, this feels like something we can continue to talk about and I think a Forum session around this might be suitable as well
08:57:21 <gtema> +1
08:57:30 <tobberydberg> #link https://etherpad.opendev.org/p/publiccloud-sig-vancouver-2023-forum-sessions
08:58:06 <tobberydberg> If you feel puck, please put it in there as a suggestion
08:58:22 <puck> Okay, sure
08:59:22 * puck considers attending possibly contentious topic of "do tested clouds need to OpenInfra financial members". :)
08:59:49 <tobberydberg> We are running out of time here ... we have one item more on the agenda before other matters :-)
08:59:50 <tobberydberg> Shall we push that one until next meeting?
09:00:10 <gtema> yeah
09:00:21 <puck> ack
09:00:23 <tobberydberg> I guess that questions have multiple answers
09:01:01 <tobberydberg> Running the tests are one thing, be presented as "certified" most probably do yea
09:02:04 <puck> Yup, but we can park that for next time.
09:02:13 <puck> And in fact, we're out of time.
09:02:26 <tobberydberg> yea we are
09:02:49 <tobberydberg> One quick last thing ... should we try to have a session during the PTG?
09:04:17 <tobberydberg> Could it be worth starting to present our ideas around standard properties, certifications etc there?
09:04:17 <puck> Seems sensible.
09:04:42 <gtema> yes, why not
09:05:07 <tobberydberg> I'll make sure to sign up for that then!
09:05:29 <tobberydberg> I know I'm doing some travelling around those dates, but not the full week
09:05:50 <tobberydberg> Thanks a lot for today folks! Talk to you soon!
09:06:16 <puck> Cheers, hope you all have a good day!
09:07:49 <tobberydberg> #endmeeting