| *** mmalchuk_ is now known as mmalchuk | 03:44 | |
| FelixKronlage-Dammers[m] | am running a tad late, going to be 9:05 for me | 07:43 |
|---|---|---|
| puck | ack | 07:45 |
| gtema | morning/evening out there | 08:00 |
| fkr | good morming | 08:01 |
| fkr | almost made it :) | 08:01 |
| gtema | squeezed through snow? | 08:01 |
| puck | o/ | 08:01 |
| tobberydberg | Good morning! :-) | 08:01 |
| gtema | I am freezing here | 08:02 |
| fkr | gtema: well, actually when I went to bed ad 0:30 it was all white outside. now it is +1C and it melted | 08:02 |
| tobberydberg | Well, some small portion of snow here :-) | 08:02 |
| tobberydberg | -5C here :-) | 08:03 |
| joek_office | Good mornig | 08:03 |
| puck | Heh, it doesn't normally snow where I live. It has snowed twice in my lifetime. | 08:03 |
| gtema | I have quite (even not too much) some snow | 08:03 |
| tobberydberg | #startmeeting publiccloud_sig | 08:04 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:04 |
| opendevmeet | The meeting name has been set to 'publiccloud_sig' | 08:04 |
| gtema | arctic outbreak :-( | 08:04 |
| joek_office | here now snow there. Very unhappy | 08:04 |
| fkr | gtema: you were busy in the hedgedoc ;) | 08:05 |
| gtema | I am driving to bring my daughter to school (16km) and there is no snow either | 08:05 |
| joek_office | also ahve -4 deg in night and now plus 1.5 | 08:05 |
| gtema | fkr - nom I guess joek_office was that | 08:05 |
| fkr | cool! yeah joek_office! | 08:05 |
| tobberydberg | So, we have not prepared an agenda for this meeting ... sorry for that... | 08:05 |
| joek_office | yes. think i have opened the hedgedoc in a tab | 08:05 |
| fkr | so, joek_office, gtema and me tried to work a bit on our favourite subject ;) | 08:05 |
| fkr | (segway'ing away from the weather) | 08:06 |
| puck | :) | 08:06 |
| tobberydberg | So I guess, the floor is open to suggest agenda bullets... ;-) | 08:06 |
| fkr | - Discoverability of flavors - and basically offerings of a iaas | 08:06 |
| fkr | And doing so we started working on userstories | 08:06 |
| fkr | https://input.scs.community/ZfP4d2kNTbagN9-Jk2ccEQ | 08:06 |
| tobberydberg | Ah, nice! | 08:07 |
| gtema | we were thinking that simply defining the properties is not sufficient | 08:07 |
| 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 |
| puck | Looks good to me | 08:08 |
| 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:08 |
| 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:09 |
| gtema | in that regard please feel free to add userstories from your side | 08:10 |
| gtema | once we have userstories we should be able to describe user view and operator view on that story | 08:12 |
| fkr | +1 | 08:12 |
| gtema | this way we should be able to really compare different views | 08:12 |
| tobberydberg | This is a really good start I think +1 | 08:13 |
| gtema | links to the SCS spec wrt naming are currently given as a reference only (to know which specifics were already defined) | 08:14 |
| gtema | this is not a must, just a helping info, so feel free to ignore it | 08:14 |
| fkr | that is actually an important point gtema | 08:14 |
| gtema | I know, I just want that people do not feel uncomfortable adding points if there is no link to scs spec | 08:15 |
| 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 |
| fkr | :) | 08:15 |
| joek_office | are there any thoughts about 'operator' user stories, i think on this side we are at the moment rare | 08:15 |
| fkr | that is indeed open | 08:16 |
| gtema | agree. This is, however, not really in scope of the "interoperability" itself | 08:16 |
| 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:16 |
| 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 |
| 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 |
| fkr | +1 again | 08:17 |
| 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 |
| gtema | damn latency, I prefer voice meetings | 08:17 |
| joek_office | +1 voice meetings | 08:18 |
| tobberydberg | Next time, next time... ;-) | 08:18 |
| gtema | lol | 08:18 |
| 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 |
| gtema | the snow is back at my place, started snowing quite strong | 08:19 |
| tobberydberg | Lucky you ;-) | 08:19 |
| gtema | tobberydberg - then feel free to start adding a bit more context under the stories | 08:20 |
| gtema | i.e. I am a bit struggling to invent anything wrt CPU architecture | 08:20 |
| gtema | this is the one which disturbs me at most due to its complexity | 08:20 |
| gtema | well, not the only one - licensed images is another thing | 08:21 |
| gtema | i.e. "why for me as a user it is important to have licensed image" and what in reallity this means | 08:21 |
| tobberydberg | "* As a user of IaaS, I want to provision a VM with ARM CPU" - that exemplifies that, right? | 08:21 |
| puck | images with multiple different licensed things - operating system and software (i.e. MS SQL Server). There's a matrix... | 08:21 |
| gtema | a) user wants to bring his license into the enterprise distron | 08:21 |
| joek_office | but at the moment we only think about use cases. Not how we solve the problems | 08:21 |
| gtema | b) user wants to get some already licensed image without paying | 08:22 |
| gtema | puck - that is the point, I want that we describe those things | 08:22 |
| gtema | because otherwise we will struggle to find proper solution | 08:22 |
| puck | Multiple fields/values in the search. | 08:23 |
| gtema | joek_office - you in example brought infiniband. I do not really know why this should/could matter for the user | 08:23 |
| fkr | tobberydberg: as a user of IaaS, I want to deploy my arm workload onto the iaas | 08:23 |
| joek_office | gtema: have copied your suggestion about licenses | 08:23 |
| fkr | for the user matters network that provides speed at factor X | 08:23 |
| fkr | regardless of medium | 08:23 |
| puck | HPC workloads may well care about the networking. | 08:23 |
| fkr | they care about the speed and latency | 08:24 |
| fkr | not medium | 08:24 |
| fkr | do they? | 08:24 |
| gtema | yeah, clear, but how that refer to hypervisor/image. Or are we down to any specifics? | 08:24 |
| tobberydberg | Hmmm...."is_licensed" was for me meant to be just an indicator that "extra costs will apply".... | 08:24 |
| 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:25 |
| 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 |
| tobberydberg | gtema ... bring your own license is for me "private image land" | 08:26 |
| gtema | guys, again: are we discussing every specific or we focus on hypervisor/image only? | 08:26 |
| gtema | bringing networking is dangerous | 08:26 |
| gtema | and in that case immediately volume types and stuff like that also lands | 08:27 |
| 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:27 |
| gtema | puck - so for you it means: user can boot such image but would need to pay extra on his bill. Right? | 08: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 |
| puck | gtema, yes | 08:29 |
| gtema | puck: got it | 08:29 |
| puck | joek_office, yes, and return the matching resource names for the resource type being requested | 08:30 |
| gtema | joek_office: as already hinted to you - you try to bring possible solution while we have not defined the question properly | 08:30 |
| joek_office | gtema: sorry, think you have to direct me every time. But you are right. | 08:31 |
| joek_office | gtema: the use case with the image and license i think can go to the iaas operator later in document | 08:34 |
| 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:34 |
| 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 |
| 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 |
| puck | Has anyone implemented those tags yet? | 08:35 |
| 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 |
| puck | Or a hint to Nova/Neutron/etc | 08:36 |
| gtema | I really want we DO NOT DISCUSS search now | 08:36 |
| puck | Ack, the user stories sound reasonable to me. | 08:37 |
| gtema | because some of the props are already there and filterable, some not | 08:37 |
| gtema | and we need to figure out the general approach | 08:37 |
| puck | Okay, so further discussion here? | 08:38 |
| gtema | I tried to "restruct" first 2 stories to try to represent user/operator view | 08:41 |
| gtema | what do you think of this approach? | 08:41 |
| tobberydberg | +1 | 08:41 |
| fkr | +1 | 08:42 |
| joek_office | +1 | 08:42 |
| gtema | great, thanks | 08:42 |
| puck | +1 with slight adjustment of "and optionally round up to nearest available option" | 08:42 |
| gtema | ?? don't get that | 08:43 |
| 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 |
| fkr | gtema: on second thought, I think it misses the why | 08:43 |
| fkr | I tried to add it | 08:43 |
| 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 |
| 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 |
| puck | (burst is more complicated, ignore that mention) | 08:44 |
| gtema | puck - totally makes sense. If operator is ready to give more resources then requested - shoot it here | 08:44 |
| 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:46 |
| 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 |
| 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 |
| puck | Oh, it should return the resource name for the next nearest thing, and charge for that resource type. | 08:47 |
| puck | But if searching in N dimensions, tricky to get the smallest match. | 08:48 |
| gtema | correct. Therefore charging by flavor name is maybe not what people really want to | 08:48 |
| 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:49 |
| 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 |
| 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:50 |
| puck | s/rations/ratios/ | 08:51 |
| gtema | ok, time is ticking | 08:52 |
| gtema | I suggest all of us think and try to add further details into the doc | 08:53 |
| fkr | +1 | 08:53 |
| gtema | and next time we can discuss next steps | 08:53 |
| gtema | so what about next time, voice? | 08:53 |
| fkr | yes, that would be the deal | 08:53 |
| tobberydberg | +1 | 08:53 |
| fkr | what I wondered: | 08:53 |
| fkr | we're in #openstack-operators | 08:53 |
| fkr | does it make sense to have the discussion properly async going to have it in #openstack-publiccloud ? | 08:54 |
| fkr | or we just keep the discussion here | 08:54 |
| fkr | since its low traffic here anyways | 08:54 |
| gtema | I would stay here | 08:54 |
| tobberydberg | yea, lets stay here,,, | 08:55 |
| puck | Downside is there are a lot of people idling in here (this is the fullest openstack IRC channel!). | 08:56 |
| puck | But I'm not too worried about that. | 08:57 |
| fkr | well, as long as noone complains :) | 08:57 |
| fkr | and mostly I only see parts/joins here anyways | 08:57 |
| puck | I don't think I've ever seen any other chatter in here other than us. | 08:57 |
| fkr | so its good if the channel sees some real traffic (aside from largescale sig of course) | 08:57 |
| fkr | puck: largescale-sig | 08:57 |
| fkr | that was a nice meeting today :) | 08:58 |
| fkr | thanks everyone | 08:58 |
| puck | Cheers folks, and thank you again for swapping the week. | 08:58 |
| gtema | thanks. Have a nice day/evening | 08:58 |
| tobberydberg | Yea, thanks for today! Have a great day! | 08:59 |
| joek_office | nice to "meet" you today. Have a nice week all of you | 08:59 |
| tobberydberg | #endmeeting | 08:59 |
| opendevmeet | Meeting ended Wed Nov 29 08:59:10 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-11-29-08.04.html | 08:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-11-29-08.04.txt | 08:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-11-29-08.04.log.html | 08:59 |
| felixhuettner[m] | just wanted to let you know that i can not join the Large Scale SIG Session later | 12:51 |
| ttx | boo | 16:01 |
| kbarrientos[m] | so sad :( | 16:01 |
| kbarrientos[m] | #startmeeting large_scale_sig | 16:01 |
| opendevmeet | Meeting started Wed Nov 29 16:01:43 2023 UTC and is due to finish in 60 minutes. The chair is kbarrientos[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'large_scale_sig' | 16:01 |
| kbarrientos[m] | #topic Rollcall | 16:01 |
| kbarrientos[m] | is anyone here for the large scale meeting? | 16:02 |
| ttx | I am :) | 16:04 |
| ttx | ping amorin | 16:04 |
| kbarrientos[m] | ty :) | 16:04 |
| kbarrientos[m] | well i guess this will be quick lol | 16:06 |
| kbarrientos[m] | #link https://etherpad.openstack.org/p/large-scale-sig-meeting | 16:06 |
| kbarrientos[m] | #topic Ops Deep Dive: Samsung SDS, December 14 | 16:06 |
| kbarrientos[m] | #Final details | 16:06 |
| kbarrientos[m] | * #link https://etherpad.openstack.org/p/large-scale-sig-meeting | 16:07 |
| kbarrientos[m] | #topic Ops Deep Dive: Samsung SDS, December 14 | 16:07 |
| ttx | Are we all set? Maybe we should follow up by email to make sure | 16:07 |
| kbarrientos[m] | amorin and felix have confirmed. did you end up reaching out to that one person you mentioned last meeting? | 16:09 |
| kbarrientos[m] | Gene | 16:10 |
| kbarrientos[m] | Still no reply from mnaser or belmiro | 16:10 |
| ttx | I did not get a reply | 16:12 |
| ttx | Maybe my email is not good. Pinging here Gene Kuo | 16:13 |
| ttx | Would you be interested in co-hosting the OpenInfra Live episode on Dec 14? | 16:13 |
| ttx | He is unliekly to be up at this hour | 16:14 |
| ttx | hopefully we should have an answer by tomorrow | 16:15 |
| kbarrientos[m] | sounds good, thank you! Other than that, we are pretty much set. I was gonna start an etherpad today and email it out to everyone | 16:15 |
| ttx | If nobody shows up to do the 3rd host I'll do it | 16:15 |
| ttx | 👍️ | 16:15 |
| kbarrientos[m] | #info confirmed host felix.huettner and amorin, potentially Gene Kuo and ttx for 3rd host if Gene cant | 16:16 |
| kbarrientos[m] | #info KB to send out etherpad to participants later today | 16:17 |
| amorin | hello | 16:17 |
| amorin | sorry I am late | 16:17 |
| kbarrientos[m] | #topic Large Scale doc | 16:17 |
| kbarrientos[m] | #link https://docs.openstack.org/large-scale | 16:17 |
| kbarrientos[m] | Any changes here? | 16:18 |
| ttx | amorin: hi! | 16:18 |
| ttx | Any comment on the ops deep dive? | 16:18 |
| amorin | nothing, good for me | 16:18 |
| kbarrientos[m] | Ohh! hi amorin !! no worries, join the party | 16:18 |
| amorin | nothing on doc side neither, no big change recently | 16:19 |
| kbarrientos[m] | perf, thank you! | 16:19 |
| kbarrientos[m] | onto the next | 16:19 |
| kbarrientos[m] | #topic Next meeting | 16:19 |
| kbarrientos[m] | #info OpenInfra Live: Dec 14, 15utc | 16:20 |
| kbarrientos[m] | and | 16:20 |
| kbarrientos[m] | #topic IRC meeting: Jan 10, 9utc | 16:21 |
| amorin | ack | 16:21 |
| kbarrientos[m] | ttx will chair, since i will be sleeping | 16:21 |
| kbarrientos[m] | #topic Open discussion | 16:22 |
| kbarrientos[m] | Anyone have anything they want to add or are we 👍️ | 16:22 |
| amorin | good | 16:23 |
| kbarrientos[m] | awesome. Well thank you ttx and amorin for being here and have a great day / rest of the week! | 16:24 |
| ttx | Actually... | 16:24 |
| kbarrientos[m] | ohh | 16:24 |
| ttx | I'll be off skiing on January 10 | 16:24 |
| amorin | I can chair | 16:24 |
| ttx | amorin: thanks! | 16:24 |
| amorin | I'll just have to read the bot basic commands :) | 16:25 |
| ttx | We can communicate our script :) | 16:25 |
| amorin | that would be nice :) | 16:25 |
| amorin | should I send the mailing list reminder as well? | 16:25 |
| kbarrientos[m] | #info amorin to chair IRC meeting: Jan 10, 9utc | 16:25 |
| ttx | ideally yes | 16:25 |
| amorin | ok, usually few days ago? | 16:26 |
| ttx | i send it on Monday | 16:26 |
| amorin | few days before* | 16:26 |
| amorin | ok | 16:26 |
| kbarrientos[m] | I can send the reminder email if you'd like amorin | 16:26 |
| amorin | thanks! I am affraid I could forget :) | 16:26 |
| kbarrientos[m] | and send you the commands with the script, etc. I just follow the one ttx sent me | 16:26 |
| amorin | ok perfect thanks | 16:26 |
| ttx | yes please | 16:26 |
| kbarrientos[m] | on it 👍️ | 16:27 |
| kbarrientos[m] | #info KB to send reminder email the week of meeting and send amorin command script | 16:27 |
| kbarrientos[m] | anything else? | 16:28 |
| kbarrientos[m] | if not, i think we are good here :) | 16:29 |
| amorin | good for me | 16:30 |
| kbarrientos[m] | Sounds great. Again, thank you and everyone have a great week! | 16:30 |
| kbarrientos[m] | #endmeeting | 16:30 |
| opendevmeet | Meeting ended Wed Nov 29 16:30:51 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:30 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/large_scale_sig/2023/large_scale_sig.2023-11-29-16.01.html | 16:30 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/large_scale_sig/2023/large_scale_sig.2023-11-29-16.01.txt | 16:30 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/large_scale_sig/2023/large_scale_sig.2023-11-29-16.01.log.html | 16:30 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!