[Openstack-operators] CentOS upgrade killed my Liberty system

2017-10-09 Thread Christopher Hull
Hi all;

About 18 months ago I did a piece by piece install of Liberty (following
instructions on the Openstack page) and had been using it until somewhat
recently when it broke after a CentOS 7 update ran.  I think Python/http is
what changed / broke (sessionless connections no longer supported?).
Basics like nova list still work, but Horizon won't run.

How can I "downgrade" my CentOS box?
Or alternatively, how painful is it to update to the most current
Openstack?

Also, I noticed that the CeotOS cloud SIG repo moved.

Please help.  :-)

BTW, for installs I wrote a tool to help with setting up the many Openstack
config files.   If interested, you can find it here.
http://chrishull.com/career/openstack/index.html
https://github.com/chrishull/github-openstack

Several months ago I tried to check this into the Openstack Operators GIT
repo, but had difficulty.

Anyway.  Please advise on how I can fix my Liberty system if you can.

Thanks;
-Chris












- Christopher T. Hull
My contract at NASA has ended and I am seeking new opportunities.
For updated resume and other info, please click this link.
http://faq.chrishull.com
Sunnyvale CA. 94085
(415) 385 4865
chrishul...@gmail.com
http://chrishull.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] Designate DNS service on Mitaka

2017-10-09 Thread Alexandra Kisin
Hello. 
Is there any installation / configuration guide for Designate service in 
Mitaka release (Ubuntu 14.04) ? 
And also I didn't find any detailed instructions for designate upgrade 
from Liberty to Mitaka. 

Thank you. 


Regards,

Alexandra Kisin
Servers & Network group, IBM R Labs in Israel
Unix & Virtualization Team


Phone: +972-48296172 | Mobile: +972-54-6976172 | Fax: +972-4-8296111









___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] COMING SOON! NEW COMMUNITY PORTAL!

2017-10-09 Thread Melvin Hillsman
Hi everyone,

We are planning to update openstack.org/community with a new fancy
contributor portal.

We would love to get your feedback. As a new user:

   - What is the first thing you should do try OpenStack?
   - How can you build a proof of concept?
   - Reading documentation or watching relevant summit videos
   - Reporting bugs
   - Grabbing tools from osops
   - Participating in the Forum and SIGs
   - etc...



*Please respond to this thread or add feedback to the etherpad by Monday,
October 16th, 2017.*

https://etherpad.openstack.org/p/contributor-portal-user-section

Mockups for reference:

*PNG* - https://www.dropbox.com/sh/h7c2as0ko33e64y/AAANLpcFHQo
1fsIcZBNivtrma?dl=0
*Invision* - https://invis.io/CSDEZTBDJ#/252645774_Landing
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] Libvirt CPU map (host-model)

2017-10-09 Thread Paul Browne
Hello Belmiro,

We ran into this issue recently, similarly upgrading a RHEL7.3 OpenStack
Platform Overcloud to RHEL7.4 and in the process upgrading libvirtd.

For instances that were spawned prior to this upgrade, we see the CPU flags
[1] , but for new instance workload the CPU flags [2]. Notably the
CMT=disabled flag is present in [1] but absent in [2]

This similarly prevents live migration of the older spawned instances, as
the CMT=disabled flag is rejected.

A RH bugzilla [3] was opened on the issue which attracted a lot of really
good contributions from libvirt maintainers. The one sure-fire workaround
we'd found is just to cold-boot the instance again, starting it under the
new libvirtd. But from that BZ there is also a slightly more hack-ish
workaround to hand-edit the running domain XML and clear the offending CMT
flag (comment 12 on that BZ).

Hope this helps some,

Thanks,
Paul Browne

[1] https://pastebin.com/JshWi6i3
[2] https://pastebin.com/5b8cAanP
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1495171

On 9 October 2017 at 04:59, Belmiro Moreira <
moreira.belmiro.email.li...@gmail.com> wrote:

> Hi,
> the CPU model that we expose to the guest VMs varies considering the
> compute node use case.
> We use "cpu_mode=host-passthrough" for the compute nodes that run batch
> processing VMs and "cpu_mode=host-model" for the compute nodes for service
> VMs. The reason to have "cpu_mode=host-model" is because we assumed that
> new CPUs (in the libvirt map) will continue to support previous features
> allowing for live migration when we need to move the VMs to a new CPU
> generation.
>
> We recently upgraded from CentOS7.3 (libvirt 2.0.0) to CentOS7.4 (libvirt
> 3.2.0) and noticed that now libvirt maps a slightly different CPU for the
> guests. For example, still "Haswell no-TSX" but no mention to the feature
> "cmt". This blocks suspended VMs to restore and live migrate.
>
> Has anyone experienced this same problem?
>
> We are thinking in few solutions but none of them are nice (downgrade
> libvirt? hard reboot instances? ...)
>
> thanks,
> Belmiro
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
***
Paul Browne
Research Computing Platforms
University Information Services
Roger Needham Building
JJ Thompson Avenue
University of Cambridge
Cambridge
United Kingdom
E-Mail: pf...@cam.ac.uk
Tel: 0044-1223-746548
***
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators