+1 on all of Jay's conclusions. :) I¹m pretty new to OpenStack, but not at all to API, REST API, and web development in general, and I concur : ŒNova¹, ŒSwift¹, ŒKeystone¹ and so on makes it very hard to learn how things work in OpenStack and what each of those parts are responsible with. I¹ll be honest, I had to print this schema (http://getcloudify.org/img/blog/openstackdiagram.jpg) and put the name on it to be able to sort myself out of it. :) I would also agree that projects/teams can keep their secret Œin the family¹ name for differentiation (and also facilitate coopetition) and tools, but I would love to be able to abstract it at some level (the service level seems perfect for that).
As a dev, this get my votes. All of them in fact :) As long as we can agree on the function of each service and associate a name that has a natural don¹t-need-a-map-to-get-it, I¹m all for it. Best, Bruno Morel Internap / iWeb Technologies On 2015-07-05, 11:45, "Jay Pipes" <[email protected]> wrote: >On 06/25/2015 02:19 PM, Monty Taylor wrote: >> On 06/25/2015 01:35 PM, Devananda van der Veen wrote: >>> Sean's point and Dmitri's are similar. >>> >>> There are APIs for projects which do not have official team or >>>"program" >>> names. And some teams may produce more than one forward-facing service. >>> Naming the API based in the team name doesn't make sense. >>> >>> My previous point is that restricting the API name to the team/program >>>name >>> will prevent any competition among projects. It'll be impossibly >>>confusing >>> to users if more than one "monitoring" project exists, they all have >>> different API, but each claim to be the one true >>>OpenStack-Monitoring-API >> >> I believe that it is important that there is only one api in OpenStack >> that provides a given short name. Even with the big tent. > >So do I. I've been saying that for quite some time. Which is why I've >been arguing for referring to things like they are referred to on the >API documentation site: > >http://developer.openstack.org/#api > >By the name of the API, which is "The OpenStack Compute API", not "The >Nova API". > >> I say that because, as a user, I ask the service catalog for a well >> known service type - "compute" or "baremetal" or "network" - and I get >> back a REST endpoint that is ostensibly for that purpose. > >Precisely correct. > >> If I then have to introspect that service to find out what it really is, >> we have fully jumped the shark and started prioritizing our own >> navel-gazing over any hope of any human ever using what we're doing. >> >> So - yes, this is potentially, although not actually, a problem right >> now. And we need to solve it before it moves from being an actual >>problem. > >Right. Which is why I was trying to prevent this problem from becoming >bigger than it needs to be, and trying to convince people to use the >service type that appears in the Keystone Service Catalog as the {NAME} >in X-OpenStack-{NAME}-API-Version header. > >Best, >-jay > >>> On Jun 25, 2015 9:37 AM, "Sean Dague" <[email protected]> wrote: >>> >>>> On 06/25/2015 12:04 PM, Anne Gentle wrote: >>>>> >>>>> >>>>> On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>> <snip> >>>>> >>>>> >>>>> I'm not sure where the assumption comes from that people will >>>>>know >>>>> "compute" better than "nova". >>>>> >>>>> >>>>> I have been supporting developer end users on the Rackspace cloud for >>>>> nearly four years now. I gave a talk in Paris at the Summit about >>>>> supporting developers. Developers using cloud resources expect to use >>>>> computing power or storage capacity to accomplish a broader task. >>>>>Nova >>>>> and swift have nothing to do with their expectations. >>>> >>>> That's good feedback, and clearly moves the needle in my head. >>>> >>>> It also does open up a question about the big tent nature, because >>>>it's >>>> unclear what projects that do not yet have a generic name allocated to >>>> them would use. >>>> >>>> -Sean >>>> >>>> -- >>>> Sean Dague >>>> http://dague.net >>>> >>>> >>>>_______________________________________________________________________ >>>>___ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>>[email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> >>>________________________________________________________________________ >>>__ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>>[email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >>_________________________________________________________________________ >>_ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >>[email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
