Open Stack

Hi JP,

Firstly thank you for your response.

Over the weekend, I did something kind of similar to what you describe.

1. Built a AIO (inside main OSA) @ 16.04/Newton
2. took it's venv files and placed them in the higher level OSAs repo
but as - Example: glance....-xenial.tgz
3. copied the existing (14.04 based) venv files to glance.....-trusty.tgz
4. Updated the os-{component}-install.yml playbooks to have '-{{
ansible_distribution_release | lower }}' in their respective
_venv_download_url: variable.
5. cleared facts, destroyed containers (the new ones), ran
setup-hosts,setup-infra(without repo-install), setup-openstack.
6.  All good.

Today I am proceeding with my other infrastructure nodes.  When I make
it through all 16.04 upgrades I plan on rebuilding the repo_container
for all repo_hosts.

I didn't do something like shut off the other || old-14.04 containers
as you described above as I thought that it would deploy 16.04 based
venvs to my existing 14.04 servers as I roll through them one at a
time.  Is that correct ?

again thank you very much for your time.

Best Regards,
Wade

On Mon, Dec 19, 2016 at 2:35 AM, Jean-Philippe Evrard
<Jean-Philippe.Evrard at rackspace.co.uk> wrote:
> Hello,
>
> This sounds like an interesting issue that we should fix as soon as possible.
> May I ask you more details on the channel?
>
> It’s still brainstorming, but I think that if you clear facts, destroy/upgrade one controller node, then make sure this controller node has a repo under 16.04, it should be the basis for the rest of the infrastructure, and ssl libs linking shouldn’t be an issue.
> Could you make sure the other repo containers are stopped, this way your load balancer always returns the repo server on the new controller?
> Then, we doing openstack services upgrade, could you continue the way you explained by destroying the container (let’s say for glance for example) and rebuilding? It should be taking the new repo server with the new venv, which should be fine (in theory).
>
> When all of that is done, I think we could have lots of fun with the ssl libs issue :D
>
> Best regards,
> JP
>
> On 17/12/2016, 00:36, "Wade Holler" <wade.holler at gmail.com> wrote:
>
>     Hi All,
>
>     I am trying to upgrade a multinode cluster that has been very valuable
>     in our environment.
>
>     The idea was to start at trusty/mitaka and get to xenial/newton.
>
>     Step1 mitaka -> newton on a trusty environment went fine.
>     Step2 trusty to xenial is not going well and I could use some help.
>
>     So far I rebuilt the 1st of 3 infra nodes with Xenial. Then re-ran
>     setup-hosts, setup-infrastructure, setup-openstack.
>
>     All playbooks ran fairly clean ( relative to the current issue ) -
>     HOWEVER the services don't actually start on the Xenial / 16.04 based
>     containers.  They just keep dying.
>
>     Example error from a glance container here: http://pastebin.com/E6DvWdHy
>
>     I jumped on IRC and "logan" was nice enough to help.  We deleted the
>     glance container, cleared ansible_facts and rebuilt.  Same errors
>     though.  "logan" mentioned that he thought since the repo-build  /
>     requirement wheels were getting built on a trusty base / container
>     that the wheels / venvs that make it to the 16.04 container are not
>     compatible.
>
>
>     So, can anyone advise on how to proceed ?
>
>     Is there someway to not use the repo_server for the 16.04 hosts, then
>     when all infra is at 16.04 re-enable the repo_server.  Just brain
>     storming.  Any help would be very welcome.
>
>     Best Regards,
>     Wade
>     wade.holler at gmail.com
>     irc: wadeholler
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> ________________________________
> Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com and delete the original message. Your cooperation is appreciated.