On Mon, Sep 25, 2017 at 5:38 PM, Giuseppe Attardi <giuseppe.atta...@garr.it> wrote:
> > On 25 set 2017, at 12:20, Frode Nordahl <frode.nord...@gmail.com> wrote: > > Hello Giuseppe, > > See replies inline. > > On Wed, Sep 13, 2017 at 12:09 PM, Giuseppe Attardi < > giuseppe.atta...@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.atta...@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 > > Yes. Historically there has existed little prior work for how the Keystone directory should be organized. We have taken a lead and have made some choices in that regard. Everyone would benefit from standardization and consistency and we will seek to achieve that with the broader community over time. > 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”. > That is unfortunate. Please do make us aware of and raise bugs for (if you have not done so already) any hard coding of these values across our Charms. So I am suggesting that > > since 2018 the OpenStack Keystone Charm would be using the project name > “service”. > Thank you for the suggestion, we will bring that into consideration. > — Beppe > -- Frode Nordahl > > 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 >> > >> > > 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@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> > > > > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
