On Mon, May 23, 2016, at 02:57 PM, Sean Dague wrote: > On 05/23/2016 03:34 PM, Gregory Haynes wrote: > > > > On Mon, May 23, 2016, at 11:48 AM, Doug Hellmann wrote: > >> Excerpts from Chris Dent's message of 2016-05-23 17:07:36 +0100: > >>> On Mon, 23 May 2016, Doug Hellmann wrote: > >>>> Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100: > >>>>> I don't think language does (or should) have anything to do with it. > >>>>> > >>>>> The question is whether or not the tool (whether service or > >>>>> dependent library) is useful to and usable outside the openstack-stack. > >>>>> For example gnocchi is useful to openstack but you can use it with other > >>>>> stuff, therefore _not_ openstack. More controversially: swift can be > >>>>> usefully used all by its lonesome: _not_ openstack. > >>>> > > > > Making a tool which is useful outside of the OpenStack context just > > seems like good software engineering - it seems odd that we would try > > and ensure our tools do not fit this description. Fortunately, many (or > > even most) of the tools we create *are* useful outside of the OpenStack > > world - pbr, git-review, diskimage-builder, (I hope) many of the oslo > > libraries. This is really a question of defining useful interfaces more > > than anything else, not a statement of whether a tool is part of our > > community. > > Only if you are willing to pay the complexity and debt cost of having > optional backends all over the place. > > For instance, I think we're well beyond that point that Keystone being > optional should be a thing anywhere (and it is a thing in a number of > places). Keystone should be our auth system, all projects 100% depend on > it, and if you have different site needs, put that into a Keystone > backend. >
Services and Projects seem to be getting conflated here. IIUC Your two points apply only to services - we certainly aren't paying any complexity costs for making pbr optional and the same could be said for many of our tools. I don't have a ton of context for why some services are electing to pay the cost of making Keystone optional. The point I was hoping to make is that there is value in defining an interface which is useful outside of OpenStack, and this is a very common pattern with many of our tools. I completely agree that there are additional costs to doing so at times, and obviously they have to be weighed against the benefits. That is really a problem-specific issue, though. > Most of the oslo libraries require other oslo libraries, which is fine. > They aren't trying to solve the general purpose case of logging or > configuration or db access. They are trying to solve a specific set of > patterns that are applicable to OpenStack projects. > This is true up to a point - there isn't any inherent value in overfitting a problem to be OpenStack specific. To beat on the pbr hammer some more - we created a tool that fulfills our needs and making it in a way where others can use it didn't cost us anything. This isn't always the case but sometimes it is, and there is absolutely value in making a tool which others can use. > -Sean > > -- > Sean Dague > http://dague.net Cheers, Greg __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
