Open Stack

Hi Steve,
I'v tried stopping all container then modify VIP then do "kolla-ansible
deploy" again. It works as expected and i saw that the endpoint in keystone
database also changed ...magically.
2016年6月5日 下午3:04，"Steven Dake (stdake)" <stdake at cisco.com>写道：

Hu,

Thinking more about my proposed workarounds, I don’t think they will work
because services are registered with keystone using the kolla external fqdn
and internal fqdn.  If you didn't specify those originally (and instead are
using IP addresses which fqdn defaults to if not specified) kolla won't
change endpoint registrations magically.

A solution for changing VIPs must involve some kind of keystone
reregistration.

For each config value in globals.yml, this kind of individual analysis must
be carried out and implemented throughout the playbooks.  As you can see by
this single case, the implementation requires lots of experimentation on
each variable to permit changes.  I'm not certain in what development cycle
that work will begin or end.  It definitely wont be backported as its a
feature.

Regards
-steve


From: Steven Dake <stdake at cisco.com>

Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Date: Saturday, June 4, 2016 at 1:01 AM

To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla]
About kolla-ansible reconfigure

Hu,

Comments inline.

From: "hu.zhijiang at zte.com.cn" <hu.zhijiang at zte.com.cn>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Date: Saturday, June 4, 2016 at 12:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Subject: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla] About
kolla-ansible reconfigure

Hi Steven,


Thanks for the information. Some further questions:

> Reconfigure was not designed to handle changes to globals.yml.  I think
its a good goal that it should be able to do so, but it does not today.

So waht is the prefered method to change kolla_internal_vip_address and
make it effective?


