08:04:06 <tobberydberg> #startmeeting publiccloud_sig
08:04:06 <opendevmeet> Meeting started Wed Nov 29 08:04:06 2023 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:04:06 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:04:06 <gtema> arctic outbreak :-(
08:04:28 <joek_office> here now snow there. Very unhappy
08:05:00 <fkr> gtema: you were busy in the hedgedoc ;)
08:05:01 <gtema> I am driving to bring my daughter to school (16km) and there is no snow either
08:05:06 <joek_office> also ahve -4 deg in night and now plus 1.5
08:05:16 <gtema> fkr - nom I guess joek_office was that
08:05:32 <fkr> cool! yeah joek_office!
08:05:44 <tobberydberg> So, we have not prepared an agenda for this meeting ... sorry for that...
08:05:46 <joek_office> yes. think i have opened the hedgedoc in a tab
08:05:47 <fkr> so, joek_office, gtema and me tried to work a bit on our favourite subject ;)
08:06:00 <fkr> (segway'ing away from the weather)
08:06:14 <puck> :)
08:06:20 <tobberydberg> So I guess, the floor is open to suggest agenda bullets... ;-)
08:06:32 <fkr> - Discoverability of flavors - and basically offerings of a iaas
08:06:44 <fkr> And doing so we started working on userstories
08:06:49 <fkr> https://input.scs.community/ZfP4d2kNTbagN9-Jk2ccEQ
08:07:11 <tobberydberg> Ah, nice!
08:07:54 <gtema> we were thinking that simply defining the properties is not sufficient
08:08:32 <gtema> or is actually not very helpful, because what in reality we need to know is under which conditions and for what exactly one or another thing is required
08:08:32 <puck> Looks good to me
08:08:36 <joek_office> i have after the meeting a bit of time invested to brainstorm, what functionality and user storys can be out there for such a discovery service
08:09:13 <gtema> once we know that (trying to represent it as a user story) we could be able to figure out how exactly it is possible to solve the usecase (whether there is solution out of box or we need to build something)
08:10:19 <gtema> in that regard please feel free to add userstories from your side
08:12:13 <gtema> once we have userstories we should be able to describe user view and operator view on that story
08:12:24 <fkr> +1
08:12:25 <gtema> this way we should be able to really compare different views
08:13:45 <tobberydberg> This is a really good start I think +1
08:14:04 <gtema> links to the SCS spec wrt naming are currently given as a reference only (to know which specifics were already defined)
08:14:22 <gtema> this is not a must, just a helping info, so feel free to ignore it
08:14:54 <fkr> that is actually an important point gtema
08:15:23 <gtema> I know, I just want that people do not feel uncomfortable adding points if there is no link to scs spec
08:15:23 <fkr> what is quoted there from the scs spec is to give context from the scs scope and not 'to push scs agenda'
08:15:30 <fkr> :)
08:15:43 <joek_office> are there any thoughts about 'operator' user stories, i think on this side we are at the moment rare
08:16:00 <fkr> that is indeed open
08:16:34 <gtema> agree. This is, however,  not really in scope of the "interoperability" itself
08:16:55 <fkr> I was about to ask, wether we could loop one of the guys from cleura, form the team that operates the cloud, in
08:17:02 <joek_office> in our meeting, we discussed several parts and then we see, that many of the discussion goes on topics that was described in the scs document. So we linked this
08:17:06 <gtema> and that is why I think it is important to describe userstories so that we all clearly understand what we all talk about and in which context
08:17:24 <fkr> +1 again
08:17:47 <fkr> for me, I'd simply would like to understand "how the ops peeps play tetris" and what they use to do it
08:17:49 <gtema> damn latency, I prefer voice meetings
08:18:09 <joek_office> +1 voice meetings
08:18:40 <tobberydberg> Next time, next time... ;-)
08:18:45 <gtema> lol
08:19:41 <tobberydberg> But I think you cover most use cases here, I can't come up with any new with my initial thinking here....
08:19:42 <gtema> the snow is back at my place, started snowing quite strong
08:19:55 <tobberydberg> Lucky you ;-)
08:20:17 <gtema> tobberydberg - then feel free to start adding a bit more context under the stories
08:20:33 <gtema> i.e. I am a bit struggling to invent anything wrt CPU architecture
08:20:50 <gtema> this is the one which disturbs me at most due to its complexity
08:21:07 <gtema> well, not the only one - licensed images is another thing
08:21:30 <gtema> i.e. "why for me as a user it is important to have licensed image" and what in reallity this means
08:21:45 <tobberydberg> "* As a user of IaaS, I want to provision a VM with ARM CPU" - that exemplifies that, right?
08:21:47 <puck> images with multiple different licensed things - operating system and software (i.e. MS SQL Server). There's a matrix...
08:21:48 <gtema> a) user wants to bring his license into the enterprise distron
08:21:50 <joek_office> but at the moment we only think about use cases. Not how we solve the problems
08:22:03 <gtema> b) user wants to get some already licensed image without paying
08:22:25 <gtema> puck - that is the point, I want that we describe those things
08:22:37 <gtema> because otherwise we will struggle to find proper solution
08:23:13 <puck> Multiple fields/values in the search.
08:23:26 <gtema> joek_office - you in example brought infiniband. I do not really know why this should/could matter for the user
08:23:28 <fkr> tobberydberg: as a user of IaaS, I want to deploy my arm workload  onto the iaas
08:23:29 <joek_office> gtema: have copied your suggestion about licenses
08:23:49 <fkr> for the user matters network that provides speed at factor X
08:23:53 <fkr> regardless of medium
08:23:54 <puck> HPC workloads may well care about the networking.
08:24:03 <fkr> they care about the speed and latency
08:24:05 <fkr> not medium
08:24:06 <fkr> do they?
08:24:30 <gtema> yeah, clear, but how that refer to hypervisor/image. Or are we down to any specifics?
08:24:31 <tobberydberg> Hmmm...."is_licensed" was for me meant to be just an indicator that "extra costs will apply"....
08:25:36 <gtema> tobberydberg: extra cost is also reason. But is is_licensed image possible to boot without providing license info or do I need to byol
08:26:03 <joek_office> fkr: yes, thats right. but it is a technical thing. Infiniband is designed to give better latency. Also it could be interesting for things like bandwith in a scenario where i have to copy large amount of data and want to know that network is fast enough
08:26:36 <tobberydberg> gtema ... bring your own license is for me "private image land"
08:26:41 <gtema> guys, again: are we discussing every specific or we focus on hypervisor/image only?
08:26:53 <gtema> bringing networking is dangerous
08:27:09 <gtema> and in that case immediately volume types and stuff like that also lands
08:27:21 <puck> Re is_licensed... Hmm, I can't find a suitable example right now, but we have a rating API - should allow finding out the price for different resources.
08:29:24 <gtema> puck - so for you it means: user can boot such image but would need to pay extra on his bill. Right?
08:29:29 <joek_office> what i said in the meeting: we speak here over openstack in very different use cases. And what the ISP is coding in his flavor naming is up to him/her. so there could be use cases where the cpu /ram is unimportant and other topics network/Storage are the important things. So i think the important thing for us is the following. The search engine should be accept diverge search criteria, probably extendable over time
08:29:43 <puck> gtema, yes
08:29:54 <gtema> puck: got it
08:30:10 <puck> joek_office, yes, and return the matching resource names for the resource type being requested
08:30:27 <gtema> joek_office: as already hinted to you - you try to bring possible solution while we have not defined the question properly
08:31:25 <joek_office> gtema: sorry, think you have to direct me every time. But you are right.
08:34:18 <joek_office> gtema: the use case with the image and license i think can go to the iaas operator later in document
08:34:39 <puck> So in general, we need to have the relevant tags added to the resources that use an agreed taxonmy (as discussed earlier in the year), but the resource names are whatever cloud providers want to use.
08:35:37 <gtema> puck: I guess the problem is that we have defined those tags, but now we know that some of them were defined in the wrong category.
08:35:37 <puck> It seems the search criteria can be whatever, but the search tool should probably return an "unknown field" or such if the field isn't supported by the cloud provider.
08:35:57 <puck> Has anyone implemented those tags yet?
08:36:18 <gtema> and then we do not know what is the real purpose of the property: a information or something user should be really able to filter upon to find what he wants to provision
08:36:36 <puck> Or a hint to Nova/Neutron/etc
08:36:45 <gtema> I really want we DO NOT DISCUSS search now
08:37:00 <puck> Ack, the user stories sound reasonable to me.
08:37:01 <gtema> because some of the props are already there and filterable, some not
08:37:13 <gtema> and we need to figure out the general approach
08:38:41 <puck> Okay, so further discussion here?
08:41:30 <gtema> I tried to "restruct" first 2 stories to try to represent user/operator view
08:41:37 <gtema> what do you think of this approach?
08:41:54 <tobberydberg> +1
08:42:25 <fkr> +1
08:42:29 <joek_office> +1
08:42:44 <gtema> great, thanks
08:42:53 <puck> +1 with slight adjustment of "and optionally round up to nearest available option"
08:43:21 <gtema> ?? don't get that
08:43:22 <joek_office> whats with the operator user storys downside the dosument. can we copy them up? Think there are no user perspective, but think are important things
08:43:43 <fkr> gtema: on second thought, I think it misses the why
08:43:47 <fkr> I tried to add it
08:44:18 <fkr> "define flavor with cpu/ram properties being set" vs. "define flavor with cpu/ram properties being set in order to be able to utilize my hardware properly"
08:44:21 <puck> We might not have 4 CPU, 8 GB, we might have 4 CPU, 16 GB.  (We do have 4/8, but for burst or GPU we don't have that small)
08:44:48 <puck> (burst is more complicated, ignore that mention)
08:44:58 <gtema> puck - totally makes sense. If operator is ready to give more resources then requested - shoot it here
08:46:43 <gtema> that is actually (optimization of usage by operator) is the thing where we understood during PTG Nova hour that things are much more complex then just defining properties
08:47:13 <puck> GPU has different options based on the license applied (can you do compute only, virtual desktop only, etc) hardware provider, slice size and number of slices.
08:47:26 <gtema> user requesting 4 cpu will not necessarily get 4 cpus, and as such charging him for flavor but in reality provisioning different resources is a tricky thing
08:47:57 <puck> Oh, it should return the resource name for the next nearest thing, and charge for that resource type.
08:48:19 <puck> But if searching in N dimensions, tricky to get the smallest match.
08:48:58 <gtema> correct. Therefore charging by flavor name is maybe not what people really want to
08:49:36 <puck> OpenStack has no other approach at this stage, unless I'm missing a product offering. GCP I think you can dial up/down the CPU/RAM count and get charged accordingly.
08:50:52 <puck> We have choosen the flavour sizings to be appropriate rations for CPU to RAM. Otherwise you end up with really unbalanced hypervisors.
08:50:54 <gtema> right. I do not want to start discussion over charging, I just wanted to make attention on the fact that what we discuss influence charging in unpredictable way
08:51:11 <puck> s/rations/ratios/
08:52:53 <gtema> ok, time is ticking
08:53:09 <gtema> I suggest all of us think and try to add further details into the doc
08:53:16 <fkr> +1
08:53:17 <gtema> and next time we can discuss next steps
08:53:34 <gtema> so what about next time, voice?
08:53:44 <fkr> yes, that would be the deal
08:53:44 <tobberydberg> +1
08:53:51 <fkr> what I wondered:
08:53:57 <fkr> we're in #openstack-operators
08:54:21 <fkr> does it make sense to have the discussion properly async going to have it in #openstack-publiccloud ?
08:54:31 <fkr> or we just keep the discussion here
08:54:36 <fkr> since its low traffic here anyways
08:54:51 <gtema> I would stay here
08:55:23 <tobberydberg> yea, lets stay here,,,
08:56:59 <puck> Downside is there are a lot of people idling in here (this is the fullest openstack IRC channel!).
08:57:20 <puck> But I'm not too worried about that.
08:57:26 <fkr> well, as long as noone complains :)
08:57:34 <fkr> and mostly I only see parts/joins here anyways
08:57:36 <puck> I don't think I've ever seen any other chatter in here other than us.
08:57:50 <fkr> so its good if the channel sees some real traffic (aside from largescale sig of course)
08:57:56 <fkr> puck: largescale-sig
08:58:11 <fkr> that was a nice meeting today :)
08:58:15 <fkr> thanks everyone
08:58:26 <puck> Cheers folks, and thank you again for swapping the week.
08:58:52 <gtema> thanks. Have a nice day/evening
08:59:02 <tobberydberg> Yea, thanks for today! Have a great day!
08:59:05 <joek_office> nice to "meet" you today. Have a nice week all of you
08:59:10 <tobberydberg> #endmeeting