08:04:06 #startmeeting publiccloud_sig 08:04:06 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:04:06 The meeting name has been set to 'publiccloud_sig' 08:04:06 arctic outbreak :-( 08:04:28 here now snow there. Very unhappy 08:05:00 gtema: you were busy in the hedgedoc ;) 08:05:01 I am driving to bring my daughter to school (16km) and there is no snow either 08:05:06 also ahve -4 deg in night and now plus 1.5 08:05:16 fkr - nom I guess joek_office was that 08:05:32 cool! yeah joek_office! 08:05:44 So, we have not prepared an agenda for this meeting ... sorry for that... 08:05:46 yes. think i have opened the hedgedoc in a tab 08:05:47 so, joek_office, gtema and me tried to work a bit on our favourite subject ;) 08:06:00 (segway'ing away from the weather) 08:06:14 :) 08:06:20 So I guess, the floor is open to suggest agenda bullets... ;-) 08:06:32 - Discoverability of flavors - and basically offerings of a iaas 08:06:44 And doing so we started working on userstories 08:06:49 https://input.scs.community/ZfP4d2kNTbagN9-Jk2ccEQ 08:07:11 Ah, nice! 08:07:54 we were thinking that simply defining the properties is not sufficient 08:08:32 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 Looks good to me 08:08:36 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 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 in that regard please feel free to add userstories from your side 08:12:13 once we have userstories we should be able to describe user view and operator view on that story 08:12:24 +1 08:12:25 this way we should be able to really compare different views 08:13:45 This is a really good start I think +1 08:14:04 links to the SCS spec wrt naming are currently given as a reference only (to know which specifics were already defined) 08:14:22 this is not a must, just a helping info, so feel free to ignore it 08:14:54 that is actually an important point gtema 08:15:23 I know, I just want that people do not feel uncomfortable adding points if there is no link to scs spec 08:15:23 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 :) 08:15:43 are there any thoughts about 'operator' user stories, i think on this side we are at the moment rare 08:16:00 that is indeed open 08:16:34 agree. This is, however, not really in scope of the "interoperability" itself 08:16:55 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 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 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 +1 again 08:17:47 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 damn latency, I prefer voice meetings 08:18:09 +1 voice meetings 08:18:40 Next time, next time... ;-) 08:18:45 lol 08:19:41 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 the snow is back at my place, started snowing quite strong 08:19:55 Lucky you ;-) 08:20:17 tobberydberg - then feel free to start adding a bit more context under the stories 08:20:33 i.e. I am a bit struggling to invent anything wrt CPU architecture 08:20:50 this is the one which disturbs me at most due to its complexity 08:21:07 well, not the only one - licensed images is another thing 08:21:30 i.e. "why for me as a user it is important to have licensed image" and what in reallity this means 08:21:45 "* As a user of IaaS, I want to provision a VM with ARM CPU" - that exemplifies that, right? 08:21:47 images with multiple different licensed things - operating system and software (i.e. MS SQL Server). There's a matrix... 08:21:48 a) user wants to bring his license into the enterprise distron 08:21:50 but at the moment we only think about use cases. Not how we solve the problems 08:22:03 b) user wants to get some already licensed image without paying 08:22:25 puck - that is the point, I want that we describe those things 08:22:37 because otherwise we will struggle to find proper solution 08:23:13 Multiple fields/values in the search. 08:23:26 joek_office - you in example brought infiniband. I do not really know why this should/could matter for the user 08:23:28 tobberydberg: as a user of IaaS, I want to deploy my arm workload onto the iaas 08:23:29 gtema: have copied your suggestion about licenses 08:23:49 for the user matters network that provides speed at factor X 08:23:53 regardless of medium 08:23:54 HPC workloads may well care about the networking. 08:24:03 they care about the speed and latency 08:24:05 not medium 08:24:06 do they? 08:24:30 yeah, clear, but how that refer to hypervisor/image. Or are we down to any specifics? 08:24:31 Hmmm...."is_licensed" was for me meant to be just an indicator that "extra costs will apply".... 08:25:36 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 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 gtema ... bring your own license is for me "private image land" 08:26:41 guys, again: are we discussing every specific or we focus on hypervisor/image only? 08:26:53 bringing networking is dangerous 08:27:09 and in that case immediately volume types and stuff like that also lands 08:27:21 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 puck - so for you it means: user can boot such image but would need to pay extra on his bill. Right? 08:29:29 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 gtema, yes 08:29:54 puck: got it 08:30:10 joek_office, yes, and return the matching resource names for the resource type being requested 08:30:27 joek_office: as already hinted to you - you try to bring possible solution while we have not defined the question properly 08:31:25 gtema: sorry, think you have to direct me every time. But you are right. 08:34:18 gtema: the use case with the image and license i think can go to the iaas operator later in document 08:34:39 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 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 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 Has anyone implemented those tags yet? 08:36:18 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 Or a hint to Nova/Neutron/etc 08:36:45 I really want we DO NOT DISCUSS search now 08:37:00 Ack, the user stories sound reasonable to me. 08:37:01 because some of the props are already there and filterable, some not 08:37:13 and we need to figure out the general approach 08:38:41 Okay, so further discussion here? 08:41:30 I tried to "restruct" first 2 stories to try to represent user/operator view 08:41:37 what do you think of this approach? 08:41:54 +1 08:42:25 +1 08:42:29 +1 08:42:44 great, thanks 08:42:53 +1 with slight adjustment of "and optionally round up to nearest available option" 08:43:21 ?? don't get that 08:43:22 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 gtema: on second thought, I think it misses the why 08:43:47 I tried to add it 08:44:18 "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 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 (burst is more complicated, ignore that mention) 08:44:58 puck - totally makes sense. If operator is ready to give more resources then requested - shoot it here 08:46:43 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 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 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 Oh, it should return the resource name for the next nearest thing, and charge for that resource type. 08:48:19 But if searching in N dimensions, tricky to get the smallest match. 08:48:58 correct. Therefore charging by flavor name is maybe not what people really want to 08:49:36 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 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 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 s/rations/ratios/ 08:52:53 ok, time is ticking 08:53:09 I suggest all of us think and try to add further details into the doc 08:53:16 +1 08:53:17 and next time we can discuss next steps 08:53:34 so what about next time, voice? 08:53:44 yes, that would be the deal 08:53:44 +1 08:53:51 what I wondered: 08:53:57 we're in #openstack-operators 08:54:21 does it make sense to have the discussion properly async going to have it in #openstack-publiccloud ? 08:54:31 or we just keep the discussion here 08:54:36 since its low traffic here anyways 08:54:51 I would stay here 08:55:23 yea, lets stay here,,, 08:56:59 Downside is there are a lot of people idling in here (this is the fullest openstack IRC channel!). 08:57:20 But I'm not too worried about that. 08:57:26 well, as long as noone complains :) 08:57:34 and mostly I only see parts/joins here anyways 08:57:36 I don't think I've ever seen any other chatter in here other than us. 08:57:50 so its good if the channel sees some real traffic (aside from largescale sig of course) 08:57:56 puck: largescale-sig 08:58:11 that was a nice meeting today :) 08:58:15 thanks everyone 08:58:26 Cheers folks, and thank you again for swapping the week. 08:58:52 thanks. Have a nice day/evening 08:59:02 Yea, thanks for today! Have a great day! 08:59:05 nice to "meet" you today. Have a nice week all of you 08:59:10 #endmeeting