On 10 November 2015 at 16:12, Giulio Fidente <gfide...@redhat.com> wrote:
> On 11/10/2015 04:47 PM, Dmitry Tantsur wrote: > >> On 11/10/2015 04:37 PM, Giulio Fidente wrote: >> >>> On 11/10/2015 04:16 PM, Dmitry Tantsur wrote: >>> >>>> On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote: >>>> >>>>> Hi all, >>>>> >>>>> At the last IRC meeting it was agreed that the new TripleO REST API >>>>> should forgo the Tuskar name, and simply be called... the TripleO >>>>> API. There's one more point of discussion: where should the API >>>>> live? There are two possibilities: >>>>> >>>>> a) Put it in tripleo-common, where the business logic lives. If we >>>>> do this, it would make sense to rename tripleo-common to simply >>>>> tripleo. >>>>> >>>> >>>> +1 for both >>>> >>>> >>>>> b) Put it in its own repo, tripleo-api >>>>> >>>> >>> if both the api (coming) and the cli (currently python-tripleoclient) >>> are meant to consume the shared code (business logic) from >>> tripleo-common, then I think it makes sense to keep each in its own repo >>> ... so that we avoid renaming tripleo-common as well >>> >> >> tripleoclient should not consume tripleo-common >> > > so FWIW I think my vote is different depending on the plans: > > a. if python-tripleoclient will be changed so that it uses tripleo-api, > then I'd vote for option 1) (have tripleo-api in -common and rename) > I think this is what we want. Supporting both a Python API and REST API adds a ton of extra work. It will take some time to transition the CLI over, but I think it is worth it. > b. if python-tripleoclient will be changed so that it uses the shared > library in -common, then I'd vote for for option 2) (have tripleo-api in > its own repo) > > > on a side note, I think it should always be possible for the deployer to > skip any business logic to give complete control over the template params > for both the initial deployments and the updates > -- > Giulio Fidente > GPG KEY: 08D733BA | IRC: giulivo > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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