*** tetsuro has joined #openstack-tc | 00:07 | |
*** jamesmcarthur has quit IRC | 00:08 | |
*** jamesmcarthur has joined #openstack-tc | 00:15 | |
*** jamesmcarthur has quit IRC | 00:27 | |
*** jamesmcarthur has joined #openstack-tc | 00:29 | |
*** markvoelker has joined #openstack-tc | 01:15 | |
*** markvoelker has quit IRC | 01:19 | |
*** EmilienM|PTO is now known as EmilienM | 01:27 | |
*** e0ne has joined #openstack-tc | 01:56 | |
*** e0ne has quit IRC | 02:01 | |
*** e0ne has joined #openstack-tc | 02:12 | |
*** e0ne has quit IRC | 02:16 | |
*** markvoelker has joined #openstack-tc | 02:21 | |
*** markvoelker has quit IRC | 02:25 | |
*** ricolin has joined #openstack-tc | 02:33 | |
*** markvoelker has joined #openstack-tc | 02:34 | |
*** markvoelker has quit IRC | 02:39 | |
*** e0ne has joined #openstack-tc | 02:43 | |
*** e0ne has quit IRC | 02:47 | |
*** tetsuro has quit IRC | 02:48 | |
*** e0ne has joined #openstack-tc | 02:58 | |
*** e0ne has quit IRC | 03:03 | |
*** jamesmcarthur has quit IRC | 03:07 | |
*** jamesmcarthur_ has joined #openstack-tc | 03:07 | |
*** jamesmcarthur_ has quit IRC | 03:09 | |
*** e0ne has joined #openstack-tc | 03:29 | |
*** markvoelker has joined #openstack-tc | 03:31 | |
*** e0ne has quit IRC | 03:34 | |
*** markvoelker has quit IRC | 03:36 | |
*** tetsuro has joined #openstack-tc | 03:47 | |
*** tetsuro has quit IRC | 03:51 | |
*** evrardjp has quit IRC | 04:33 | |
*** evrardjp has joined #openstack-tc | 04:33 | |
*** ricolin_ has joined #openstack-tc | 04:56 | |
*** ricolin has quit IRC | 04:57 | |
*** tetsuro has joined #openstack-tc | 05:03 | |
*** tetsuro has quit IRC | 05:08 | |
*** cloudnull has quit IRC | 05:23 | |
*** markvoelker has joined #openstack-tc | 05:32 | |
*** markvoelker has quit IRC | 05:36 | |
*** Luzi has joined #openstack-tc | 05:37 | |
*** cloudnull has joined #openstack-tc | 05:48 | |
*** tosky has joined #openstack-tc | 06:39 | |
*** ralonsoh has joined #openstack-tc | 07:19 | |
*** e0ne has joined #openstack-tc | 07:50 | |
*** ricolin_ has quit IRC | 10:01 | |
ShadowJonathan | heya openstack technical committee, i have some ideas i might want to add to https://governance.openstack.org/ideas/, but first of all i want to run them by here (and on the mailing list, when i have the chance) to get some feedback and possibly some history on the nature of the proposal itself (if it's ever been brought up before) | 10:29 |
---|---|---|
ShadowJonathan | I have 3 distinct ideas in total: | 10:40 |
ShadowJonathan | project "Nebula": A transparent layer that provides Openstack APIs and flows to proprietary clouds, tie resources from multiple clouds together in workflows, or provision resources from unconventional workflows. Goal: Abstracting proprietary clouds with a OpenStack API | 10:40 |
ShadowJonathan | project "Aurora": Provide a framework where members of a community can add and remove resources dynamically to a wider community, think "that desktop in the basement that's On all the time", being able to provide a openstack-like experience with sparse resources. Goal: Allow a community to source resources together for their own use | 10:40 |
ShadowJonathan | project "Dew": Allow Openstack to work in an asperous or constrained environment, think old desktops, old hardware, scrapped hardware from last decennia, non-conventional server hardware, raspberry Pis, user desktops, etc, and have Openstack work tolerantly in an overlay over these resources, Tolerance (no loss of data) > uptime. Goal: Allow refurbishment of computing hardware to give new life to a | 10:40 |
ShadowJonathan | cloud-like environment | 10:40 |
ShadowJonathan | (here's some further notes and scribbles i wrote when i was relatively insomniac & could not sleep late at night, they may be a little bit weirdly formatted, but i think they can give some further or deeper idea in my thoughts about this: https://hastebin.com/oralobehon.md) | 10:42 |
ShadowJonathan | (further note on Aurora; for security, maybe peered resources only can have access to eachother on a "need-to-know" basis, where a compute resource only has access to a storage resource if it's "needed", and a ticket/token from a central controller (keystone or similar) can allow resources to access eachother on basis of least privilege) | 10:45 |
ShadowJonathan | all of these ideas hopefully could contribute to lowering a barrier for entry to openstack, and possibly widening its scope a little to encompass people outside datacenters, and further Openstack's missions | 10:47 |
ShadowJonathan | (oh whoops, i did not know that was a user) | 10:47 |
*** markvoelker has joined #openstack-tc | 11:06 | |
*** markvoelker has quit IRC | 11:16 | |
*** giblet is now known as gibi | 11:17 | |
*** ricolin_ has joined #openstack-tc | 11:23 | |
*** tkajinam has quit IRC | 11:37 | |
*** adriant has quit IRC | 11:58 | |
*** masayukig has quit IRC | 11:58 | |
*** masayukig has joined #openstack-tc | 11:58 | |
*** adriant has joined #openstack-tc | 11:59 | |
ttx | Those are interesting thoughts. Of those, Nebula is probably the easiest. Re: Aurora, there were some initial thoughts around combining heterogeneous resources at the edge: being able to rely on local "ambient computing" resources to run edge applications. But that usually falls short due to security/privacy | 12:01 |
*** markvoelker has joined #openstack-tc | 12:01 | |
*** markvoelker has quit IRC | 12:04 | |
*** e0ne has quit IRC | 12:15 | |
*** e0ne_ has joined #openstack-tc | 12:15 | |
ttx | Interesting: https://imgur.com/a/umAPPoI | 12:23 |
ttx | This increase in activity is visible across all categories of repositories. | 12:25 |
mnaser | ShadowJonathan: don't worry, openstack is a bot, so we can bother them | 12:31 |
mnaser | ShadowJonathan: that's some really interesting and fresh idea. fyi, anyone can publish anything into that ideas website. would it be cool to push out those ideas (even as little as that markdown paste) into it? | 12:32 |
ShadowJonathan | That was my intention, after having found that website, I instantly had 2 thoughts, Aurora came later (out of a little distant idea to make distributed trustless computing completely secure: https://security.stackexchange.com/questions/232568/is-uncompromisable-obfuscated-x86-64-execution-possible) | 12:33 |
ShadowJonathan | i'm just posting these ideas on here (for now) to get some feedback and deduplication if an initiative is already ongoing or has been cancelled for reasons in the past, or has been abandoned | 12:34 |
ShadowJonathan | ttx: > But that usually falls short due to security/privacy | 12:36 |
ShadowJonathan | That's why one of the non-goals and intentional out-of-scope warnings of utilization of the project is the non- or minimal management of trust and security in that model, the idea fundamentally trades off centralization of resources and monitored exchanges with community-provided resources where the whole community (or large chunks of it) must have a pre-existing trust relationship with eachother | 12:36 |
ShadowJonathan | as small as 2 people just sharing servers for redundancy, to a whole worldwide community of enthusiasts providing their spare scrap to work for a common goal | 12:37 |
ShadowJonathan | the point isnt to make a foundation of trustless computing, the point is to empower pre-existing trust foundations | 12:37 |
ShadowJonathan | the impact that a rogue actor within such a system can have is bigger than normal, yes, but that's why i added 2 clauses where; 1. users can have preferences for "who's resources" they will restrict their dynamic cloud allocation to, and 2. resources can only access eachother on a need-to-know basis, so that any compromise is limited "locally". | 12:40 |
ShadowJonathan | But that usually falls short due to security/privacy | 12:40 |
ShadowJonathan | (whoops, that last message isnt what i meant to send) | 12:41 |
ShadowJonathan | i meant to say "These measures are meant to mitigate breaches, not prevent them" | 12:41 |
ttx | ShadowJonathan: makes sense. When I looked into that the idea was to enable edge, ultra-low-latency workloads to run on ambient computing resources (think random idle ISP boxes) which would require to be able to run untrusted workloads on untrusted hardware. Not there yet :) | 12:41 |
ShadowJonathan | i intentionally didn't want to label this "edge computing", but "communal computing", as a non-goal of it is to minimize latency and performance, but rather to give any resource *at all* to a community which already has those resources, but rather have openstack act as an orchestrator on top of it, and provide the cloud experience | 12:43 |
*** ralonsoh has quit IRC | 12:43 | |
*** ralonsoh has joined #openstack-tc | 12:44 | |
ShadowJonathan | i looked into FHE (fully homomorphic encryption) which is what could enable such 'trustless computing', but it is both not suited for everyday commercial processors, and its not a fully researched topic either, with (afaik) only IBM seriously trying to research it | 12:44 |
mnaser | ShadowJonathan: i'm curious as to what your background is :) | 12:45 |
ttx | ShadowJonathan: yes I arrives to the same conclusion | 12:46 |
ShadowJonathan | self-educated systems enthusiast, 20 years old, not yet out of college, but just interested in all of these systems trying to work together | 12:46 |
ttx | arrived* | 12:46 |
ShadowJonathan | my (shitty) web page is https://automatia.nl (for projects, huge overhaul coming soon (i hope)), and https://me.jboi.nl for some personal info (which is also outdated, hurray me for maintainance) | 12:47 |
mnaser | ShadowJonathan: that's some really interesting ideas that you bring up and i'd be happy to help get a patch up to openstack/ideas -- and then perhaps explore ways we can make some strides to at least setup the infrastructure to get us there | 12:48 |
ShadowJonathan | i dont have much "background", im just interested in this | 12:48 |
*** ijolliffe has joined #openstack-tc | 12:48 | |
mnaser | i'd disagree and say you seem to have a lot of background, a lot more than i've ran into, surely :) | 12:48 |
ShadowJonathan | yeah, i know of myself im much more of a 'dreamer', so i'd rather document these ideas than promise that i'll throw my full weight behind making this happen all the way, as i know better than that now | 12:48 |
ShadowJonathan | no i meant "background" as in "job background" and soforth, which is what the intention of the meaning often is behind the word | 12:49 |
mnaser | of course, the ideas repository is not a commitment to do work, but its the fact that someone thought this through and documented some sort of "way to move forward" with this | 12:49 |
ShadowJonathan | "whats your background?" often equals to "where have you worked before? which people do you know?" | 12:49 |
ShadowJonathan | which in my case is "none" and "nobody really" | 12:49 |
ShadowJonathan | "nowhere"* | 12:49 |
ShadowJonathan | ahhh ok | 12:49 |
mnaser | evrardjp started the initiative, perhaps they can do a better job selling it than me :) | 12:50 |
evrardjp | I will read the scrollback when I can, I just can't right now :) | 12:51 |
ShadowJonathan | no problem, i mostly meant to post these messages already and set this up for tomorrow morning (UTC time) so i can get some feedback before i start getting into it in-depth and flesh out some areas im 99% sure i haven't thought of before | 12:52 |
evrardjp | ML aren't too bad for exploring things too, as you probably mentioned :) | 12:53 |
evrardjp | The thing to keep in mind with ideas: There will always be people who love, and people who hate some ideas. But that shouldn't be a problem to document things, and have proposals. ANyway, I will read all of this soon... Thanks for proposing ideas ShadowJonathan, it's very valuable! :) | 12:54 |
ShadowJonathan | yeah, i still have to set up a (serious) email provider for my own domains, im currently stuck between setting up my own droplet & getting managed hosting. the tradeoff between those two is; self-managed hosting costs time and maintainance, and possibly is expensive finance-wise (but i get full control over the mail) | 12:54 |
ShadowJonathan | but managed hosting can be hands-off "just works", but i'd have less control and some restrictions | 12:54 |
ShadowJonathan | no prob, glad to help! | 12:55 |
ttx | tc-members: it's newsletter week, so if you have any news to communicate out, please add to https://etherpad.opendev.org/p/newsletter-openstack-news | 12:59 |
jungleboyj | o/ | 13:01 |
ShadowJonathan | o/ | 13:03 |
*** zombieJulia is now known as TheJulia | 13:06 | |
gmann | o/ | 13:26 |
openstackgerrit | Zane Bitter proposed openstack/governance master: Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369 | 13:26 |
openstackgerrit | Merged openstack/governance-sigs master: Clean up some wording to be clearer https://review.opendev.org/739830 | 13:26 |
*** e0ne_ has quit IRC | 13:27 | |
*** irclogbot_3 has quit IRC | 13:27 | |
*** gibi has quit IRC | 13:27 | |
*** e0ne_ has joined #openstack-tc | 13:28 | |
*** irclogbot_3 has joined #openstack-tc | 13:28 | |
*** gibi has joined #openstack-tc | 13:28 | |
*** noonedeadpunk has quit IRC | 13:31 | |
*** noonedeadpunk has joined #openstack-tc | 13:33 | |
*** Luzi has quit IRC | 14:00 | |
gmann | ShadowJonathan: interesting ideas and thanks for sharing here. 'Nebula' can help on interop side also, I will check the details once it is up and we can discuss more on how we can leverage this to improve or widen the interop coverage. | 14:02 |
ShadowJonathan | gmann: Once I have a mail domain up, I'll throw a more-fleshed-out version on there to be discussed with greater detail | 14:05 |
ShadowJonathan | Also: love that name | 14:05 |
gmann | +1 | 14:05 |
fungi | ttx: on the merged changes increase, i saw the same increase reflected in opendev engagement/activity counts comparing 2019-q2 to 2020-q2, and yes most of that was openstack but there were similar trends in some other communities | 14:07 |
fungi | makes me wonder if a lot of folks are finding working from home more efficient, or maybe it's the lack of travel and inability to have any significant in-person social lives lately ;) | 14:09 |
ShadowJonathan | gmann: an extra note on Nebula as well; my initial thoughts about it is is that it is a simple immutable-by-version api frontend (documented by something like openapi) with a myriad of backends as a baseline, a simple interop between cloud apis | 14:16 |
ShadowJonathan | with possibly an orchestration/"glue" engine on top of that that can allocate cloud resources on different clouds, but have them work together as if all of them exist in the same cloud (with caveats, obviously, but to have it be automated to the best ability and least friction possibility) | 14:16 |
njohnston | o/ | 14:17 |
ShadowJonathan | initially i thought it could be a client-sided "swiss-knife", or an api proxy, but it can also have potential as a Rancher/Gardener-type manager that can make complicated situations like hybrid clouds seamless, for example | 14:17 |
ShadowJonathan | also, o/ njohnston | 14:17 |
njohnston | May be some confusion between Nebula and https://opennebula.io/ | 14:17 |
fungi | ShadowJonathan: also an interesting naming choice, especially on the 10th anniversary of openstack's formation, the project which eventually became openstack nova was originally named nebula | 14:17 |
fungi | njohnston: they arguably brought that naming confusion upon themselves, it was an intentional similarity | 14:18 |
ShadowJonathan | i simply had some names in my head one night, and tried to bring forth some systematic ideas out of its abstract idea, much like how Cinder and Keystone got their names | 14:18 |
ShadowJonathan | might indeed wanna provide alternatives | 14:18 |
ShadowJonathan | oooo, "constellation" could work very nicely as well | 14:19 |
njohnston | fungi: No doubt, just noting that it exists | 14:19 |
ShadowJonathan | im seeing "Lodestar" here as well, could be an interesting name as something else | 14:20 |
ShadowJonathan | im very much inclined to change it to "Constellation" now that i notice the similarities between "Nebula" and "Nova", and indeed that historic similarities | 14:29 |
ShadowJonathan | there's also a fairly logical reason why not to use it now, as it could gunk up documentation and communication, because of legacy backlog or outdated definitions, and thus causing misdirection | 14:29 |
ShadowJonathan | those* historic similarities | 14:29 |
ShadowJonathan | also "Nimbus" and other cloud synonyms could fit, but that'd get a bit on the nose with the similarity to the word "cloud" in general | 14:34 |
*** beekneemech is now known as bnemec | 14:38 | |
*** dklyle has joined #openstack-tc | 14:39 | |
smcginnis | There's some conflict with naming "constellation" as well, but given how poorly that effort went, there are probably only about 10 people that would have a chance of being confused by the name. :) | 14:40 |
ShadowJonathan | smcginnis: oh? im curious about this, what happened in the past? | 14:42 |
fungi | constellations were what we were calling different identifiable combinations of openstack services for various use cases. currently represented by a mostly empty git repository generating some boilerplate documentation | 14:44 |
ShadowJonathan | "different identifiable combinations of openstack services for various use cases" wouldn't those just be simply called "stacks"? i always thought of them that way | 14:45 |
fungi | https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html#navigating-with-constellations | 14:45 |
ShadowJonathan | my idea behind the naming of "openstack" not being "opencloud" is because the org is giving a "stack" of components that can be reshuffled or cherrypicked from | 14:45 |
fungi | we surprisingly don't use the term "stacks" much in openstack, outside the heat service anyway | 14:45 |
ShadowJonathan | huh, interesting | 14:46 |
fungi | and yeah, the idea was that with a map of the 70 or so official api services which make up openstack, different use cases could be represented by connecting different services on that map | 14:47 |
fungi | it's probably more like 50 api services, not all the official projects maintain rest apis since some are focused on libraries or deployment tooling | 14:48 |
ShadowJonathan | when i initially tried to dig into openstack, opening up the wikipedia page and seeing more services added every release was something akin to a very good horror movie for me, because i had set out to research openstack top-to-bottom at that point | 14:49 |
ShadowJonathan | i still have that plan, but i just extended the time a whole lot | 14:49 |
ShadowJonathan | another thing im a bit afraid about is that services at the "fringes" would be getting a whole less love than "core" services, resulting in neglect and interoperability issues, and drought of manpower | 14:50 |
ShadowJonathan | voluntary manpower* | 14:50 |
fungi | in some cases that does happen. in many cases though it just limits the scope of what they can implement successfully | 14:55 |
gmann | ShadowJonathan: also we have lot of things to do in API side itself. OpenStack different services APIs are not consistent on "how to change" which can be existing challenges for interop and so does will be for nebula. | 15:14 |
ShadowJonathan | i recommend openapi then as a 'single source of truth' as how to version and provide reference documentation on how those APIs evolve | 15:16 |
gmann | and as they are existing APIs, it is not easy/possible to build new set of consistent APIs but something or as much as we can improve to make 'OpenStack API changes more consistently'can be good | 15:16 |
gmann | ShadowJonathan: yeah that we considered for Nova API changes and gave some effort also but for existing APIs it was too difficult to adopt that. For new API of new services yes openapi is much recommended way to make API maintainer/user life easy | 15:18 |
ShadowJonathan | maybe slowly integrate it as "accommodating documentation", and then eventually switch over to have it be the absolute source of truth for how the api is defined | 15:19 |
ShadowJonathan | i know its possibly not really possible to document all the kinks that existing apis have, but maybe thats also an initiative to make them all uniform to 1 definition standard | 15:20 |
*** e0ne_ has quit IRC | 15:20 | |
*** e0ne has joined #openstack-tc | 15:20 | |
gmann | yeah, we have few past ref/discussion/effort for those. improving (making consistent) the error message across openstack APIs was one of recent one. | 15:23 |
gmann | ShadowJonathan: this one, though we do not have any consensus yet on this - https://etherpad.opendev.org/p/rest-api-error-consistency | 15:26 |
gmann | but i feel these kind of things can be discussed and improved(if we cannot do in current APIs) in your idea. | 15:27 |
smcginnis | At the time at least, OpenAPI was not able to express some of the existing APIs too. So I think a lot of work went into trying to get it to work, but ultimately it had to be dropped. | 15:29 |
gmann | yeah | 15:30 |
fungi | if only openapi had existed before openstack was created | 15:31 |
fungi | zuul did end up using openapi at least: https://zuul.opendev.org/openapi | 15:31 |
ShadowJonathan | im not saying its too late, im especially just saying its a candidate for standardization across all projects, a nice mold where some initiative can put effort into | 15:32 |
ShadowJonathan | im not at all saying it is "the" solution, just one that i note could fit this | 15:32 |
fungi | sure, just remember there are lots of solutions which would have made sense if they already existed a decade ago when openstack was created, or if openstack didn't need to maintain backward compatibility for its apis | 15:33 |
ShadowJonathan | ofc ofc, thats why i dont wanna exclusively push it as that and that only | 15:35 |
ShadowJonathan | i know that i have that tendency with some things, so im just pointing that out right now | 15:35 |
gmann | designing time of APIs is the crucial and after that improving or changing that is not always difficult especially open source projects having wide(lot of unknown) usage | 15:36 |
gmann | * changing that is always difficult | 15:37 |
ShadowJonathan | yeah, who knows, maybe openapi v4 will come out sometime soon that can encompass an even wider range of usabilities and knick-knacks in api request/response logic. when i worked on trying to document an existing api (as an intern job) i was kinda frustrated with how limited openapi was on some fronts, but my friend (who works as a backend developer) has some great experience with it, "openapi or go home", | 15:41 |
ShadowJonathan | so i guess it has it's uses, yeah | 15:41 |
ShadowJonathan | anyway, this was a diversion which im not truly knowledged about, so i'd rather want to talk about some of my proposals, is there any more feedback on those? | 15:44 |
ShadowJonathan | (i can repost them for anyone who has joined the IRC late, or doesn't have the chat history readily available for that) | 15:44 |
gmann | ShadowJonathan: that will be good to add the proposals and then we start the tech debt one by one. | 15:46 |
ShadowJonathan | Yeah, tech debt is something I didn't really want to discuss just yet (both because it's out of scope for my proposals, but alsl because I know I can't comment very well when I don't know much about the total and detailed state of everything in openstack), so yeah | 15:48 |
ShadowJonathan | gmann: what do you mean "add the proposals"? To the git repository? | 15:48 |
ShadowJonathan | I still want comments from the tc office hours tomorrow, and from the mailing list, before I'll draft something up that'll go on the wiki | 15:49 |
ShadowJonathan | I know I don't know much enough about what I want to formulate in what format, and that I'm definitely missing some things, so that's why I want some feedback first | 15:50 |
ShadowJonathan | (though I'll probably make another hastebin with my initial message in it so that it's a bit more sharable) | 15:50 |
gmann | ShadowJonathan: i feel if you can brings it on idea repo and then we review in tc, office hours etc(so you do not need to repeat the things or detail on IRC), collect some feedback and then mailing list of more wider feedback/tech debt. | 15:54 |
ShadowJonathan | new hastebin: https://hastebin.com/tigupurohi.md | 15:56 |
ShadowJonathan | alright, i'll make up a draft then | 15:56 |
gmann | thanks. | 15:57 |
*** e0ne has quit IRC | 16:18 | |
*** diablo_rojo__ has joined #openstack-tc | 16:20 | |
*** diablo_rojo__ is now known as diablo_rojo | 16:26 | |
openstackgerrit | Luigi Toscano proposed openstack/project-team-guide master: Import the Zuul v3 porting guide https://review.opendev.org/740727 | 16:28 |
openstackgerrit | Luigi Toscano proposed openstack/project-team-guide master: Import the Zuul v3 porting guide https://review.opendev.org/740727 | 16:29 |
tosky | a bit late, but I managed to do it ^ | 16:30 |
gmann | tosky: thanks, that is much needed and will be helpful for many projects. i will review it sometime later today | 16:31 |
*** e0ne has joined #openstack-tc | 16:43 | |
fungi | thanks tosky! i also had that rotting somewhere in the depths of my to do list but i'm pretty sure i'd have never gotten to it | 16:44 |
*** johnthetubaguy has quit IRC | 17:02 | |
*** johnthetubaguy has joined #openstack-tc | 17:03 | |
*** e0ne has quit IRC | 17:09 | |
*** e0ne has joined #openstack-tc | 17:10 | |
*** ralonsoh has quit IRC | 17:23 | |
openstackgerrit | Luigi Toscano proposed openstack/project-team-guide master: Import the Zuul v3 porting guide https://review.opendev.org/740727 | 17:25 |
*** ricolin_ has quit IRC | 17:40 | |
*** ijolliffe has quit IRC | 18:32 | |
*** e0ne has quit IRC | 19:01 | |
*** johnthetubaguy has quit IRC | 20:46 | |
*** johnthetubaguy has joined #openstack-tc | 20:47 | |
*** diablo_rojo has quit IRC | 21:18 | |
*** tosky has quit IRC | 22:42 | |
*** tkajinam has joined #openstack-tc | 22:54 | |
*** adriant has quit IRC | 23:32 | |
*** adriant has joined #openstack-tc | 23:33 | |
*** knikolla has joined #openstack-tc | 23:50 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!