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