| tobberydberg | #startmeeting publiccloud_sig | 08:01 |
|---|---|---|
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:01 |
| opendevmeet | The meeting name has been set to 'publiccloud_sig' | 08:01 |
| tobberydberg | o/ | 08:01 |
| fkr | o/ | 08:01 |
| diablo_rojo | o/ | 08:01 |
| kopecmartin | o/ | 08:01 |
| 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:01 |
| tobberydberg | Nice to have you here kopecmartin and diablo_rojo :-) | 08:02 |
| diablo_rojo | Happy to be here! | 08:02 |
| fkr | tobberydberg: I can pick up that task (either to remind you or send out the reminder ;) | 08:02 |
| tobberydberg | I wonder as well if gtema is around? | 08:02 |
| gtema | hi, I'm here | 08:02 |
| gtema | morning | 08:02 |
| tobberydberg | awesome ... morning! | 08:04 |
| tobberydberg | Agenda to be find #link https://etherpad.opendev.org/p/publiccloud-sig-meeting | 08:04 |
| frickler | \o | 08:04 |
| tobberydberg | 1. Forum session in Vancouver | 08:04 |
| 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:05 |
| tobberydberg | I also received information that kopecmartin submitted a session that interest us | 08:06 |
| tobberydberg | #link https://docs.google.com/document/d/1CW0k0K7Ghnv6vN2L-c4KnWShMPQXnh3IfyRVVERel_E/edit?usp=sharing | 08:06 |
| gtema | great | 08:06 |
| kopecmartin | yes, basically continue the discussion we had in berlin about what other tests we could have in interop | 08:07 |
| tobberydberg | I think that sounds great | 08:08 |
| 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:09 |
| kopecmartin | the submission is closed now, isn't it? | 08:10 |
| kopecmartin | yes, agree | 08:10 |
| tobberydberg | We had one suggestion to send in one regarding "Public Cloud Certification" | 08:10 |
| gtema | for summit yes, but not for forum | 08:10 |
| gtema | it closes somewhere in April | 08:10 |
| tobberydberg | I think forum deadline was some time in March | 08:10 |
| tobberydberg | ok, maybe april ;-) | 08:10 |
| kopecmartin | ah, i see, i missed that :) | 08:10 |
| diablo_rojo | I don't actually have the date off the top of my head either, but I think its early April. | 08:11 |
| kopecmartin | i requested only 30 min, is that enough? should i edit the proposal? | 08:11 |
| gtema | April 21st | 08:11 |
| diablo_rojo | But we might send out some acceptances before then, that's just the final submission date. | 08:11 |
| diablo_rojo | Thanks gtema ! | 08:11 |
| gtema | kopecmartin, I would suggest to really increase it quite lot | 08:11 |
| gtema | so it should be min 1hour | 08:11 |
| kopecmartin | gtema: i have the same feeling | 08:12 |
| kopecmartin | it's either 30 or 70 min | 08:12 |
| tobberydberg | The above mentioned session I can still se as valid, it has more attached to it then just the "interop improvement" | 08:12 |
| tobberydberg | #link https://etherpad.opendev.org/p/publiccloud-sig-vancouver-2023-forum-sessions | 08:12 |
| gtema | personally I would vote for something close to 90 min - I think it requires quite lot of discussions | 08:12 |
| tobberydberg | Here we have our brainstorming from last meeting | 08:12 |
| fkr | +1 on ~ 90 min | 08:13 |
| tobberydberg | We will also add another regarding "standard set of properties" ... to continue that discussion | 08:14 |
| tobberydberg | +1 90min | 08:14 |
| tobberydberg | Regarding this topic ... some question poped up last time regarding the "powered program/certification" | 08:15 |
| 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:15 |
| tobberydberg | For the properties NilsMagnus[m] ? | 08:16 |
| 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:16 |
| tobberydberg | Agree on that | 08:17 |
| 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 |
| tobberydberg | One of the question was regarding Ceph with rados and how mandatory Swift per see should matter in the interop tests | 08:18 |
| gtema | right. In my eyes this is a tip of an iceberg with validations of which software really runs | 08:19 |
| tobberydberg | yea | 08:20 |
| tobberydberg | Which led in to the question what really are the requirements for being "powered" | 08:20 |
| 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:22 |
| kopecmartin | I think that right now no tests in the current powered programs prevent anyone from getting the stamp | 08:23 |
| kopecmartin | well, apart from cinder tests maybe as that service doesn't need to be technically active in a working openstack cloud | 08:24 |
| 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 |
| 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:24 |
| 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:25 |
| kopecmartin | yes, correct | 08:26 |
| 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:26 |
| 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 |
| 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:27 |
| 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:28 |
| 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 |
| gtema | right | 08:29 |
| gtema | and would help to get rid of current problem of having too many staled results in marketplace | 08:30 |
| diablo_rojo | tobberydberg: https://www.openstack.org/brand/openstack-powered/ | 08:30 |
| diablo_rojo | There's a bit more here too - https://www.openstack.org/brand/interop/ | 08:32 |
| gtema | right diablo_rojo. And with that all clouds with Ceph are only able to get maximum "OpenStack Powered Compute" | 08:32 |
| diablo_rojo | Yep that matches what I am reading too | 08:32 |
| gtema | and OpenStack compatible is only applicable for certain drivers | 08:32 |
| 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 |
| gtema | but those can not be anyway listed as "public cloud" then | 08:33 |
| tobberydberg | As a public cloud I do not see that as an issue | 08:34 |
| gtema | and we now talk (at least I) about verification of public clouds | 08:34 |
| tobberydberg | Me too, but I totally get that there are other use cases out there as well for private clouds etc | 08:34 |
| frickler | but is a cloud automatically non-public if access to the APIs is protected via a customer-only VPN? | 08:34 |
| gtema | I can't honestly imagine such combination | 08:35 |
| gtema | for me this is a total non-public cloud anymore | 08:35 |
| gtema | imagine AWS/GCP/co do something like that | 08:35 |
| 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:37 |
| 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 |
| fkr | frickler: I would not say that that is a public cloud then | 08:38 |
| 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 |
| gtema | but not in general | 08:39 |
| 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:39 |
| tobberydberg | And one obvious thing in this is that we do not cover "admin api calls" in these tests | 08:40 |
| frickler | but what is "open use"? nobody offers any service to anyone, just to registered customers. is that open? | 08:41 |
| 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 |
| 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 |
| 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 |
| kopecmartin | tobberydberg: that's right | 08:42 |
| gtema | so this can we solved if the case really occurs | 08:42 |
| tobberydberg | I guess so too | 08:43 |
| 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:44 |
| tobberydberg | I totally understand the membership parts to be allowed to use the logo etc | 08:45 |
| kopecmartin | or a stamp more oriented on public clouds, the current ones don't differentiate much between a public and private one | 08:45 |
| tobberydberg | That is of course a good idea as well | 08:46 |
| 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 |
| tobberydberg | for example | 08:46 |
| 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:47 |
| tobberydberg | private clouds might be much more interested in covering admin api calls | 08:48 |
| tobberydberg | but yea, there are different use cases for public and private clouds in general that make sense | 08:49 |
| kopecmartin | different use cases and we may take a different approach to certify them | 08:49 |
| tobberydberg | Maybe we should plan for a separate forum session regarding the "stamps"? | 08:50 |
| tobberydberg | Like en oversight of whats there and what we lack, need to change etc | 08:52 |
| kopecmartin | sure, why not | 08:52 |
| kopecmartin | these 2 discussions relates, but are completely different disucssions (testing and certification, granting stamps) | 08:53 |
| tobberydberg | We can have that in mind .... it all ties in together, so might be to early at this point... | 08:53 |
| tobberydberg | I agree on that, and the reason I thought a session might be good | 08:54 |
| tobberydberg | Time flies ... anything else that we would like to bring up today? | 08:54 |
| 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:56 |
| tobberydberg | Awesome fkr ... will for sure help out there! | 08:57 |
| tobberydberg | Well ... thanks a lot for today and hope to chat with again in two weeks if not prior to that! :-) | 09:00 |
| diablo_rojo | Thank you! | 09:01 |
| kopecmartin | thank you | 09:01 |
| tobberydberg | #endmeeting | 09:01 |
| opendevmeet | Meeting ended Wed Jan 18 09:01:06 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-01-18-08.01.html | 09:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-01-18-08.01.txt | 09:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-01-18-08.01.log.html | 09:01 |
| fkr | thanks tobberydberg for moderating | 09:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!