08:01:03 <tobberydberg> #startmeeting publiccloud_sig
08:01:03 <opendevmeet> Meeting started Wed Jan 18 08:01:03 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:03 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:03 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:01:10 <tobberydberg> o/
08:01:13 <fkr> o/
08:01:18 <diablo_rojo> o/
08:01:33 <kopecmartin> o/
08:01:51 <tobberydberg> Morning! As usual these days I forgot to send a reminder ... I will have to create a reminder to send a reminder I guess ;-)
08:02:05 <tobberydberg> Nice to have you here kopecmartin and diablo_rojo :-)
08:02:19 <diablo_rojo> Happy to be here!
08:02:24 <fkr> tobberydberg: I can pick up that task (either to remind you or send out the reminder ;)
08:02:40 <tobberydberg> I wonder as well if gtema is around?
08:02:55 <gtema> hi, I'm here
08:02:57 <gtema> morning
08:04:34 <tobberydberg> awesome ... morning!
08:04:34 <tobberydberg> Agenda to be find #link https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:04:52 <frickler> \o
08:04:53 <tobberydberg> 1. Forum session in Vancouver
08:05:41 <tobberydberg> We still have some time so there is nu rush on that one yet, but we had some discussion last meeting and have some ideas.
08:06:25 <tobberydberg> I also received information that kopecmartin submitted a session that interest us
08:06:39 <tobberydberg> #link https://docs.google.com/document/d/1CW0k0K7Ghnv6vN2L-c4KnWShMPQXnh3IfyRVVERel_E/edit?usp=sharing
08:06:42 <gtema> great
08:07:07 <kopecmartin> yes, basically continue the discussion we had in berlin about what other tests we could have in interop
08:08:31 <tobberydberg> I think that sounds great
08:09:18 <tobberydberg> And in my opinion I don't see the need to send in a similar one, we could probably cover all in one session ...
08:10:03 <kopecmartin> the submission is closed now, isn't it?
08:10:12 <kopecmartin> yes, agree
08:10:13 <tobberydberg> We had one suggestion to send in one regarding "Public Cloud Certification"
08:10:20 <gtema> for summit yes, but not for forum
08:10:24 <gtema> it closes somewhere in April
08:10:35 <tobberydberg> I think forum deadline was some time in March
08:10:44 <tobberydberg> ok, maybe april ;-)
08:10:50 <kopecmartin> ah, i see, i missed that :)
08:11:14 <diablo_rojo> I don't actually have the date off the top of my head either, but I think its early April.
08:11:15 <kopecmartin> i requested only 30 min, is that enough? should i edit the proposal?
08:11:25 <gtema> April 21st
08:11:28 <diablo_rojo> But we might send out some acceptances before then, that's just the final submission date.
08:11:35 <diablo_rojo> Thanks gtema !
08:11:45 <gtema> kopecmartin, I would suggest to really increase it quite lot
08:11:57 <gtema> so it should be min 1hour
08:12:01 <kopecmartin> gtema: i have the same feeling
08:12:06 <kopecmartin> it's either 30 or 70 min
08:12:29 <tobberydberg> The above mentioned session I can still se as valid, it has more attached to it then just the "interop improvement"
08:12:40 <tobberydberg> #link https://etherpad.opendev.org/p/publiccloud-sig-vancouver-2023-forum-sessions
08:12:40 <gtema> personally I would vote for something close to 90 min - I think it requires quite lot of discussions
08:12:57 <tobberydberg> Here we have our brainstorming from last meeting
08:13:41 <fkr> +1 on ~ 90 min
08:14:09 <tobberydberg> We will also add another regarding "standard set of properties" ... to continue that discussion
08:14:26 <tobberydberg> +1 90min
08:15:16 <tobberydberg> Regarding this topic ... some question poped up last time regarding the "powered program/certification"
08:15:28 <NilsMagnus[m]> I'd like to have at least a proposal document by the time of the summit. Are we able to do that? Should we assign secretaries for that or does writing to the pad suffice?
08:16:30 <tobberydberg> For the properties NilsMagnus[m] ?
08:16:32 <gtema> etherpad should be enough, but sure we should fill it in advance with thoughts so that people come prepared with thoughts and arguments
08:17:30 <tobberydberg> Agree on that
08:18:00 <tobberydberg> Discussion from last meeting: #link https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-01-04-08.10.log.html
08:18:46 <tobberydberg> One of the question was regarding Ceph with rados and how mandatory Swift per see should matter in the interop tests
08:19:31 <gtema> right. In my eyes this is a tip of an iceberg with validations of which software really runs
08:20:30 <tobberydberg> yea
08:20:31 <tobberydberg> Which led in to the question what really are the requirements for being "powered"
08:22:05 <tobberydberg> And potentially if another concept need to be introduced - like "OpenStack Compliant" - if the powered program has requirements that prevent cloud providers to get the stamp "powered"?
08:23:41 <kopecmartin> I think that right now no tests in the current powered programs prevent anyone from getting the stamp
08:24:00 <kopecmartin> well, apart from cinder tests maybe as that service doesn't need to be technically active in a working openstack cloud
08:24:09 <NilsMagnus[m]> Not just on the properties but a whole document that can be handed over to the board about Interop procedures and policies. Details may be changed by us or others, but I think we (and others) really need something to refer to.
08:24:42 <gtema> no, and that is exactly the point why I raised this. afaik lot of clouds really run ceph with rados and with that only few clouds would have right to obtain "powered by" officially
08:25:27 <kopecmartin> but there aren't many cases like that, introduction of a compliant program might be a good idea when we would like to include some tests which we know won't pass on *every* openstack cloud
08:26:00 <kopecmartin> yes, correct
08:26:45 <tobberydberg> But the powered program also comes with the "legal stuff" .... maybe diablo_rojo knows more here... But I believe being a sponsor is one, maybe also signing off of using native swift is another?
08:27:00 <gtema> and more then that - no test is really capable to properly verify version of software running in cloud, what is an "expectation" of the testing (like only few release cycles back)
08:27:27 <diablo_rojo> tobberydberg: I remember something like that, but I would need to go read up on the details before I could say for sure.
08:28:30 <tobberydberg> No problem, but something that could be really good to know in this discussion. I should know I feel, but I don't remember ;-)
08:29:29 <tobberydberg> As discussed in Berlin, having tests/checks running periodically from a central location, pretending to be end user could validate "openstack compliant" in real time and make a lot of sense for end users
08:29:43 <gtema> right
08:30:09 <gtema> and would help to get rid of current problem of having too many staled results in marketplace
08:30:50 <diablo_rojo> tobberydberg: https://www.openstack.org/brand/openstack-powered/
08:32:24 <diablo_rojo> There's a bit more here too - https://www.openstack.org/brand/interop/
08:32:25 <gtema> right diablo_rojo. And with that all clouds with Ceph are only able to get maximum "OpenStack Powered Compute"
08:32:41 <diablo_rojo> Yep that matches what I am reading too
08:32:46 <gtema> and OpenStack compatible is only applicable for certain drivers
08:33:34 <kopecmartin> running from a centralized location has a security problem, not all (maybe the majority of them) testing clouds are available to the public
08:33:54 <gtema> but those can not be anyway listed as "public cloud" then
08:34:03 <tobberydberg> As a public cloud I do not see that as an issue
08:34:08 <gtema> and we now talk (at least I) about verification of public clouds
08:34:51 <tobberydberg> Me too, but I totally get that there are other use cases out there as well for private clouds etc
08:34:58 <frickler> but is a cloud automatically non-public if access to the APIs is protected via a customer-only VPN?
08:35:35 <gtema> I can't honestly imagine such combination
08:35:44 <gtema> for me this is a total non-public cloud anymore
08:35:58 <gtema> imagine AWS/GCP/co do something like that
08:37:54 <gtema> to that direction - how are you supposed to make your swift static hosting to the public if access (and this goes through api) is requiring VPN
08:38:04 <tobberydberg> I agree on that, but if such solution exists and the cloud is multi tenant I assume there could be a way to open up API towards a selected central location to a single tenant to perform the tests as well, if the provider is interested in the tests and results
08:38:54 <fkr> frickler: I would not say that that is a public cloud then
08:39:14 <gtema> correct. Good design for public cloud would be to enable user to limit API management of his/her domains only through VPN (like ACLs for API access)
08:39:29 <gtema> but not in general
08:39:53 <fkr> NIST says: "The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider." ;)
08:40:30 <tobberydberg> And one obvious thing in this is that we do not cover "admin api calls" in these tests
08:41:15 <frickler> but what is "open use"? nobody offers any service to anyone, just to registered customers. is that open?
08:42:31 <tobberydberg> Before I forget it, kopecmartin have planned to setup off some time during the Virtual PTG for this topic as well, you will have to correct me if I misunderstood you :-)
08:42:46 <fkr> frickler: I'd actually say that following the NIST definition an api that is 'exclusive' is not something that makes a difference to wether it is considered public cloud or not
08:42:48 <gtema> anyway, I think if that could be the case it would be still possible to agree on deploying certain "runners" to the cloud in question
08:42:52 <kopecmartin> tobberydberg: that's right
08:42:59 <gtema> so this can we solved if the case really occurs
08:43:33 <tobberydberg> I guess so too
08:44:47 <tobberydberg> In my opinion we potentially need a new "stamp" (openstack compliant or what not), or adjust the current ones that are there, to enhance the end user value to them
08:45:14 <tobberydberg> I totally understand the membership parts to be allowed to use the logo etc
08:45:26 <kopecmartin> or a stamp more oriented on public clouds, the current ones don't differentiate much between a public and private one
08:46:02 <tobberydberg> That is of course a good idea as well
08:46:45 <tobberydberg> But from a end user user perspective, I'm not really THAT interested in if it is really native swift in the bottom or just swift apis on ceph
08:46:49 <tobberydberg> for example
08:47:23 <kopecmartin> good only if the public clouds would be tested with a different set of tests which aren't expected to work on private one, if there are such tests
08:48:30 <tobberydberg> private clouds might be much more interested in covering admin api calls
08:49:06 <tobberydberg> but yea, there are different use cases for public and private clouds in general that make sense
08:49:47 <kopecmartin> different use cases and we may take a different approach to certify them
08:50:42 <tobberydberg> Maybe we should plan for a separate forum session regarding the "stamps"?
08:52:29 <tobberydberg> Like en oversight of whats there and what we lack, need to change etc
08:52:43 <kopecmartin> sure, why not
08:53:43 <kopecmartin> these 2 discussions relates, but are completely different disucssions (testing and certification, granting stamps)
08:53:45 <tobberydberg> We can have that in mind .... it all ties in together, so might be to early at this point...
08:54:14 <tobberydberg> I agree on that, and the reason I thought a session might be good
08:54:44 <tobberydberg> Time flies ... anything else that we would like to bring up today?
08:56:35 <fkr> just the note that I started brushing the wiki page of the SIG. Feel free to join and bring in new items there
08:57:51 <tobberydberg> Awesome fkr ... will for sure help out there!
09:00:29 <tobberydberg> Well ... thanks a lot for today and hope to chat with again in two weeks if not prior to that! :-)
09:01:00 <diablo_rojo> Thank you!
09:01:02 <kopecmartin> thank you
09:01:06 <tobberydberg> #endmeeting