Open Stack

On Thu, Apr 16, 2020 at 10:27 AM Tom Barron <tpb at dyncloud.net> wrote:

> On 16/04/20 14:07 +0100, Sean Mooney wrote:
> >On Thu, 2020-04-16 at 07:29 -0500, Sean McGinnis wrote:
> >> On 4/15/20 6:47 PM, Jeremy Stanley wrote:
> >> > On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote:
> >> > [...]
> >> > > People care because they are invested in the community as a whole,
> >> > > and I think the thought of such a major change does bring fear. I
> >> > > think that is totally natural and honestly I feel the same way.
> >> > > Also at the same time, I think we risk letting the fear control
> >> > > us. Thus prohibits us and prevents us from what may be the right
> >> > > direction. In part, that is also why we need to talk through these
> >> > > things. :)
> >> >
> >> > [...]
> >> >
> >> > In my case, I just want to make sure folks are approaching these
> >> > sorts of decisions by first identifying problems and only *then*
> >> > moving to discussing solutions. Otherwise there's a risk that a lot
> >> > of effort and resources are wasted on work which doesn't solve
> >> > whatever needs solving. Hear each of the arguments (for and against)
> >> > with a critical ear, and ask whether they're good solutions for the
> >> > problems you've identified.
> >> >
> >> > Above all, try to avoid the trap of using problems to justify a
> >> > solution which has already been chosen for other reasons. When the
> >> > discussion starts out as a proposal for some particular solution,
> >> > that's how it tends to come across.
> >>
> >> We also have other projects that can and are used standalone. Cinder has
> >> been enabled for that for years, but I'm pretty sure there are others.
> >well swift comes to mind im pretty sure it can run standalone or at most
> using keystone.
> >speaking of which keystone can be used standablone in open source mano or
> keystone.
> >im not aware of anyone using placment standalone but it would also be a
> good candidate.
> >glance has no depency on other project to function out side of perhaps
> keystone.
> >im ignoring oslo deps in all cases above by the way since libary
> dependises are not an overhead
> >for the operator they are an over head for the distro maintaienr or you
> can grab them form pip.
> >
> >things like horizon and heat by there nature obviously cannot be used
> standalone but many of
> >the lower level porject could be. if they are actully used standalone is
> another matter.
>
> Manila can run standalone or with keystone only.  With keystone is the
> way we position it (with CSI plugin) for running multiple Kubernetes
> clusters as isolated tenants with common storage infrastructure.
>
> It would be handy to also have other, loosely coupled, multi-tenant
> service infrastructure services, including one that offers bare metal
> compute instances, developed in a community dedicated to the four open
> principles [1] and aligned with a common technical vision [2].
>
> As I follow this thread I'm trying to understand what "Ironic moving
> out of OpenStack" would mean in terms of the previous paragraph.  That
> doesn't have anything do do with fear of change or wanting to control
> the destinies of other developers.
>
> [1] https://governance.openstack.org/tc/reference/opens.html
>
> [2] https://governance.openstack.org/tc/reference/technical-vision.html
>
>
> >
> >>
> >> So part of this long discussion, I think, is to make sure whatever
> >> action the community takes is one that makes sense and does not confuse
> >> the situation even more. Looking at it as a whole, does it make sense
> >> for any service that can be used standalone to become its own top level
> >> project. If it's only after a certain level of adoption, what is the
> >> threshold or how is that decided? Is there a better way to not disrupt
> >> the community while still addressing the needs of the projects that want
> >> to stand out more as something that could be seen as more independent?
> >>
> >> There isn't really an easy answer here, so it's worth getting input from
> >> those involved in the community to make sure we don't go down a path we
> >> are going to regret later.
> >>
> >> Sean
> >>
> >>
> >
> >
>
>

Is this a technical decision that is supported by contributors to the
project?
Is this a perception decision that is supported by contributors to the
project?
Both?
If there is support, how much? 60%, 80%, 100%

I am just some dumb operator, can someone please explain in regular
human terms what the desired end result is from the move.
All of the technical bits and bytes are good and all - but like big
picture - what does the effort to move result in?

-- 
~/DonnyD
C: 805 814 6800
"No mission too difficult. No sacrifice too great. Duty First"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200416/8ca4f34a/attachment.html>