| *** harlowja has quit IRC | 00:23 | |
| *** annabelleB has quit IRC | 00:31 | |
| *** annabelleB has joined #openstack-tc | 00:36 | |
| *** ricolin has joined #openstack-tc | 00:42 | |
| *** annabelleB has quit IRC | 00:49 | |
| fungi | tc-members and everyone else, it's office hour once again | 01:03 |
|---|---|---|
| fungi | as of 4 minutes ago | 01:04 |
| mnaser | fungi: quiet one | 01:19 |
| fungi | so it seems | 01:19 |
| mnaser | We probably should look into changing this slot hour | 01:20 |
| fungi | it was originally chosen to be a time when the americas and asia have overlap, so i don't know how much we can shift it if we want to keep that property | 01:23 |
| *** gouthamr has quit IRC | 01:23 | |
| fungi | it's already late enough that most of the tc members in the americas don't chime in so pushing it later is unlikely to help that | 01:24 |
| fungi | but if your point is that our bulk of tc members in north america aren't around anyway and none of the apac community members take advantage of it, i agree it's been fairly unsuccessful at its purpose | 01:32 |
| jbryce | Based off some of the conversations I had at the recent OpenStack days, I'm not sure many of the apac community members know about it or understand how it's supposed to work | 01:46 |
| fungi | that's excellent to know, thanks jbryce! | 01:47 |
| fungi | suggests we should do a better job of communicating that | 01:47 |
| jbryce | Yeah I tried to communicate it in my conversations. Happy to think about ways we can help get the message out | 01:48 |
| fungi | it gets mentioned in every weekly summary from the tc chair, for example | 01:48 |
| fungi | suggests maybe those aren't interesting enough for them to read either | 01:49 |
| fungi | or that the messaging around it could be more welcoming | 01:49 |
| jbryce | Well some of them definitely do and follow it all extensively (e.g. were more up to date than I was since I'd been on the road for 2 weeks) | 01:50 |
| jbryce | I'll try to find some of the contacts and maybe get additional input | 01:51 |
| fungi | that'll be a great help. thanks again! | 02:00 |
| fungi | and i guess the hour is up | 02:00 |
| lbragstad | this is just my own recent experience, but having just made a trip to china i got to experience connectivity hurdles first hand | 02:27 |
| lbragstad | it might be that people are aware, but being present is difficult (totally depending on locality) | 02:28 |
| *** gouthamr has joined #openstack-tc | 02:36 | |
| *** edmondsw has quit IRC | 02:45 | |
| *** edleafe has quit IRC | 02:46 | |
| *** diablo_rojo has quit IRC | 03:34 | |
| *** Bhujay has joined #openstack-tc | 04:16 | |
| *** edleafe has joined #openstack-tc | 05:03 | |
| *** diablo_rojo has joined #openstack-tc | 06:33 | |
| *** gagehugo has quit IRC | 06:49 | |
| *** tosky has joined #openstack-tc | 07:13 | |
| *** jpich has joined #openstack-tc | 07:20 | |
| *** dtantsur|afk is now known as dtantsur | 07:22 | |
| *** gagehugo has joined #openstack-tc | 07:26 | |
| *** evrardjp has joined #openstack-tc | 07:26 | |
| *** tosky has quit IRC | 07:43 | |
| *** tosky has joined #openstack-tc | 07:43 | |
| *** e0ne has joined #openstack-tc | 08:01 | |
| *** cdent has joined #openstack-tc | 08:31 | |
| *** diablo_rojo has quit IRC | 08:48 | |
| *** tosky has quit IRC | 08:59 | |
| *** tosky has joined #openstack-tc | 09:00 | |
| *** ricolin has quit IRC | 09:04 | |
| *** ttx has joined #openstack-tc | 09:17 | |
| ttx | beh, this +r stuff makes netsplitting a bit harder | 09:18 |
| ttx | zaneb: good question, right? | 09:19 |
| ttx | fungi: It's in the context of my comment on the TC vision review. Should we encourage or discourage (theoretical example) Glance to depend on Mistral because it needs workflows ? | 09:20 |
| ttx | Traditionally I thought we should encourage, as a way to avoid overlap and duplication of code... but with more components being reused standalone, those dependencies between OpenStack components are a bit onerous | 09:21 |
| ttx | So that is something we might want to specifically address in the vision | 09:21 |
| ttx | I /think/ we should avoid those: like if Nova needs a queue it should use RabbitMQ rather than Zaqar, but the right answer may be more subtle (like dependencies are OK as long as you depend on "inner layers") | 09:26 |
| ttx | but that is yet another full can of worms | 09:26 |
| *** tobberydberg has joined #openstack-tc | 09:31 | |
| *** jaosorior_ has quit IRC | 10:05 | |
| cdent | those are good questions ttx, and really get at the root of the need for a vision: | 10:22 |
| cdent | are we creating a cloud solution (in which case the dependencies are required, important, useful) that _can_ be used in isolation. Or are we creating isolated pieces (which may wish to eschew dependencies) that _can_ be used to make a cloud. | 10:23 |
| *** ricolin has joined #openstack-tc | 10:23 | |
| cdent | we keep saying in the mission and in this new draft vision that it is balanced towards the former, but we operate like it is the latter | 10:23 |
| cdent | the point of the vision is to drive change in how we operate | 10:24 |
| cdent | s/point of/activism in/ | 10:24 |
| ttx | I wonder if we could/should discourage operational dependencies while fostering user-facing complementarity | 10:36 |
| ttx | i.e. Glance should not depend on Mistral (but could leverage an oslo lib that provides that functionality), but users should be able to benefit if both end up being available. | 10:38 |
| ttx | Thin line to walk on admittedly | 10:38 |
| ttx | But it's a more interesting angle than "IaaS or more" imho | 10:39 |
| cdent | I think it depends very much on what we're trying to create. That remains the core disagreement. If we still have a large body of people (and those people "win" or "matter") who think it is something other than "a working cloud" zaneb's work is for naught. | 10:42 |
| cdent | to be blunt about it | 10:42 |
| tosky | ttx: re netsplit, if you use SASL to connect instead of nickserv to authenticate, it should work better | 10:44 |
| *** jaosorior has joined #openstack-tc | 11:15 | |
| *** edmondsw has joined #openstack-tc | 11:33 | |
| jroll | cdent: it also depends how we define "a working cloud", right? is it "I can boot a boring VM" or is it "I can deploy $cloud_native_application" or is it "I have 50 different high level services like AWS"? | 11:51 |
| cdent | jroll: of course, but at least as I've understood it "boot a boring vm" has been discounted from "working cloud" by the draft vision | 11:53 |
| cdent | your comment gets rather to the root of the point being made | 11:54 |
| jroll | nod | 11:54 |
| jroll | I shamefully have not read that yet, is on my list for today | 11:54 |
| *** mriedem_away is now known as mriedem | 11:54 | |
| cdent | it's good food for thought. I'm not sure, based on these points, if it can realistically survive, as is. Which is a bit of a concern. | 11:55 |
| *** mriedem has left #openstack-tc | 11:57 | |
| *** mriedem has joined #openstack-tc | 11:57 | |
| *** mriedem has quit IRC | 12:01 | |
| *** mriedem has joined #openstack-tc | 12:01 | |
| smcginnis | I've had a vague thought in the back of my mind for cinder on the "we're building a cloud" vs the "we're building infrastructure automation that can be used in a cloud" thing. | 12:19 |
| smcginnis | Where I need to figure out if there is some sort of dividing line in concerns in Cinder and whether it would make sense to split it (at least internally) into two parts. | 12:20 |
| smcginnis | One that is solely a base SDS controller that anything that needs to programmatically manage storage can use. | 12:20 |
| smcginnis | Then a layer on top of that that is purely the orchestration and bits that are needed to make that a "cloud" component. | 12:20 |
| smcginnis | With standalone Cinder, usually the lower layer is just needed. But that causes some conflicting concerns with those that just want to make the higher layer. | 12:21 |
| jroll | so basically split cinder-volume out and give it a nice http api? | 12:21 |
| smcginnis | Yeah, something along those lines. | 12:22 |
| jroll | obviously simplified :) | 12:22 |
| cdent | that seems to be an openstack-developer phase: let's take this thing, whatever it is, and pull out the guts to a thing, and put the orchestration in this other thing above | 12:22 |
| smcginnis | There has been some work by Gorka to make a wrapper for the drivers to be used as a lib, but I think that's too lower level. | 12:22 |
| cdent | I reckno it is a pretty good impulse | 12:22 |
| smcginnis | There's certainly value for end consumers for both "a common storage API" and for "a cloud storage API". | 12:24 |
| ttx | smcginnis: to take a horrible example, would you rather have Glance depend on Cinder, or Glance depend on a cinder-lib that lets you use drivers directly ? | 12:24 |
| smcginnis | At that point, I think the lib. | 12:25 |
| *** rosmaita has joined #openstack-tc | 12:25 | |
| ttx | but if you split cinder-volume, you could see it as depending on that internal service? | 12:25 |
| smcginnis | Just like for standalone cinder, it would make that a lot simpler if we could have a keystone lib that gets conditionally pulled in to be able to do auth without an entire separate service. | 12:25 |
| smcginnis | Yeah, I think dependencies on the lower level service are fine. I would still consider it a deliverable for other projects or consumers, inside or outside of OpenStack, to consume. | 12:26 |
| ttx | yes, the duality of services being used by users and other services creates that tension in terms of dependencies | 12:27 |
| ttx | (users meaning humans or cloud applications) | 12:27 |
| cdent | speaking of pulled in without separate service, did you see, smcginnis, the PlacementDirect thing I referenced in a respons to tbarron (sic?). It's very hacky, but does that with a potentialy resuable strategy | 12:27 |
| smcginnis | cdent: Yeah, that seems like something similar along these lines. Maybe that's one of the subconscious things feeding into my thought on this. | 12:28 |
| * ttx ignores channel for a minute to read Doug's post | 12:28 | |
| smcginnis | ttx: It could cause some tension in terms of dependencies, depending how it's done. | 12:28 |
| tbarron | cdent: smcginnis: also thinking about manila as open infrastructure that can run in full openstack or not, and with or without keystone if "standalone" | 12:30 |
| tbarron | cdent: so yeah, I want to learn about placement as library and as lightweight service ... | 12:31 |
| tbarron | smcginnis: and keystone :) - and maybe alternate versions of keystone middleware | 12:32 |
| smcginnis | tbarron: I would think (especially knowing history) there would be a lot of overlap in things between cinder and manila as far as standalone needs. | 12:32 |
| tbarron | smcginnis: agree | 12:32 |
| cdent | tbarron: are you familiar with my placement in a container blog posts (I forget if I mentioned those)? | 12:33 |
| tbarron | smcginnis: I think the main difference is that manila doesn't serve up storage through hypervisor but over a network so | 12:34 |
| tbarron | smcginnis: we really don't care if the consumer is a VM or e.g. a baremetal host for container workloads | 12:34 |
| smcginnis | Yeah, otherwise very similar in needs and operation otherwise. | 12:34 |
| tbarron | cdent: no, pls share them with me | 12:34 |
| cdent | tbarron: this has links to most of them https://anticdent.org/placement-container-playground-6.html and links to various github and dockerhub stuff | 12:35 |
| tbarron | cdent: thanks | 12:35 |
| cdent | tbarron: if you've got questions or comments about any of that stuff, os-dev list, #openstack-placement or comments on the post themselves is all good | 12:53 |
| tbarron | cdent: kk, thanks | 12:54 |
| dims | o/ | 13:15 |
| *** Bhujay has quit IRC | 13:21 | |
| *** gouthamr has quit IRC | 14:00 | |
| ttx | tc-members: we need volunteers for the Berlin Forum topics selection committee! Ideally two people who are not up for reelection | 14:08 |
| cdent | i'm happy to do that ttx, but am also happy to not, if people are clamoring | 14:09 |
| smcginnis | Same here. | 14:09 |
| cdent | i'm not just happy, I might even like to do it | 14:09 |
| ttx | so.. cdent dims mugsie mnaser smcginnis ttx zaneb | 14:09 |
| smcginnis | Do we also want to try to avoid people that will also be proposing topics? I suppose given this group that is not likely to work though. | 14:10 |
| fungi | tosky: interesting anecdote... yesterday freenode rebooted the server to which i was connected, so i issued a /reconnect rather than wait 30 seconds for auto-reconnect. when my client connected to the new server there was a sasl auth timeout reported and then i was shunted to the unregistered channel. doesn't always seem to help (though i should figure out what setting i'm missing to make it abort and | 14:10 |
| fungi | retry if sasl auth fails) | 14:10 |
| mugsie | ttx: I can help with selection | 14:10 |
| ttx | More volunteers than seats ! Perfect. | 14:10 |
| ttx | The job is generally more to find the right mix of parallel sessions (too many and you miss stuff, too little and you miss stuff) | 14:12 |
| fungi | cdent: i don't read the vision as implying "boot a boring vm" isn't expected to work, just that we should prioritize other things over making boring vm lifecycle maintenance and featureset more robust | 14:12 |
| ttx | there is /some/ amount of "selection" as a result, but not too much | 14:12 |
| cdent | fungi: of course it has to work | 14:12 |
| cdent | I said "discounted" meaning exactly what you've said, not "not work" | 14:13 |
| tosky | fungi: uhm, I had a disconnection today and the freenode reconnection worked, while on oftc (not SASL) I could not reenter few channels because I was not identified (yet) | 14:13 |
| zaneb | mnaser: Zaqar has a Redis driver, and it's kind of the recommended default now I think. possibly it only depends only on the still-open core part, but I don't know | 14:14 |
| *** efried is now known as efried_goatin | 14:14 | |
| fungi | yeah, the redis components i saw listed as getting the new non-commercial-use license clause looked like plugins/extensions | 14:16 |
| fungi | cdent: got it. "discounted" could have several meanings in that context | 14:17 |
| zaneb | cdent: I wouldn't say 'for naught'. I have a particular opinion about what I think OpenStack should be, but if the outcome of the vision exercise is that we all agree I'm wrong then that's still success IMO | 14:17 |
| evrardjp | I thought the relicensing of redis didn't matter for client side | 14:18 |
| cdent | zaneb: agreed, somewhat. I guess my own bias, and to some extent frustration, is showing: If your very positive and thoughtful work is going to get somehow vetoed by minority conservatism and unwillingness to think in terms of the (much) wider community I'm a bit...ugh, fine, whatever | 14:20 |
| cdent | If I excise that frustration I _completely_ agree with you that the exercise of merely discussing it is a very positive thing. | 14:21 |
| zaneb | evrardjp: that is correct, but it's also no longer open source. so as fungi said, when distros start dropping it we don't really have the option to e.g. test it any more | 14:27 |
| evrardjp | oh so they didn't update the page on redis.io yet | 14:28 |
| *** annabelleB has joined #openstack-tc | 14:29 | |
| fungi | though also if any of our software depends on features provided by those bits then we're basically saying people who want to deploy the software we're writing also have to deploy this other software along with it which doesn't meet the same standards of software freedom | 14:30 |
| zaneb | presumably distros will keep the open core part around and just drop the proprietary bits, so a lot depends on whether we rely on those bits | 14:30 |
| fungi | yep | 14:30 |
| evrardjp | ok that was my understanding too. | 14:31 |
| evrardjp | thanks for the clarification | 14:31 |
| zaneb | http://antirez.com/news/120 implies that the stuff being relicensed was previously AGPL | 14:34 |
| tosky | zaneb: that's an example of one module; it's not clear to me if the other relicensed modules were internal only previously | 14:37 |
| zaneb | yes, he sneakily glossed over that | 14:38 |
| cdent | it's all a bit messy, but I can very much appreciate the motivation | 14:40 |
| cdent | it's frustrating when companies making billions off the back of open source without sufficiently providing resources to help it be healthy | 14:40 |
| * cdent experiences irony | 14:40 | |
| *** annabelleB has quit IRC | 14:42 | |
| *** annabelleB has joined #openstack-tc | 14:48 | |
| *** gilfoyle has joined #openstack-tc | 14:54 | |
| fungi | yeah, the agpl ones being relicensed is the bigger impact. saying that agpl3 is more closed than apache2+noncommercial is a stretch | 14:55 |
| fungi | debian was willing to carry agpl software in its main component set | 14:55 |
| fungi | but that "commons clause" is decidedly not going to meet dfsg or count as osi approved | 14:56 |
| jroll | it's pointed out to me that these are out of tree, plugin-style modules being relicensed | 14:58 |
| *** tonyb has quit IRC | 15:04 | |
| *** efried_goatin is now known as efried | 15:06 | |
| persia | "open" vs "closed" is not a continuum, but rather a collection of individual bits ("can one do foo"). Comparing that to what one wishes to do results in a boolean result, but folk with different wishes end up with different results. I know of groups that feel GPLv2 is "more open" than Apache2.0, because one of the things they want to do is retain the ability to enforce patents over released code. Other groups feel Apache2.0 is "more open" than | 15:13 |
| persia | GPLv2, because one of the things they want to do is retain the ability to ship binaries for which the source is not disclosed. To each their own. For redis, the interesting question should be "are the components used compatible with OpenStack licensing", rather than trying to declare if they are open or closed. | 15:13 |
| corvus | ttx: i added a proposal for a gertty lightning talk to https://etherpad.openstack.org/p/PTG4-postlunch | 15:15 |
| corvus | (that was scheduled for dublin but was snowed out) | 15:15 |
| * mugsie <3 gertty | 15:16 | |
| *** annabelleB has quit IRC | 15:28 | |
| *** openstackgerrit has quit IRC | 15:31 | |
| dhellmann | smcginnis : if you're thinking about splitting cinder's inner functions and orchestration, I wonder if we want to consider doing that with a higher level orchestration tool instead; moving some of that orchestration complexity into 1 service that talks to many simplified backend services may actually simplify the orchestration because then 1 thing has all of the state | 15:35 |
| dhellmann | ttx: keep in mind I oversimplified some of the history for the original non-openstack audience | 15:36 |
| *** efried has quit IRC | 15:36 | |
| smcginnis | dhellmann: Yeah, that could also address some of the needs for cross service orchestration that nova has been trying to remove (boot VM from volume, etc). | 15:37 |
| smcginnis | Still just some half formed thoughts in my mind right now though. | 15:37 |
| dhellmann | yeah, that's exactly what I was thinking of. | 15:39 |
| zaneb | smcginnis: is there some overlap between what you're suggesting and the idea of making the compute node a single project with its own API? | 15:41 |
| zaneb | not so much the single project part, but the giving the part that runs on the compute node its own API sounds similar | 15:42 |
| smcginnis | Except when you don't want compute but containers probably. | 15:43 |
| smcginnis | I always shy away from anything that in compute focused, even if that is the majority use case. | 15:43 |
| *** annabelleB has joined #openstack-tc | 15:44 | |
| smcginnis | But I still think some of this work would need to be done in Cinder. Because there are expectations now of what Cinder is, but like a lot of these conversations it's dependent on context - is it a storage IaaS API or is it a cloud storage service. | 15:46 |
| cdent | is it accurate to say that a cloud storage service needs access to a storage IaaS? | 15:48 |
| smcginnis | I think that's almost always the case. | 15:50 |
| dhellmann | sure, the transition would need to include work in both places. I'm just thinking about the end-state. | 15:51 |
| smcginnis | I see possible value in both a two-layer Cinder model as well as a higher level orchestration (porcelain?) service. | 15:52 |
| mnaser | i like the two layer cinder model idea | 15:56 |
| mnaser | smcginnis: maybe nova-compute would even avoid having a zillion duplicated image backend drivers and rely on a cinder-volume service on the same machine with local storage | 15:57 |
| smcginnis | mnaser: That could definitely be a benefit of it too. | 15:57 |
| *** gilfoyle has quit IRC | 15:59 | |
| *** diablo_rojo has joined #openstack-tc | 16:02 | |
| zaneb | mnaser++ | 16:19 |
| *** annabelleB has quit IRC | 16:23 | |
| *** masayukig has quit IRC | 16:28 | |
| * notmyname notices questions about "cloud storage services" relying on "storage IaaS" | 16:34 | |
| ttx | corvus: if it is 5min we could pre-schedule it on the Friday... See currently-proposed agenda at http://lists.openstack.org/pipermail/openstack-tc/2018-August/001533.html | 16:38 |
| * smcginnis isn't going to get into semantics and opinions on what is "cloud storage" :) | 16:38 | |
| notmyname | smcginnis: what is the "two layer cinder model"? | 16:38 |
| ttx | Alternatively you could check with aspiers and diablo_rojo that youwould all fit within 30min | 16:38 |
| ttx | corvus: ^ | 16:39 |
| corvus | ttx: yes, 5m is all i need | 16:39 |
| ttx | since it would be in the "tools" theme | 16:39 |
| smcginnis | notmyname: I just mentioned earlier that I had some thoughts bouncing around for a little while now of making a logical split within Cinder between two competing concerns. | 16:39 |
| smcginnis | notmyname: Part of the overall "what is OpenStack" debate too. | 16:39 |
| notmyname | smcginnis: what are those two concerns? (I'm just trying to get my head around the conversation) | 16:39 |
| smcginnis | notmyname: There are some that want it to be cloud only, while there are some, certainly within cinder, that want API enabled storage that can be used to build a cloud. | 16:40 |
| *** jpich has quit IRC | 16:40 | |
| smcginnis | notmyname: So my thought was to look at how we can have a lower-layer cinder that addresses the full API-enablement of storage management so that part can be used for any need where you need programmatic control of storage. OK, block storage. | 16:41 |
| ttx | corvus: let me know what works best for you | 16:41 |
| smcginnis | notmyname: And then a higher level layer that provides the granularity wanted for building a block storage component of a cloud. | 16:41 |
| ttx | (Friday or negotiate 5min in the "tools" segment Tuesday) | 16:41 |
| notmyname | smcginnis: is that lower layer component the thing that implements/provides block storage? ie traditionally what's provided by lvm or vendors? | 16:42 |
| *** annabelleB has joined #openstack-tc | 16:42 | |
| smcginnis | notmyname: No, not the storage devices themselves. That's still up to Ceph, LVM, vendor array, etc. | 16:42 |
| smcginnis | notmyname: But it would provide that interface that abstracts managing all those different kinds of storage in a somewhat consistent way. | 16:43 |
| corvus | ttx: i feel like diablo_rojo and aspiers probably could use the fully alloted time and i wouldn't want to try to squeeze another talk in, so i'd advocate for friday. however, if i'm mistaken and in fact we need more content for tuesday, that would be fine with me. | 16:43 |
| smcginnis | So if someone needed to build storage into, for example, their enterprise change control system or something, they could use that level. | 16:43 |
| ttx | ok, I'll pack as appropriate, thanks for the flexibility | 16:43 |
| smcginnis | And if they are building an OpenStack powered cloud, they can use the cloud-focused higher level. | 16:44 |
| smcginnis | Anyway, just some completely unbaked thoughts I've had. | 16:44 |
| ttx | it was part of the "should we encourage dependencies between openstack projects or discourage them" debate | 16:45 |
| dhellmann | mnaser , smcginnis , zaneb : I still like the idea of 1 service on a node to manage all of its resources, instead of having to run N different daemons | 16:45 |
| notmyname | smcginnis: hmm... ok, thanks. I'll admit I don't really follow that thought train yet. I don't really get the two different levels of abstraction, one on the other | 16:46 |
| notmyname | smcginnis: but I'm ok with not understanding yet and knowing that you're a lot closer to the problem and have thought a lot more about it | 16:46 |
| notmyname | smcginnis: but you know, my interest in piqued whenever I see the words "cloud" and "storage" in close proximity :-) | 16:47 |
| dhellmann | notmyname : I see it as a separation between the simple "give me a volume" stuff and the more complicated "launch a VM from a snapshot and make 3 volumes at once" | 16:47 |
| smcginnis | :) | 16:47 |
| smcginnis | notmyname: If I ever spend the time to get the ideas more fully baked I will write it down in a better to consume fashion. | 16:48 |
| notmyname | dhellmann: seems that line of thinking would lead you somewhere similar to removing all orchestration from nova and having it in somewhere like heat. nova only gives a VM. cinder only gives a volume. heat is the only thing that can put them together | 16:50 |
| cdent | notmyname: there are some N>1 people who definitely fantasize about that | 16:51 |
| notmyname | cdent: we probable need to know "what *is* openstack" first. you know, maybe it's layers or circles or core/not-core. probably would be pretty simple to figure that out first, then reorg the projects to fit ;-) | 16:54 |
| notmyname | oh! tents of various sizes! | 16:54 |
| smcginnis | Welcome to the campground. | 16:55 |
| notmyname | smcginnis: and to abuse the metaphor (but sortof accurately capture some of the previous discussions)... "but I want my latrine right where your tent is!" | 16:56 |
| smcginnis | Hah | 16:56 |
| zaneb | dhellmann: I still like that idea too, but maybe it needs to be adjusted to take into account that something like k8s could use e.g. the storage part of it directly and bypass the current Cinder REST API, and therefore it might be helpful for it to at least be modular | 16:56 |
| zaneb | also I'm not sure if containerised deployments means having different daemons offers security benefits or if it's just a PITA having different daemons | 16:59 |
| *** e0ne has quit IRC | 17:07 | |
| *** ricolin has quit IRC | 17:21 | |
| *** mtreinish has quit IRC | 17:25 | |
| *** EmilienM has quit IRC | 17:25 | |
| *** dims has quit IRC | 17:25 | |
| *** corvus has quit IRC | 17:25 | |
| *** jeblair has joined #openstack-tc | 17:30 | |
| *** EmilienM has joined #openstack-tc | 17:30 | |
| *** dims_ has joined #openstack-tc | 17:35 | |
| *** jeblair is now known as corvus | 17:41 | |
| fungi | part of my struggle in the "what is openstack" debate is that to me at least openstack is not a product. it's a community of people building complimentary tools and services. that's easy to see in how we operate and interact, but much harder to market and explain to the world | 17:49 |
| fungi | soylentstack is people! | 17:52 |
| scas | obligatory: openstack is not a product, it's a people | 17:52 |
| scas | my cat odin might have said it | 17:52 |
| *** mtreinish has joined #openstack-tc | 17:52 | |
| fungi | i'm also convinced that "what is openstack?" and "what do we want openstack to be?" are related but separate questions | 17:54 |
| cdent | that latter is certainly very true | 17:54 |
| fungi | people seem to rarely want to reflect on the current state of what we have because we put so much emphasis on thinking about where we want to go | 17:54 |
| scas | here's a perspective on 'what is openstack?' beyond the metaphysical implications: OpenStack is a cloud computing infrastructure capable of handling | 17:55 |
| scas | big data | 17:55 |
| fungi | most of the confusion, i think, is because everyone seems to want to conflate the two questions, so their answers as to what openstack is tend to be about what they want to build, not what they already built | 17:55 |
| scas | that's from peking university | 17:56 |
| cdent | I think there are plenty of people who ack that we are "a community of people building complimentary tools and services" but also think "that's simply not good enough in terms of focusing energy" | 17:56 |
| scas | i would consider it an 'out looking in' perspective | 17:56 |
| cdent | the desire to use energy more effectively is what keeps the "what is" or "what will it be" question coming back round again and again | 17:57 |
| fungi | sure, but a grasp of what it is we are already is necessary for any realistic idea of what we want to change | 17:57 |
| cdent | yeah, totally agree | 17:58 |
| persia | The desire to use energy more efficiently, where "energy" is defined as "contributor time and attention", is masked by the assertion that "openstack" carries "direction". One of the key elements of the governance model of openstack is that direction comes from contributing orgs, which makes the allocation of resources a distributed problem. | 18:04 |
| persia | Neither the TC nor the Board is empowered to say "work on X", and none of the contributing orgs is obliged to commit explicit quantities of resources in such a way that allocation can be planned. | 18:05 |
| cdent | persia, yeah, that would be nice to change too :) | 18:07 |
| cdent | not by fiat, but by agreement | 18:07 |
| dhellmann | zaneb : sure, modularity is good | 18:08 |
| *** dangtrinhnt_x has joined #openstack-tc | 18:08 | |
| *** annabelleB has quit IRC | 18:09 | |
| notmyname | I was only joking when I said we needed to answer the "waht is openstack" question first. it's something that comes up about once a year and is never answered satisfactorily (and I submit will never be answered). recently I've seen more people talking about "openstack as people", and that must be closer to the truth. | 18:11 |
| notmyname | we're a group with different desires and motivations who work together (in the python "we're all adults here" sense) because we see more benefit in working together than woring separately | 18:11 |
| *** mriedem is now known as mriedem_lunch | 18:14 | |
| scas | the outward perception of 'openstack is corporations' is something that weighs down on being able to define 'what is openstack'. as it stands, contributors signify their organizational affiliation. for a great number, that happens to be private sector companies. thus, a perception forms that 'openstack is companies' | 18:14 |
| TheJulia | Could project teams take it upon themselves to help demolish perceptions? | 18:15 |
| persia | cdent: Which way do you want to change it? To grant that authority, to cause the contributing orgs to provide direction, or to educate the general polity that they should be approaching the contributing orgs for guidance? | 18:15 |
| scas | in my past life, it was heavily expounded among the truthseekers that 'X is volunteers' | 18:15 |
| *** ChanServ has quit IRC | 18:16 | |
| persia | TheJulia: Only if the idea that "openstack" is a consolidated thing is first dismantled. Until then, project team messaging is overwhelmed by "openstack" messaging, where "openstack" is a conflation of the community, the foundation, and the technology. | 18:16 |
| scas | ++ | 18:16 |
| TheJulia | ++ | 18:16 |
| cdent | If we're going to demolish something, I'd choose project teams | 18:16 |
| TheJulia | I'm not sure how that would help given trust issues and desires to control... | 18:17 |
| persia | Taking away the ability to control is an excellent way to remove the desire. | 18:17 |
| persia | In other contexts, I've seen removal of authority of individuals to gate used as a means to cause increase in activity. When there is no answer to the question "who can approve foo", things tend to get done faster. | 18:18 |
| cdent | TheJulia: I was mostly being sarcastic: we shouldn't demolish anything, especially given that we have a history of a way of being | 18:19 |
| persia | On the other hand, it does require more folk to care about ensuring there are effective means to ensure that the use cases they care about remain supported: some of this is automated testing, and some is active involvement (to help fix things that are landing before they land). | 18:19 |
| TheJulia | I guess what I was wondering is if teams tried to break the molds they have been et into as part of being explicitly part of openstack. I'm specifically thinking of things like "The Bare Metal Service" instead of saying "ironic" | 18:19 |
| cdent | but if it were possible to rewrite history, I think project divisions are problematic | 18:19 |
| scas | from my foxhole, i've viewed what i do as not a 'project lead' but more of a steward, if anything. it's currently the most appropriate verb right now, for me that is. it's not 'my' code, as evidenced by the extensive copyright claims all over the source, but i look after it for 'the community'. unfortunate as it is, the whole term gets rolled up into 'openstack' right now | 18:20 |
| persia | cdent: Awkwardly, in this context, the project started with an inbuilt us vs. them structure. | 18:20 |
| scas | i'd say the ptl role itself gives false signals of structure. that label itself has had contested meaning lately | 18:21 |
| scas | some groups use it as a means to impose structure, some don't | 18:22 |
| *** ChanServ has joined #openstack-tc | 18:22 | |
| *** barjavel.freenode.net sets mode: +o ChanServ | 18:22 | |
| notmyname | it doesn't matter what the answer is. talking about it is only slightly more beneficial, in that it can breed shared purpose in a group. we're people who work together, sometimes better than others. that's it. "what is openstack" is something that the historians can figure out. the annual navel-gazing debates we have on the topic have probably caused more division than unity, and the discussions certainl | 18:34 |
| notmyname | y haven't resulted in something that matters for apps running in prod | 18:34 |
| persia | I remain unconvinced that the shared purpose matters for the set of "current openstack contributors", most of whom have no authority to control their tasking (and whose activity in attempting to adjust tasking supports the assertion that "one cannot do anything in openstack" that gets passed around certain product management circles). | 18:37 |
| notmyname | the shared purpose only matters for the in-group dynamics and facilitates people working together, not for any sort of "...and therefore here's our prioritized list of tasks" | 18:39 |
| cdent | I don't think your assertion is all that true for heavy contributors persia | 18:41 |
| cdent | plenty of heavy contributors are guessing at what they are supposed to be doing to make things better, from whatever info they have available. their mission from employers is effectively "keep it going, and make us be a presence" | 18:42 |
| persia | cdent: Being fair, it isn't. I'd argue that many of those that fit the exception work for one of a very small number of contributing organisations that have significant experience stewarding open source projects. | 18:42 |
| cdent | who are responsible for a very very large number of the changes to the code | 18:42 |
| persia | On the other hand, I beleive that if the contributing orgs instead said "please enable feature foo", things would go faster, and we wouldn't wonder as much about direction. | 18:43 |
| *** dtantsur is now known as dtantsur|afk | 18:43 | |
| cdent | persia: that may be true, do you want that? | 18:43 |
| persia | I think it would be healthier. | 18:44 |
| notmyname | cdent: are there people who are paid to contribute to openstack and are simply given the mandate of "make it better and participate with our logo"? if so, that's amazing | 18:44 |
| notmyname | cdent: it's not my (limited) experience | 18:44 |
| cdent | in my experience many of the people I've worked with over the past few years (including me) are in a boat like that, but the "it" is more narrow than "all of openstack" | 18:45 |
| smcginnis | There are some with at least some degree of that. | 18:45 |
| persia | notmyname: There are a fairly large number of people who have that mandate. I believe they are responsible for a significant number of code changes. I don't beleive they are a majority. | 18:45 |
| cdent | but there is clear awareness that because we are a group "it" has to expand to be more of openstack | 18:45 |
| notmyname | interesting. (this helps me understand some other things I've seen) | 18:46 |
| persia | Working with organisations that contribute to open source for marketing based reasons, my experience is that having clear direction both makes for happier staff (who either work towards a goal, or argue internally to change goal, rather than being surprised at employer action), and better press (because one can align press releases, various presentations, and other messaging with work actually completed). | 18:47 |
| *** tosky has quit IRC | 18:47 | |
| persia | It is often, but not always, associated with higher development velocity, more complex test suites, and more pressure to avoid tech debt (as each contributing org has a selfish desire to block other org's features if they increase the maintenenace burden for themselves) | 18:48 |
| persia | Whether it is appropriate for OpenStack is another question, of course :) | 18:48 |
| *** mriedem_lunch is now known as mriedem | 18:55 | |
| zaneb | notmyname: speaking for myself only, nobody has ever given me any other instructions | 19:01 |
| zaneb | come to think of it, the 'participate with our logo' part has never come up either | 19:02 |
| persia | zaneb: You're lucky. Most orgs who provide that instruction get very fussy if stackalytics doesn't have the right affiliation. | 19:10 |
| cdent | persia: I gotta say I spend far more time with people like zaneb then these other people you say are so common | 19:15 |
| persia | To me, that's interesting. Orgs that "get it" rarely engage me, so I don't have as much insight there. I have been privy to discussions about ways to get one's openstack developers to register with stackalytics, including bragging about compliance numbers, although not since second Austin. | 19:17 |
| persia | If lots of orgs don't use that to brag, I wonder what they do use, or if "logo" isn't important to some of them. | 19:17 |
| cdent | persia: is it possible that some orgs simple want the product to work well, so they have something worth selling? | 19:19 |
| cdent | and that get that wellness, they need people who are community oriented and invested? | 19:19 |
| persia | cdent: I'd be more inclined to believe that from orgs that provide direction to developers. For example, "here are the problems our product team has identified with our product. Please have them fixed upstream." or "here are our key customer complaints: please have them fixed upstream.". | 19:20 |
| persia | Orgs that both a) want their derived product to work well and b) don't tell the developers what to do seem to me to be lacking in product planning. Without product planning, I'm suspicious of their ability to maintain continuity (as they have no idea what they will be selling). For a very small number of firms that are established in the business of providing liability insurance for the operation of open source, this matters less. That said, I | 19:23 |
| persia | don't believe such insurance firms can help us seek direction, and I don't believe that the project taking direction helps the business of those firms. | 19:23 |
| cdent | persia a thing I hear from my employee is "we'd like it if openstack were more accessible to casual contributors who are unable to attend in the same way that you, chris, are" | 19:23 |
| cdent | as in: make it possible for our field people and third tier support people to be more involved in openstack without it being a horrible experience where they feel like they make no progress | 19:23 |
| persia | Excellent. That's precisely the sort of direction/goal I think contributing orgs can provide. Much more precise than "make it better" or "wave a flag with our logo". Not all folk get such precise direction. | 19:23 |
| cdent | to use the lingo: it's a hard ask | 19:24 |
| persia | Admittedly. Still, better than nothing. If you have access to the folk encountering issues, presumably you can analyse systemic problems and promote policy that adjusts those. | 19:28 |
| cdent | I can engage people who have experience difficulties and try to make some conclusions about causes of those issues | 19:30 |
| cdent | and work to highlight those issues | 19:30 |
| cdent | in the past my naive recommendation has been "spend more time upstream" but that ignores several important issues, the leading (but not only) one being how much engagement is required to have a presence | 19:32 |
| cdent | what has surprised me sometimes is how little people are aware of some of the issues, or at least willing to admit | 19:33 |
| persia | I once spent some time wtih an organisation that wanted everyone on their staff to be part of a specific software community, regardless of their normal activities. This caused a lot of pain. The pain was resolved by a combination of changing the org policy such that only some folk needed to be officially part of the community and others would be assigned clear delegates to help them resolve issues, along with changing the community policy to | 19:33 |
| persia | highlight and reward folk who were observed to be acting as proxies, rather than insisting on the original contributor being involved. | 19:33 |
| *** mriedem has quit IRC | 19:35 | |
| persia | Mind you, this did require funding to hire the delegates, but it ended up that the total time required to resolve things by field engineers + delegates was less than the time previously spent by field engineers, so ended up being considered positive. | 19:35 |
| cdent | yeah, in my situation there are people who used to be considered delegates but gave up | 19:35 |
| persia | The change to the community policies was very much a critical part of the solution I described. Without that side, it ends up being a recipe for burnout for the delegates. | 19:37 |
| cdent | (for a combination of reasons but external (here) and internal) | 19:37 |
| * cdent nods | 19:37 | |
| *** mriedem has joined #openstack-tc | 19:38 | |
| *** rosmaita has quit IRC | 19:40 | |
| *** e0ne has joined #openstack-tc | 19:57 | |
| *** annabelleB has joined #openstack-tc | 20:21 | |
| *** tonyb has joined #openstack-tc | 20:26 | |
| *** e0ne has quit IRC | 20:27 | |
| *** harlowja has joined #openstack-tc | 20:42 | |
| *** annabelleB has quit IRC | 21:11 | |
| *** gouthamr has joined #openstack-tc | 21:11 | |
| fungi | most of my reasons are purely infernal | 21:28 |
| *** annabelleB has joined #openstack-tc | 21:33 | |
| *** dansmith is now known as htimsnad | 21:34 | |
| *** mriedem has quit IRC | 21:55 | |
| *** bodgix has quit IRC | 22:01 | |
| *** annabelleB has quit IRC | 22:27 | |
| *** ChanServ has quit IRC | 22:49 | |
| *** ChanServ has joined #openstack-tc | 23:03 | |
| *** barjavel.freenode.net sets mode: +o ChanServ | 23:03 | |
| *** cdent_ has joined #openstack-tc | 23:41 | |
| *** cdent has quit IRC | 23:44 | |
| *** cdent_ is now known as cdent | 23:44 | |
| *** gouthamr has quit IRC | 23:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!