In latest version of python-keystoneclient using admin_token in auth_token middleware was depracted. So in future we need to create configuration similar to openstack with nailgun_service user. In that configuration there should be no problem with upgrades. We can do it after 5.1.
On Mon, Jul 28, 2014 at 5:28 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, > > 1. yes, we can do it, if it's possible to create new user with > admin_token. But it will complicate upgrade process and will take some time > to design/implement and test, because I see several new cases, for example > we need to create new user in previous version of the container (we use > nailgun api before upgrade too), and then in new container, and in case of > rollback delete it from previous container. > > 2. afaik, this config is not in the container, it's on the host system, > and it will be replaced by puppet on the host system > > > On Mon, Jul 28, 2014 at 6:37 PM, Lukasz Oles <lo...@mirantis.com> wrote: > >> As I said in another topic, storing user password in plain text is not an >> option. >> >> Ad. 1. >> We can create special "upgrade_user" with the same rights as admin user. >> We can use it to authenticate in nailgun. It can be done after 5.1 release. >> >> Ad. 2. >> In perfect world during upgrade /etc/fuel/client/config.yaml should be >> copied to new container. If it's not possible, warning in documentation >> should be ok. >> >> Regards >> >> >> On Mon, Jul 28, 2014 at 3:59 PM, Mike Scherbakov < >> mscherba...@mirantis.com> wrote: >> >>> Lukasz, >>> what do you think on this? Is someone addressing the issues mentioned by >>> Evgeny? >>> >>> Thanks, >>> >>> >>> On Fri, Jul 25, 2014 at 3:31 PM, Evgeniy L <e...@mirantis.com> wrote: >>> >>>> Hi, >>>> >>>> I have several concerns about password changing. >>>> >>>> >> Default password can be changed via UI or via fuel-cli. In case of >>>> changing password via UI or fuel-cli password is not stored in any file >>>> only in keystone >>>> >>>> It's important to change password in /etc/fuel/astute.yaml >>>> otherwise it will be impossible for user to run upgrade, >>>> >>>> 1. upgrade system uses credentials from /etc/fuel/astute.yaml >>>> to authenticate in nailgun >>>> 2. upgrade system runs puppet to upgrade dockerctl/fuelclient >>>> on the host system, puppet uses credentials from >>>> /etc/fuel/astute.yaml >>>> to update config /etc/fuel/client/config.yaml [1], even if user >>>> changed >>>> the password in the config for fuelclient, it will be overwritten >>>> after upgrade >>>> >>>> If we don't want to change credentials in /etc/fuel/astute.yaml >>>> lets at least add some warning in the documentation. >>>> >>>> [1] >>>> https://github.com/stackforge/fuel-library/blob/705dc089037757ed8c5a25c4cf78df71f9bd33b0/deployment/puppet/nailgun/examples/host-only.pp#L51-L55 >>>> >>>> >>>> >>>> On Thu, Jul 24, 2014 at 6:17 PM, Lukasz Oles <lo...@mirantis.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> one more thing. You do not need to install keystone in your >>>>> development environment. By default it runs there in fake mode. Keystone >>>>> mode is enabled only on iso. If you want to test it locally you have to >>>>> install keystone and configure nailgun as Kamil explained. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> On Thu, Jul 24, 2014 at 3:57 PM, Mike Scherbakov < >>>>> mscherba...@mirantis.com> wrote: >>>>> >>>>>> Kamil, >>>>>> thank you for the detailed information. >>>>>> >>>>>> Meg, do we have anything documented about authx yet? I think Kamil's >>>>>> email can be used as a source to prepare user and operation guides for >>>>>> Fuel >>>>>> 5.1. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> On Thu, Jul 24, 2014 at 5:45 PM, Kamil Sambor <ksam...@mirantis.com> >>>>>> wrote: >>>>>> >>>>>>> Hi folks, >>>>>>> >>>>>>> All parts of code related to stage I and II from blueprint >>>>>>> http://docs-draft.openstack.org/29/96429/11/gate/gate-fuel-specs-docs/2807f30/doc/build/html/specs/5.1/access-control-master-node.htm >>>>>>> <http://docs-draft.openstack.org/29/96429/11/gate/gate-fuel-specs-docs/2807f30/doc/build/html/specs/5.1/access-control-master-node.html> >>>>>>> are >>>>>>> merged. In result of that, fuel (api and UI) we now have >>>>>>> authentication via keystone and now is required as default. Keystone is >>>>>>> installed in new container during master installation. We can configure >>>>>>> password via fuelmenu during installation (default user:password - >>>>>>> admin:admin). Password is saved in astute.yaml, also admin_token is >>>>>>> stored >>>>>>> here. >>>>>>> Almost all endpoints in fuel are protected and they required >>>>>>> authentication token. We made exception for few endpoints and they are >>>>>>> defined in nailgun/middleware/keystone.py in public_url . >>>>>>> Default password can be changed via UI or via fuel-cli. In case of >>>>>>> changing password via UI or fuel-cli password is not stored in any file >>>>>>> only in keystone, so if you forgot password you can change it using >>>>>>> keystone client from master node and admin_token from astute.yaml using >>>>>>> command: keystone --os-endpoint=http://10.20.0.2:35357/v2.0 >>>>>>> --os-token=admin_token >>>>>>> password-update . >>>>>>> Fuel client now use for authentication user and passwords which are >>>>>>> stored in /etc/fuel/client/config.yaml. Password in this file is not >>>>>>> changed during changing via fuel-cli or UI, user must change this >>>>>>> password >>>>>>> manualy. If user don't want use config file can provide user and >>>>>>> password >>>>>>> to fuel-cli by flags: --os-username=admin --os-password=test. We added >>>>>>> also >>>>>>> possibilities to change password via fuel-cli, to do this we should >>>>>>> execute: fuel user --change-password --new-pass=new . >>>>>>> To run or disable authentication we should change >>>>>>> /etc/nailgun/settings.yaml (AUTHENTICATION_METHOD) in nailgun container. >>>>>>> >>>>>>> Best regards, >>>>>>> Kamil S. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenStack-dev mailing list >>>>>>> OpenStack-dev@lists.openstack.org >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mike Scherbakov >>>>>> #mihgen >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Łukasz Oleś >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Mike Scherbakov >>> #mihgen >>> >>> >> >> >> -- >> Łukasz Oleś >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Łukasz Oleś
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev