Tuesday, 2018-08-14

*** openstackgerrit has quit IRC01:06
*** ricolin has joined #openstack-tc02:38
*** openstackgerrit has joined #openstack-tc05:52
openstackgerritKeiichi Hikita proposed openstack/governance master: Add qinling-dashboard under Qinling project  https://review.openstack.org/59155905:52
openstackgerritKeiichi Hikita proposed openstack/governance master: Add qinling-dashboard under Qinling project  https://review.openstack.org/59155905:53
*** ricolin has quit IRC06:43
*** e0ne has joined #openstack-tc07:18
*** jpich has joined #openstack-tc07:59
*** openstackstatus has quit IRC08:12
*** dtantsur|afk is now known as dtantsur08:15
*** cdent has joined #openstack-tc08:43
evrardjpmorning08:50
* cdent waves08:52
cmurphyo/08:53
*** jaosorior has quit IRC08:53
cdenttc-members it's officer hours09:00
EmilienMhellow09:00
cmurphyEmilienM: this time you have to be in france09:01
EmilienMI'm somewhere :D09:01
EmilienMthe city of love ;-)09:02
evrardjpfor pidgins?09:03
cmurphyhow are people leaning on https://review.openstack.org/590601 versus https://review.openstack.org/588644 ?09:07
evrardjpit seems we have a tendency to give a safety rope, so it would make sense to go towards https://review.openstack.org/590601 to me...09:09
evrardjpBut I'd love hearing what ppl are thinking about this09:09
evrardjpit's giving a bad message if someone is volunteering IMO, at least it's bad if we don't give a proper explanation09:10
evrardjpagain, just my personal opinion09:10
cdentcmurphy: I can't decide. I agree that having a volunteer is a good sign and meaningful. But on the other hand at some point it feels like (and this phrasing is a bit stronger than I mean and not meant to reflect on any projects) we need to cut the dead weight09:14
evrardjpcdent: I agree on the dead weight, but here there is someone that's willing to step in09:17
cdentyeah, thus the indecision09:17
cdentthe problem is that searchlight has been effectively dead for about a year09:17
evrardjpthat breaks my heart to say "no we have decided to kill this, continue this on your own if you want"09:17
evrardjpcdent: that's true09:18
cdentand "not governed" is not the same as "killed"09:18
evrardjpbut if it's more than a year it doesn't change09:18
evrardjpthat's why my question yesterday: what's the risk of having "not governed" projects09:19
evrardjpI think this was well known when you see: https://github.com/openstack/governance/blob/master/reference/projects.yaml#L325609:20
evrardjpI think the governance repo is lacking a "temporal" aspect that might be used.09:21
evrardjpanyway, sorry to have intervened, go backs to lurking mode.09:22
cdentthis stuff is open to everyone. that's kind of the point. no need to lurk.09:24
*** openstackstatus has joined #openstack-tc09:42
*** ChanServ sets mode: +v openstackstatus09:42
*** jaosorior has joined #openstack-tc10:51
*** jaosorior has quit IRC11:17
*** jaosorior has joined #openstack-tc11:17
*** rosmaita has joined #openstack-tc11:33
smcginnisI actually forgot we tagged searchlight as maintenance-mode.12:24
smcginnisI wonder if we need to change the way we do some things for projects with that tag.12:25
smcginnisNo expected releases every cycle, no PTL election, PTL stays the contact point for the project until they hand off to someone else or we find something needs attention and they are not able or willing to provide it.12:26
cdents/things.*/things/12:26
smcginnisSeems like a maintenance-mode project really should have different expectations and requirements than a normal active one.12:27
smcginniscdent: Hah, fair enough.12:27
*** tellesnobrega has joined #openstack-tc12:27
cdentI think if we don't require the ptl election and releases, both, then we make it easy for the project to slip under the radar. The ptl election is sort of like a "yeah, I'm still here and paying attention check"12:28
cdentI agree that requiring releases for something that is "stable" is odd12:28
cmurphy++ I don't think being able to get in contact with the PTL and reminding them to submit a change to the elections repo once every six months should be too much to ask12:29
smcginnisTrue12:29
cdentIt might, however, make sense for an individual to be the stable-maintenance ptl for multiple projects12:32
smcginnisThat could work.12:35
*** jaosorior has quit IRC12:39
*** zaneb has joined #openstack-tc13:22
TheJuliacdent: That is kind of what I was thinking in the back of my head would be ideal13:33
*** jaosorior has joined #openstack-tc13:44
dhellmanndoes anything about our structure prevent that today? someone could just sign up, right?14:02
jrollthe only catch is they'd need a commit to the project14:03
cdentjroll: I think that's the crux of the biscuit, yeah. which is why naming it something slightly different might help14:04
jrollyep14:05
cdentdhellmann: and underlying the idea is basically a sense of an even further back step: members of the TC (as licensed upstream over-committers) become designated stable-maint ptls14:05
cdentwhich I do _not_ think we should do14:05
cdentbut highlights what it could all mean14:05
jrollthe different name might help with external perception too - this person won't be an expert on searchlight/etc, but can help with maintenance and point people14:05
jrollor s/perception/understanding/14:05
* cdent nods at jroll 14:06
cdentpabelanger: have you made any contact wiith masakari folk?14:06
cdenti don't want to repeat effort if you have14:06
pabelangercdent: I have not14:11
pabelangerbut can if you'd like14:11
cdentpabelanger: if you're willing and able that would be awesome14:12
pabelangersure, will send out an email today14:13
cdentcool, thanks14:14
*** ricolin has joined #openstack-tc14:15
dhellmannthis still feels like one of those cases where we want to attach a special name to something that people could already do14:18
dhellmannI'm not sure that's bad, it just seems surprising that it came up14:19
cdentpeople may be scared of being held responsible for something in a way that implies more than they can do14:27
cdentThere's a different expectation between a teacher and a substitute teacher14:28
smcginnisGood analogy.14:31
* cdent is full of 'em14:32
dhellmannmaybe rather than having 1 person maintain multiple projects as a sub, we want to rehome those projects to a team with that as its mission14:32
dhellmannthat would be somewhat like the oslo team does14:32
dhellmanntc-members: please take a few minutes to go through the open reviews, express your opinion on https://review.openstack.org/#/c/590790/, and confirm the PTL appointments14:37
EmilienMdhellmann: ack14:37
EmilienM(ah, done already)14:38
cdentzaneb: I assume you saw jay's mulligan? I was hoping for openstack v2, not nova v2, but despite that it still has some interesting things to think about.14:44
zanebcdent: I only read part 1 so far14:44
*** annabelleB has joined #openstack-tc14:44
cdenthow very disciplined(?) of you :()14:45
zanebI saw it at like 11pm on Friday and I was on PTO yesterday14:45
zanebwas slightly confused about why, if you wanted to start a project with no vendors, no conferences, and no scope outside of managing virtual machines, you would start with a project that has thousands of people doing all of those things and then try to kick them out14:46
zanebbut I am excited for part 214:46
dhellmannthe company I worked for before I worked on OpenStack built Mulligan (though we didn't call it that). There were about 8 of us, and we built something much like what he describes. We did no marketing, so between that and the fact that it met no one's real needs we had no customers. They're out of business now.14:48
dhellmannSo, I'm not sure any of that is really what I would call a winning strategy.14:48
cdentperhaps useful as a Gedankenexperiment14:49
zanebdhellmann: almost as if all those vendors and conferences contributed something of value after all14:49
dhellmannzaneb : I do like living in a house.14:49
dhellmanncdent : if it was "we should fix some architectural issues" then yes. But that's not really how I read it.14:49
cdentdhellmann: I dunno. If someone lays out a model for a different thing, that still provides by potential for stuff worth stealing. It's fertile as ideas, but not ncessarily as actions.14:50
dhellmannwhich ideas would you take, then?14:51
cdentDespite what jay says in his posts about do instead of write I think we _way_ under-write and reflect and digest14:51
cdentthe biggest thing I think worth thinking about is not at all original is jay's thing: use etcd and watchers thereof as a way of managing intent14:52
cdents/is/in/14:52
zanebUGH SPOILERS14:52
cdentAnd, in any case, it's the ideas that come as secondary thoughts from reading others' ideas that matter14:52
cdentstimulation, even to do the opposite, is good14:52
cdentzaneb: the butler did it14:53
cdentMind you, I'm no trying to indicate support for jay's proposals. I don't think it's practical or practicable14:54
cdentbut it is food14:54
dhellmannit feels to me like jay misses randy bias' "contributions" to the community14:55
dhellmannI haven't read the 2nd post yet though, so maybe there's more substance there14:55
scasit's a great thought exercise, and is in-line with the open source mindset. i think if applied, it would send all sorts of signals, not all intended14:58
fungistill reading scrollback, but i like the idea of not requiring releases for maintenance-mode projects (maybe that tag should come with its own release model of the same name?) and allowing any atc to volunteer for ptl even if they're not an apc (the extreme low number of commits could mean there was no particular reason for a developer who cares about the project to need to get a commit merged to it)14:58
fungior put another way, if a project has almost no commits then the pool of candidates for ptl is remarkably constranied14:59
dhellmannwe already have a release model for projects that don't do a lot of releases, or don't do a release every cycle.14:59
scas<--14:59
scaschef is in one of those grey areas of release models. one 'coordinated' release a cycle is what i strive for, with incremental updates to the stable branches as folks consume the next release15:01
scasin practice, without a team all working toward that goal, work really doesn't start until packages are GA15:02
scasof course, the word 'release' is somewhat loaded. what i consider 'released' is 'on supermarket', which is different than someone else's interpretation15:04
*** e0ne has quit IRC15:16
persiadhellmann: Maybe when projects go into maintenance mode, part of that process should be a review of the release model with the release team?15:19
dhellmannsure, that makes sense15:20
*** e0ne has joined #openstack-tc15:20
openstackgerritDoug Hellmann proposed openstack/constellations master: import zuul job settings from project-config  https://review.openstack.org/59173915:23
openstackgerritDoug Hellmann proposed openstack/constellations master: switch documentation job to new PTI  https://review.openstack.org/59174015:23
*** jungleboyj has joined #openstack-tc15:32
jaypipesdhellmann: at the end of the second blog post, I'm pretty clear that what I'm describing isn't "OpenStack v2". It's a completely different thing, with little to no connection to openstack other than learning some lessons in what not to do by building a giant marketing hype machine.15:36
dhellmannI haven't had a chance to read that yet.15:37
jaypipesdhellmann: it was originally about fixing architectural issues. but, sorry, I just don't think openstack is able to overcome its existing weight and change fundamental directions from an architectural perspective.15:39
jaypipesdhellmann: too much legacy. too much vendor input. too little focus on a small footprint and small scope.15:40
jaypipesperhaps Randy Bias hit on too many truthful points...15:43
*** e0ne has quit IRC15:52
*** cdent has quit IRC15:58
*** jpich has quit IRC16:38
*** ricolin has quit IRC17:05
*** rosmaita has quit IRC17:05
openstackgerritDoug Hellmann proposed openstack/constellations master: use python3 in tox  https://review.openstack.org/59178617:09
*** zaneb has quit IRC17:45
*** eandersson has joined #openstack-tc17:46
*** dtantsur is now known as dtantsur|afk18:15
*** annabelleB has quit IRC18:25
*** annabelleB has joined #openstack-tc18:29
*** diablo_rojo has joined #openstack-tc18:46
*** annabelleB has quit IRC19:06
*** zaneb has joined #openstack-tc19:22
*** e0ne has joined #openstack-tc19:23
*** e0ne has quit IRC19:26
*** e0ne has joined #openstack-tc19:27
*** annabelleB has joined #openstack-tc19:37
zanebok I finished part 219:44
zanebjaypipes: I'm impressed that you actually managed to require more external dependencies than Nova v1 has :P19:44
*** jaosorior has quit IRC19:45
*** cdent has joined #openstack-tc19:53
jaypipeszaneb: yes, three is indeed onerous.19:54
zanebjaypipes: if I were to write a similar blog post I would use FoundationDB for everything19:55
cdentif _I_ were to write a similar blog post I would persist as little as possible19:58
*** jaosorior has joined #openstack-tc19:58
jaypipeszaneb: not having SQL for relational data just means you end up writing joins in memory.19:59
jaypipeszaneb: but it's fine for certain types of data.19:59
jaypipeszaneb: also, not being able to do aggregate querying on highly relational data like usage tables is just choosing the wrong tool for the job, IMO.20:00
zanebjaypipes: they reportedly had a layer (unfortunately not open sourced) that was on-the-wire-compatible with postgres. in theory there's nothing you can do in sql that you can't do in FoundatoinDB20:00
jaypipeszaneb: why not cockroachdb if you want distributed SQL?20:00
jaypipesit's PG-compatible (mostly)20:01
zanebbecause you can also do simpler stuff without needing to implement a full-on SQL layer20:01
zaneblike queues20:02
zanebwhich don't go well in an SQL DB in my experience ;)20:02
jaypipeszaneb: pretty sure I've never recommended writing a queue using a SQL db.20:03
jaypipescdent: you gotta put data somewhere, right? :)20:04
zanebjaypipes: right, but I'm saying FoundationDB could potentially replace all of the DB, queue, and etcd components. whereas cockroach can probably only replace the DB part which leaves us back where we started20:04
jaypipeszaneb: it's not a "DB" I need. It's SQL.20:04
jaypipeszaneb: if all I need is a "DB", I'll use etcd for it.20:05
zanebok, the SQL, key-value store, and queue components20:05
jaypipeszaneb: i.e. I want to use the right tool for the job.20:05
jaypipeszaneb: I would imagine that if you used foundationdb as your only data store, you'd run into the same kinds of square-peg-round-hole problems that *both* Nova and k8s have exhibited.20:06
jaypipeszaneb: Nova in the case of being too reliant on a relational SQL DB for everything and k8s for thinking a k/v store (transactional even) is the right tool when you need to perform aggregate querying and calculations.20:07
zanebmaybe20:08
zanebit'd certainly be a lot easier to argue for if they'd open sourced the SQL layer20:08
jaypipeszaneb: but if you're telling me foundationDB "has it all", then I'd consider it. but from what I can gather, it's not a real SQL database.20:08
zanebbut everything I've read suggests to me that this is basically what AWS is doing with Dynamo20:09
jaypipeszaneb: sorry, not following you... by "that this" you mean putting a SQL layer on top of a distributed K/V store?20:11
zanebdon't know about an SQL layer, but it appears to me that all of AWS runs on Dynamo20:12
jaypipeszaneb: because that ain't new by a long shot :) facebook's been doing that for years with rocksdb and myrocks (http://myrocks.io/)20:13
jaypipeszaneb: oh, you mean AWS has been dogfooding itself with Dynamo.. yes, true dat20:14
zanebit's a confusing topic to discuss because AWS also now has a product called DynamoDB that makes (parts of?) Dynamo available to end users20:16
cdentjaypipes: data either goes in ram/cache or $some_layer_above that cares20:32
cdentjaypipes: also, there would be infinite resource classes20:32
jaypipescdent: heh20:36
*** jaosorior has quit IRC20:56
*** diablo_rojo has quit IRC21:05
*** annabelleB has quit IRC21:23
*** annabelleB has joined #openstack-tc21:38
*** cdent has quit IRC21:59
*** e0ne has quit IRC22:39
*** annabelleB has quit IRC23:54

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!