Monday, 2020-07-13

*** tetsuro has joined #openstack-tc00:07
*** jamesmcarthur has quit IRC00:08
*** jamesmcarthur has joined #openstack-tc00:15
*** jamesmcarthur has quit IRC00:27
*** jamesmcarthur has joined #openstack-tc00:29
*** markvoelker has joined #openstack-tc01:15
*** markvoelker has quit IRC01:19
*** EmilienM|PTO is now known as EmilienM01:27
*** e0ne has joined #openstack-tc01:56
*** e0ne has quit IRC02:01
*** e0ne has joined #openstack-tc02:12
*** e0ne has quit IRC02:16
*** markvoelker has joined #openstack-tc02:21
*** markvoelker has quit IRC02:25
*** ricolin has joined #openstack-tc02:33
*** markvoelker has joined #openstack-tc02:34
*** markvoelker has quit IRC02:39
*** e0ne has joined #openstack-tc02:43
*** e0ne has quit IRC02:47
*** tetsuro has quit IRC02:48
*** e0ne has joined #openstack-tc02:58
*** e0ne has quit IRC03:03
*** jamesmcarthur has quit IRC03:07
*** jamesmcarthur_ has joined #openstack-tc03:07
*** jamesmcarthur_ has quit IRC03:09
*** e0ne has joined #openstack-tc03:29
*** markvoelker has joined #openstack-tc03:31
*** e0ne has quit IRC03:34
*** markvoelker has quit IRC03:36
*** tetsuro has joined #openstack-tc03:47
*** tetsuro has quit IRC03:51
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-tc04:33
*** ricolin_ has joined #openstack-tc04:56
*** ricolin has quit IRC04:57
*** tetsuro has joined #openstack-tc05:03
*** tetsuro has quit IRC05:08
*** cloudnull has quit IRC05:23
*** markvoelker has joined #openstack-tc05:32
*** markvoelker has quit IRC05:36
*** Luzi has joined #openstack-tc05:37
*** cloudnull has joined #openstack-tc05:48
*** tosky has joined #openstack-tc06:39
*** ralonsoh has joined #openstack-tc07:19
*** e0ne has joined #openstack-tc07:50
*** ricolin_ has quit IRC10:01
ShadowJonathanheya 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
ShadowJonathanI have 3 distinct ideas in total:10:40
ShadowJonathanproject "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 API10:40
ShadowJonathanproject "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 use10:40
ShadowJonathanproject "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 a10:40
ShadowJonathancloud-like environment10: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
ShadowJonathanall 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 missions10:47
ShadowJonathan(oh whoops, i did not know that was a user)10:47
*** markvoelker has joined #openstack-tc11:06
*** markvoelker has quit IRC11:16
*** giblet is now known as gibi11:17
*** ricolin_ has joined #openstack-tc11:23
*** tkajinam has quit IRC11:37
*** adriant has quit IRC11:58
*** masayukig has quit IRC11:58
*** masayukig has joined #openstack-tc11:58
*** adriant has joined #openstack-tc11:59
ttxThose 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/privacy12:01
*** markvoelker has joined #openstack-tc12:01
*** markvoelker has quit IRC12:04
*** e0ne has quit IRC12:15
*** e0ne_ has joined #openstack-tc12:15
ttxInteresting: https://imgur.com/a/umAPPoI12:23
ttxThis increase in activity is visible across all categories of repositories.12:25
mnaserShadowJonathan: don't worry, openstack is a bot, so we can bother them12:31
mnaserShadowJonathan: 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
ShadowJonathanThat 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
ShadowJonathani'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 abandoned12:34
ShadowJonathanttx: > But that usually falls short due to security/privacy12:36
ShadowJonathanThat'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 eachother12:36
ShadowJonathanas 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 goal12:37
ShadowJonathanthe point isnt to make a foundation of trustless computing, the point is to empower pre-existing trust foundations12:37
ShadowJonathanthe 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
ShadowJonathanBut that usually falls short due to security/privacy12:40
ShadowJonathan(whoops, that last message isnt what i meant to send)12:41
ShadowJonathani meant to say "These measures are meant to mitigate breaches, not prevent them"12:41
ttxShadowJonathan: 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
ShadowJonathani 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 experience12:43
*** ralonsoh has quit IRC12:43
*** ralonsoh has joined #openstack-tc12:44
ShadowJonathani 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 it12:44
mnaserShadowJonathan: i'm curious as to what your background is :)12:45
ttxShadowJonathan: yes I arrives to the same conclusion12:46
ShadowJonathanself-educated systems enthusiast, 20 years old, not yet out of college, but just interested in all of these systems trying to work together12:46
ttxarrived*12:46
ShadowJonathanmy (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
mnaserShadowJonathan: 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 there12:48
ShadowJonathani dont have much "background", im just interested in this12:48
*** ijolliffe has joined #openstack-tc12:48
mnaseri'd disagree and say you seem to have a lot of background, a lot more than i've ran into, surely :)12:48
ShadowJonathanyeah, 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 now12:48
ShadowJonathanno i meant "background" as in "job background" and soforth, which is what the intention of the meaning often is behind the word12:49
mnaserof 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 this12:49
ShadowJonathan"whats your background?" often equals to "where have you worked before? which people do you know?"12:49
ShadowJonathanwhich in my case is "none" and "nobody really"12:49
ShadowJonathan"nowhere"*12:49
ShadowJonathanahhh ok12:49
mnaserevrardjp started the initiative, perhaps they can do a better job selling it than me :)12:50
evrardjpI will read the scrollback when I can, I just can't right now :)12:51
ShadowJonathanno 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 before12:52
evrardjpML aren't too bad for exploring things too, as you probably mentioned :)12:53
evrardjpThe 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
ShadowJonathanyeah, 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
ShadowJonathanbut managed hosting can be hands-off "just works", but i'd have less control and some restrictions12:54
ShadowJonathanno prob, glad to help!12:55
ttxtc-members: it's newsletter week, so if you have any news to communicate out, please add to https://etherpad.opendev.org/p/newsletter-openstack-news12:59
jungleboyjo/13:01
ShadowJonathano/13:03
*** zombieJulia is now known as TheJulia13:06
gmanno/13:26
openstackgerritZane Bitter proposed openstack/governance master: Create starter-kit:kubernetes-in-virt tag  https://review.opendev.org/73636913:26
openstackgerritMerged openstack/governance-sigs master: Clean up some wording to be clearer  https://review.opendev.org/73983013:26
*** e0ne_ has quit IRC13:27
*** irclogbot_3 has quit IRC13:27
*** gibi has quit IRC13:27
*** e0ne_ has joined #openstack-tc13:28
*** irclogbot_3 has joined #openstack-tc13:28
*** gibi has joined #openstack-tc13:28
*** noonedeadpunk has quit IRC13:31
*** noonedeadpunk has joined #openstack-tc13:33
*** Luzi has quit IRC14:00
gmannShadowJonathan: 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
ShadowJonathangmann: Once I have a mail domain up, I'll throw a more-fleshed-out version on there to be discussed with greater detail14:05
ShadowJonathanAlso: love that name14:05
gmann+114:05
fungittx: 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 communities14:07
fungimakes 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
ShadowJonathangmann: 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 apis14:16
ShadowJonathanwith 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
njohnstono/14:17
ShadowJonathaninitially 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 example14:17
ShadowJonathanalso, o/ njohnston14:17
njohnstonMay be some confusion between Nebula and https://opennebula.io/14:17
fungiShadowJonathan: also an interesting naming choice, especially on the 10th anniversary of openstack's formation, the project which eventually became openstack nova was originally named nebula14:17
funginjohnston: they arguably brought that naming confusion upon themselves, it was an intentional similarity14:18
ShadowJonathani 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 names14:18
ShadowJonathanmight indeed wanna provide alternatives14:18
ShadowJonathanoooo, "constellation" could work very nicely as well14:19
njohnstonfungi: No doubt, just noting that it exists14:19
ShadowJonathanim seeing "Lodestar" here as well, could be an interesting name as something else14:20
ShadowJonathanim very much inclined to change it to "Constellation" now that i notice the similarities between "Nebula" and "Nova", and indeed that historic similarities14:29
ShadowJonathanthere'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 misdirection14:29
ShadowJonathanthose* historic similarities14:29
ShadowJonathanalso "Nimbus" and other cloud synonyms could fit, but that'd get a bit on the nose with the similarity to the word "cloud" in general14:34
*** beekneemech is now known as bnemec14:38
*** dklyle has joined #openstack-tc14:39
smcginnisThere'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
ShadowJonathansmcginnis: oh? im curious about this, what happened in the past?14:42
fungiconstellations 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 documentation14: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 way14:45
fungihttps://governance.openstack.org/tc/resolutions/20170404-vision-2019.html#navigating-with-constellations14:45
ShadowJonathanmy 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 from14:45
fungiwe surprisingly don't use the term "stacks" much in openstack, outside the heat service anyway14:45
ShadowJonathanhuh, interesting14:46
fungiand 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 map14:47
fungiit's probably more like 50 api services, not all the official projects maintain rest apis since some are focused on libraries or deployment tooling14:48
ShadowJonathanwhen 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 point14:49
ShadowJonathani still have that plan, but i just extended the time a whole lot14:49
ShadowJonathananother 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 manpower14:50
ShadowJonathanvoluntary manpower*14:50
fungiin some cases that does happen. in many cases though it just limits the scope of what they can implement successfully14:55
gmannShadowJonathan: 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
ShadowJonathani recommend openapi then as a 'single source of truth' as how to version and provide reference documentation on how those APIs evolve15:16
gmannand 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 good15:16
gmannShadowJonathan: 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 easy15:18
ShadowJonathanmaybe 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 defined15:19
ShadowJonathani 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 standard15:20
*** e0ne_ has quit IRC15:20
*** e0ne has joined #openstack-tc15:20
gmannyeah, 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
gmannShadowJonathan: this one, though we do not have any consensus yet on this - https://etherpad.opendev.org/p/rest-api-error-consistency15:26
gmannbut i feel these kind of things can be discussed and improved(if we cannot do in current APIs) in your idea.15:27
smcginnisAt 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
gmannyeah15:30
fungiif only openapi had existed before openstack was created15:31
fungizuul did end up using openapi at least: https://zuul.opendev.org/openapi15:31
ShadowJonathanim 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 into15:32
ShadowJonathanim not at all saying it is "the" solution, just one that i note could fit this15:32
fungisure, 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 apis15:33
ShadowJonathanofc ofc, thats why i dont wanna exclusively push it as that and that only15:35
ShadowJonathani know that i have that tendency with some things, so im just pointing that out right now15:35
gmanndesigning 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) usage15:36
gmann*  changing that is always difficult15:37
ShadowJonathanyeah, 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
ShadowJonathanso i guess it has it's uses, yeah15:41
ShadowJonathananyway, 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
gmannShadowJonathan: that will be good to add the proposals and then we start the tech debt one by one.15:46
ShadowJonathanYeah, 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 yeah15:48
ShadowJonathangmann: what do you mean "add the proposals"? To the git repository?15:48
ShadowJonathanI 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 wiki15:49
ShadowJonathanI 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 first15: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
gmannShadowJonathan:  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
ShadowJonathannew hastebin: https://hastebin.com/tigupurohi.md15:56
ShadowJonathanalright, i'll make up a draft then15:56
gmannthanks.15:57
*** e0ne has quit IRC16:18
*** diablo_rojo__ has joined #openstack-tc16:20
*** diablo_rojo__ is now known as diablo_rojo16:26
openstackgerritLuigi Toscano proposed openstack/project-team-guide master: Import the Zuul v3 porting guide  https://review.opendev.org/74072716:28
openstackgerritLuigi Toscano proposed openstack/project-team-guide master: Import the Zuul v3 porting guide  https://review.opendev.org/74072716:29
toskya bit late, but I managed to do it ^16:30
gmanntosky: thanks, that is much needed and will be helpful for many projects. i will review it sometime later today16:31
*** e0ne has joined #openstack-tc16:43
fungithanks 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 it16:44
*** johnthetubaguy has quit IRC17:02
*** johnthetubaguy has joined #openstack-tc17:03
*** e0ne has quit IRC17:09
*** e0ne has joined #openstack-tc17:10
*** ralonsoh has quit IRC17:23
openstackgerritLuigi Toscano proposed openstack/project-team-guide master: Import the Zuul v3 porting guide  https://review.opendev.org/74072717:25
*** ricolin_ has quit IRC17:40
*** ijolliffe has quit IRC18:32
*** e0ne has quit IRC19:01
*** johnthetubaguy has quit IRC20:46
*** johnthetubaguy has joined #openstack-tc20:47
*** diablo_rojo has quit IRC21:18
*** tosky has quit IRC22:42
*** tkajinam has joined #openstack-tc22:54
*** adriant has quit IRC23:32
*** adriant has joined #openstack-tc23:33
*** knikolla has joined #openstack-tc23:50

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!