| *** edmondsw has joined #openstack-tc | 00:07 | |
| *** edmondsw has quit IRC | 00:12 | |
| *** annabelleB has quit IRC | 00:25 | |
| *** ricolin has joined #openstack-tc | 00:32 | |
| *** ianychoi_ is now known as ianychoi | 01:16 | |
| *** edmondsw has joined #openstack-tc | 01:55 | |
| *** edmondsw has quit IRC | 02:00 | |
| *** edmondsw has joined #openstack-tc | 03:43 | |
| *** edmondsw has quit IRC | 03:48 | |
| *** diablo_rojo has quit IRC | 04:02 | |
| *** flwang1 has quit IRC | 05:03 | |
| *** edmondsw has joined #openstack-tc | 05:31 | |
| *** edmondsw has quit IRC | 05:36 | |
| *** edmondsw has joined #openstack-tc | 07:20 | |
| *** edmondsw has quit IRC | 07:24 | |
| *** tosky has joined #openstack-tc | 07:36 | |
| *** jpich has joined #openstack-tc | 07:54 | |
| *** dtantsur|afk is now known as dtantsur | 08:57 | |
| *** edmondsw has joined #openstack-tc | 09:08 | |
| *** edmondsw has quit IRC | 09:12 | |
| *** cdent has joined #openstack-tc | 09:28 | |
| *** dtantsur is now known as dtantsur|brb | 09:55 | |
| *** aprice has quit IRC | 10:10 | |
| *** aprice has joined #openstack-tc | 10:10 | |
| *** ricolin has quit IRC | 10:24 | |
| *** srwilkers has quit IRC | 10:34 | |
| *** srwilkers has joined #openstack-tc | 10:34 | |
| *** edmondsw has joined #openstack-tc | 10:56 | |
| *** edmondsw has quit IRC | 11:00 | |
| *** cdent has quit IRC | 11:34 | |
| *** cdent has joined #openstack-tc | 11:38 | |
| *** edmondsw has joined #openstack-tc | 11:44 | |
| *** cdent has quit IRC | 11:48 | |
| *** cdent has joined #openstack-tc | 11:52 | |
| *** rosmaita has joined #openstack-tc | 12:00 | |
| dims | o/ | 12:53 |
|---|---|---|
| mnaser | Hi everyone ! | 12:56 |
| cdent | o/ | 12:57 |
| pabelanger | o/ | 13:02 |
| smcginnis | Good morning | 13:03 |
| *** mriedem has joined #openstack-tc | 13:18 | |
| *** dtantsur|brb is now known as dtantsur | 13:29 | |
| dhellmann | o/ | 13:45 |
| *** hongbin has joined #openstack-tc | 14:08 | |
| *** annabelleB has joined #openstack-tc | 14:09 | |
| *** edmondsw has quit IRC | 14:23 | |
| *** edmondsw has joined #openstack-tc | 14:24 | |
| *** edmondsw has quit IRC | 14:27 | |
| *** edmondsw has joined #openstack-tc | 14:32 | |
| *** annabelleB has quit IRC | 14:38 | |
| *** purplerbot has quit IRC | 14:49 | |
| *** hongbin has quit IRC | 14:49 | |
| *** hongbin has joined #openstack-tc | 14:49 | |
| *** purplerbot has joined #openstack-tc | 14:49 | |
| *** annabelleB has joined #openstack-tc | 14:58 | |
| *** openstackgerrit has quit IRC | 15:19 | |
| mriedem | here you go tc people http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-07-06.log.html#t2018-07-06T14:34:01 | 15:20 |
| mriedem | an example of (1) what is openstack and (2) why is nova so mean | 15:21 |
| mriedem | as a callback to a discussion a couple of weeks ago | 15:21 |
| mriedem | jaypipes: zaneb: ^ specifically related to your conversation in the ML | 15:21 |
| cdent | _so mean_ | 15:25 |
| zaneb | mriedem: good example. so how can we make those requests go away, other than repeatedly telling people to go away? | 15:25 |
| smcginnis | mriedem: It seems like that particular one should be redirected to Horizon. | 15:29 |
| *** openstackgerrit has joined #openstack-tc | 15:30 | |
| openstackgerrit | Chris Dent proposed openstack/project-team-guide master: Emphasize value of mailing lists https://review.openstack.org/580694 | 15:30 |
| openstackgerrit | Chris Dent proposed openstack/project-team-guide master: Replace out of date reference to cross project meeting https://review.openstack.org/580695 | 15:30 |
| mriedem | smcginnis: or osc | 15:32 |
| mriedem | or something | 15:32 |
| mriedem | shade | 15:32 |
| mriedem | oaktree | 15:33 |
| mriedem | everyting in openlab | 15:33 |
| mriedem | zaneb: idk | 15:33 |
| mriedem | zaneb: either always tell them no, or just bend over and do it | 15:33 |
| mriedem | or redirect to some other orchestration thingy that does it for them already | 15:33 |
| zaneb | mriedem: I was thinking along the lines of a clear statement of what Nova is and is not, and how it fits in with other tools (e.g. orchestration) | 15:34 |
| mriedem | that's what i linked into the spec review | 15:35 |
| mriedem | https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-more-orchestration | 15:35 |
| mriedem | even though we clearly bend that rule at times | 15:36 |
| mriedem | with things like the get me a network feature in mitaka | 15:36 |
| smcginnis | Wow, somehow I read that as "get me a network failure" at first. :D | 15:37 |
| openstackgerrit | Chris Dent proposed openstack/project-team-guide master: Emphasize value of mailing lists https://review.openstack.org/580694 | 15:37 |
| openstackgerrit | Chris Dent proposed openstack/project-team-guide master: Replace out of date reference to cross project meeting https://review.openstack.org/580695 | 15:37 |
| zaneb | that doc actually looks pretty good | 15:37 |
| dansmith | fwiw, we've been trying to say no to more orch like this for years, hence writing it down in that document | 15:45 |
| *** mriedem is now known as mriedem_away | 15:45 | |
| dansmith | network ports have a lot more attributes like this, which we're kinda opening ourselves up to if we start doing more of this | 15:46 |
| dansmith | we (openstack) needs to decide if the other projects are really intended to be used like we've been saying (create a volume, pass it to nova) or if nova is really going to be *the* api for everything up to a point | 15:46 |
| zaneb | I'm sure a large part of the problem is that when you open the door to this (which happened years ago and can't be fixed) everyone is going to want to pile on their minor little enhancement | 15:47 |
| dansmith | because if we do this for volumes, I imagine people are going to ask why they have to go talk to neutron themselves...all they want is a port but with a few extra attributes....maaaan. | 15:47 |
| zaneb | dansmith++ | 15:47 |
| smcginnis | There was also the proposal to have some other "openstack api" layer over the top of everything so it's not nova's api and cinder's api and neutron's api - consumers would just interact with "the API" and it would hide all the lower layer stuff. | 15:49 |
| dansmith | either we're a bunch of related but distinct services, or we're not. | 15:49 |
| clarkb | part of the complication with nova and neutron was that nova net "just worked" (tm) | 15:49 |
| zaneb | smcginnis: if we do that we definitely need to call it 'Corona' | 15:49 |
| smcginnis | :) | 15:50 |
| clarkb | and you lost that functionality as a user when clouds upgraded to neutron | 15:50 |
| zaneb | clarkb: was that the same with Cinder vs. nova-volume too? (that part was before my time) | 15:51 |
| dansmith | clarkb: yeah, I'm not saying splitting services and apis was the right thing to do, I'm saying we need to decide at this point | 15:51 |
| clarkb | zaneb: I think that boot from volume was a feature added after the split so no feature parity concerns with that (but I'm not a fan of the boot from volume stuff so not sure if that was there early on) | 15:52 |
| clarkb | dansmith: ya I think it does help inform how we got to where we are today though. And deciding how to move forward is good idea | 15:52 |
| dansmith | aye | 15:52 |
| cdent | ttx, smcginnis : a) thanks, b) that was too easy | 16:14 |
| smcginnis | cdent: Thanks for getting that added/updated. As usually, docs don't ever get enough attention. | 16:15 |
| openstackgerrit | Merged openstack/project-team-guide master: Emphasize value of mailing lists https://review.openstack.org/580694 | 16:21 |
| openstackgerrit | Merged openstack/project-team-guide master: Replace out of date reference to cross project meeting https://review.openstack.org/580695 | 16:24 |
| dhellmann | mriedem_away , dansmith : thanks for those links. I agree that continuing to reiterate the message that we don't want to cram lots of orchestration features into nova may help. Maybe someone would even build those into a layer like oaktree (or a new thing as smcginnis & zaneb mention) | 16:26 |
| dansmith | I don't think it will actually help, but... yeah :) | 16:27 |
| dhellmann | maybe describing what that orchestration layer might look like would encourage someone to start it and relieve some of the pressure | 16:27 |
| dhellmann | dansmith : well, stand strong in the mean time :-) | 16:27 |
| dhellmann | the game is over and it's time for lunch, bbiab | 16:27 |
| zaneb | dhellmann: we actually had to build that orchestration layer inside the OS::Nova::Server resource in Heat and it looks ****in' horrible | 16:28 |
| *** annabelleB has quit IRC | 16:33 | |
| *** dtantsur is now known as dtantsur|afk | 16:37 | |
| *** ricolin has joined #openstack-tc | 16:39 | |
| *** jpich has quit IRC | 16:50 | |
| zaneb | I don't even wanna know how many thousand words that email I just sent was | 16:59 |
| dhellmann | zaneb : I wonder if extracting that stuff into a separate service of some sort makes sense. I haven't looked at the internal architecture of heat in ages. | 17:00 |
| dhellmann | maybe heat just morphs into being the orchestration layer | 17:01 |
| zaneb | dhellmann: maybe. I believe Rackspace did a bunch of stuff where they created Heat templates for common use cases and presented it to customers in the dashboard as if it was an API | 17:01 |
| dhellmann | heh | 17:02 |
| zaneb | down to the point of hiding them from 'stack list' so the users wouldn't know | 17:03 |
| dhellmann | I wouldn't go that far, but having some pre-populated things makes sense | 17:03 |
| *** diablo_rojo has joined #openstack-tc | 17:04 | |
| zaneb | to your other suggestion, I don't think splitting it into a separate service would help with Heat's "inner platform effect" problem. the issue is that an orchestration API needs to have access to everything that is going on. so whatever stealth orchestration Nova/Cinder/Neutron do under the covers we have to deal with/reimplement to handle updates correctly | 17:05 |
| zaneb | e.g. we had to reimplement get-me-a-network to support get-me-a-network with updates | 17:05 |
| dhellmann | hmm | 17:06 |
| zaneb | we reimplement the thing of automagically creating a port so we can keep track of what ports there are | 17:06 |
| zaneb | like I said, horrible | 17:06 |
| zaneb | dhellmann: it's one API call in neutron, so not as bad as it sounds, but we are in fact calling it from Heat and not passing it to Nova | 17:07 |
| dhellmann | I guess there's a good bit of difference between the need for something that manages a resources through it's lifecycle and a thing that orchestrates setting up some resources that are then left to be managed by something else | 17:07 |
| *** smcginnis is now known as smcginnis_afk | 17:08 | |
| zaneb | yep, exactly | 17:08 |
| zaneb | http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resources/openstack/nova/server_network_mixin.py#n366 | 17:09 |
| clarkb | right what we need is something that understands what useful aggregates of primitive resources look like | 17:10 |
| clarkb | that a user facing orchestration tool could talk to | 17:10 |
| *** mriedem_away is now known as mriedem | 17:10 | |
| dhellmann | that sounds a lot like a set of default stacks in heat | 17:10 |
| zaneb | it really does, yeah | 17:10 |
| dhellmann | the tricky part is describing that in a way that we can use for the interop program | 17:11 |
| cdent | zaneb: I just finished those however many thousands of words and had an interesting (to me) reaction: a) I enjoyed reading that, b) i have no idea what to do now | 17:11 |
| cdent | I think (b) is the curse of our current days | 17:12 |
| clarkb | from the network api perspective routers, subnets and networks are basicaully useless as individual resources | 17:12 |
| clarkb | as a user you need all three "wired" together to do anything useful | 17:12 |
| zaneb | cdent: have a beer? it's Friday. | 17:12 |
| * dhellmann slips a link to https://amzn.to/2MTFduU into the conversation | 17:12 | |
| clarkb | I think the api you want is "Give me useable networking" and not "lookup a heat stack published by cloud by default" | 17:13 |
| dhellmann | right, we have some very low level APIs in some places and some higher level APIs in others and we're not consistent across services | 17:13 |
| cdent | dhellmann: yeah, it's a balance. the amount of color zaneb provided by using that many words is important to me. I have what feels like a higher fidelity context. | 17:13 |
| cdent | zaneb: soon on the beer | 17:14 |
| dhellmann | as annoying as neutron's low-level-ness can be, maybe that's actually the right approach | 17:14 |
| zaneb | dhellmann: 256 pages :) | 17:14 |
| dhellmann | cdent : yeah, I haven't read the email | 17:14 |
| cdent | zaneb: in fact I think it's going to be fish and chips and beer on the beach | 17:15 |
| zaneb | I might try turning it into a blog post. interleaving responses with jaypipes probably contributed a lot to the length | 17:15 |
| cdent | that's a good idea | 17:15 |
| zaneb | cdent: that's cruel when you know I'm stuck in a country without decent fish & chips | 17:15 |
| dhellmann | zaneb : does heat have a notion of stacks owned by one project but available publicly? | 17:17 |
| dhellmann | or is everything separated by tenants? | 17:17 |
| zaneb | everything is separated by tenant | 17:18 |
| dhellmann | ok | 17:18 |
| zaneb | unless you are a super-admin, then you can list everyone's stacks | 17:18 |
| zaneb | but you have to turn that on in policy.json | 17:18 |
| cdent | i've often wonder about shareable/reusable stacks | 17:18 |
| dhellmann | that doesn't help with providing default stacks that are just part of the installation of heat itself | 17:19 |
| cdent | zaneb: some people like these fish and chips, say they are very good, but I don't like them. They are cooked in beef dripping, which is on trend, but I think makes for a brick in the belly | 17:19 |
| zaneb | I think we need shareable *templates*, not stacks | 17:19 |
| zaneb | you can always throw those in Swift and make it public | 17:19 |
| zaneb | Glare was going to make that easier, but... :( | 17:20 |
| dhellmann | I guess my idea is that after installing openstack there would be a thing ready to be used, and the user wouldn't have to do anything to import templates or whatever | 17:20 |
| dhellmann | there are probably some implementation details of heat that I'm not familiar with that are leading me to use imprecise wording | 17:20 |
| zaneb | so a stack is what you get after instantiating a template | 17:21 |
| zaneb | so what you want is some sort of standardised template repo | 17:21 |
| dhellmann | maybe? it still feels like that requires an extra step | 17:22 |
| dhellmann | I want to install heat and then call a heat API to instantiate a *server* in a way that requires orchestration | 17:22 |
| dhellmann | I don't want to have to give the cloud instructions for what that looks like | 17:22 |
| dhellmann | if we're going to move orchestration out of nova, it needs to be baked into something else | 17:22 |
| dhellmann | even if that can be extended, a certain amount of minimal functionality needs to just be there | 17:23 |
| clarkb | dhellmann: ya that is what I meant earlire the api needs to be make me a network/VM/high level useable resource. Not lookup the 10 templates to put together to do that | 17:23 |
| zaneb | I could see a thin wrapper service that emulates the current Nova API, assembles a Heat template to do all the behind-the-scenes bits, and then instantiates it in Heat | 17:23 |
| dhellmann | when we had that problem with routers at Dreamhost, we hooked into the account creation process to create some defaults in neutron for the user when they signed up. so I guess that's an option | 17:23 |
| clarkb | the implementation behind the scenes might run those templates for you | 17:23 |
| dhellmann | clarkb : right | 17:23 |
| dhellmann | zaneb : I'm not even worried with emulation. Nova's existing API wouldn't go away for some time, so adding a new one doesn't necessarily need to bring any "baggage" with it | 17:24 |
| dims | like kubevirt? https://github.com/kubevirt/kubevirt/blob/master/cluster/examples/vm-cirros.yaml | 17:24 |
| dhellmann | I don't know, does that do orchestration? | 17:25 |
| dims | kubevirt talks to local libvirt | 17:25 |
| dhellmann | that feels a little lower-level than what we're talking about, then | 17:26 |
| dims | the orchestrator is kubernetes though. for example volumes can be mounted - https://github.com/kubevirt/kubevirt/blob/master/docs/direct-pv-disks.md | 17:27 |
| dims | this probably helps - https://kubernetes.io/blog/2018/05/22/getting-to-know-kubevirt/ | 17:28 |
| dhellmann | I don't really want to throw everything we've done away. I want to consider how thinking differently about what responsibilities we place on each service makes things easier. | 17:28 |
| clarkb | thats also more of a nova net model aiui, you get what is prebuilt for you at the networking layer | 17:30 |
| dhellmann | So saying that we want to stop adding orchestration to nova means we need somewhere else to do it. Not wanting every user to have to implement that means we want it in a reusable service of some sort. Heat is already doing a lot of orchestration work. Can we use that, somehow, and still provide an installation that has a useful minimal set of features without the user having to understand how to import templates to make | 17:30 |
| dhellmann | the cloud do something for them. | 17:30 |
| dhellmann | if not in heat, then is there another place that makes sense? or do we need a new place? and if we make a new place, how does heat also change as a result of that? | 17:30 |
| zaneb | dhellmann: I believe that yes, you could write a pretty small service to do that. I don't believe it belongs in Heat, because it doesn't need access to anything other than Heat's public API | 17:31 |
| dhellmann | cdent : I'm finally getting around to reading https://anticdent.org/some-opinions-on-openstack.html | 17:31 |
| dhellmann | using oslo.config as a global is an anti-pattern, fwiw | 17:31 |
| dhellmann | it's just a very pervasive one | 17:31 |
| dhellmann | zaneb : sure. I guess your comments about having to re-implement existing orchestration features made me think we should look at it from the other way. | 17:32 |
| *** ricolin has quit IRC | 17:35 | |
| zaneb | dhellmann: it's a good idea. we already reimplemented them once in Heat, so why not reuse them rather than do a third reimplementation | 17:35 |
| dhellmann | on the other hand, maybe we'd get it right the third time? ;-) | 17:35 |
| cdent | dhellmann: I can't remember if I wrote on that the context in which those notes were made: I was sitting outside with no electricity and noodling. It was actually pretty much random. So that oslo.config thing was a sort of blip of memory rather than a OMG I HATE OSLO_CONFIG | 17:36 |
| zaneb | cdent: I can't stand all this talk of fish & chips. I'm going to get BBQ for lunch. | 17:36 |
| cdent | 3rd times a charm | 17:36 |
| cdent | zaneb: good choice, that's something I can't get | 17:36 |
| cdent | (at least not _good_) | 17:36 |
| dhellmann | cdent : yeah, we have a global configopts instance mostly to avoid breaking the projects that had that before oslo.config was extracted from the incubator, but none of the other oslo libraries use it so you have to pass a conf object around anyway | 17:37 |
| dhellmann | there's a whole thing about that in the oslo.config docs somewhere | 17:37 |
| * dhellmann steps out to run an errand | 17:38 | |
| cdent | dhellmann: if you have some more respones to that thing, I'd love to hear them (or see them written down somewhere). jaypipes you still planning to write something? | 17:41 |
| *** e0ne has joined #openstack-tc | 17:44 | |
| dims | so fyi to folks, the next thing for k8s<->openstack will an implementation/provider for the "cluster-api" https://github.com/kubernetes-sigs/cluster-api | 17:46 |
| dims | will be a new repo with initial code from https://github.com/kubernetes-sigs/cluster-api/pull/176 | 17:47 |
| cdent | dims: so this is clusters of k8s clusters? | 17:48 |
| dims | yep | 17:49 |
| cdent | cool | 17:49 |
| cdent | so much going on | 17:49 |
| dims | yep | 17:50 |
| cdent | I think I better call it a day before my brain melts | 17:51 |
| * cdent waves | 17:51 | |
| *** cdent has quit IRC | 17:51 | |
| *** e0ne has quit IRC | 17:56 | |
| jroll | I feel the same as cdent about that email | 17:58 |
| jroll | zaneb: thanks for sending that | 17:58 |
| jroll | it very much solidified (for me) where you're coming from with many of the things you've been saying for years :) | 17:59 |
| *** e0ne has joined #openstack-tc | 18:04 | |
| notmyname | zaneb: IMO the key part of your email (holy wall of text, batman!) is the response to the "[nova's competition is] the compute provisioning parts of [public cliuds]" | 18:17 |
| notmyname | zaneb: I agree with your summary there. ("working at cross-purposes") | 18:19 |
| *** e0ne has quit IRC | 18:24 | |
| fungi | zaneb: not to echo what others have said, but i really appreciated the porcelain/plumbing analogy ;) | 18:33 |
| fungi | and we actually have decent fish and chips in the part of the country where i reside, but that's mostly thanks to the ready availability of fresh fish _and_ fresh beer from the brewery who is in the back of the pub using it in their batter | 18:34 |
| fungi | though i ended up getting it on a bun instead | 18:35 |
| clarkb | fungi: I think zaneb is in the same part of the country as you | 18:35 |
| fungi | (i do recall getting a fair amount of terrible fish and chips when i lived in the mountains) | 18:36 |
| fungi | ((on the other hand, bbq in the mountains was stellar)) | 18:38 |
| fungi | clarkb: in the same state, but about 500mi inland and up into a mountain chain | 18:40 |
| fungi | basically where i grew up | 18:40 |
| fungi | before i fled to find civilization, and then fled again to get away from civilization | 18:41 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: write up the python3-first goal https://review.openstack.org/575933 | 18:54 |
| openstackgerrit | Merged openstack/governance master: Add os-acc repository to the governance repository https://review.openstack.org/579079 | 19:25 |
| openstackgerrit | Merged openstack/governance master: Remove release-tools from Release Management https://review.openstack.org/579199 | 19:25 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: add check_review_status.py https://review.openstack.org/579953 | 19:28 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: write up the python3-first goal https://review.openstack.org/575933 | 19:34 |
| zaneb | jroll: me too :) | 19:37 |
| *** flwang1 has joined #openstack-tc | 19:39 | |
| zaneb | fungi: you can get decent pub fish & chips anywhere there is an Irish pub (so, anywhere), but nasty, cheap, greasy fish & chip shop fish & chips just doesn't exist in this country and I miss it so much | 19:45 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: write up the python3-first goal https://review.openstack.org/575933 | 19:46 |
| fungi | zaneb: oh, yes that really oily dense stuff | 19:46 |
| fungi | i concur. i've only ever received it in certain parts of the british isles though i expect it has permeated other parts of the former commonwealth | 19:47 |
| zaneb | indeed it has :) | 19:47 |
| fungi | ironically, we have no irish pubs here, which is a strikingly odd situation. also no italian, greek or middle-eastern restaurants | 20:02 |
| fungi | unless i want to hit up one of the towns an hour or so away on the mainland that is | 20:03 |
| zaneb | fungi: which island do you live on? | 20:04 |
| fungi | depends on who you ask, but the usgs labells it as bodie island | 20:05 |
| fungi | kill devil hills is the township | 20:06 |
| fungi | basically the strip north of hatteras and pea islands, east of roanoke island | 20:06 |
| zaneb | oh cool, yeah I have been there a couple of times | 20:08 |
| fungi | it's technically a peninsula in present day since the inlets to the north have shoaled over and so it's physically connected to the southeast corner of virginia, but that's not accessible by vehicle | 20:08 |
| zaneb | we have a friend whose family is from Ocracoke | 20:09 |
| *** edmondsw_ has joined #openstack-tc | 20:09 | |
| fungi | love that place. pain to get to but they've just opened a slightly faster pedestrian-only ferry as an alternative to the automotive ferry now | 20:10 |
| fungi | drops you off in the marina right in town as opposed to 10 miles away at the point | 20:10 |
| zaneb | One time I went to her wedding on Ocracoke on a Saturday night and then left on the 5am ferry to drive to Raleigh to get to Tokyo on Monday night for the Summit | 20:11 |
| *** edmondsw has quit IRC | 20:11 | |
| fungi | ouch | 20:11 |
| zaneb | luckily the plane was empty and I had 3 full seats to lie down and sleep on | 20:12 |
| fungi | that helps. i rarely experience that on flights in more recent years | 20:12 |
| fungi | seems like i'm always on the sardine express any more | 20:13 |
| zaneb | that's the only time it's ever happened to me | 20:13 |
| fungi | oh, also ocracoke has a brewery on the island as of less than a year ago. i haven't been down that way since it opened but intend to once the tourists recede | 20:15 |
| zaneb | nice | 20:19 |
| fungi | good opportunity to finally try out that fancy pedestrian ferry too | 20:19 |
| zaneb | it leaves from Hatteras? | 20:20 |
| fungi | yep, same terminal ferry on the hatteras side, but the ocracoke side is where the swan quarter ferry lets off | 20:21 |
| fungi | basically the marina right in the middle of town | 20:21 |
| zaneb | that seems like a much better system :) | 20:22 |
| fungi | it's technically more distance on the water if you plot a dead straight course, but since i expect it rides higher with less weight it can clear some of the shallows to the sides of the inlet without swinging quite as far out into the sound, so probably actually less actual distance | 20:23 |
| fungi | the travel times are 15 minutes faster at any rate | 20:24 |
| fungi | plus you can just leave your car in hatteras, and it's not as if they charge to park there (not so far at least) | 20:25 |
| fungi | i think they're just trying to curb (no pun intended) as much of the vehicular traffic on ocracoke as they can | 20:25 |
| jaypipes | zaneb: I specifically called out the mountains of North Carolina for a reason. :) | 20:33 |
| fungi | i'm going to be up there a couple times over the next month. my favorite caribbean restaurant (outside the actual caribbean) is there. oh, and family | 20:33 |
| fungi | strange that i can get better caribbean food in the mountains than down here at the beach | 20:34 |
| zaneb | fungi: is it Salsa's? It's Salsa's isn't it. | 20:35 |
| * fungi laughs | 20:35 | |
| fungi | nine mile | 20:35 |
| fungi | the one in montford. that new haywood rd location isn't rubbish but it lacks atmosphere | 20:35 |
| fungi | granted, i haven't been in the montford location since the renovations this year, so who knows | 20:36 |
| zaneb | I should go to the one in Montford. only been to Haywood Rd and it did indeed lack atmosphere | 20:36 |
| jaypipes | notmyname: I'm a little confused... if you look at Swift, would you ever think to say "you know, what we need to add to Swift is a filesystem layer so that our object storage system can look more familiar to application developers who want a filesystem"? I view the requests to have Nova be more than a low-level compute provisioning system in much the same way, which is why I push back hard on the scope of Nova expanding further than it already | 20:37 |
| jaypipes | has. | 20:37 |
| notmyname | jaypipes: you mean like https://github.com/swiftstack/ProxyFS ;-) | 20:38 |
| fungi | jaypipes: i've at times wanted posix-like filesystem features out of swift, albeit for entirely misguided reasons | 20:38 |
| jaypipes | notmyname: that is your company's product. | 20:38 |
| clarkb | I think jaypipes is saying you wouldn't put it in swift itself | 20:38 |
| jaypipes | clarkb: bingo. | 20:38 |
| notmyname | it's an open source project that our company has written | 20:39 |
| clarkb | building such a tool is fine, but out of scope for the low level thing | 20:39 |
| jaypipes | notmyname: yes, I know. and there's nothing wrong with that at all. | 20:39 |
| jaypipes | notmyname: I'm not saying "product" as if it's a bad thing. :) | 20:39 |
| jaypipes | notmyname: I'm just pointing out that there's a reason you didn't just tack all that functionality into Swift itself. | 20:39 |
| jaypipes | notmyname: because it would violate a sense of single responsibility of Swift's purpose. | 20:40 |
| notmyname | ok. yes there are reasons (technical and otherwise) why proxyfs isn't in the swift codebase | 20:40 |
| notmyname | sorry, I've context shifted from whatever you were replying to me about, and I don't remember. what's the context? :-) | 20:40 |
| jaypipes | notmyname: you were saying you agreed completely with zaneb's response to me about "[nova's competition is] the compute provisioning parts of [public cliuds]" | 20:41 |
| zaneb | jaypipes: I look at Swift and think "why is Storlets a thing that is tied to Swift, instead of being a service that listens to a cross-project OpenStack event bus?" We could have invented Lambda first if we hadn't been all stuck in our silos :/ | 20:41 |
| notmyname | jaypipes: ah, right. I agree with his statement that different groups in openstack have been building towards different goals all the while saying we're building the same thing. that leads to working at cross purposes | 20:42 |
| notmyname | and I found that to be the crux of the argument/response | 20:43 |
| * fungi thought lisp invented lambda functions | 20:43 | |
| zaneb | jaypipes: the point of the email isn't asking for more porcelain in Nova. Nobody _here_ wants that (although there are plenty of people who misguidedly want that, Matt pointed out some this morning) | 20:44 |
| notmyname | jaypipes: your recent brief reply to zaneb about rancher is interesting. you point out that people refered to "openstack" and not "nova". but zaneb [I thought] was saying more generally that the two are largely equated and have been for years | 20:50 |
| notmyname | when reading these "what is openstack" email threads when they pop up every year, my opinion is that participants often use "openstack" and "nova" (or "compute provisioning") rather fluidly. or at least with a "openstack's primary purpose is compute provisioning" perspective | 20:53 |
| notmyname | I think that's a common perspective both inside openstack and in the wider tech community. | 20:54 |
| *** zaneb has quit IRC | 21:00 | |
| *** diablo_rojo has quit IRC | 21:14 | |
| *** diablo_rojo has joined #openstack-tc | 21:23 | |
| *** rosmaita has quit IRC | 21:40 | |
| *** edmondsw_ has quit IRC | 21:53 | |
| *** mriedem has quit IRC | 22:12 | |
| *** hongbin has quit IRC | 22:25 | |
| *** edmondsw has joined #openstack-tc | 22:49 | |
| *** edmondsw has quit IRC | 22:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!