Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla] About kolla-ansible reconfigure

[jason]

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)" <std...@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 <std...@cisco.com>

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

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

Hu,

Comments inline.

From: "hu.zhiji...@zte.com.cn" <hu.zhiji...@zte.com.cn>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Saturday, June 4, 2016 at 12:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@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.y

Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla] About kolla-ansible reconfigure

[Steven Dake (stdake)]

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 <std...@cisco.com<mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, June 4, 2016 at 1:01 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla] About 
kolla-ansible reconfigure

Hu,

Comments inline.

From: "hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>" 
<hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, June 4, 2016 at 12:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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 w

Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [Kolla] About kolla-ansible reconfigure

[Steven Dake (stdake)]

Hu,

Comments inline.

From: "hu.zhiji...@zte.com.cn" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Saturday, June 4, 2016 at 12:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
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)" >
收件人: 
"openstack-dev@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