_
From: Thierry Carrez [thie...@openstack.org]
Sent: Thursday, July 19, 2018 5:24 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
Zane Bitter wrote:
> [...]
>> And I'm not convinced that's an either/or choice...
>
> I said specifi
Zane Bitter wrote:
[...]
And I'm not convinced that's an either/or choice...
I said specifically that it's an either/or/and choice.
I was speaking more about the "we need to pick between two approaches,
let's document them" that the technical vision exercise started as.
Basically I mean
On 17/07/18 10:44, Thierry Carrez wrote:
Finally found the time to properly read this...
For anybody else who found the wall of text challenging, I distilled the
longest part into a blog post:
https://www.zerobanana.com/archive/2018/07/17#openstack-layer-model-limitations
Zane Bitter
Inlining with KF>
From: Thierry Carrez [thie...@openstack.org]
Sent: Tuesday, July 17, 2018 7:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
Finally found the time to properly read this...
Zane Bit
Finally found the time to properly read this...
Zane Bitter wrote:
[...]
We chose to add features to Nova to compete with vCenter/oVirt, and not
to add features the would have enabled OpenStack as a whole to compete
with more than just the compute provisioning subset of EC2/Azure/GCP.
Could
I'm not Kevin but I think I can clarify some of these.
On 03/07/18 16:04, Jay Pipes wrote:
On 07/03/2018 02:37 PM, Fox, Kevin M wrote:
So these days containers are out clouding vms at this use case. So, does Nova continue to be cloudy vm or does it go for the more production vm use case like
On 07/06/2018 12:58 PM, Zane Bitter wrote:
On 02/07/18 19:13, Jay Pipes wrote:
Nova's primary competition is:
* Stand-alone Ironic
* oVirt and stand-alone virsh callers
* Parts of VMWare vCenter [3]
* MaaS in some respects
Do you see KubeVirt or Kata or Virtlet or RancherVM ending up on this
On 02/07/18 19:13, Jay Pipes wrote:
Also note that when I've said that *OpenStack* should have a smaller
mission and scope, that doesn't mean that higher-level services
aren't necessary or wanted.
Thank you for saying this, and could I please ask you to repeat this
disclaimer whenever you
dhat.com]
*Sent:* Thursday, July 05, 2018 11:17 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [tc] [all] TC Report 18-26
On Thu, Jul 5, 2018, 19:31 Fox, Kevin M <mailto:kevin@pnnl.gov>> wrote:
We're pretty far into a ta
]
Sent: Thursday, July 05, 2018 10:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 2018-07-05 17:30:23 + (+), Fox, Kevin M wrote:
[...]
> Deploying k8s doesn't need a general solution to deploying gene
Tantsur [dtant...@redhat.com]
Sent: Thursday, July 05, 2018 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On Thu, Jul 5, 2018, 19:31 Fox, Kevin M
mailto:kevin@pnnl.gov>> wrote:
We're pretty far into a t
f folks are interested in continuing this discussion, lets open a new
> thread.
>
> Thanks,
> Kevin
>
>
> From: Dmitry Tantsur [dtant...@redhat.com]
> Sent: Wednesday, July 04, 2018 4:24 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [ope
On 2018-07-05 17:30:23 + (+), Fox, Kevin M wrote:
[...]
> Deploying k8s doesn't need a general solution to deploying generic
> base OS's. Just enough OS to deploy K8s and then deploy everything
> on top in containers. Deploying a seed k8s with minikube is pretty
> trivial. I'm not
in continuing this discussion, lets open a new thread.
Thanks,
Kevin
From: Dmitry Tantsur [dtant...@redhat.com]
Sent: Wednesday, July 04, 2018 4:24 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
Tried hard
n?
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, July 03, 2018 10:06 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 07/02/2018 03:31 PM, Zane Bitter wrote:
On 28/06/18 15:09, Fox, Kevin M wrote:
Replying inline in outlook. Sorry. :( Prefixing with KF>
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Tuesday, July 03, 2018 1:04 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
I'll answer inline, so that i
o I
don't really see the correlation here. That said, I'm 100% against a
monolithic application approach, as I've mentioned before.
Best,
-jay
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Monday, July 02, 2018 4:13 PM
To: openstack-dev@
OpenStack to get a self
hosting ironic working.
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, July 03, 2018 10:06 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 07/02/2018 03:31 PM
ade it this far without their head exploding already. :)
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Monday, July 02, 2018 2:45 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 07/02/2018 03
Pipes [jaypi...@gmail.com]
Sent: Monday, July 02, 2018 4:13 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 06/27/2018 07:23 PM, Zane Bitter wrote:
> On 27/06/18 07:55, Jay Pipes wrote:
>> Above, I was saying that the scope of the *
On Tue, Jul 3, 2018 at 1:06 PM Jay Pipes wrote:
>
> On 07/02/2018 03:31 PM, Zane Bitter wrote:
> > On 28/06/18 15:09, Fox, Kevin M wrote:
> >> * made the barrier to testing/development as low as 'curl
> >> http://..minikube; minikube start' (this spurs adoption and
> >> contribution)
> >
>
On 07/02/2018 03:31 PM, Zane Bitter wrote:
On 28/06/18 15:09, Fox, Kevin M wrote:
* made the barrier to testing/development as low as 'curl
http://..minikube; minikube start' (this spurs adoption and
contribution)
That's not so different from devstack though.
* not having large
Zane Bitter wrote:
[...]
I think if OpenStack wants to gain back some of the steam it had
before, it needs to adjust to the new world it is living in. This means:
* Consider abolishing the project walls. They are driving bad
architecture (not intentionally but as a side affect of structure)
On 06/27/2018 07:23 PM, Zane Bitter wrote:
On 27/06/18 07:55, Jay Pipes wrote:
Above, I was saying that the scope of the *OpenStack* community is
already too broad (IMHO). An example of projects that have made the
*OpenStack* community too broad are purpose-built telco applications
like
On 07/02/2018 03:12 PM, Fox, Kevin M wrote:
I think a lot of the pushback around not adding more common/required services
is the extra load it puts on ops though. hence these:
* Consider abolishing the project walls.
* simplify the architecture for ops
IMO, those need to change to break
think it would make for a much healthier OpenStack.
Thanks,
Kevin
From: Zane Bitter [zbit...@redhat.com]
Sent: Wednesday, June 27, 2018 4:23 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 27/06/18 07:55, Jay P
Monday, July 02, 2018 11:41 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 06/28/2018 02:09 PM, Fox, Kevin M wrote:
> I'll weigh in a bit with my operator hat on as recent experience it pertains
> to the current conversation
>
&
s and get a vastly simpler
> architecture for operators to deal with. Yes, this would be a major
> disruptive change to OpenStack. But long term, I think it would make for a
> much healthier OpenStack.
>
> Thanks,
> Kevin
>
> From: Zane B
On Thu, 28 Jun 2018, Fox, Kevin M wrote:
I think if OpenStack wants to gain back some of the steam it had before, it
needs to adjust to the new world it is living in. This means:
* Consider abolishing the project walls. They are driving bad architecture (not
intentionally but as a side affect
My two cents:
> I think if OpenStack wants to gain back some of the steam it had before, it
> needs to adjust to the new world it is living in. This means:
> * Consider abolishing the project walls. They are driving bad architecture
> (not intentionally but as a side affect of structure)
As
.com]
Sent: Wednesday, June 27, 2018 4:23 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 27/06/18 07:55, Jay Pipes wrote:
> WARNING:
>
> Danger, Will Robinson! Strong opinions ahead!
I'd have been disappointed with anything less :)
>
On 27/06/18 07:55, Jay Pipes wrote:
WARNING:
Danger, Will Robinson! Strong opinions ahead!
I'd have been disappointed with anything less :)
On 06/26/2018 10:00 PM, Zane Bitter wrote:
On 26/06/18 09:12, Jay Pipes wrote:
Is (one of) the problem(s) with our community that we have too small
Jay Pipes wrote:
[...]
I've also argued in the past that all distro- or vendor-specific
deployment tools (Fuel, Triple-O, etc [3]) should live outside of
OpenStack because these projects are more products and the relentless
drive of vendor product management (rightfully) pushes the scope of
WARNING:
Danger, Will Robinson! Strong opinions ahead!
On 06/26/2018 10:00 PM, Zane Bitter wrote:
On 26/06/18 09:12, Jay Pipes wrote:
Is (one of) the problem(s) with our community that we have too small
of a scope/footprint? No. Not in the slightest.
Incidentally, this is an
On 26/06/18 09:12, Jay Pipes wrote:
Is (one of) the problem(s) with our community that we have too small of
a scope/footprint? No. Not in the slightest.
Incidentally, this is an interesting/amusing example of what we talked
about this morning on IRC[1]: you say your concern is that the scope
On 26/06/18 09:12, Jay Pipes wrote:
On 06/26/2018 08:41 AM, Chris Dent wrote:
Meanwhile, to continue [last week's theme](/tc-report-18-25.html),
the TC's role as listener, mediator, and influencer lacks
definition.
Zane wrote up a blog post explaining the various ways in which the
OpenStack
"What is OpenStack"
From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, June 26, 2018 6:12 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 06/26/2018 08:41 AM, Chris Dent wrote:
&
On 06/26/2018 08:41 AM, Chris Dent wrote:
Meanwhile, to continue [last week's theme](/tc-report-18-25.html),
the TC's role as listener, mediator, and influencer lacks
definition.
Zane wrote up a blog post explaining the various ways in which the
OpenStack Foundation is
HTML: https://anticdent.org/tc-report-18-26.html
All the bits and pieces of OpenStack are interconnected and
interdependent across the many groupings of technology and people.
When we plan or make changes, wiggling something _here_ has
consequences over _there_. Some intended, some unintended.
39 matches
Mail list logo
