services or service project name?

[Giuseppe Attardi]

> On 25 set 2017, at 12:20, Frode Nordahl <frode.nordahl at gmail.com> wrote:
> 
> Hello Giuseppe,
> 
> See replies inline.
> 
> On Wed, Sep 13, 2017 at 12:09 PM, Giuseppe Attardi <giuseppe.attardi at garr.it <mailto:giuseppe.attardi at garr.it>> wrote:
> To avoid any confusion, I decided to do this:
> 
>         juju config keystone service-tenant=service
> 
> FWIW; I would not recommend changing this default.
>  
> — Beppe
> 
> > On 12 set 2017, at 19:19, Giuseppe Attardi <giuseppe.attardi at garr.it <mailto:giuseppe.attardi at garr.it>> wrote:
> >
> > I am upgrading an OpenStack deployed with Juju release Mitaka to Ocata.
> > Juju has created a project named “services” (actually two, one in domain default and one in domain admin_domain).
> 
> The OpenStack Keystone Charm has been using the project name "services" since 2012.

You are confirming that the Keystone Charm uses a different name from the one suggested by the official documentation.
Throughout the OpenStack installation guides the suggested name is “service”:

	https://docs.openstack.org/mitaka/install-guide-obs/keystone-users.html

You would avoid a source of confusion if Keystone Charm would also use “service”, especially if the name of the service project is hard coded in certain Charms.
I had to delve deep into che code of some charm to find that somewhere “service” was used and elsewhere “services”.

So I am suggesting that

since 2018 the OpenStack Keystone Charm would be using the project name “service”.

— Beppe

> 
> When you set configration option 'preferred-api-version' to 3 on the Keystone charm, all charms that support it will configure services to use a Keystone v3 API endpoint and authenticate using the service accounts in project 'services' in the 'service_domain' domain.
> 
> We currently maintain the service accounts in 'services' project both for 'default' domain and 'service_domain' domain to give our users the choice of switching freely between using Keystone v2 API endpoints and Keystone v3 API endpoints. This is deliberate and by design.
> 
> Any application written for or configured to use the Keystone v2 API is oblivious to the fact that domains exists. Thus we need to retain the 'default' domain for compatibility in this transition phase.
>  
> > The current documentation for Ocata seems to use the name “service” instead of “services”, for example here:
> >
> >       https://docs.openstack.org/project-install-guide/telemetry/ocata/install-base-ubuntu.html <https://docs.openstack.org/project-install-guide/telemetry/ocata/install-base-ubuntu.html>
> >
> 
> The guide you reference to is for the telemetry service and the commands provided in the guide is examples of how it could be set up.
>  
> > I would like your advice on whether I can stick to “services” or should I switch to “service” to avoid future problems or inconsistencies.
> > For future deployment, is there a way to tell Juju to use “service” as project name?


> As you have already figured out this can be changed with a configuration option. However, I would not recommend changing the charm default unless you have strong reasons to do so.
> 
> -- 
> Frode Nordahl
> 
> > Thank you.
> >
> > — Attardi
> >
> 
> 
> --
> Juju mailing list
> Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju <https://lists.ubuntu.com/mailman/listinfo/juju>
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170925/003a33bc/attachment.html>