Open Stack

Many tHanks
Ignazio

Il Mer 2 Ott 2019, 09:44 Pierre Riteau <pierre at stackhpc.com> ha scritto:

> Hi everyone,
>
> I hope you don't mind me reviving this thread, to let you know I wrote
> an article after we successfully completed the migration of a running
> OpenStack deployment to Kolla:
> http://www.stackhpc.com/migrating-to-kolla.html
>
> Don't hesitate to contact me if you have more questions about how this
> type of migration can be performed.
>
> Pierre
>
> On Mon, 1 Jul 2019 at 14:02, Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
> >
> > I checked them and I modified for fitting to new installation
> > thanks
> > Ignazio
> >
> > Il giorno lun 1 lug 2019 alle ore 13:36 Mohammed Naser <
> mnaser at vexxhost.com> ha scritto:
> >>
> >> You should check your cell mapping records inside Nova.  They're
> probably not right of you moved your database and rabbit
> >>
> >> Sorry for top posting this is from a phone.
> >>
> >> On Mon., Jul. 1, 2019, 5:46 a.m. Ignazio Cassano, <
> ignaziocassano at gmail.com> wrote:
> >>>
> >>> 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 <
> mark at stackhpc.com> 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 <
> ignaziocassano at gmail.com> 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 <
> mark at stackhpc.com> ha scritto:
> >>>> >>
> >>>> >> On Thu, 27 Jun 2019 at 14:46, Ignazio Cassano <
> ignaziocassano at gmail.com> 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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191002/51e7f987/attachment-0001.html>