From eblock at nde.ag Mon Jul 1 07:31:14 2019 From: eblock at nde.ag (Eugen Block) Date: Mon, 01 Jul 2019 07:31:14 +0000 Subject: glance image upload error [Errno 32] Broken pipe In-Reply-To: Message-ID: <20190701073114.Horde.OFwjjcHd__j9TawGaNnt3iK@webmail.nde.ag> Hi, have you checked if your glance services are still up and running? The error message indicates that it's not ceph but the glance endpoint that's not there. Regards, Eugen Zitat von Satish Patel : > I have installed opnestack-ansible and integrate glance with ceph > storage, first day when i upload image it works but today when i am > trying to upload image i am getting this error > > [root at ostack-infra-2-1-utility-container-c166f549 ~]# openstack image > create --file cirros-0.3.4-x86_64-disk.raw --container-format bare > --disk-format raw --public cirros-0.3.4-tmp > Error finding address for > http://172.28.8.9:9292/v2/images/8f3456aa-52fc-4b4a-8b11-dfbadb8e88ca/file: > [Errno 32] Broken pipe > > I do have enough space on ceph storage, i am not seeing any error on > glance logs also which help me. > > [root at ostack-infra-01-ceph-mon-container-692bea95 root]# ceph df detail > GLOBAL: > SIZE AVAIL RAW USED %RAW USED OBJECTS > 9314G 3526G 5787G 62.14 245k > POOLS: > NAME ID QUOTA OBJECTS QUOTA BYTES USED > %USED MAX AVAIL OBJECTS DIRTY READ WRITE RAW > USED > images 6 95367M N/A 22522M > 3.62 584G 2839 2839 2594k 36245 > 67568M > vms 7 N/A N/A 1912G > 76.58 584G 248494 242k 6567M 3363M > 5738G > volumes 8 N/A N/A 0 > 0 584G 0 0 0 0 > > backups 9 N/A N/A 0 > 0 584G 0 0 0 0 > > metrics 10 N/A N/A 0 > 0 584G 0 0 0 0 > From mark at stackhpc.com Mon Jul 1 08:10:34 2019 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 1 Jul 2019 09:10:34 +0100 Subject: [kolla-ansible] migration In-Reply-To: References:

