Open Stack

Hu,

Comments inline.

From: "hu.zhijiang at zte.com.cn<mailto:hu.zhijiang at zte.com.cn>" <hu.zhijiang at zte.com.cn<mailto:hu.zhijiang at zte.com.cn>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:stdake at cisco.com>>
收件人:         "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto: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<mailto:hu.zhijiang at zte.com.cn>" <hu.zhijiang at zte.com.cn<mailto:hu.zhijiang at zte.com.cn>>
Reply-To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, June 1, 2016 at 6:24 PM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto: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<mailto: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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160604/b89c317a/attachment.html>