08:01:25 <tobberydberg> #startmeeting publiccloud_sig
08:01:25 <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:25 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:25 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:01:28 <amorin> hello
08:01:30 <puck> Good evening
08:01:36 <gtema> tobberydberg: I brought SCS guys as promised ;-)
08:01:57 <tobberydberg> Awesome gtema :-)
08:02:10 <fkr> <- scs guy
08:02:13 <fkr> p/
08:02:27 <tobberydberg> Great to see so many people here today, even without promised reminder ;-)
08:03:22 <gtema> agenda is on https://etherpad.opendev.org/p/publiccloud-sig-meeting, right?
08:03:24 <tobberydberg> #link https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:03:26 <tobberydberg> Please put your name under participants for a start
08:03:30 <tobberydberg> Yes
08:04:18 <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:50 <tobberydberg> I tried to do that, found under "Suggestion standard properties"
08:05:20 <gtema> hehe, looks fun
08:05:30 <gtema> frequency of the CPU
08:06:10 <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:45 <gtema> it feels honestly to me now as way too much
08:07:24 <puck> Yeah, feels a bit too detailed. I'm surprised that CPU flags enabled are missing! ;)
08:07:25 <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:27 <fkr> gtema: in the sense of the flavors becoming to complicated to read?
08:07:28 <gtema> its great to have this all info, but is it really necessary? that is the point
08:08:11 <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:18 <gtema> so that scripts can find proper one
08:08:20 <puck> Having said that, we have certainly had customers who have asked those kinds of questions.
08:08:29 <tobberydberg> Exactly, so this is properties (meta data only)
08:09:00 <amorin> what is the "hypervisor" for?
08:09:09 <amorin> like kvm, xen ?
08:09:16 <NilsMagnus[m]> For me, numcores and amountram is sufficient
08:09:25 <gtema> yes, afaik it was present in the scs blueprint
08:09:36 <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:41 <fkr> gtema: this one? https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md
08:10:02 <gtema> yes
08:10:07 <amorin> ack
08:10:13 <puck> Operating system of the hypervisor might be relevant. In particular for licensing and support options.
08:10:26 * puck looks at RHEL and SUSE
08:10:46 <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:11:07 <amorin> maybe we can flags some of them mandatory and other optional?
08:11:24 <puck> I think mandatory/optional is a reasonable idea.
08:11:27 <fkr> amorin: ack. thats what scs chose.
08:11:28 <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:12:34 <amorin> ok, hypervisor is not mandatory to me, nice to have
08:12:43 <amorin> cpu, memory are mandatory
08:12:56 <amorin> nested is nice to have
08:13:11 <amorin> should we vote? how to we proceed?
08:13:33 <gtema> maybe leave a vote note for marking as mandatory?
08:14:01 <gtema> what stays with less then 3 votes (approx half of us now here) - is kept optional
08:14:19 <amorin> ok
08:16:43 <fkr> if we add the mandatory to a category, this implies all subsequent points, correct?
08:17:07 <fkr> (example: memory, as I think, all three points should be mandatory)
08:17:09 <gtema> I see lot of votes under cpu oversubscription (but not under detailed one). This requires clarification from my pov
08:17:34 <fkr> gtema: i think, this would imply all subsequent ones? see my question ;)
08:17:52 <gtema> yeah, I got it after I pressed "send"
08:18:21 <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:24 <fkr> no one else thinks if no ECC is present this does not need to be noted?
08:19:07 <gtema> Nils, we exactly try to identify this metadata required to be provided by cloud providers and not the flavor name itself
08:19:08 <puck> For CPU vendor, I think that'd commonly be a different flavour generator.
08:19:09 <amorin> agree with lack of ECC
08:19:13 <puck> s/generator/generation/
08:19:24 <tobberydberg> How we should define the details of oversubscription can be discussed...
08:20:03 <puck> ECC should be a boolean, shouldn't it?
08:20:27 <amorin> I think so
08:20:30 <tobberydberg> puck agree
08:20:37 <gtema> can somebody explain me why for me as for user of the cloud ECC should really matter?
08:21:27 <puck> I was wondering that as well. It does mean the memory corruption will be detected if ECC is enabled.
08:21:48 <puck> quota:disk_total_iops_sec <- isn't this a factor of the block device selected?
08:23:25 <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:25:10 <puck> ah, true
08:25:24 <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:31 <puck> Is ephemeral storage needed? We have that disabled...
08:25:52 <puck> I was going to ask if anyone deploying OpenStack uses non-ECC memory...
08:26:23 <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:26 <puck> I mean, should ephemeral storage be a flag.
08:26:30 <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:47 <mj_richardson> heh
08:27:32 <tobberydberg> puck my thought was that "disk" is always present, and "0" is "boot from volume"
08:28:20 <puck> I think the name should be ephemeral_disk then
08:28:39 <puck> or ephemeral_disk_size
08:30:01 <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:08 <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:24 <puck> tobberydberg, okay, ignore me on that then. ;)
08:30:31 <gtema> puck - we have "XXX_latest" images
08:30:38 <gtema> but that leads only to problems
08:31:10 <puck> heh, we use like debian-11 for the latest of that release.
08:31:31 <tobberydberg> Even though its not the same thing, but build_date would give you a hint
08:31:33 <gtema> we would have "Debian-11_latest" and "Debian-11_prev"
08:32:08 <tobberydberg> then we are into naming convention again... ;-)
08:32:10 <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:14 <amorin> we renamed them to like 'Debian 11 - deprecated' on our side
08:32:26 <amorin> and I think we provide a build_date as well
08:32:37 <amorin> but not sure this should be mandatory for a first shot
08:32:41 <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:57 <puck> build_date isn't always known, if using a published image.
08:33:19 <tobberydberg> property "latest" an option?
08:33:20 <amorin> ah, you mean build_date from upstream
08:33:46 <fkr> amorin: yes. that is what we do. if the image is not built by the CSP, it is upstream info.
08:33:55 <puck> That is how I interpret build_date
08:34:00 <amorin> our build_date is a internal build_date
08:34:09 <amorin> we use packer to build our images, even if we do nothing on it
08:34:32 <puck> ... can you do that for some images? Ubuntu don't allow that, unless you pay Canonical money.
08:34:52 <amorin> yes, we do nothing on them
08:35:46 <amorin> build_date is more like an upload date for us then
08:35:50 <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:36:46 <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:37:11 <gtema> right
08:37:31 <gtema> and oversubscription is exactly the one requiring most explanations ;-)
08:37:41 <fkr> tobberydberg: am not finished yet (am going over the image stuff)
08:37:59 <tobberydberg> for sure gtema
08:38:33 <puck> I can totally imagine that some providers wouldn't want to advertise their oversubscription ratios.
08:38:42 <fkr> hrhrhr
08:38:44 <fkr> :)
08:39:00 * puck glances sidelong at VPS providers
08:39:26 <tobberydberg> Most probably, but a thing that would be fair to the user ... exactly like what iops can you expect...
08:39:52 <puck> But, I can also understand that oversubscription can be a differentiator between different flavours. We intend on having that.
08:40:06 <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:23 <gtema> why?
08:40:24 <puck> Wanted: aliases
08:40:48 <fkr> tobberydberg: imho it is a matter of transparency to the user/customer and as such something to strive for ;)
08:40:55 <puck> There are benefits in a common base name to make multi-cloud easier for terraform etc.
08:41:49 <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:42:09 <amorin> I dont think this will be possible
08:42:25 <tobberydberg> So, naming convension but for a property "alias"?
08:42:45 <gtema> also don't think it is possible
08:43:09 <gtema> alias can be surely created, but if all data is available raw - why would you even need to look at alias?
08:43:42 <puck> Can teraform etc query the metadata?
08:43:51 <tobberydberg> I agree, it would only be useful for names if you ook at the tooling out there
08:43:53 <puck> And use that to select a flavour name?
08:44:17 <gtema> terraform can be teached to do that
08:44:48 <tobberydberg> https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/data-sources/compute_flavor_v2
08:44:49 <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:45:02 <gtema> and that is the smallest problem from my pov
08:45:17 <tobberydberg> Yes, and the base standard need to be defined prior to that
08:45:30 <gtema> correct
08:45:59 <puck> ack
08:47:56 <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:48:00 <fkr> mj_richardson, tobberydberg: for the nested vt - why should that be mandatory?
08:48:08 <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:55 <mj_richardson> fkr - some customers seem to assume that it's always enabled.  Would settle for optional however.
08:49:10 <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:28 <tobberydberg> BUT on the other hand ... that is more of a cloud generic thing right?
08:49:35 <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:46 <puck> Funnily enough the people most in favour of nested vt seem to be our staff who want to use it!
08:49:58 <mj_richardson> :-)
08:50:08 <fkr> puck: hehe
08:50:57 <puck> NilsMagnus[m], interesting. But would have have minimum specs around the required capabilities as well? Otherwise there could be some ... interesting differences.
08:51:05 <gtema> Nils Magnus: its clear what, but not clear why? What should that bring?
08:51:07 <puck> s/have/there/
08:51:24 <tobberydberg> NilsMagnus[m] I'm all for that
08:51:26 <tobberydberg> But I don't see that as very useful if filtering could take place with all tools of the meta data instead
08:53:11 <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:28 <puck> For things like nested vt, can it be defined as "assume this is false unless flagged as true"?
08:53:47 <tobberydberg> (well, that is out of scope with the discussion here except for potential in flavor root disk)
08:54:06 <amorin> for volume iops, it's possible with volume flavors
08:54:06 <fkr> puck: isn't that in general like that? eg. flavors can always over-perform but should not under perform?
08:54:37 <fkr> na, scratch that. badly  formulated. need to re-formulate.
08:54:38 <puck> We define IOPS in the block device name now. But didn't start with, so our b1.standard is "meh, whatevers"
08:55:15 <puck> block device flavour name
08:55:51 <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:56:58 <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:57:25 <puck> Sorry, the BIOS setting is often to disable vt completely.
08:57:31 <tobberydberg> So, time flies again. Should we limit the "suggestion" based on the "3 votes"?
08:57:56 <mj_richardson> +1
08:58:00 <gtema> +1
08:58:02 <fkr> +1
08:58:09 <amorin> +1
08:58:12 <puck> +1
08:58:19 <jmurezovh> +1
08:58:49 <mj_richardson> (Nested VT could lead some to believe they'll have noisy neighbours... he mutters just before time is called)
08:59:17 <puck> Images: architecture - that must be compulsory?
08:59:24 <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:38 <fkr> puck: what do you mean?
08:59:57 <tobberydberg> that is required by openstack, so covered anyhow :-)
08:59:59 <puck> An image that is built for arm won't run on amd64.
09:00:05 <puck> Right, htat's what i meant.
09:00:40 <tobberydberg> Ok, So I summarize that based on the current votes. Some details still need to be figured out, oversubscription etc etc
09:01:23 <tobberydberg> (would have needed more than one hour for this ;-) )
09:01:34 <gtema> :)
09:01:44 <tobberydberg> Anything else before we wrap up here?
09:01:45 <puck> heh
09:02:14 <puck> Just to apologise for missing the last meeting. I now have a recurring meeting in my calendar.
09:02:20 <gtema> nothing urgent what could not wait till next meeting from our side ;-)
09:03:24 <tobberydberg> :-)
09:03:26 <tobberydberg> Awesome! Thanks for today and look forward to chat more in two weeks :-)
09:03:42 <gtema> thanks everybody
09:03:54 <puck> Cheers everyone, hope y'all have a great rest of your day.
09:04:02 <amorin> thanks
09:04:18 <FelixKronlage-Dammers[m]> this is every two weeks, correct?
09:04:23 <gtema> yes
09:04:30 <mj_richardson> Ciao!
09:04:46 <tobberydberg> Thanks and the same to you
09:04:49 <tobberydberg> Bye
09:04:53 <tobberydberg> #endmeeting