Message-ID: It sounds like you got quite close to having this working. I'd suggest debugging this instance build failure. One difference with kolla is that we run libvirt inside a container. Have you stopped libvirt from running on the host? Mark On Sun, 30 Jun 2019 at 09:55, Ignazio Cassano wrote: > > Hi Mark, > let me to explain what I am trying. > I have a queens installation based on centos and pacemaker with some instances and heat stacks. > I would like to have another installation with same instances, projects, stacks ....I'd like to have same uuid for all objects (users,projects instances and so on, because it is controlled by a cloud management platform we wrote. > > I stopped controllers on old queens installation backupping the openstack database. > I installed the new kolla openstack queens on new three controllers with same addresses of the old intallation , vip as well. > One of the three controllers is also a kvm node on queens. > I stopped all containeres except rabbit,keepalive,rabbit,haproxy and mariadb. > I deleted al openstack db on mariadb container and I imported the old tables, changing the address of rabbit for pointing to the new rabbit cluster. > I restarded containers. > Changing the rabbit address on old kvm nodes, I can see the old virtual machines and I can open console on them. > I can see all networks (tenant and provider) of al installation, but when I try to create a new instance on the new kvm, it remains in buiding state. > Seems it cannot aquire an address. > Storage between old and new installation are shred on nfs NETAPP, so I can see cinder volumes. > I suppose db structure is different between a kolla installation and a manual instaltion !? > What is wrong ? > Thanks > Ignazio > > > > > Il giorno gio 27 giu 2019 alle ore 16:44 Mark Goddard ha scritto: >> >> On Thu, 27 Jun 2019 at 14:46, Ignazio Cassano wrote: >> > >> > Sorry, for my question. >> > It does not need to change anything because endpoints refer to haproxy vips. >> > So if your new glance works fine you change haproxy backends for glance. >> > Regards >> > Ignazio >> >> That's correct - only the haproxy backend needs to be updated. >> >> > >> > >> > Il giorno gio 27 giu 2019 alle ore 15:21 Ignazio Cassano ha scritto: >> >> >> >> Hello Mark, >> >> let me to verify if I understood your method. >> >> >> >> You have old controllers,haproxy,mariadb and nova computes. >> >> You installed three new controllers but kolla.ansible inventory contains old mariadb and old rabbit servers. >> >> You are deployng single service on new controllers staring with glance. >> >> When you deploy glance on new controllers, it changes the glance endpoint on old mariadb db ? >> >> Regards >> >> Ignazio >> >> >> >> Il giorno gio 27 giu 2019 alle ore 10:52 Mark Goddard ha scritto: >> >>> >> >>> On Wed, 26 Jun 2019 at 19:34, Ignazio Cassano wrote: >> >>> > >> >>> > Hello, >> >>> > Anyone have tried to migrate an existing openstack installation to kolla containers? >> >>> >> >>> Hi, >> >>> >> >>> I'm aware of two people currently working on that. Gregory Orange and >> >>> one of my colleagues, Pierre Riteau. Pierre is away currently, so I >> >>> hope he doesn't mind me quoting him from an email to Gregory. >> >>> >> >>> Mark >> >>> >> >>> "I am indeed working on a similar migration using Kolla Ansible with >> >>> Kayobe, starting from a non-containerised OpenStack deployment based >> >>> on CentOS RPMs. >> >>> Existing OpenStack services are deployed across several controller >> >>> nodes and all sit behind HAProxy, including for internal endpoints. >> >>> We have additional controller nodes that we use to deploy >> >>> containerised services. If you don't have the luxury of additional >> >>> nodes, it will be more difficult as you will need to avoid processes >> >>> clashing when listening on the same port. >> >>> >> >>> The method I am using resembles your second suggestion, however I am >> >>> deploying only one containerised service at a time, in order to >> >>> validate each of them independently. >> >>> I use the --tags option of kolla-ansible to restrict Ansible to >> >>> specific roles, and when I am happy with the resulting configuration I >> >>> update HAProxy to point to the new controllers. >> >>> >> >>> As long as the configuration matches, this should be completely >> >>> transparent for purely HTTP-based services like Glance. You need to be >> >>> more careful with services that include components listening for RPC, >> >>> such as Nova: if the new nova.conf is incorrect and you've deployed a >> >>> nova-conductor that uses it, you could get failed instances launches. >> >>> Some roles depend on others: if you are deploying the >> >>> neutron-openvswitch-agent, you need to run the openvswitch role as >> >>> well. >> >>> >> >>> I suggest starting with migrating Glance as it doesn't have any >> >>> internal services and is easy to validate. Note that properly >> >>> migrating Keystone requires keeping existing Fernet keys around, so >> >>> any token stays valid until the time it is expected to stop working >> >>> (which is fairly complex, see >> >>> https://bugs.launchpad.net/kolla-ansible/+bug/1809469). >> >>> >> >>> While initially I was using an approach similar to your first >> >>> suggestion, it can have side effects since Kolla Ansible uses these >> >>> variables when templating configuration. As an example, most services >> >>> will only have notifications enabled if enable_ceilometer is true. >> >>> >> >>> I've added existing control plane nodes to the Kolla Ansible inventory >> >>> as separate groups, which allows me to use the existing database and >> >>> RabbitMQ for the containerised services. >> >>> For example, instead of: >> >>> >> >>> [mariadb:children] >> >>> control >> >>> >> >>> you may have: >> >>> >> >>> [mariadb:children] >> >>> oldcontrol_db >> >>> >> >>> I still have to perform the migration of these underlying services to >> >>> the new control plane, I will let you know if there is any hurdle. >> >>> >> >>> A few random things to note: >> >>> >> >>> - if run on existing control plane hosts, the baremetal role removes >> >>> some packages listed in `redhat_pkg_removals` which can trigger the >> >>> removal of OpenStack dependencies using them! I've changed this >> >>> variable to an empty list. >> >>> - compare your existing deployment with a Kolla Ansible one to check >> >>> for differences in endpoints, configuration files, database users, >> >>> service users, etc. For Heat, Kolla uses the domain heat_user_domain, >> >>> while your existing deployment may use another one (and this is >> >>> hardcoded in the Kolla Heat image). Kolla Ansible uses the "service" >> >>> project while a couple of deployments I worked with were using >> >>> "services". This shouldn't matter, except there was a bug in Kolla >> >>> which prevented it from setting the roles correctly: >> >>> https://bugs.launchpad.net/kolla/+bug/1791896 (now fixed in latest >> >>> Rocky and Queens images) >> >>> - the ml2_conf.ini generated for Neutron generates physical network >> >>> names like physnet1, physnet2… you may want to override >> >>> bridge_mappings completely. >> >>> - although sometimes it could be easier to change your existing >> >>> deployment to match Kolla Ansible settings, rather than configure >> >>> Kolla Ansible to match your deployment." >> >>> >> >>> > Thanks >> >>> > Ignazio >> >>> > From bence.romsics at gmail.com Mon Jul 1 09:26:21 2019 From: bence.romsics at gmail.com (Bence Romsics) Date: Mon, 1 Jul 2019 11:26:21 +0200 Subject: [neutron] bug deputy report for week of 2019-06-24 Message-ID: Hi Everybody, These are the new bugs of last week: Critical: * https://bugs.launchpad.net/neutron/+bug/1834298 Neutron-fwaas python 3.7 job is broken Fix tested, needs +2 from neutron-fwaas cores: https://review.opendev.org/667736 * https://bugs.launchpad.net/neutron/+bug/1833902 Revert resize tests are failing in jobs with iptables_hybrid fw driver A nova bug breaking neutron gate. Fix merged: https://review.opendev.org/667035 High: * https://bugs.launchpad.net/neutron/+bug/1834257 dhcp-agent can overwhelm neutron server with dhcp_ready_on_ports RPC calls Fix in progress: https://review.opendev.org/659274 * https://bugs.launchpad.net/neutron/+bug/1834484 [QoS] qos_plugin._extend_port_resource_request is killing port retrieval performance Fix in progress: https://review.opendev.org/667981, https://review.opendev.org/667998 Medium: * https://bugs.launchpad.net/neutron/+bug/1834308 [DVR][DB] too many slow query during agent restart Needs more information to reproduce * https://bugs.launchpad.net/neutron/+bug/1834753 TC filter priority parameter in Pyroute is "prio" Fix in progress: https://review.opendev.org/668308 * https://bugs.launchpad.net/neutron/+bug/1834825 Rule to prevent SNAT for router's internal traffic is wrong Fix in progress: https://review.opendev.org/668378 RFE: * https://bugs.launchpad.net/neutron/+bug/1834174 [RFE] Add support for IPoIB interface driver * https://bugs.launchpad.net/neutron/+bug/1834176 [RFE] Add support for per-physnet interface driver Cheers, Bence (rubasov) From ignaziocassano at gmail.com Mon Jul 1 10:10:58 2019 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 1 Jul 2019 12:10:58 +0200 Subject: [kolla-ansible] migration In-Reply-To: References:

Message-ID: Hi Mark, the kolla environment has a new kvm host hosted on controller node. The kolla openstack can see instances on old kvm nodes and it can access them using vnc console porvided by dashboard, but cannot run new instances on new kvm host :-( Regards Ignazio Il giorno lun 1 lug 2019 alle ore 10:10 Mark Goddard ha scritto: > It sounds like you got quite close to having this working. I'd suggest > debugging this instance build failure. One difference with kolla is > that we run libvirt inside a container. Have you stopped libvirt from > running on the host? > Mark > > On Sun, 30 Jun 2019 at 09:55, Ignazio Cassano > wrote: > > > > Hi Mark, > > let me to explain what I am trying. > > I have a queens installation based on centos and pacemaker with some > instances and heat stacks. > > I would like to have another installation with same instances, projects, > stacks ....I'd like to have same uuid for all objects (users,projects > instances and so on, because it is controlled by a cloud management > platform we wrote. > > > > I stopped controllers on old queens installation backupping the > openstack database. > > I installed the new kolla openstack queens on new three controllers with > same addresses of the old intallation , vip as well. > > One of the three controllers is also a kvm node on queens. > > I stopped all containeres except rabbit,keepalive,rabbit,haproxy and > mariadb. > > I deleted al openstack db on mariadb container and I imported the old > tables, changing the address of rabbit for pointing to the new rabbit > cluster. > > I restarded containers. > > Changing the rabbit address on old kvm nodes, I can see the old virtual > machines and I can open console on them. > > I can see all networks (tenant and provider) of al installation, but > when I try to create a new instance on the new kvm, it remains in buiding > state. > > Seems it cannot aquire an address. > > Storage between old and new installation are shred on nfs NETAPP, so I > can see cinder volumes. > > I suppose db structure is different between a kolla installation and a > manual instaltion !? > > What is wrong ? > > Thanks > > Ignazio > > > > > > > > > > Il giorno gio 27 giu 2019 alle ore 16:44 Mark Goddard > ha scritto: > >> > >> On Thu, 27 Jun 2019 at 14:46, Ignazio Cassano > wrote: > >> > > >> > Sorry, for my question. > >> > It does not need to change anything because endpoints refer to > haproxy vips. > >> > So if your new glance works fine you change haproxy backends for > glance. > >> > Regards > >> > Ignazio > >> > >> That's correct - only the haproxy backend needs to be updated. > >> > >> > > >> > > >> > Il giorno gio 27 giu 2019 alle ore 15:21 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> >> > >> >> Hello Mark, > >> >> let me to verify if I understood your method. > >> >> > >> >> You have old controllers,haproxy,mariadb and nova computes. > >> >> You installed three new controllers but kolla.ansible inventory > contains old mariadb and old rabbit servers. > >> >> You are deployng single service on new controllers staring with > glance. > >> >> When you deploy glance on new controllers, it changes the glance > endpoint on old mariadb db ? > >> >> Regards > >> >> Ignazio > >> >> > >> >> Il giorno gio 27 giu 2019 alle ore 10:52 Mark Goddard < > mark at stackhpc.com> ha scritto: > >> >>> > >> >>> On Wed, 26 Jun 2019 at 19:34, Ignazio Cassano < > ignaziocassano at gmail.com> wrote: > >> >>> > > >> >>> > Hello, > >> >>> > Anyone have tried to migrate an existing openstack installation > to kolla containers? > >> >>> > >> >>> Hi, > >> >>> > >> >>> I'm aware of two people currently working on that. Gregory Orange > and > >> >>> one of my colleagues, Pierre Riteau. Pierre is away currently, so I > >> >>> hope he doesn't mind me quoting him from an email to Gregory. > >> >>> > >> >>> Mark > >> >>> > >> >>> "I am indeed working on a similar migration using Kolla Ansible with > >> >>> Kayobe, starting from a non-containerised OpenStack deployment based > >> >>> on CentOS RPMs. > >> >>> Existing OpenStack services are deployed across several controller > >> >>> nodes and all sit behind HAProxy, including for internal endpoints. > >> >>> We have additional controller nodes that we use to deploy > >> >>> containerised services. If you don't have the luxury of additional > >> >>> nodes, it will be more difficult as you will need to avoid processes > >> >>> clashing when listening on the same port. > >> >>> > >> >>> The method I am using resembles your second suggestion, however I am > >> >>> deploying only one containerised service at a time, in order to > >> >>> validate each of them independently. > >> >>> I use the --tags option of kolla-ansible to restrict Ansible to > >> >>> specific roles, and when I am happy with the resulting > configuration I > >> >>> update HAProxy to point to the new controllers. > >> >>> > >> >>> As long as the configuration matches, this should be completely > >> >>> transparent for purely HTTP-based services like Glance. You need to > be > >> >>> more careful with services that include components listening for > RPC, > >> >>> such as Nova: if the new nova.conf is incorrect and you've deployed > a > >> >>> nova-conductor that uses it, you could get failed instances > launches. > >> >>> Some roles depend on others: if you are deploying the > >> >>> neutron-openvswitch-agent, you need to run the openvswitch role as > >> >>> well. > >> >>> > >> >>> I suggest starting with migrating Glance as it doesn't have any > >> >>> internal services and is easy to validate. Note that properly > >> >>> migrating Keystone requires keeping existing Fernet keys around, so > >> >>> any token stays valid until the time it is expected to stop working > >> >>> (which is fairly complex, see > >> >>> https://bugs.launchpad.net/kolla-ansible/+bug/1809469). > >> >>> > >> >>> While initially I was using an approach similar to your first > >> >>> suggestion, it can have side effects since Kolla Ansible uses these > >> >>> variables when templating configuration. As an example, most > services > >> >>> will only have notifications enabled if enable_ceilometer is true. > >> >>> > >> >>> I've added existing control plane nodes to the Kolla Ansible > inventory > >> >>> as separate groups, which allows me to use the existing database and > >> >>> RabbitMQ for the containerised services. > >> >>> For example, instead of: > >> >>> > >> >>> [mariadb:children] > >> >>> control > >> >>> > >> >>> you may have: > >> >>> > >> >>> [mariadb:children] > >> >>> oldcontrol_db > >> >>> > >> >>> I still have to perform the migration of these underlying services > to > >> >>> the new control plane, I will let you know if there is any hurdle. > >> >>> > >> >>> A few random things to note: > >> >>> > >> >>> - if run on existing control plane hosts, the baremetal role removes > >> >>> some packages listed in `redhat_pkg_removals` which can trigger the > >> >>> removal of OpenStack dependencies using them! I've changed this > >> >>> variable to an empty list. > >> >>> - compare your existing deployment with a Kolla Ansible one to check > >> >>> for differences in endpoints, configuration files, database users, > >> >>> service users, etc. For Heat, Kolla uses the domain > heat_user_domain, > >> >>> while your existing deployment may use another one (and this is > >> >>> hardcoded in the Kolla Heat image). Kolla Ansible uses the "service" > >> >>> project while a couple of deployments I worked with were using > >> >>> "services". This shouldn't matter, except there was a bug in Kolla > >> >>> which prevented it from setting the roles correctly: > >> >>> https://bugs.launchpad.net/kolla/+bug/1791896 (now fixed in latest > >> >>> Rocky and Queens images) > >> >>> - the ml2_conf.ini generated for Neutron generates physical network > >> >>> names like physnet1, physnet2… you may want to override > >> >>> bridge_mappings completely. > >> >>> - although sometimes it could be easier to change your existing > >> >>> deployment to match Kolla Ansible settings, rather than configure > >> >>> Kolla Ansible to match your deployment." > >> >>> > >> >>> > Thanks > >> >>> > Ignazio > >> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Jul 1 10:38:13 2019 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 1 Jul 2019 12:38:13 +0200 Subject: [kolla-ansible] migration In-Reply-To: References:

Message-ID: PS I presume the problem is neutron, because instances on new kvm nodes remain in building state e do not aquire address. Probably the netron db imported from old openstack installation has some difrrences ....probably I must check defferences from old and new neutron services configuration files. Ignazio Il giorno lun 1 lug 2019 alle ore 10:10 Mark Goddard ha scritto: > It sounds like you got quite close to having this working. I'd suggest > debugging this instance build failure. One difference with kolla is > that we run libvirt inside a container. Have you stopped libvirt from > running on the host? > Mark > > On Sun, 30 Jun 2019 at 09:55, Ignazio Cassano > wrote: > > > > Hi Mark, > > let me to explain what I am trying. > > I have a queens installation based on centos and pacemaker with some > instances and heat stacks. > > I would like to have another installation with same instances, projects, > stacks ....I'd like to have same uuid for all objects (users,projects > instances and so on, because it is controlled by a cloud management > platform we wrote. > > > > I stopped controllers on old queens installation backupping the > openstack database. > > I installed the new kolla openstack queens on new three controllers with > same addresses of the old intallation , vip as well. > > One of the three controllers is also a kvm node on queens. > > I stopped all containeres except rabbit,keepalive,rabbit,haproxy and > mariadb. > > I deleted al openstack db on mariadb container and I imported the old > tables, changing the address of rabbit for pointing to the new rabbit > cluster. > > I restarded containers. > > Changing the rabbit address on old kvm nodes, I can see the old virtual > machines and I can open console on them. > > I can see all networks (tenant and provider) of al installation, but > when I try to create a new instance on the new kvm, it remains in buiding > state. > > Seems it cannot aquire an address. > > Storage between old and new installation are shred on nfs NETAPP, so I > can see cinder volumes. > > I suppose db structure is different between a kolla installation and a > manual instaltion !? > > What is wrong ? > > Thanks > > Ignazio > > > > > > > > > > Il giorno gio 27 giu 2019 alle ore 16:44 Mark Goddard > ha scritto: > >> > >> On Thu, 27 Jun 2019 at 14:46, Ignazio Cassano > wrote: > >> > > >> > Sorry, for my question. > >> > It does not need to change anything because endpoints refer to > haproxy vips. > >> > So if your new glance works fine you change haproxy backends for > glance. > >> > Regards > >> > Ignazio > >> > >> That's correct - only the haproxy backend needs to be updated. > >> > >> > > >> > > >> > Il giorno gio 27 giu 2019 alle ore 15:21 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> >> > >> >> Hello Mark, > >> >> let me to verify if I understood your method. > >> >> > >> >> You have old controllers,haproxy,mariadb and nova computes. > >> >> You installed three new controllers but kolla.ansible inventory > contains old mariadb and old rabbit servers. > >> >> You are deployng single service on new controllers staring with > glance. > >> >> When you deploy glance on new controllers, it changes the glance > endpoint on old mariadb db ? > >> >> Regards > >> >> Ignazio > >> >> > >> >> Il giorno gio 27 giu 2019 alle ore 10:52 Mark Goddard < > mark at stackhpc.com> ha scritto: > >> >>> > >> >>> On Wed, 26 Jun 2019 at 19:34, Ignazio Cassano < > ignaziocassano at gmail.com> wrote: > >> >>> > > >> >>> > Hello, > >> >>> > Anyone have tried to migrate an existing openstack installation > to kolla containers? > >> >>> > >> >>> Hi, > >> >>> > >> >>> I'm aware of two people currently working on that. Gregory Orange > and > >> >>> one of my colleagues, Pierre Riteau. Pierre is away currently, so I > >> >>> hope he doesn't mind me quoting him from an email to Gregory. > >> >>> > >> >>> Mark > >> >>> > >> >>> "I am indeed working on a similar migration using Kolla Ansible with > >> >>> Kayobe, starting from a non-containerised OpenStack deployment based > >> >>> on CentOS RPMs. > >> >>> Existing OpenStack services are deployed across several controller > >> >>> nodes and all sit behind HAProxy, including for internal endpoints. > >> >>> We have additional controller nodes that we use to deploy > >> >>> containerised services. If you don't have the luxury of additional > >> >>> nodes, it will be more difficult as you will need to avoid processes > >> >>> clashing when listening on the same port. > >> >>> > >> >>> The method I am using resembles your second suggestion, however I am > >> >>> deploying only one containerised service at a time, in order to > >> >>> validate each of them independently. > >> >>> I use the --tags option of kolla-ansible to restrict Ansible to > >> >>> specific roles, and when I am happy with the resulting > configuration I > >> >>> update HAProxy to point to the new controllers. > >> >>> > >> >>> As long as the configuration matches, this should be completely > >> >>> transparent for purely HTTP-based services like Glance. You need to > be > >> >>> more careful with services that include components listening for > RPC, > >> >>> such as Nova: if the new nova.conf is incorrect and you've deployed > a > >> >>> nova-conductor that uses it, you could get failed instances > launches. > >> >>> Some roles depend on others: if you are deploying the > >> >>> neutron-openvswitch-agent, you need to run the openvswitch role as > >> >>> well. > >> >>> > >> >>> I suggest starting with migrating Glance as it doesn't have any > >> >>> internal services and is easy to validate. Note that properly > >> >>> migrating Keystone requires keeping existing Fernet keys around, so > >> >>> any token stays valid until the time it is expected to stop working > >> >>> (which is fairly complex, see > >> >>> https://bugs.launchpad.net/kolla-ansible/+bug/1809469). > >> >>> > >> >>> While initially I was using an approach similar to your first > >> >>> suggestion, it can have side effects since Kolla Ansible uses these > >> >>> variables when templating configuration. As an example, most > services > >> >>> will only have notifications enabled if enable_ceilometer is true. > >> >>> > >> >>> I've added existing control plane nodes to the Kolla Ansible > inventory > >> >>> as separate groups, which allows me to use the existing database and > >> >>> RabbitMQ for the containerised services. > >> >>> For example, instead of: > >> >>> > >> >>> [mariadb:children] > >> >>> control > >> >>> > >> >>> you may have: > >> >>> > >> >>> [mariadb:children] > >> >>> oldcontrol_db > >> >>> > >> >>> I still have to perform the migration of these underlying services > to > >> >>> the new control plane, I will let you know if there is any hurdle. > >> >>> > >> >>> A few random things to note: > >> >>> > >> >>> - if run on existing control plane hosts, the baremetal role removes > >> >>> some packages listed in `redhat_pkg_removals` which can trigger the > >> >>> removal of OpenStack dependencies using them! I've changed this > >> >>> variable to an empty list. > >> >>> - compare your existing deployment with a Kolla Ansible one to check > >> >>> for differences in endpoints, configuration files, database users, > >> >>> service users, etc. For Heat, Kolla uses the domain > heat_user_domain, > >> >>> while your existing deployment may use another one (and this is > >> >>> hardcoded in the Kolla Heat image). Kolla Ansible uses the "service" > >> >>> project while a couple of deployments I worked with were using > >> >>> "services". This shouldn't matter, except there was a bug in Kolla > >> >>> which prevented it from setting the roles correctly: > >> >>> https://bugs.launchpad.net/kolla/+bug/1791896 (now fixed in latest > >> >>> Rocky and Queens images) > >> >>> - the ml2_conf.ini generated for Neutron generates physical network > >> >>> names like physnet1, physnet2… you may want to override > >> >>> bridge_mappings completely. > >> >>> - although sometimes it could be easier to change your existing > >> >>> deployment to match Kolla Ansible settings, rather than configure > >> >>> Kolla Ansible to match your deployment." > >> >>> > >> >>> > Thanks > >> >>> > Ignazio > >> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From missile0407 at gmail.com Mon Jul 1 11:23:19 2019 From: missile0407 at gmail.com (Eddie Yen) Date: Mon, 1 Jul 2019 19:23:19 +0800 Subject: [kolla][ceph] Cache OSDs didn't stay in the root=cache after ceph deployment. Message-ID: Hi, I'm using stable/rocky to try ceph cache tiering. Now I'm facing a one issue. I chose one SSD to become cache tier disk. And set below options in globals.yml. ceph_enable_cache = "yes" ceph_target_max_byte= "" ceph_target_max_objects = "