I can't think of any known way to do this.  Internal VIPs are typically
permanent allocations.  Reconfigure iIRC does not copy configuration files
if there are no changes to the relevant /etc/kolla/config/* file (such as
nova.conf).  Since you can't get new config files generated on your
deployed targets, the containers won't pick them up.  If they did pick them
up, they wouldn't actually restart because they are designed to only
restart on a reconfigure operation that reconfigures something (I.e. there
is new config content).

One option that comes to mind is to login to every host in your cluster,
sed replace the original internal VIP address in every file in /etc/kolla/*
with the new one, then docker stop every container on every node, then
docker start every container on every node.  I know, not optimal and only
works with COPY_ALWAYS.  This could be automated in an ansible playbook
with relative ease.

Another way that may work (less confidence here) is to stop every container
on every node, and run kolla-ansible deploy.  There is no stop operation in
kolla-ansible – but you can look at the cleanup code here to craft your own:

https://github.com/openstack/kolla/blob/master/ansible/cleanup.yml
https://github.com/openstack/kolla/blob/master/tools/kolla-ansible#L45
https://github.com/openstack/kolla/blob/master/ansible/roles/cleanup/tasks/main.yml#L1-L4

Make certain to leave out line 6 – as that removes named volumes (you would
lose your persistent data).  You only need lines 1-4 (of main.yml).

Please file a bug.

Maybe someone else has a more elegant solution.


> Reconfigure was designed to handle changes to /etc/kolla/config/* (where
custom config for services live).  Reconfigure in its current incarnation
in all our branches and master is really a misnomer – it should be
 service-reconfgiure – but that is wordy and we plan to make globals.yml
reconfigurable if feasible – but probably not anytime soon.

There is no /etc/kolla/config/* located in my env before or after
successful deployment. Is that right?


That is right.  To provide custom configuration for nova for example, you
could add a /etc/kolla/config/nova.conf file and put:

[libvirt]
virt_typer=qemu

(documented here:
http://docs.openstack.org/developer/kolla/deployment-philosophy.html)

Run reconfigure and from that point forward all of your machines would use
QEMU software emulation instead of KVM hardware virt.  The use case the
reconfigure action was designed to handle was reconfiguring
/etc/kolla/config files, (e.g. Merging custom config with defaults while
overriding when that is called for).

Handling a reconfiguration of globals.yml and passwords.yml is much more
complex.  I'd like to see us get reconfigure for passwords working next for
password rotation required by various government regulations.

There are a lot of problems that come to mind with reconfiguring
globals.yml.  I'm not quite sure how it could sanely be implemented without
a full cluster shutdown followed by a full cluster start.  This would
require adding a stop operation.  Deploy already starts containers for us.

Regards
-steve






发件人:         "Steven Dake (stdake)" <stdake at cisco.com>
收件人:         "openstack-dev at lists.openstack.org" <
openstack-dev at lists.openstack.org>,
日期:         2016-06-03 06:16
主题:        [probably forge email可能是仿冒邮件]Re: [openstack-dev] [Kolla] About
kolla-ansible reconfigure
------------------------------



Hu,

Reconfigure was not designed to handle changes to globals.yml.  I think its
a good goal that it should be able to do so, but it does not today.

Reconfigure was designed to handle changes to /etc/kolla/config/* (where
custom config for services live).  Reconfigure in its current incarnation
in all our branches and master is really a misnomer – it should be
service-reconfgiure – but that is wordy and we plan to make globals.yml
reconfigurable if feasible – but probably not anytime soon.

Regards
-steve


*From: *"*hu.zhijiang at zte.com.cn* <hu.zhijiang at zte.com.cn>" <
*hu.zhijiang at zte.com.cn* <hu.zhijiang at zte.com.cn>>
* Reply-To: *"*openstack-dev at lists.openstack.org*
<openstack-dev at lists.openstack.org>" <*openstack-dev at lists.openstack.org*
<openstack-dev at lists.openstack.org>>
* Date: *Wednesday, June 1, 2016 at 6:24 PM
* To: *"*openstack-dev at lists.openstack.org*
<openstack-dev at lists.openstack.org>" <*openstack-dev at lists.openstack.org*
<openstack-dev at lists.openstack.org>>
* Subject: *[openstack-dev] [Kolla] About kolla-ansible reconfigure

Hi

After modifying the kolla_internal_vip_address in /etc/kolla/global.yml , I
use kolla-ansible reconfigure to reconfigure OpenStack. But I got the
following error.

TASK: [mariadb | Restart containers]
******************************************
skipping: [localhost] => (item=[{'group': 'mariadb', 'name': 'mariadb'},
{'KOLLA_BASE_DISTRO': 'centos', 'PS1': '$(tput bold)($(printenv
KOLLA_SERVICE_NAME))$(tput sgr0)[$(id -un)@$(hostname -s) $(pwd)]$ ',
'KOLLA_INSTALL_TYPE': 'binary', 'changed': False, 'item': {'group':
'mariadb', 'name': 'mariadb'}, 'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS',
'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
'invocation': {'module_name': u'kolla_docker', 'module_complex_args':
{'action': 'get_container_env', 'name': u'mariadb'}, 'module_args': ''},
'KOLLA_SERVICE_NAME': 'mariadb', 'KOLLA_INSTALL_METATYPE': 'rdo'}, {'cmd':
['docker', 'exec', 'mariadb', '/usr/local/bin/kolla_set_configs',
'--check'], 'end': '2016-06-02 11:32:18.866276', 'stderr':
'INFO:__main__:Loading config file at
/var/lib/kolla/config_files/config.json\nINFO:__main__:Validating config
file\nINFO:__main__:The config files are in the expected state', 'stdout':
u'', 'item': {'group': 'mariadb', 'name': 'mariadb'}, 'changed': False,
'rc': 0, 'failed': False, 'warnings': [], 'delta': '0:00:00.075316',
'invocation': {'module_name': u'command', 'module_complex_args': {},
'module_args': u'docker exec mariadb /usr/local/bin/kolla_set_configs
--check'}, 'stdout_lines': [], 'failed_when_result': False, 'start':
'2016-06-02 11:32:18.790960'}])

TASK: [mariadb | Waiting for MariaDB service to be ready through VIP]
*********
failed: [localhost] => {"attempts": 6, "changed": false, "cmd": ["docker",
"exec", "mariadb", "mysql", "-h", "10.43.114.148/24", "-u", "haproxy",
"-e", "show databases;"], "delta": "0:00:03.924516", "end": "2016-06-02
11:33:57.928139", "failed": true, "rc": 1, "start": "2016-06-02
11:33:54.003623", "stdout_lines": [], "warnings": []}
stderr: ERROR 2005 (HY000): Unknown MySQL server host '10.43.114.148/24'
(-2)
msg: Task failed as maximum retries was encountered

FATAL: all hosts have already failed -- aborting


It seems that mariadb was not restart as expected.


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
(and any attachment transmitted herewith) is privileged and confidential
and is intended for the exclusive use of the addressee(s).  If you are not
an intended recipient, any disclosure, reproduction, distribution or other
dissemination or use of the information contained is strictly prohibited.
If you have received this mail in error, please delete it and notify us
immediately.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this
mail (and any attachment transmitted herewith) is privileged and
confidential and is intended for the exclusive use of the
addressee(s).  If you are not an intended recipient, any disclosure,
reproduction, distribution or other dissemination or use of the
information contained is strictly prohibited.  If you have received
this mail in error, please delete it and notify us immediately.




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160612/f6701c36/attachment.html>