| gtema | Hey everybody | 08:00 |
|---|---|---|
| tobberydberg | Morning :-) | 08:00 |
| fkr | good morning | 08:00 |
| NilsMagnus[m] | hi | 08:00 |
| tobberydberg | #startmeeting publiccloud_sig | 08:01 |
| opendevmeet | Meeting started Wed Sep 28 08:01:25 2022 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 |
| amorin | hello | 08:01 |
| puck | Good evening | 08:01 |
| gtema | tobberydberg: I brought SCS guys as promised ;-) | 08:01 |
| tobberydberg | Awesome gtema :-) | 08:01 |
| fkr | <- scs guy | 08:02 |
| fkr | p/ | 08:02 |
| tobberydberg | Great to see so many people here today, even without promised reminder ;-) | 08:02 |
| gtema | agenda is on https://etherpad.opendev.org/p/publiccloud-sig-meeting, right? | 08:03 |
| tobberydberg | #link https://etherpad.opendev.org/p/publiccloud-sig-meeting | 08:03 |
| tobberydberg | Please put your name under participants for a start | 08:03 |
| tobberydberg | Yes | 08:03 |
| tobberydberg | As decided last week, we should put together a "proposal" of attributes "to start with", so that we have something to start working with | 08:04 |
| tobberydberg | I tried to do that, found under "Suggestion standard properties" | 08:04 |
| gtema | hehe, looks fun | 08:05 |
| gtema | frequency of the CPU | 08:05 |
| tobberydberg | So, first item on the agenda is to review that one ... and we can deduct or add things as well of course | 08:06 |
| gtema | it feels honestly to me now as way too much | 08:06 |
| puck | Yeah, feels a bit too detailed. I'm surprised that CPU flags enabled are missing! ;) | 08:07 |
| tobberydberg | Exactly gtema, I thought about that one when I added it ... not sure that will be feasible for many clouds to present, will most likely differ between computes....especially for smaller clouds | 08:07 |
| fkr | gtema: in the sense of the flavors becoming to complicated to read? | 08:07 |
| gtema | its great to have this all info, but is it really necessary? that is the point | 08:07 |
| gtema | fkr - that is why we said we do not even want to try to put this all info into the flavor name, but ensure it is available as flavor properties | 08:08 |
| gtema | so that scripts can find proper one | 08:08 |
| puck | Having said that, we have certainly had customers who have asked those kinds of questions. | 08:08 |
| tobberydberg | Exactly, so this is properties (meta data only) | 08:08 |
| amorin | what is the "hypervisor" for? | 08:09 |
| amorin | like kvm, xen ? | 08:09 |
| NilsMagnus[m] | For me, numcores and amountram is sufficient | 08:09 |
| gtema | yes, afaik it was present in the scs blueprint | 08:09 |
| tobberydberg | So, a suggestion form my side. Lets go over them one by one, scratch them if they are not "needed", put example values etc. | 08:09 |
| fkr | gtema: this one? https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md | 08:09 |
| gtema | yes | 08:10 |
| amorin | ack | 08:10 |
| puck | Operating system of the hypervisor might be relevant. In particular for licensing and support options. | 08:10 |
| * puck looks at RHEL and SUSE | 08:10 | |
| NilsMagnus[m] | there will always be situations where you need to have more information, but if it comes to migrate a service from public cloud vendor A to B that should be the absolute minimum | 08:10 |
| amorin | maybe we can flags some of them mandatory and other optional? | 08:11 |
| puck | I think mandatory/optional is a reasonable idea. | 08:11 |
| fkr | amorin: ack. thats what scs chose. | 08:11 |
| tobberydberg | For sure. We could also mark items with a * for required and leave others as optional if we feel that is a good way | 08:11 |
| amorin | ok, hypervisor is not mandatory to me, nice to have | 08:12 |
| amorin | cpu, memory are mandatory | 08:12 |
| amorin | nested is nice to have | 08:12 |
| amorin | should we vote? how to we proceed? | 08:13 |
| gtema | maybe leave a vote note for marking as mandatory? | 08:13 |
| gtema | what stays with less then 3 votes (approx half of us now here) - is kept optional | 08:14 |
| amorin | ok | 08:14 |
| fkr | if we add the mandatory to a category, this implies all subsequent points, correct? | 08:16 |
| fkr | (example: memory, as I think, all three points should be mandatory) | 08:17 |
| gtema | I see lot of votes under cpu oversubscription (but not under detailed one). This requires clarification from my pov | 08:17 |
| fkr | gtema: i think, this would imply all subsequent ones? see my question ;) | 08:17 |
| gtema | yeah, I got it after I pressed "send" | 08:17 |
| NilsMagnus[m] | I still have one question stepping one step back: We can pretty much extract matching flavors by facilitating the API/SDK. Why are we now establising a second, potentially conflicting way by naming conventions? It is relatively easy to implement something like... (full message at <https://matrix.org/_matrix/media/r0/download/matrix.org/gzozLvsDJOZuRaFttgBPiMkx>) | 08:18 |
| fkr | no one else thinks if no ECC is present this does not need to be noted? | 08:18 |
| gtema | Nils, we exactly try to identify this metadata required to be provided by cloud providers and not the flavor name itself | 08:19 |
| puck | For CPU vendor, I think that'd commonly be a different flavour generator. | 08:19 |
| amorin | agree with lack of ECC | 08:19 |
| puck | s/generator/generation/ | 08:19 |
| tobberydberg | How we should define the details of oversubscription can be discussed... | 08:19 |
| puck | ECC should be a boolean, shouldn't it? | 08:20 |
| amorin | I think so | 08:20 |
| tobberydberg | puck agree | 08:20 |
| gtema | can somebody explain me why for me as for user of the cloud ECC should really matter? | 08:20 |
| puck | I was wondering that as well. It does mean the memory corruption will be detected if ECC is enabled. | 08:21 |
| puck | quota:disk_total_iops_sec <- isn't this a factor of the block device selected? | 08:21 |
| tobberydberg | Yes, but if you have ephemeral storage in your flavor it is harder to present to the user ... or maybe I'm mistaken here... | 08:23 |
| puck | ah, true | 08:25 |
| fkr | gtema: to be honest - this answer is not really technical - but in scs we concluded that: "as a user I expect a Cloud Provider to use hardware that has ECC and it should be noted if this is not the case". | 08:25 |
| puck | Is ephemeral storage needed? We have that disabled... | 08:25 |
| puck | I was going to ask if anyone deploying OpenStack uses non-ECC memory... | 08:25 |
| fkr | gtema: i'm thinking right now what actually happends to a vm, if the host detects memory corruption in the memory allocated | 08:26 |
| puck | I mean, should ephemeral storage be a flag. | 08:26 |
| tobberydberg | We currently have ephemeral storage for a lot of flavors, even though we are making a transition from that... An old mistake to have that... | 08:26 |
| mj_richardson | heh | 08:26 |
| tobberydberg | puck my thought was that "disk" is always present, and "0" is "boot from volume" | 08:27 |
| puck | I think the name should be ephemeral_disk then | 08:28 |
| puck | or ephemeral_disk_size | 08:28 |
| puck | Any thoughts on how to flag an image as "old"? We rename images to have the original date in the image name. | 08:30 |
| tobberydberg | by standard you have "disk" and "ephemeral", that defaults to "0" if I remember correctly ... so do you really think we need to add another property? | 08:30 |
| puck | tobberydberg, okay, ignore me on that then. ;) | 08:30 |
| gtema | puck - we have "XXX_latest" images | 08:30 |
| gtema | but that leads only to problems | 08:30 |
| puck | heh, we use like debian-11 for the latest of that release. | 08:31 |
| tobberydberg | Even though its not the same thing, but build_date would give you a hint | 08:31 |
| gtema | we would have "Debian-11_latest" and "Debian-11_prev" | 08:31 |
| tobberydberg | then we are into naming convention again... ;-) | 08:32 |
| gtema | real problem (for most of the tools) is when you have few images with same name and need to analyse build_date prop | 08:32 |
| amorin | we renamed them to like 'Debian 11 - deprecated' on our side | 08:32 |
| amorin | and I think we provide a build_date as well | 08:32 |
| amorin | but not sure this should be mandatory for a first shot | 08:32 |
| puck | tobberydberg, yeah, I was looking at build_date and that's why I was thinking. We use the upload date on the old images. | 08:32 |
| puck | build_date isn't always known, if using a published image. | 08:32 |
| tobberydberg | property "latest" an option? | 08:33 |
| amorin | ah, you mean build_date from upstream | 08:33 |
| fkr | amorin: yes. that is what we do. if the image is not built by the CSP, it is upstream info. | 08:33 |
| puck | That is how I interpret build_date | 08:33 |
| amorin | our build_date is a internal build_date | 08:34 |
| amorin | we use packer to build our images, even if we do nothing on it | 08:34 |
| puck | ... can you do that for some images? Ubuntu don't allow that, unless you pay Canonical money. | 08:34 |
| amorin | yes, we do nothing on them | 08:34 |
| amorin | build_date is more like an upload date for us then | 08:35 |
| fkr | as a reference, here is the stuff we came up with: https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/Image-Properties-Spec.md - the idea being that with the openstack image manager (that OSISM works on) there is the tooling that assists with managing the images within the OS cloud. | 08:35 |
| tobberydberg | So, looking at the current voting ... it is actually not 3 votes on a lot of things that not already is required by default in openstack ... for flavors ... I guess oversubscription is the only "new" | 08:36 |
| gtema | right | 08:37 |
| gtema | and oversubscription is exactly the one requiring most explanations ;-) | 08:37 |
| fkr | tobberydberg: am not finished yet (am going over the image stuff) | 08:37 |
| tobberydberg | for sure gtema | 08:37 |
| puck | I can totally imagine that some providers wouldn't want to advertise their oversubscription ratios. | 08:38 |
| fkr | hrhrhr | 08:38 |
| fkr | :) | 08:38 |
| * puck glances sidelong at VPS providers | 08:39 | |
| tobberydberg | Most probably, but a thing that would be fair to the user ... exactly like what iops can you expect... | 08:39 |
| puck | But, I can also understand that oversubscription can be a differentiator between different flavours. We intend on having that. | 08:39 |
| NilsMagnus[m] | I have one additional question: Does it make sense to require at least one flavour with a fixed name which defines a minimum set of properties? | 08:40 |
| gtema | why? | 08:40 |
| puck | Wanted: aliases | 08:40 |
| fkr | tobberydberg: imho it is a matter of transparency to the user/customer and as such something to strive for ;) | 08:40 |
| puck | There are benefits in a common base name to make multi-cloud easier for terraform etc. | 08:40 |
| NilsMagnus[m] | I don't care about the details but just want a, say, very small VM - that would be really useful I think. | 08:41 |
| amorin | I dont think this will be possible | 08:42 |
| tobberydberg | So, naming convension but for a property "alias"? | 08:42 |
| gtema | also don't think it is possible | 08:42 |
| gtema | alias can be surely created, but if all data is available raw - why would you even need to look at alias? | 08:43 |
| puck | Can teraform etc query the metadata? | 08:43 |
| tobberydberg | I agree, it would only be useful for names if you ook at the tooling out there | 08:43 |
| puck | And use that to select a flavour name? | 08:43 |
| gtema | terraform can be teached to do that | 08:44 |
| tobberydberg | https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/data-sources/compute_flavor_v2 | 08:44 |
| gtema | and the whole initiative is only making sense if we also work on ensuring tools that customers are using are capable in consuming this | 08:44 |
| gtema | and that is the smallest problem from my pov | 08:45 |
| tobberydberg | Yes, and the base standard need to be defined prior to that | 08:45 |
| gtema | correct | 08:45 |
| puck | ack | 08:45 |
| tobberydberg | The votes on images gives us much more required attributes that are not required by default, which is good, because that brings new valuables :-) | 08:47 |
| fkr | mj_richardson, tobberydberg: for the nested vt - why should that be mandatory? | 08:48 |
| mj_richardson | Can easily imagine that aliases would be useful for Clouds wishing to change tack for some reason, and users who don't wish to look at the raw data. | 08:48 |
| mj_richardson | fkr - some customers seem to assume that it's always enabled. Would settle for optional however. | 08:48 |
| tobberydberg | fkr My thoughts was a flag on/off if it is enabled or not, so that users in need of that can see that | 08:49 |
| tobberydberg | BUT on the other hand ... that is more of a cloud generic thing right? | 08:49 |
| NilsMagnus[m] | I am not sure if I explained my proposal in an understandable way: I just proposed to have at least three flavor names as "default-s, m, and l". Then it's up to the service providers to pick the specific configuration but they have to make sure that those flavour names exist. | 08:49 |
| puck | Funnily enough the people most in favour of nested vt seem to be our staff who want to use it! | 08:49 |
| mj_richardson | :-) | 08:49 |
| fkr | puck: hehe | 08:50 |
| puck | NilsMagnus[m], interesting. But would have have minimum specs around the required capabilities as well? Otherwise there could be some ... interesting differences. | 08:50 |
| gtema | Nils Magnus: its clear what, but not clear why? What should that bring? | 08:51 |
| puck | s/have/there/ | 08:51 |
| tobberydberg | NilsMagnus[m] I'm all for that | 08:51 |
| tobberydberg | But I don't see that as very useful if filtering could take place with all tools of the meta data instead | 08:51 |
| tobberydberg | One thing that I would really like to see as a user is what "iops" and such things I can expect, is that even possible today for volumes? | 08:53 |
| puck | For things like nested vt, can it be defined as "assume this is false unless flagged as true"? | 08:53 |
| tobberydberg | (well, that is out of scope with the discussion here except for potential in flavor root disk) | 08:53 |
| amorin | for volume iops, it's possible with volume flavors | 08:54 |
| fkr | puck: isn't that in general like that? eg. flavors can always over-perform but should not under perform? | 08:54 |
| fkr | na, scratch that. badly formulated. need to re-formulate. | 08:54 |
| puck | We define IOPS in the block device name now. But didn't start with, so our b1.standard is "meh, whatevers" | 08:54 |
| puck | block device flavour name | 08:55 |
| fkr | puck: what I meant: if nested vt is not noted, it could be on, but is not promised to be on. if it is noted to be there, it must be on. that is what I meant. am wondering, wether if people would actually want to make sure they have an instance where this is deliberatly turned off - then this of course does not work. | 08:55 |
| puck | As a user, I don't think I'd ever want to make sure that nested vt is not available. Although I guess that is often a BIOS setting, so there must be use cases where people want it off? | 08:56 |
| puck | Sorry, the BIOS setting is often to disable vt completely. | 08:57 |
| tobberydberg | So, time flies again. Should we limit the "suggestion" based on the "3 votes"? | 08:57 |
| mj_richardson | +1 | 08:57 |
| gtema | +1 | 08:58 |
| fkr | +1 | 08:58 |
| amorin | +1 | 08:58 |
| puck | +1 | 08:58 |
| jmurezovh | +1 | 08:58 |
| mj_richardson | (Nested VT could lead some to believe they'll have noisy neighbours... he mutters just before time is called) | 08:58 |
| puck | Images: architecture - that must be compulsory? | 08:59 |
| tobberydberg | I would have liked to have a vote on "recommended_votes" ... to have a list of required and recommended ... not sure what you think about that? Or should we just skip that? | 08:59 |
| fkr | puck: what do you mean? | 08:59 |
| tobberydberg | that is required by openstack, so covered anyhow :-) | 08:59 |
| puck | An image that is built for arm won't run on amd64. | 08:59 |
| puck | Right, htat's what i meant. | 09:00 |
| tobberydberg | Ok, So I summarize that based on the current votes. Some details still need to be figured out, oversubscription etc etc | 09:00 |
| tobberydberg | (would have needed more than one hour for this ;-) ) | 09:01 |
| gtema | :) | 09:01 |
| tobberydberg | Anything else before we wrap up here? | 09:01 |
| puck | heh | 09:01 |
| puck | Just to apologise for missing the last meeting. I now have a recurring meeting in my calendar. | 09:02 |
| gtema | nothing urgent what could not wait till next meeting from our side ;-) | 09:02 |
| tobberydberg | :-) | 09:03 |
| tobberydberg | Awesome! Thanks for today and look forward to chat more in two weeks :-) | 09:03 |
| gtema | thanks everybody | 09:03 |
| puck | Cheers everyone, hope y'all have a great rest of your day. | 09:03 |
| amorin | thanks | 09:04 |
| FelixKronlage-Dammers[m] | this is every two weeks, correct? | 09:04 |
| gtema | yes | 09:04 |
| mj_richardson | Ciao! | 09:04 |
| tobberydberg | Thanks and the same to you | 09:04 |
| tobberydberg | Bye | 09:04 |
| tobberydberg | #endmeeting | 09:04 |
| opendevmeet | Meeting ended Wed Sep 28 09:04:53 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-09-28-08.01.html | 09:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-09-28-08.01.txt | 09:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-09-28-08.01.log.html | 09:04 |
| *** spotz__ is now known as spotz | 14:04 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!