[Openstack-operators] [openstack-ansible][queens] networking_sfc plugin not found - venv pb ?

[nicolas]

OpenStack version : stable/queens
OSA version   : 17.0.9.dev22
python env version: python2.7
operating system  : Ubuntu Server 16.04


Hi all,
I was trying to install the *networking_sfc* plugin on my openstack 
environment thanks to OSA,

but it failed. But I may have found the problem.


I think the problem comes from the python virtualenv and the 
networking_sfc python package that is not installed by OSA.

Thanks to OSA, I have a python2.7 virtualenv on my neutron-server:
"/openstack/venvs/neutron-17.0.9/lib/python2.7"

I think its a bug in OSA. But maybe I missed something.


These are my steps:
1. Following the inspiration from here (link below), but without 
installing ODL.

I modified the OSA "user_variables.yml" like this.
https://docs.openstack.org/openstack-ansible-os_neutron/latest/app-opendaylight.html

  user@OSA: vim /etc/openstack_deploy/user_variables.yml
  ```
  [...]
  neutron_plugin_base:
   - router
   - metering
   - networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin
   - networking_sfc.services.sfc.plugin.SfcPlugin
  [...]
  ```


2. After the OSA deployment is finished with success (with 0 failed), I 
can see in the neutron-server log that plugins related to SFC are not 
found.


  user@neutron-serveur: less /var/log/neutron/neutron-server.log
  ```
  [...]
  Plugin 
'networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin' not 
found.

  [...]
  ```


3. I decided to manually install [over my OSA deployment] and configure 
networking_sfc following these links:

* https://docs.openstack.org/networking-sfc/latest/install/install.html
* https://docs.openstack.org/releasenotes/networking-sfc/queens.html

I install with pip (python2.7).

BUT first, I must source the right venv (OSA seems to be prepared for 
that):
  user@neutron-serveur: source 
/openstack/venvs/neutron-17.0.9/bin/activate


Then I install networking-sfc:
  (neutron-17.0.9) user@neutron-serveur: pip install -c 
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/queens 
networking-sfc==6.0.0


The install seems to be ok (no error, only Ignoring python3.x version of 
soft).


Then, I modify the neutron config files like this:
https://docs.openstack.org/networking-sfc/latest/install/configuration.html

And then it seems to be good so far (`openstack network agent list` show 
all the agent needed, but I have not tested SFC feature yet. I can keep 
you updated next week).





Also, I don't have the CLI "neutron-db-manage" and I don't find how to 
install/use it. And I don't know if this is important for OSA.


Best regards,
--
Nicolas

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

Re: [Openstack-operators] [openstack-ansible] configuration file override

[Budai Laszlo]

On 21.08.2018 12:32, jean-phili...@evrard.me wrote:

My problem is that the servers that I'm using have their name defined as 
dcx-cy-blz (datacenter - chassis - blade). After installing openstack these 
names are reflected as the names of the hosts in nova.
We would like to have our compute nodes referenced as compute1, compute2 


The simplest is then to use compute1, compute2, etc. in your 
/etc/openstack_deploy/openstack_user_config. You can still internally refer to 
dcx-cy-blz if you like, it will just not appear openstack or in the inventory.

Regards,
JP




This is how I tried, but did not worked out  in the 
/etc/openstack_deploy/openstack_user_config.yml I had:

_compute_hosts: _hosts
  compute1:
ip: 10.210.201.40
host_vars:
neutron_neutron_conf_overrides:
  DEFAULT:
host: "{{ inventory_hostname }}.example.intra"
nova_nova_conf_overrides:
  DEFAULT:
host: "{{ inventory_hostname }}.example.intra"
  compute2:
ip: 10.210.201.41
host_vars:
neutron_neutron_conf_overrides:
  DEFAULT:
host: "{{ inventory_hostname }}.example.intra"
nova_nova_conf_overrides:
  DEFAULT:
host: "{{ inventory_hostname }}.example.intra"


What have done wrong?

Thank you,
Laszlo

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

Re: [Openstack-operators] [openstack-ansible] configuration file override

[Budai Laszlo]

Hello Jean-Philippe,

thank you for your answer.
for the version I have this:

root@ansible-ws1:~# openstack-ansible --version
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e 
@/etc/openstack_deploy/user_variables.yml "
ansible-playbook 2.4.4.0
  config file = /root/.ansible.cfg
  configured module search path = ['/etc/ansible/roles/plugins/library']
  ansible python module location = 
/opt/ansible-runtime/lib/python3.5/site-packages/ansible
  executable location = /opt/ansible-runtime/bin/ansible-playbook
  python version = 3.5.2 (default, Nov 23 2017, 16:37:01) [GCC 5.4.0 20160609]

EXIT NOTICE [Playbook execution success] **
===
root@ansible-ws1:~#

I'm trying to install the queens release of openstack.

My problem is that the servers that I'm using have their name defined as 
dcx-cy-blz (datacenter - chassis - blade). After installing openstack these 
names are reflected as the names of the hosts in nova.
We would like to have our compute nodes referenced as compute1, compute2 
We found that the "host" parameter of the nova.conf can be used for this. We've 
set an override for this in the user variables:

nova_nova_conf_overrides:
  DEFAULT:
host: "{{ inventory_hostname }}.ourdomain"

The result was that the name in nova became OK, but when nova-compute was 
trying to start instances it was failing as interfaces were not created in the 
ovs br-int. It turned out that we need the same host setting for neutron as 
well ...

so I decided to add a similar entry for the neutron.conf as well, but then in the 
neutron,conf on the neutron-server we had a name of the form 
"network1_neutron_server_container-HASH.ourdomain". And the neutron server was 
complaining that this is not a valid hostname (I suppose due to the underscores that 
appears in the name ... ).

So right now I'm looking for a way to set that host parameter in the 
neutron.conf and nova.conf only on the compute nodes.

Thank you,
Laszlo

On 20.08.2018 17:28, jean-phili...@evrard.me wrote:

In this example the override is part of a compute host definition and there it is in the 
host_vars section (compute_hosts -> 900089-compute001 -> host_vars -> 
override). Is it possible to apply such an override for all the compute hosts by not 
using the hostname? For instance something like:

" compute_hosts:
nova_nova_conf_overrides:
  DEFAULT:
remove_unused_original_minimum_age_seconds: 43200
"


You can set nova_nova_conf_overrides: into a file named 
/etc/openstack_deploy/user_variables.yml and it will apply on all your nodes.

If you want to be more surgical, you'd have to give more details about your 
OpenStack-Ansible version and what you're trying to achieve.

Regards,
Jean-Philippe Evrard (evrardjp)





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

[Openstack-operators] [openstack-ansible] configuration file override

[Budai Laszlo]

Dear all,

Openstack-ansible (OSA) allows us to override parameters in the configuration 
files as described here: 
https://docs.openstack.org/project-deploy-guide/openstack-ansible/draft/app-advanced-config-override.html

there is the following statement:

"You can also apply overrides on a per-host basis with the following 
configuration in the /etc/openstack_deploy/openstack_user_config.yml file:

compute_hosts:
  900089-compute001:
ip: 192.0.2.10
host_vars:
  nova_nova_conf_overrides:
DEFAULT:
  remove_unused_original_minimum_age_seconds: 43200
libvirt:
  cpu_mode: host-model
  disk_cachemodes: file=directsync,block=none
database:
  idle_timeout: 300
  max_pool_size: 10

"

In this example the override is part of a compute host definition and there it is in the 
host_vars section (compute_hosts -> 900089-compute001 -> host_vars -> 
override). Is it possible to apply such an override for all the compute hosts by not 
using the hostname? For instance something like:

" compute_hosts:
  nova_nova_conf_overrides:
DEFAULT:
  remove_unused_original_minimum_age_seconds: 43200
"

would this be correct?


Thank you,
Laszlo

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

Re: [Openstack-operators] [openstack-ansible] How to manage system upgrades ?

[Gilles Mocellin]

Le lundi 30 juillet, Matt Riedemann écrivit :

> On 7/27/2018 3:34 AM, Gilles Mocellin wrote:
> > - for compute nodes : disable compute node and live-evacuate instances...
> 
> To be clear, what do you mean exactly by "live-evacuate"? I assume you mean
> live migration of all instances off each (disabled) compute node *before*
> you upgrade it. I wanted to ask because "evacuate" as a server operation is
> something else entirely (it's rebuild on another host which is definitely
> disruptive to the workload on that server).
> 
> http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/
> 
> -- 
> 
> Thanks,
> 
> Matt

[Sorry for the delay, my mail was blocked]

Ah yes, I know the difference. Of course, I mean live migrate all instances on 
the node before disabling it, and upgrade / reboot.
So, the following nova command match :

$ nova host-evacuate-live



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

[Openstack-operators] [openstack-ansible] galera issues with mitaka-eol

[Jonathan Proulx]

Hi All,

In my continuing quest to install an OSA cluster with mitaka-eol in
hopes of digging our to a non-eol release eventually I've hit another
snag...

setup-hosts plays out fine
setup-infrastructure chodes soem where in galera-install

the 1st galera container gets properly bootstrapped into a 1 node
cluster.

the 2nd container (1st that needs replication) fails with:

180802 14:59:49 [Warning] WSREP: Gap in state sequence. Need state transfer.
180802 14:59:49 [Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'joiner' 
--address '172.29.238.84' --datadir
 '/var/lib/mysql/'   --parent '3719' --binlog '/var/lib/mysql/mariadb-bin' '
WSREP_SST: [ERROR] FATAL: The innobackupex version is 1.5.1. Needs 
xtrabackup-2.3.5 or higher to perform SST (20180
802 14:59:50.235)
180802 14:59:50 [ERROR] WSREP: Failed to read 'ready ' from: 
wsrep_sst_xtrabackup-v2 --role 'joiner' --addres
s '172.29.238.84' --datadir '/var/lib/mysql/'   --parent '3719' --binlog 
'/var/lib/mysql/mariadb-bin' 
Read: '(null)'
180802 14:59:50 [ERROR] WSREP: Process completed with error: 
wsrep_sst_xtrabackup-v2 --role 'joiner' --address '172
.29.238.84' --datadir '/var/lib/mysql/'   --parent '3719' --binlog 
'/var/lib/mysql/mariadb-bin' : 2 (No such file o
r directory)
180802 14:59:50 [ERROR] WSREP: Failed to prepare for 'xtrabackup-v2' SST. 
Unrecoverable.
180802 14:59:50 [ERROR] Aborting

The container has:

percona-xtrabackup-22/unknown,now 2.2.13-1.trusty amd64 [installed]

which is clearly the source of sadness. Seem seems bit odd that a very
default vanilla install woudl tangle like this but it is EOL and
perhaps the world has changed around it. 

What is the most OSA friendly way digging out of this?

My current prod cluster (which I eventually want this to take over) is
using

wsrep_sst_method = mysqldump

So I could set some overrides and probably make that go in OSA land
but I'd rather converge toward "noraml OSA way" unless there's
explict local reason to change from defaults and in this case I don't
have any particular need for mysqldump over xtrabackup.

-Jon

-- 

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

[Openstack-operators] Openstack Ansible ODL+OvS+SFC

[nicolas]

Hi Openstack community !

I have a question regarding Openstack Ansible (OSA) and one deployement 
scenario "Scenario - OpenDaylight and Open vSwitch" (link below).

https://docs.openstack.org/openstack-ansible-os_neutron/latest/app-opendaylight.html



This is a lab test and I take inspiration from "Test environment" 
example :

https://docs.openstack.org/openstack-ansible/queens/user/test/example.html



First, I have already tried and achieve to use the "OSA Scenario - Using 
Open vSwitch" (link below), which was necessary to understand before 
trying the ODL + OvS scenario.

https://docs.openstack.org/openstack-ansible-os_neutron/latest/app-openvswitch.html

This means I was able to deploy Openstack with OvS as network driver and 
I was able to instatiates VMs on tenant VxLAN network, test networks 
between VMs, use floating IPs, etc..




Now I want to try the "Scenario - OpenDaylight and Open vSwitch" 
scenario because I want to deploy my Openstack environnement with the 
"networking-sfc" driver activated.


I understand that I must modify the config file 
"/etc/openstack_deploy/user_variables.yml" like this :


```
   # /etc/openstack_deploy/user_variables.yml

   ### Ensure the openvswitch kernel module is loaded
   openstack_host_specific_kernel_modules:
 - name: "openvswitch"
   pattern: "CONFIG_OPENVSWITCH"
   group: "network_hosts"

   ### Use OpenDaylight SDN Controller
   neutron_plugin_type: "ml2.opendaylight"

   odl_ip: "{{ 
hostvars[groups['opendaylight'][0]]['ansible_default_ipv4']['address'] 
}}"

   neutron_opendaylight_conf_ini_overrides:
 ml2_odl:
   url: "http://{{ odl_ip }}:8180/controller/nb/v2/neutron"
   username: 
   password: 

   neutron_plugin_base:
- router
- metering
- networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin
- networking_sfc.services.sfc.plugin.SfcPlugin

```

But there are no information about the 
"/etc/openstack_deploy/openstack_user_config.yml" config file.
I am not sure if I understand where ansible get the value of "{{ odl_ip 
}}" and "{{ hostvars[group


In the file "/opt/openstack-ansible/tests/test_inventory.py", I find out 
that there is an entry for "opendaylight" in the

class TestAnsibleInventoryFormatConstraints(unittest.TestCase).


I assumed I must modify 
"/etc/openstack_deploy/openstack_user_config.yml" like this :


```
   # /etc/openstack_deploy/openstack_user_config.yml
   [...]

   # horizon
   dashboard_hosts:
 infra41:
   ip: infra41.dom4.net

   # neutron server, agents (L3, etc)
   network_hosts:
 network41:
   ip: network41.dom4.net

   opendaylight:
 network41:
   ip: network41.dom4.net
   [...]
```

I have an infra node (with most of Openstack core services) and a 
network node (dedicated to neutron). On my first try, I wanted to 
install ODL on the network node (because I thought it will be deployed 
in a LXC container). But I can dedicate an host to ODL if needed.



Could someone gives me some hints on this ? My goal is to deploy my 
Openstack environnement with the "networking-sfc" driver, and using OSA.


Maybe there are other method like "kolla-ansible", but I found that OSA 
has a more dense documentation.



Thanks you for your time.
--
Nicolas

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

[Openstack-operators] [openstack-ansible] Change in our IRC channel

[jean-philippe]

Hello everyone,

Due to a continuously increasing spam [0] on our IRC channels, I have decided 
to make our channel (#openstack-ansible on freenode) only joinable by 
Freenode's nickserv registered users.

I am sorry for the inconvenience, as it will now be harder to reach us (but 
it's not that hard to register! [1]). The conversations will be easier to 
follow though.

You can still contact us on the mailing lists too.

Regards,
Jean-Philippe Evrard (evrardjp)

[0]: https://freenode.net/news/spambot-attack
[1]: https://freenode.net/kb/answer/registration


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

Re: [Openstack-operators] [openstack-ansible] How to manage system upgrades ?

[Christian Zunker]

Hi Matt,

you are right. That's at least what I understand under 'live-evacuate'. The
compute is still working, all VMs on it are running.
Our VMs can all be live-migrated. We wrote a script to live-migrate all VMs
to other computes, to do hardware maintenance on the evacuated
compute server.

I know, this is not going to work for every setup, but could be starting
point, for what Gilles described.



Matt Riedemann  schrieb am Mo., 30. Juli 2018 um
20:20 Uhr:

> On 7/27/2018 3:34 AM, Gilles Mocellin wrote:
> > - for compute nodes : disable compute node and live-evacuate instances...
>
> To be clear, what do you mean exactly by "live-evacuate"? I assume you
> mean live migration of all instances off each (disabled) compute node
> *before* you upgrade it. I wanted to ask because "evacuate" as a server
> operation is something else entirely (it's rebuild on another host which
> is definitely disruptive to the workload on that server).
>
>
> http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/
>
> --
>
> Thanks,
>
> Matt
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-ansible] How to manage system upgrades ?

[Matt Riedemann]

On 7/27/2018 3:34 AM, Gilles Mocellin wrote:

- for compute nodes : disable compute node and live-evacuate instances...


To be clear, what do you mean exactly by "live-evacuate"? I assume you 
mean live migration of all instances off each (disabled) compute node 
*before* you upgrade it. I wanted to ask because "evacuate" as a server 
operation is something else entirely (it's rebuild on another host which 
is definitely disruptive to the workload on that server).


http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/

--

Thanks,

Matt

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

Re: [Openstack-operators] [openstack-ansible] How to manage system upgrades ?

[Christian Zunker]

Hi Gilles,

sounds like a good idea. We've just written a script for live evacuate,
which we can contribute after some refactoring.


Gilles Mocellin  schrieb am Fr., 27. Juli
2018 um 10:44 Uhr:

> Hello !
>
> Would be great to have a playbook to upgrade system parts of an
> OpenStack Cloud !
> With OpenStack Ansible : LXC containers and hosts.
>
> It would be awesome to do a controlled rolling reboot of hosts when
> needed...
>
> Different conditions to check :
> - for controllers : check galera status...
> - for compute nodes : disable compute node and live-evacuate
> instances...
> - for storage : with Ceph : set no out...
>
> I know, I can do it and contribute, but perhaps someone already has
> something similar ?
> It could be hosted in one of these projects :
> - https://git.openstack.org/cgit/openstack/openstack-ansible-ops
> -
> https://git.openstack.org/cgit/openstack/ansible-role-openstack-operations
>
> (Why already to project for the same goal ?)
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-ansible] How to manage system upgrades ?

[Gilles Mocellin]

Hello !

Would be great to have a playbook to upgrade system parts of an 
OpenStack Cloud !

With OpenStack Ansible : LXC containers and hosts.

It would be awesome to do a controlled rolling reboot of hosts when 
needed...


Different conditions to check :
- for controllers : check galera status...
- for compute nodes : disable compute node and live-evacuate 
instances...

- for storage : with Ceph : set no out...

I know, I can do it and contribute, but perhaps someone already has 
something similar ?

It could be hosted in one of these projects :
- https://git.openstack.org/cgit/openstack/openstack-ansible-ops
- 
https://git.openstack.org/cgit/openstack/ansible-role-openstack-operations


(Why already to project for the same goal ?)

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

[Openstack-operators] [openstack-ansible] group_binds exceptions

[Budai Laszlo]

Dear all,

is there a way to define exceptions for the group_binds for a network 
definition?

for instance we have something like this:
- network:
container_bridge: "vlan4"
container_type: "veth"
container_interface: "eth1"
ip_from_q: "container"
type: "raw"
group_binds:
  *- all_containers*
  - hosts
is_container_address: true
is_ssh_address: true

So, instead of *all_containers* I would be interested in something like 
"all_containers except those running on the ceph nodes".

Any ideas are welcome.

Thank you,
Laszlo

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

Re: [Openstack-operators] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Also, this is the change that drops it, so feel free to vote with your
opinion there too:

https://review.openstack.org/578887 Drop SELinux support from os_swift

On Thu, Jun 28, 2018 at 12:56 PM, Mohammed Naser  wrote:
> Hi everyone:
>
> This email is to ask if there is anyone out there opposed to removing
> SELinux bits from OpenStack ansible, it's blocking some of the gates
> and the maintainers for them are no longer working on the project
> unfortunately.
>
> I'd like to propose removing any SELinux stuff from OSA based on the 
> following:
>
> 1) We don't gate on it, we don't test it, we don't support it.  If
> you're running OSA with SELinux enforcing, please let us know how :-)
> 2) It extends beyond the scope of the deployment project and there are
> no active maintainers with the resources to deal with them
> 3) With the work currently in place to let OpenStack Ansible install
> distro packages, we can rely on upstream `openstack-selinux` package
> to deliver deployments that run with SELinux on.
>
> Is there anyone opposed to removing it?  If so, please let us know. :-)
>
> Thanks!
> Mohammed
>
> --
> Mohammed Naser — vexxhost
> -
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mna...@vexxhost.com
> W. http://vexxhost.com



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[Openstack-operators] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Hi everyone:

This email is to ask if there is anyone out there opposed to removing
SELinux bits from OpenStack ansible, it's blocking some of the gates
and the maintainers for them are no longer working on the project
unfortunately.

I'd like to propose removing any SELinux stuff from OSA based on the following:

1) We don't gate on it, we don't test it, we don't support it.  If
you're running OSA with SELinux enforcing, please let us know how :-)
2) It extends beyond the scope of the deployment project and there are
no active maintainers with the resources to deal with them
3) With the work currently in place to let OpenStack Ansible install
distro packages, we can rely on upstream `openstack-selinux` package
to deliver deployments that run with SELinux on.

Is there anyone opposed to removing it?  If so, please let us know. :-)

Thanks!
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[Openstack-operators] [openstack-ansible] Restarting our very own "SIG" teams

[Jean-Philippe Evrard]

Hello,

TL:DR; If you have spare cycles, join one of our interest groups!

In the Queens cycle, I have formalised the "liaisons" work, making
them an integral part of the Thursday's meeting agenda. Sadly, that
initiative didn't work, as almost no liaison worked/reported on those
meetings, and I stopped the initiative.

Upon common agreement that we now need to change how we scale the
team, we will now start our "liaison 2.0" work.

So, I have started an etherpad [1], where you could see all the
"groups" of people that OSA need, and where you could help.

Please don't hesitate to edit this etherpad, adding your new special
interest group, or simply joining an existing one if you have spare
cycles!

Thank you!

Jean-Philippe Evrard (evrardjp)

[1]: https://etherpad.openstack.org/p/osa-liaisons

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

Re: [Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

[Jean-Philippe Evrard]

> Right, you can set the stable-branch-type field to 'tagless' (see
> http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and
> then set the branch location field to the SHA you want to use.

Exactly what I thought.

> If you would be ready to branch all of the roles at one time, you could
> put all of them into 1 deliverable file. Otherwise, you will want to
> split them up into their own files.

Same.

>
> And since you have so many, I will point out that we're really into
> automation over here on the release team, and if you wanted to work on
> making the edit-deliverable command smart enough to determine the SHA
> for you I could walk you through that code to get you started.

Cool.

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

Re: [Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

[Doug Hellmann]

Excerpts from Jean-Philippe Evrard's message of 2018-06-05 10:14:12 +0200:
> Hello,
> 
> *TL:DR;* If you are an openstack-ansible user, consuming our roles directly,
> with tags, without using openstack-ansible plays or integrated repo,
> then things will change for you. Start using git shas instead of tags.
> All other openstack-ansible users should not see a difference, even if
> they use openstack-ansible tags.
> 
> 
> During the summit, I had a discussion with dhellman (and smcginnis)
> to change how openstack-ansible does its releases.
> 
> Currently, we tag openstack-ansible + many roles under our umbrella
> every two weeks. As far as I know, nobody requested to have roles
> tagged every two weeks. Only OpenStack-Ansible need to be tagged
> for consumption. Even people using our roles directly outside
> openstack-ansible generally use sha for roles. We don't rely on
> ansible galaxy.
> 
> Because there is no need to tag the roles, there is no need to make them
> part of the "openstack-ansible" deliverable [1][2]. I will therefore
> clarify the governance repo for that, separating the roles, each of them
> with their own deliverable, instead of grouping some roles within
> openstack-ansible, and some others outside it.
> 
> With this done, a release of openstack-ansible becomes straightforward
> using the standard release tooling. The releases of openstack-ansible
> becomes far simpler to request, review, and will not have timeouts
> anymore :p
> 
> There are a few issues I see from the change. Still according to the
> discussion, it seems we can overcome those.
> 
> 1. As this will be applied on all the branches, we may reach some
> issues with releasing in the next days. While the validate tooling
> of releases has shown me that it wouldn't be a problem (just
> warning) to not have all the repos in the deliverable, I would
> expect a governance change could be impactful.
> However, that is only impacting openstack-ansible, releases,
> and governance team: Keep in mind, openstack-ansible will not
> change for its users, and will still be tagged as you know it.
> 
> 2. We will keep branching our roles the same way we do now. What
> we liked for roles being part of this deliverable, is the ability
> of having them automatically branched and their files adapted.
> To what I heard, it is still possible to do so, by having a
> devstack-like behavior, which branches on a sha, instead of
> branching on tag. So I guess it means all our roles will now be
> part of release files like this one [3], or even on a single release
> file, similar to it.

Right, you can set the stable-branch-type field to 'tagless' (see
http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and
then set the branch location field to the SHA you want to use.

If you would be ready to branch all of the roles at one time, you could
put all of them into 1 deliverable file. Otherwise, you will want to
split them up into their own files.

And since you have so many, I will point out that we're really into
automation over here on the release team, and if you wanted to work on
making the edit-deliverable command smart enough to determine the SHA
for you I could walk you through that code to get you started.

Doug

> 
> What I would like to have, from this email, is:
> 1. Raise awareness to all the involved parties;
> 2. Confirmation we can go ahead, from a governance standpoint;
> 3. Confirmation we can still benefit from this automatic branch
> tooling.
> 
> Thank you in advance.
> 
> Jean-Philippe Evrard (evrardjp)
> 
> 
> [1]: 
> https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540
> [2]: 
> https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851
> [3]: 
> https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml
> 

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

[Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

[Jean-Philippe Evrard]

Hello,

*TL:DR;* If you are an openstack-ansible user, consuming our roles directly,
with tags, without using openstack-ansible plays or integrated repo,
then things will change for you. Start using git shas instead of tags.
All other openstack-ansible users should not see a difference, even if
they use openstack-ansible tags.


During the summit, I had a discussion with dhellman (and smcginnis)
to change how openstack-ansible does its releases.

Currently, we tag openstack-ansible + many roles under our umbrella
every two weeks. As far as I know, nobody requested to have roles
tagged every two weeks. Only OpenStack-Ansible need to be tagged
for consumption. Even people using our roles directly outside
openstack-ansible generally use sha for roles. We don't rely on
ansible galaxy.

Because there is no need to tag the roles, there is no need to make them
part of the "openstack-ansible" deliverable [1][2]. I will therefore
clarify the governance repo for that, separating the roles, each of them
with their own deliverable, instead of grouping some roles within
openstack-ansible, and some others outside it.

With this done, a release of openstack-ansible becomes straightforward
using the standard release tooling. The releases of openstack-ansible
becomes far simpler to request, review, and will not have timeouts
anymore :p

There are a few issues I see from the change. Still according to the
discussion, it seems we can overcome those.

1. As this will be applied on all the branches, we may reach some
issues with releasing in the next days. While the validate tooling
of releases has shown me that it wouldn't be a problem (just
warning) to not have all the repos in the deliverable, I would
expect a governance change could be impactful.
However, that is only impacting openstack-ansible, releases,
and governance team: Keep in mind, openstack-ansible will not
change for its users, and will still be tagged as you know it.

2. We will keep branching our roles the same way we do now. What
we liked for roles being part of this deliverable, is the ability
of having them automatically branched and their files adapted.
To what I heard, it is still possible to do so, by having a
devstack-like behavior, which branches on a sha, instead of
branching on tag. So I guess it means all our roles will now be
part of release files like this one [3], or even on a single release
file, similar to it.

What I would like to have, from this email, is:
1. Raise awareness to all the involved parties;
2. Confirmation we can go ahead, from a governance standpoint;
3. Confirmation we can still benefit from this automatic branch
tooling.

Thank you in advance.

Jean-Philippe Evrard (evrardjp)


[1]: 
https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540
[2]: 
https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851
[3]: 
https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml

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

[Openstack-operators] [openstack-ansible] Sydney summit -- We'll be there!

[Jean-Philippe Evrard]

Hello everyone,

A small delegation of our openstack-ansible team will be in Sydney,
and we are looking forward to meeting all of you!

We'll have an ops feedback session during the forum happening on
Monday 6th, 1:30 pm - 2:10 pm.

If you're willing to get started with openstack-ansible, contribute,
or get to know us, please join us on Tuesday 7th,  9:50 - 10:30 AM.

Last, but not least, if you want to know what happened in
openstack-ansible in the last cycle(s) or if you're interested by our
future strategy, that would be on Tuesday 7th, 5:50 pm - 6:10 pm
during our traditional "Project Update" session.

I am looking forward meeting all of you!

Best regards,
Jean-Philippe Evrard (evrardjp)

PS: We have an etherpad listing all these activities and more details
about the ops session here:
https://etherpad.openstack.org/p/osa-sydney-summit-planning

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

[Openstack-operators] [openstack-ansible]: Ensure glance service fails while setting up Openstack

[andres sanchez ramos]

Hello,


I am working on deploying a lab environment using openstack-ansible. While 
executing the setup-openstack.yml I encounter errors on the following task: 
TASK [os_glance : Ensure glance service] 
/etc/ansible/roles/os_glance/tasks/glance_service_setup.yml


Looking into the output from ansible the relevant part seems to be:


line 324, in get_raw_token_from_identity_service\n_('Authorization failed: 
%s') % e)\nkeystoneauth1.exceptions.auth.AuthorizationFailure: Authorization 
failed: Unable to establish connection to 
http://192.168.100.30:35357/v3/auth/tokens\ndebug3: mux_client_read_packet: 
read header failed: Broken pipe\


In order to troubleshoot i have done the following:


- Check that I can access 192.168.100.30 (infra node).

- Check that I can access different containers from the deployment host.

- Check that Iptables and haproxy are configure correctly on infra node.

- Check that port 35357 is listening on both the infra node and the container.

- Debugged ansible to check whether variables used add the service where 
getting values (keystone URL, user name, etc).


I also read that using ControlMaster might cause problems on ssh connection and 
also tried to disable it but the result is the same. I ran out of ideas if 
anyone can give me a hint about what might be causing the issue i would 
appreciate it :).


Best regards,


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

[Openstack-operators] Openstack-ansible and HAProxy

[Matteo Gerola]

Dear all,
Hope this is the right ML for this question, otherwise please let me know.

I have setup an openstack-ansible based infrastructure (pike) with 3 
controllers and 8 computes. Everything works fine except when i configure a 
dedicated IP to be shared between the ctrls.

There are several bridges, but the one involved here are:
br-public (bridge toward internet)
I have one public ip for each ctrl (x.x.x.1, x.x.x.2, x.x.x.3) configured on 
each bridge
br-mgmt (default internal bridge for OS ansible setup)
I have one private ip for each ctrl (y.y.y.1, y.y.y.2, y.y.y.3) configured on 
each bridge
Then, I have configured the openstack-ansible files like:

/etc/openstack_deploy/openstack_user_config.yml
  internal_lb_vip_address: y.y.y.1
I’m using the first ctrl ip for the internal network, but I’m not sure if it’s 
the right config
  external_lb_vip_address: x.x.x.4
I’m using a free IP in the public network to be shared by the controllers
/etc/openstack_deploy/user_variables.yml
haproxy_keepalived_external_vip_cidr: "{{external_lb_vip_address}}/24”
Here do I have to put /32 (default) or /24 (mi CIDR)?
haproxy_keepalived_internal_vip_cidr: "{{internal_lb_vip_address}}/24”
Here do I have to put /32 (default) or /24 (mi CIDR)?
haproxy_keepalived_external_interface: br-public
haproxy_keepalived_internal_interface: br-mgmt

With netstat, I see HAProxy binding all the service ports in the ctrls, but I 
cannot ping (and access horizon or the other services) using the public ip 
x.x.x.4.

Any suggestion?

Thanks a lot,
Matteo

Matteo Gerola, Dott.
Research Engineer

CREATE-NET Research Center
Fondazione Bruno Kessler (FBK)
via alla Cascata 56D
38123 Povo, Trento (Italy)
F: +39 0461 31​2425
e-mail: ​mger...@fbk.eu <--- THIS HAS CHANGED!
www:​​ ​http://create-net.fbk.eu

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited according to the Italian Law 196/2003 of the 
Legislature. If you received this in error, please contact the sender and 
delete the material from any computer.
Le informazioni contenute in questo messaggio di posta elettronica e nei file 
allegati sono da considerarsi strettamente riservate. Il loro utilizzo e' 
consentito esclusivamente al destinatario del messaggio, per le finalità 
indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne 
il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di 
procedere alla cancellazione del messaggio stesso dal Vostro sistema. 
Trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad 
altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce 
comportamento contrario ai principi dettati dal D. Lgs. 196/2003.


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

Re: [Openstack-operators] [openstack-ansible]: Container errors on task "lxc_container_create : Drop container network file (interfaces)"

[Jean-Philippe Evrard]

On 13 October 2017 at 11:29, andres sanchez ramos
 wrote:
> Hello guys,
>
> I am trying to deploy a lab Openstack environment using ansible in order to
> get acquainted with this tool. Actually i am stuck with an error i am not
> being able to resolve. It happens on the following task:
>
> TASK [lxc_container_create : Drop container network file (interfaces)]
> *
>
> task path:
> /etc/ansible/roles/lxc_container_create/tasks/container_create.yml:262
>
> The console prints out this error for each one of the containers:
>
> container_name: "infra1_cinder_scheduler_container-8054b2be"
> physical_host: "infra1"
> Container confirmed
> <192.168.100.30> ESTABLISH SSH CONNECTION FOR USER: lab232
> An exception occurred during task execution. The full traceback is:
> Traceback (most recent call last):
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
> line 98, in run
> item_results = self._run_loop(items)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
> line 290, in _run_loop
> res = self._execute(variables=task_vars)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
> line 511, in _execute
> result = self._handler.run(task_vars=variables)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/template.py",
> line 149, in run
> tmp = self._make_tmp_path(remote_user)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/__init__.py",
> line 224, in _make_tmp_path
> tmpdir =  self._remote_expand_user(C.DEFAULT_REMOTE_TMP, sudoable=False)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/__init__.py",
> line 506, in _remote_expand_user
> initial_fragment = data['stdout'].strip().splitlines()[-1]
> IndexError: list index out of range
>
> fatal: [infra1_nova_scheduler_container-92a94180]: FAILED! => {
> "failed": true,
> "msg": "Unexpected failure during module execution.",
> "stdout": ""
> }
>
> Regarding my setup i have one infrastructure node and one compute node. I am
> attaching the interface config for each node and the
> openstack_user_config.yml file so you get a complete picture of my setup. I
> would deeply appreciate any help or any pointers that might help me
> troubleshoot this!
>
> I think the only relevant change i make regarding the instructions is my
> management network which is 192.168.100.0./24 since I already have this set
> up for other equipment.
>
>
>
>
> Enviado desde Outlook
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

Sorry, I forgot to reply all.

With the information you gave me, I think the user could be the cause.
Our connection plugin doesn't seem to
work with the sudo trick you did.

May I suggest you to file a bug to list what you did in practice,
explain this issue, and you'd expect?

In the meantime, could you try running as root on your destination
node? And maybe later on your deploy node too, to see the results?

Best regards,
Jean-Philippe Evrard (evrardjp)

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

[Openstack-operators] [openstack-ansible]: Container errors on task "lxc_container_create : Drop container network file (interfaces)"

[andres sanchez ramos]

Hello guys,

I am trying to deploy a lab Openstack environment using ansible in order to get 
acquainted with this tool. Actually i am stuck with an error i am not being 
able to resolve. It happens on the following task:

TASK [lxc_container_create : Drop container network file (interfaces)] *

task path: 
/etc/ansible/roles/lxc_container_create/tasks/container_create.yml:262

The console prints out this error for each one of the containers:

container_name: "infra1_cinder_scheduler_container-8054b2be"
physical_host: "infra1"
Container confirmed
<192.168.100.30> ESTABLISH SSH CONNECTION FOR USER: lab232
An exception occurred during task execution. The full traceback is:
Traceback (most recent call last):
  File 
"/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
 line 98, in run
item_results = self._run_loop(items)
  File 
"/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
 line 290, in _run_loop
res = self._execute(variables=task_vars)
  File 
"/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
 line 511, in _execute
result = self._handler.run(task_vars=variables)
  File 
"/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/template.py",
 line 149, in run
tmp = self._make_tmp_path(remote_user)
  File 
"/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/__init__.py",
 line 224, in _make_tmp_path
tmpdir =  self._remote_expand_user(C.DEFAULT_REMOTE_TMP, sudoable=False)
  File 
"/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/__init__.py",
 line 506, in _remote_expand_user
initial_fragment = data['stdout'].strip().splitlines()[-1]
IndexError: list index out of range

fatal: [infra1_nova_scheduler_container-92a94180]: FAILED! => {
"failed": true,
"msg": "Unexpected failure during module execution.",
"stdout": ""
}

Regarding my setup i have one infrastructure node and one compute node. I am 
attaching the interface config for each node and the openstack_user_config.yml 
file so you get a complete picture of my setup. I would deeply appreciate any 
help or any pointers that might help me troubleshoot this!


I think the only relevant change i make regarding the instructions is my 
management network which is 192.168.100.0./24 since I already have this set up 
for other equipment.




Enviado desde Outlook


Compute interfaces
Description: Compute interfaces


openstack_user_config.yml
Description: openstack_user_config.yml


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

[Openstack-operators] [openstack-ansible] Meetings change

[Jean-Philippe Evrard]

Hello everyone,

Some people on this planet are more aware of others of this fact:
we have too many meetings in our life.

I don't think OpenStack-Ansible should be so greedy to take 8 hours of
your life a month for meetings. I therefore propose the reduction to 4
meetings/month: 3 bug triages and 1 community meeting.

On top of that, attendance in meetings is low, so I'd rather we find,
all together, a timeslot that matches the majority of us.

I started this etherpad [1], to list timeslots. I'd like you to:
1) (Optionally) Add timeslot that would suit you best
2) Vote for a timeslot in which you can regularily attend
OpenStack-Ansible meetings

Please give your irc nick too, that would help.

Thank you in advance.

Best regards,
Jean-Philippe Evrard (evrardjp)

[1] https://etherpad.openstack.org/p/osa-meetings-planification

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

[Openstack-operators] [openstack-ansible] restrictive umask / file permissions in target hosts

[Markus Zoeller]

How do you deal with hosts which have a restrictive umask of 077
*before* openstack-ansible starts the setup? Do you start with the
default umask of 022 and opt-in later to that security hardening[1]?

What's the development policy of openstack-ansible regarding setting
file or directory permissions in tasks?

* is a umask value of 022 assumed for tasks to work?
* should tasks always explicitly set the file/dir mode?
* other options I'm not aware of?

Background
--
The (internal) folks who gave me the target hosts for openstack-ansible
set the umask to 077 *before* I started the installation and I wasn't
aware of that setting. So I spent some time figuring out why the nginx
server in the repo container can't serve files like the requirements
file "requirements_absolute_requirements.txt"[2] because of file
permissions like this:

-rw--- 1 root root [...] requirements_absolute_requirements.txt

This also affects the nginx config files (which, for example, set the
'autoindex' behavior, which is needed to serve the python wheels):

cd /etc/nginx/sites-available/
ll openstack-slushee.vhost
-rw--- 1 root root [...] openstack-slushee.vhost

Not sure if that was also the root cause of [3].

References
--
[1]
https://github.com/openstack/openstack-ansible-security/blob/40c744c86dd7e5e53e88a5ddd7389333a26f92d2/defaults/main.yml#L340-L363
[2]
https://github.com/openstack/openstack-ansible-repo_build/blob/fe3ae20f74a912925d5c78040984957a6d55f9de/tasks/repo_post_build.yml#L43-L46
[3]
https://stackoverflow.com/questions/42286765/using-repo-other-then-pypi-with-pip

-- 
Regards, Markus Zoeller (markus_z)


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

Re: [Openstack-operators] Openstack-Ansible (Ocata branch) deployment failing - "No matching distribution found for mysql-python"

[Jean-Philippe Evrard]

Hello,

I forgot to do a “reply all” this morning. Here was the gist:

Don’t hesitate to give us the logs you can find on 
/openstack/logs/dc2-controller-01_repo_container-7ce807b6/repo (particularily 
the repo_venv_builder.log). It could help us debugging requirements issues.

Best regards,
JP

From: Andy McCrae <andy.mcc...@gmail.com>
Date: Thursday, 4 May 2017 at 12:10
To: Eugene Duvenage <euge...@sahomeloans.com>
Cc: "openstack-operators@lists.openstack.org" 
<openstack-operators@lists.openstack.org>
Subject: Re: [Openstack-operators] Openstack-Ansible (Ocata branch) deployment 
failing - "No matching distribution found for mysql-python"

Hi Eugene,

You're right that error doesn't give us much.
My best advice for a next step would be to manually run "bash 
/opt/op-venv-script.sh" from inside the repo container: 
dc2-controller-01_repo_container-7ce807b6. I've had similar issues, which is 
usually a constraints issue (we're working ways to improve this too).

The output from the script is often more useful - additionally there are logs 
in the repo container for the venv build process, so check those out too.

On a plus side - which doesn't help you right now but may make this easier in 
future - we're looking to potentially move away from that bash script and 
manage the venv process via ansible tasks. This will hopefully make the issue 
more clear when it fails, and improve debugging.

Hope that helps!
Andy



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 ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Openstack-Ansible (Ocata branch) deployment failing - "No matching distribution found for mysql-python"

[Andy McCrae]

Hi Eugene,

You're right that error doesn't give us much.
My best advice for a next step would be to manually run "bash
/opt/op-venv-script.sh" from inside the repo container:
dc2-controller-01_repo_container-7ce807b6.
I've had similar issues, which is usually a constraints issue (we're
working ways to improve this too).

The output from the script is often more useful - additionally there are
logs in the repo container for the venv build process, so check those out
too.

On a plus side - which doesn't help you right now but may make this easier
in future - we're looking to potentially move away from that bash script
and manage the venv process via ansible tasks. This will hopefully make the
issue more clear when it fails, and improve debugging.

Hope that helps!
Andy
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Openstack-Ansible (Ocata branch) deployment failing - "No matching distribution found for mysql-python"

[Andy McCrae]

Hi Eugene,

With just that error it's a bit difficult to see exactly why it's failing.

Could you use paste.openstack.org (or similar) to paste a more detailed log
of the error/output?

I'd also suggest jumping into #openstack-ansible on the Freenode irc
server, there are usually some people about who may be able to help and
provide more feedback/pointers.

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

[Openstack-operators] OpenStack-Ansible Onboarding -day/time change

[Amy Marrich]

Just wanted to let everyone know the time and day for the OpenStack-Ansible
Onboarding has changed. We will now have our onboarding on Wednesday, May
10 from 9:00 to 10:30.

https://www.openstack.org/summit/boston-2017/summit-
schedule/events/18711/ansible-project-onboarding

Hope to see lots of new and familiar faces!

Amy (aka spotz)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-ansible] Way to cleanup existing Openstack-Ansible deployment

[Amit Kumar]

Hi All,

I am trying to install Openstack Newton using OSA 14.0.8. Playbooks
setup-hosts.yml and setup-infrastructure.yml are getting stuck at some
point or other. Is there any way to cleanup everything which OSA has
deployed. I want to re-run all the playbooks as if I am doing a fresh
deployment.

Thanks.

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

Re: [Openstack-operators] (openstack-ansible) Mitaka 13.3.12 failing to report correct resource usage

[Jesse Pretorius]

From: "Craft, Mike" <mike.cr...@viasat.com>
Date: Thursday, March 2, 2017 at 7:50 PM
To: "openstack-operators@lists.openstack.org" 
<openstack-operators@lists.openstack.org>
Subject: [Openstack-operators] (openstack-ansible) Mitaka 13.3.12 failing to 
report correct resource usage

Hello,

Did an upgrade from liberty to mitaka and we are experiencing an issue where 
the audit of locally available compute resource usage is not seeing instances 
that were deployed prior to the upgrade. Has anyone experienced this before? We 
hard power cycled all the vms (and hypervisor) to make sure they are running on 
the latest nova version. This is impacting scheduling of resources/quota usage 
as you could imagine ☺

If you look in the nova database, can you see those instances there? From the 
look of things, your hypervisor has no instances allocated to it in its 
database. I hope that you have a backup! ☺



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 ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] (openstack-ansible) Mitaka 13.3.12 failing to report correct resource usage

[Craft, Mike]

Hello,

Did an upgrade from liberty to mitaka and we are experiencing an issue where 
the audit of locally available compute resource usage is not seeing instances 
that were deployed prior to the upgrade. Has anyone experienced this before? We 
hard power cycled all the vms (and hypervisor) to make sure they are running on 
the latest nova version. This is impacting scheduling of resources/quota usage 
as you could imagine ☺

Example from one box.

2017-03-02 19:37:52.189 17586 INFO nova.compute.resource_tracker 
[req-da808a51-f9e3-4762-b46b-ee313183d2d2 - - - - -] Auditing locally available 
compute resources for node usw1comp024.openstack.local
2017-03-02 19:37:54.413 17586 INFO nova.compute.resource_tracker 
[req-da808a51-f9e3-4762-b46b-ee313183d2d2 - - - - -] Total usable vcpus: 56, 
total allocated vcpus: 0
2017-03-02 19:37:54.413 17586 INFO nova.compute.resource_tracker 
[req-da808a51-f9e3-4762-b46b-ee313183d2d2 - - - - -] Final resource view: 
name=hostname.openstack.local phys_ram=257725MB used_ram=2048MB 
phys_disk=4433GB used_disk=2GB total_vcpus=56 used_vcpus=0 pci_stats=[]

virsh list --all
IdName   State

2 instance-18ed  running
3 instance-18ea  running
4 instance-18e4  running
5 instance-18de  running
6 instance-076f  running
7 instance-0420  running

libvirt+  7995  1.6  0.2 13401648 653416 ? Sl   19:07   0:40 
/usr/bin/qemu-system-x86_64 -name instance-18ed -S -machine 
pc-i440fx-trusty,accel=kvm,usb=off -cpu 
SandyBridge,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+movbe,+dca,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
 -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
d306091c-e1a6-44ef-b5ff-bc412c4b2341 -smbios type=1,manufacturer=OpenStack 
Foundation,product=OpenStack 
Nova,version=13.1.3,serial=03000200-0400-0500-0006-000700080009,uuid=d306091c-e1a6-44ef-b5ff-bc412c4b2341,family=Virtual
 Machine -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-18ed.monitor,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on 
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive 
file=/var/lib/nova/instances/d306091c-e1a6-44ef-b5ff-bc412c4b2341/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,discard=ignore
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=27 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:bc:3c:ee,bus=pci.0,addr=0x3 
-chardev 
file,id=charserial0,path=/var/lib/nova/instances/d306091c-e1a6-44ef-b5ff-bc412c4b2341/console.log
 -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 
-device isa-serial,chardev=charserial1,id=serial1 -chardev pty,id=charchannel0 
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -spice port=5900,addr=10.60.16.73,disable-ticketing,seamless-migration=on -k 
en-us -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
libvirt+  8516  1.6  0.2 13401672 594804 ? Sl   19:07   0:39 
/usr/bin/qemu-system-x86_64 -name instance-18ea -S -machine 
pc-i440fx-trusty,accel=kvm,usb=off -cpu 
SandyBridge,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+movbe,+dca,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
 -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
2e3cdf87-5022-45df-8a47-150afee1ca83 -smbios type=1,manufacturer=OpenStack 
Foundation,product=OpenStack 
Nova,version=13.1.3,serial=03000200-0400-0500-0006-000700080009,uuid=2e3cdf87-5022-45df-8a47-150afee1ca83,family=Virtual
 Machine -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-18ea.monitor,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on 
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive 
file=/var/lib/nova/instances/2e3cdf87-5022-45df-8a47-150afee1ca83/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,discard=ignore
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=28 -device 

Re: [Openstack-operators] [openstack-ansible] Unbound problem

[Andreas Vallin]

Hi Logan,

Thanks for your quick answer and solution to the problem. I could do a 
complete reinstall on this system so I did that and tried again with 
your patch and it looks much better. Unbound is now deployed in 
containers only and the bare metal machines are configured to use those 
containers.


Regards,
Andreas


On 02/08/2017 08:05 PM, Logan V. wrote:

Hi Andreas,

Thanks for reporting this. I just pushed a patch to resolve this here
https://review.openstack.org/#/c/431110/. If you are able to start
with a fresh environment this should resolve the issue. The unbound
service should only be installed in the containers, not the hosts, so
that was the issue here.

If you need to get this environment working where you saw this issue,
you could purge unbound from the hosts, apply the patch above, and
re-run the unbound-install playbook to refresh the resolv.conf across
the environment.

Logan

On Wed, Feb 8, 2017 at 12:45 PM, Andreas Vallin  wrote:

Hi!

I am using openstack-ansible 14.0.6-10 and have deployed Unbound but there
seems to be a conflict with Dnsmasq (that is installed by OSA) and Unbound:

Feb  8 19:20:21 Infra8 unbound[5637]: [1486578021] unbound[6973:0] error:
can't bind socket: Address already in use for 0.0.0.0
Feb  8 19:20:21 Infra8 unbound[5637]: [1486578021] unbound[6973:0] fatal
error: could not open ports

root@Infra8:~# netstat -pl|grep localhost:domain
tcp0  0 localhost:domain *:* LISTEN
1840/dnsmasq
tcp6   0  0 localhost:domain [::]:*  LISTEN
1840/dnsmasq
udp0  0 localhost:domain *:*
1840/dnsmasq
udp6   0  0 localhost:domain [::]:*
1840/dnsmasq

Here is the config used in openstack_user_config.yml

unbound_hosts:
   Infra7:
 ip: 172.22.5.7
   Infra8:
 ip: 172.22.5.8
   Infra9:
 ip: 172.22.5.9

There are three containers created, one at each Infra machine (Unbound works
fine in the containers). Unbound also gets installed on the bare metal Infra
nodes and it is there the problem is. Is this a bug or something that I have
done wrong?

Regards,
Andreas


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



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

Re: [Openstack-operators] [openstack-ansible] Unbound problem

[Logan V.]

Hi Andreas,

Thanks for reporting this. I just pushed a patch to resolve this here
https://review.openstack.org/#/c/431110/. If you are able to start
with a fresh environment this should resolve the issue. The unbound
service should only be installed in the containers, not the hosts, so
that was the issue here.

If you need to get this environment working where you saw this issue,
you could purge unbound from the hosts, apply the patch above, and
re-run the unbound-install playbook to refresh the resolv.conf across
the environment.

Logan

On Wed, Feb 8, 2017 at 12:45 PM, Andreas Vallin  wrote:
> Hi!
>
> I am using openstack-ansible 14.0.6-10 and have deployed Unbound but there
> seems to be a conflict with Dnsmasq (that is installed by OSA) and Unbound:
>
> Feb  8 19:20:21 Infra8 unbound[5637]: [1486578021] unbound[6973:0] error:
> can't bind socket: Address already in use for 0.0.0.0
> Feb  8 19:20:21 Infra8 unbound[5637]: [1486578021] unbound[6973:0] fatal
> error: could not open ports
>
> root@Infra8:~# netstat -pl|grep localhost:domain
> tcp0  0 localhost:domain *:* LISTEN
> 1840/dnsmasq
> tcp6   0  0 localhost:domain [::]:*  LISTEN
> 1840/dnsmasq
> udp0  0 localhost:domain *:*
> 1840/dnsmasq
> udp6   0  0 localhost:domain [::]:*
> 1840/dnsmasq
>
> Here is the config used in openstack_user_config.yml
>
> unbound_hosts:
>   Infra7:
> ip: 172.22.5.7
>   Infra8:
> ip: 172.22.5.8
>   Infra9:
> ip: 172.22.5.9
>
> There are three containers created, one at each Infra machine (Unbound works
> fine in the containers). Unbound also gets installed on the bare metal Infra
> nodes and it is there the problem is. Is this a bug or something that I have
> done wrong?
>
> Regards,
> Andreas
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Openstack-operators] [openstack-ansible] Unbound problem

[Andreas Vallin]

Hi!

I am using openstack-ansible 14.0.6-10 and have deployed Unbound but 
there seems to be a conflict with Dnsmasq (that is installed by OSA) and 
Unbound:


Feb  8 19:20:21 Infra8 unbound[5637]: [1486578021] unbound[6973:0] 
error: can't bind socket: Address already in use for 0.0.0.0
Feb  8 19:20:21 Infra8 unbound[5637]: [1486578021] unbound[6973:0] fatal 
error: could not open ports


root@Infra8:~# netstat -pl|grep localhost:domain
tcp0  0 localhost:domain *:* LISTEN  
1840/dnsmasq
tcp6   0  0 localhost:domain [::]:*  LISTEN  
1840/dnsmasq
udp0  0 localhost:domain *:* 
1840/dnsmasq
udp6   0  0 localhost:domain [::]:*  
1840/dnsmasq


Here is the config used in openstack_user_config.yml

unbound_hosts:
  Infra7:
ip: 172.22.5.7
  Infra8:
ip: 172.22.5.8
  Infra9:
ip: 172.22.5.9

There are three containers created, one at each Infra machine (Unbound 
works fine in the containers). Unbound also gets installed on the bare 
metal Infra nodes and it is there the problem is. Is this a bug or 
something that I have done wrong?


Regards,
Andreas


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

Re: [Openstack-operators] [openstack-ansible] configuration to use nfs for glance and cinder

[Andreas Vallin]

Hi Andy,

Yes it probably does not matter if the variables are visible in other 
containers (you get a working system up and running anyway) but it is 
not the expected behavior when using limit_container_types. I did manage 
to get the variables limited to cinder_volume containers when I typed 
the configuration like this:


  XxX:
ip: 172.22.5.9
container_vars:
  cinder_storage_availability_zone: cinderAZ_1
  cinder_default_availability_zone: cinderAZ_1
  cinder_backends:
limit_container_types: cinder_volume
cinder_nfs:
  volume_backend_name: cinder_nfs
  volume_driver: cinder.volume.drivers.nfs.NfsDriver
  nfs_mount_options: 
"_netdev,auto,rw,intr,noatime,async,vers=3,proto=tcp,wsize=1048576,rsize=1048576,timeo=1200,actimeo=120"

  cinder_nfs_client:
limit_container_types: cinder_volume
nfs_shares_config: /etc/cinder/nfs_shares
shares:
  - ip: "172.22.20.254"
share: "/nfs/cinder/production"


However, I did not find any way to limit the glance nfs configuration to 
only the glance containers. It looks like this in 
openstack_user_config.yml.prod.example:


image_hosts:
  infra1:
ip: 172.29.236.11
container_vars:
  limit_container_types: glance
  glance_nfs_client:
- server: "172.29.244.15"
  remote_path: "/images"
  local_path: "/var/lib/glance/images"
  type: "nfs"
  options: "_netdev,auto"

My workaround to the problem was to add the glance configuration to 
user_variables.yml instead, that way you don't get the inventory full 
with glance configuration on all containers. This is what I added to 
user_variables.yml:


glance_nfs_client:
  - server: "172.22.20.254"
remote_path: "/nfs/glance/production"
local_path: "/var/lib/glance/images"
type: "nfs"
options: 
"_netdev,auto,rw,intr,noatime,async,vers=3,proto=tcp,wsize=1048576,rsize=1048576,timeo=1200,actimeo=120"



So it sounds like you are aware of the problem and are working on a fix, 
that is great.

Thank you all for a very good work with openstack-ansible.

Regards,
Andreas



On 02/03/2017 05:27 PM, Andy McCrae wrote:

Hi Andreas,

The way you're doing it at the end looks correct - the docs are not 
quite right on that one.
The nfs_shares file will only get templated on the cinder_volumes 
hosts, as will the nfs_shares_config option  - so in essence it 
shouldn't matter that the var isn't limited to volume hosts.


That said, there is a bug here that we've been working to fix - this 
will work if you have one backend.
Mainly it means there is no support for multiple backends, if one of 
them is an NFS backend, and there is no support for multiple NFS backends.
A patch has gone in to allow multiple NFS backends (and change the way 
they're configured) - but it's not quite ready for release - so we're 
working on a subsequent fix that will then be a part of newton 14.0.8 
release for OSA.


I'd be happy to keep you updated - if you'd like to drop into 
#openstack-ansible on Freednode IRC there are a lot of active 
operators/developers/deployers, we'd be happy to help further.


But barring that I'll try add a reminder to drop an update here once 
that's working.


Andy


On 3 February 2017 at 08:56, Andreas Vallin > wrote:


Hi!

I need to ask how do you correctly configure nfs to be used with
openstack-ansible newton (14.0.6). I think it is great that there
is an production example file that uses nfs for glance and cinder
(openstack_user_config.yml.pro
d.example) but the cinder
config is not working for me.

I use this config for storage_hosts, only changing ip, and share
from production example:

storage_hosts:
  XxXx:
ip: 172.22.5.9
container_vars:
  cinder_backends:
limit_container_types: cinder_volume
cinder_nfs_client:
  nfs_shares_config: /etc/cinder/nfs_shares
  shares:
- ip: "172.22.20.254"
  share: "/nfs/cinder/production"

And this is the failure when running os-cinder-install.yml

TASK [os_cinder : Add in cinder devices types]
*
fatal: [XxXx_cinder_volumes_container-080139bd]: FAILED! =>
{"failed": true, "msg": "the field 'args' has an invalid value,
which appears to include a variable that is undefined. The error
was: 'dict object' has no attribute 'volume_backend_name'\n\nThe
error appears to have been in
'/etc/ansible/roles/os_cinder/tasks/cinder_backends.yml': line 30,
column 3, but may\nbe elsewhere in the file depending on the exact
syntax problem.\n\nThe offending line appears to be:\n\n\n- name:
Add in cinder devices types\n  ^ here\n"}

OK, so volume_backend_name is missing. The playbook runs if I add
volume_backend_name 

Re: [Openstack-operators] [openstack-ansible] configuration to use nfs for glance and cinder

[Andy McCrae]

Hi Andreas,

The way you're doing it at the end looks correct - the docs are not quite
right on that one.
The nfs_shares file will only get templated on the cinder_volumes hosts, as
will the nfs_shares_config option  - so in essence it shouldn't matter that
the var isn't limited to volume hosts.

That said, there is a bug here that we've been working to fix - this will
work if you have one backend.
Mainly it means there is no support for multiple backends, if one of them
is an NFS backend, and there is no support for multiple NFS backends.
A patch has gone in to allow multiple NFS backends (and change the way
they're configured) - but it's not quite ready for release - so we're
working on a subsequent fix that will then be a part of newton 14.0.8
release for OSA.

I'd be happy to keep you updated - if you'd like to drop into
#openstack-ansible on Freednode IRC there are a lot of active
operators/developers/deployers, we'd be happy to help further.

But barring that I'll try add a reminder to drop an update here once that's
working.

Andy


On 3 February 2017 at 08:56, Andreas Vallin  wrote:

> Hi!
>
> I need to ask how do you correctly configure nfs to be used with
> openstack-ansible newton (14.0.6). I think it is great that there is an
> production example file that uses nfs for glance and cinder (
> openstack_user_config.yml.prod.example) but the cinder config is not
> working for me.
>
> I use this config for storage_hosts, only changing ip, and share from
> production example:
>
> storage_hosts:
>   XxXx:
> ip: 172.22.5.9
> container_vars:
>   cinder_backends:
> limit_container_types: cinder_volume
> cinder_nfs_client:
>   nfs_shares_config: /etc/cinder/nfs_shares
>   shares:
> - ip: "172.22.20.254"
>   share: "/nfs/cinder/production"
>
> And this is the failure when running os-cinder-install.yml
>
> TASK [os_cinder : Add in cinder devices types]
> *
> fatal: [XxXx_cinder_volumes_container-080139bd]: FAILED! => {"failed":
> true, "msg": "the field 'args' has an invalid value, which appears to
> include a variable that is undefined. The error was: 'dict object' has no
> attribute 'volume_backend_name'\n\nThe error appears to have been in
> '/etc/ansible/roles/os_cinder/tasks/cinder_backends.yml': line 30, column
> 3, but may\nbe elsewhere in the file depending on the exact syntax
> problem.\n\nThe offending line appears to be:\n\n\n- name: Add in cinder
> devices types\n  ^ here\n"}
>
> OK, so volume_backend_name is missing. The playbook runs if I add
> volume_backend_name to the config like this:
>
>
> storage_hosts:
>   XxXx:
> ip: 172.22.5.9
> container_vars:
>   cinder_backends:
> limit_container_types: cinder_volume
> cinder_nfs_client:
>   volume_backend_name: cinder_nfs
>   nfs_shares_config: /etc/cinder/nfs_shares
>   shares:
> - ip: "172.22.20.254"
>   share: "/nfs/cinder/production"
>
>
> But now there is no /etc/cinder/nfs_shares file in the
> cinder-volumes-container so the nfs share will not be mounted. This is
> because the "Create nfs shares export file" task in cinder_post_install.yml
> doesn't see that cinder_nfs_client is defined. You also get this in
> cinder.conf:
>
> enabled_backends=cinder_nfs_client
> # All given backend(s)
> [cinder_nfs_client]
> volume_backend_name=cinder_nfs
> nfs_shares_config=/etc/cinder/nfs_shares
> shares=[{u'ip': u'172.22.20.254', u'share': u'/nfs/cinder/production'}]
>
>
> This configuration works for me:
>
> storage_hosts:
>   XxXx:
> ip: 172.22.5.9
> container_vars:
>   cinder_storage_availability_zone: cinderAZ_1
>   cinder_default_availability_zone: cinderAZ_1
>   limit_container_types: cinder_volume
>   cinder_backends:
> cinder_nfs:
>   volume_backend_name: cinder_nfs
>   volume_driver: cinder.volume.drivers.nfs.NfsDriver
>   nfs_mount_options: "_netdev,auto,rw,intr,noatime,
> async,vers=3,proto=tcp,wsize=1048576,rsize=1048576,timeo=1200,actimeo=120"
>   cinder_nfs_client:
> nfs_shares_config: /etc/cinder/nfs_shares
> shares:
>   - ip: "172.22.20.254"
> share: "/nfs/cinder/production"
>
>
> BUT when I look in the inventory file (openstack_inventory.json) it
> doesn't look like this configuration is limited to cinder_volume containers
> even if "limit_container_types: cinder_volume" is used. So now I feel it is
> time to ask how a correct configuration should look like.
>
> Regards,
> Andreas
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

[Openstack-operators] [openstack-ansible] configuration to use nfs for glance and cinder

[Andreas Vallin]

Hi!

I need to ask how do you correctly configure nfs to be used with 
openstack-ansible newton (14.0.6). I think it is great that there is an 
production example file that uses nfs for glance and cinder 
(openstack_user_config.yml.prod.example) but the cinder config is not 
working for me.


I use this config for storage_hosts, only changing ip, and share from 
production example:


storage_hosts:
  XxXx:
ip: 172.22.5.9
container_vars:
  cinder_backends:
limit_container_types: cinder_volume
cinder_nfs_client:
  nfs_shares_config: /etc/cinder/nfs_shares
  shares:
- ip: "172.22.20.254"
  share: "/nfs/cinder/production"

And this is the failure when running os-cinder-install.yml

TASK [os_cinder : Add in cinder devices types] 
*
fatal: [XxXx_cinder_volumes_container-080139bd]: FAILED! => {"failed": 
true, "msg": "the field 'args' has an invalid value, which appears to 
include a variable that is undefined. The error was: 'dict object' has 
no attribute 'volume_backend_name'\n\nThe error appears to have been in 
'/etc/ansible/roles/os_cinder/tasks/cinder_backends.yml': line 30, 
column 3, but may\nbe elsewhere in the file depending on the exact 
syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Add in 
cinder devices types\n  ^ here\n"}


OK, so volume_backend_name is missing. The playbook runs if I add 
volume_backend_name to the config like this:



storage_hosts:
  XxXx:
ip: 172.22.5.9
container_vars:
  cinder_backends:
limit_container_types: cinder_volume
cinder_nfs_client:
  volume_backend_name: cinder_nfs
  nfs_shares_config: /etc/cinder/nfs_shares
  shares:
- ip: "172.22.20.254"
  share: "/nfs/cinder/production"


But now there is no /etc/cinder/nfs_shares file in the 
cinder-volumes-container so the nfs share will not be mounted. This is 
because the "Create nfs shares export file" task in 
cinder_post_install.yml doesn't see that cinder_nfs_client is defined. 
You also get this in cinder.conf:


enabled_backends=cinder_nfs_client
# All given backend(s)
[cinder_nfs_client]
volume_backend_name=cinder_nfs
nfs_shares_config=/etc/cinder/nfs_shares
shares=[{u'ip': u'172.22.20.254', u'share': u'/nfs/cinder/production'}]


This configuration works for me:

storage_hosts:
  XxXx:
ip: 172.22.5.9
container_vars:
  cinder_storage_availability_zone: cinderAZ_1
  cinder_default_availability_zone: cinderAZ_1
  limit_container_types: cinder_volume
  cinder_backends:
cinder_nfs:
  volume_backend_name: cinder_nfs
  volume_driver: cinder.volume.drivers.nfs.NfsDriver
  nfs_mount_options: 
"_netdev,auto,rw,intr,noatime,async,vers=3,proto=tcp,wsize=1048576,rsize=1048576,timeo=1200,actimeo=120"

  cinder_nfs_client:
nfs_shares_config: /etc/cinder/nfs_shares
shares:
  - ip: "172.22.20.254"
share: "/nfs/cinder/production"


BUT when I look in the inventory file (openstack_inventory.json) it 
doesn't look like this configuration is limited to cinder_volume 
containers even if "limit_container_types: cinder_volume" is used. So 
now I feel it is time to ask how a correct configuration should look like.


Regards,
Andreas


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

Re: [Openstack-operators] [openstack-ansible] Remove compute node command

[Matt Riedemann]

On 2/1/2017 6:14 AM, Salman Toor wrote:

hi,

According to the Newton guide:

http://docs.openstack.org/developer/openstack-ansible/newton/developer-docs/ops-remove-computehost.html

The last command is

# openstack-ansible remove_compute_node.yml -e node_to_be_removed=“compute1"


With this I end up getting following error:

fatal: [infra1_utility_container-fb0edc5f]: FAILED! => {"changed":
false, "failed": true, "msg": "host_to_be_removed must be defined as
ansible user variable”}

Please update the guide with correct variable name. Variable name is
“host_to_be_removed” NOT “node_to_be_removed”.

Regards..
Salman


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se 
http://www.it.uu.se/katalog/salto690




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



Not directly related to this, but coincidentally we were talking about a 
bug in nova related to deleting compute nodes which reminded me of this fix:


https://review.openstack.org/#/c/406627/

And the bug for it, and the fact you have to manually delete compute 
nodes from the nova database, but you can delete the nova-compute 
service via the os-hypervisors REST API.


While working on that bug I pointed out the need for a nova-manage 
command or something similar to remove a compute node record from the 
database, which would also have to build in some checks to make sure 
that's safe, but the point is, this is a need we have in nova itself, so 
it'd be sweet if someone was willing to work on adding that command to 
nova, rather than have lots of random similar scripts in different tools 
repos.


--

Thanks,

Matt Riedemann

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

Re: [Openstack-operators] [openstack-ansible] Remove compute node command

[Salman Toor]

Hi again,

Ok, next time i will file a bug report.

With this thread I really want to thank OpenStack-Ansible team for their HEROIC 
efforts. I love this project: Simple, Cool and Effective :-)

Best Regards..
Salman.

PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690


On Feb 1, 2017, at 11:21 PM, Anne Gentle 
> wrote:



On Wed, Feb 1, 2017 at 4:16 PM, Andy McCrae 
> wrote:
Hi Salman,

Thanks for pointing that out - I'll file a fix for that now ( 
https://review.openstack.org/427950 )

If you find any more it'd be great if you could file a bug in launchpad:
https://bugs.launchpad.net/openstack-ansible


Also, you can click the bug icon on any docs page to open a pre-filled 
Launchpad template, mapped to the project where the doc bugs are tracked.

Anne

We triage bugs once a week (on Tuesdays), so we usually pick them up pretty 
quickly.

Thanks for letting us know!
Andy


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




--

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.com

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

Re: [Openstack-operators] [openstack-ansible] Remove compute node command

[Anne Gentle]

On Wed, Feb 1, 2017 at 4:16 PM, Andy McCrae  wrote:

> Hi Salman,
>
> Thanks for pointing that out - I'll file a fix for that now (
> https://review.openstack.org/427950 )
>
> If you find any more it'd be great if you could file a bug in launchpad:
> https://bugs.launchpad.net/openstack-ansible
>
>
Also, you can click the bug icon on any docs page to open a pre-filled
Launchpad template, mapped to the project where the doc bugs are tracked.

Anne


> We triage bugs once a week (on Tuesdays), so we usually pick them up
> pretty quickly.
>
> Thanks for letting us know!
> Andy
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-ansible] Remove compute node command

[Andy McCrae]

Hi Salman,

Thanks for pointing that out - I'll file a fix for that now (
https://review.openstack.org/427950 )

If you find any more it'd be great if you could file a bug in launchpad:
https://bugs.launchpad.net/openstack-ansible

We triage bugs once a week (on Tuesdays), so we usually pick them up pretty
quickly.

Thanks for letting us know!
Andy
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators][openstack-ansible] Optioanal services documentation for Newton

[Salman Toor]

Hi,

Thanks Melvin! I already been to these links and I don’t think these links 
contains the information about optional services. For example FWaaS, LBaaS or 
even Ceilometer.

Those are what I am looking for the Newton release. Mitaka version works fine 
but just want to check if there is any change in the Newton.

Regards..
Salman.


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690


On Jan 23, 2017, at 5:08 AM, Melvin Hillsman 
> wrote:

Hey Salman,

Maybe this will help - 
http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/ - the 
documentation has changed a bit since Newton ( 
http://docs.openstack.org/developer/openstack-ansible/newton/ )

On Sun, Jan 22, 2017 at 2:12 PM, Salman Toor 
> wrote:
Hi,

Wondering can someone help me pointing the openstack-ansible (Newton) guide for 
optional services? I have found for Mitaka but not for Newton.

Basically looking for a similar link for Newton (Following is for Mitaka):

http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure.html

Regards..
Salman.



PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690

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




--
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command

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

Re: [Openstack-operators] [openstack-operators][openstack-ansible] Optioanal services documentation for Newton

[Melvin Hillsman]

Hey Salman,

Maybe this will help -
http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/ -
the documentation has changed a bit since Newton (
http://docs.openstack.org/developer/openstack-ansible/newton/ )

On Sun, Jan 22, 2017 at 2:12 PM, Salman Toor  wrote:

> Hi,
>
> Wondering can someone help me pointing the openstack-ansible (Newton)
> guide for optional services? I have found for Mitaka but not for Newton.
>
> Basically looking for a similar link for Newton (Following is for Mitaka):
>
> http://docs.openstack.org/developer/openstack-ansible/
> mitaka/install-guide/configure.html
>
> Regards..
> Salman.
>
>
>
> PhD, Scientific Computing
> Researcher, IT Department,
> Uppsala University.
> Senior Cloud Architect,
> SNIC.
> Cloud Application Expert,
> UPPMAX.
> salman.t...@it.uu.se
> 
> http://www.it.uu.se/katalog/salto690
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-operators][openstack-ansible] Optioanal services documentation for Newton

[Salman Toor]

Hi,

Wondering can someone help me pointing the openstack-ansible (Newton) guide for 
optional services? I have found for Mitaka but not for Newton.

Basically looking for a similar link for Newton (Following is for Mitaka):

http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure.html

Regards..
Salman.



PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-operators][openstack-ansible]

[Wade Holler]

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
 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"  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.hol...@gmail.com
> irc: wadeholler
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@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 ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.

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

Re: [Openstack-operators] [openstack-operators][openstack-ansible]

[Jean-Philippe Evrard]

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"  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.hol...@gmail.com
irc: wadeholler

___
OpenStack-operators mailing list
OpenStack-operators@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 ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-operators][openstack-ansible]

[Wade Holler]

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.hol...@gmail.com
irc: wadeholler

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

Re: [Openstack-operators] [openstack-ansible] networking services of compute nodes on LXC

[Achi Hamza]

Hi Jean-Philippe Evrard and Jesse,

Thank you both for your responses.
Finally i succeeded in deploying DVR setup but i don’t know if my approach
is good or not. I am going to describe it for the sake of sharing.

I used newton tag 14.0.2 and my scenario is VLANs tenant networks+flat
external network+DVR. Inside  neutron agents containers i created 2 OVS
bridges, br-prv for tenant networks and br-floating for the flat network,
then i attached eth11 and eth12 as ports accordingly, like this:

*ovs-vsctl add-br br-floating*
*ovs-vsctl add-br br-prv*
*ovs-vsctl add-port br-prv eth11*
*ovs-vsctl add-port br-floating eth12*

In the compute nodes it was a bit hard for me as the equivalent  of eth11
and eth12 interfaces don’t exist, also OpenvSwitch cannot accept br-vlan to
be a port for both  br-prv and br-floating. So, what i ended up doing is
creating 2 *internal* OVS ports one for br-prv and the other for
br-floating, then i added them to br-vlan bridge in
 /etc/network/interfaces file, like this:

*auto p_prv*
*allow-br-prv p_prv*
*iface p_prv inet manual*
* ovs_type OVSIntPort*
* ovs_bridge br-prv*


*auto p_floating*
*allow-br-floating p_floating*
*iface p_floating inet manual*
* ovs_type OVSIntPort*
* ovs_bridge br-floating*

*auto br-vlan*
*iface br-vlan inet manual*
*bridge_stp off*
*bridge_waitport 0*
*bridge_fd 0*
*bridge_ports enp4s1 p_prv p_floating*


I hope we could get other solutions that use openstack-ansible with DVR to
select the best one since DVR is new in openstack-ansible.

Best regards,
Hamza

On 5 December 2016 at 10:51, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

>
>
> *From: *Achi Hamza <h16m...@gmail.com>
> *Date: *Saturday, December 3, 2016 at 12:19 PM
> *To: *"openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> *Subject: *[Openstack-operators] [openstack-ansible] networking services
> of compute nodes on LXC
>
>
>
> Hello,
>
> I need to install the networking services of the compute nodes into LXC,
> just like networking services on the infra nodes (neutron_agents_container)
> so that i can leverage eth11 and eth12 interfaces within the container on
> the compute nodes for my setup (DVR).
>
> How openstack-ansible should be configured to deploy the the networking
> services of the compute nodes on LXC too ?
>
> Hi Achi,
>
> The short answer is that you don’t. For the moment we do not use
> containers for compute services, or neutron agent services on compute, so
> you would need to ensure that those hosts are configured with the
> appropriate bridges/interfaces to make it work.
>
> Unfortunately I’m unfamiliar with DVR or networking at the best of times,
> and with DVR being a new feature in Newton I haven’t had the chance to give
> it a go. Perhaps someone who has given it a try will be able to advise.
>
> Best regards,
>
>
>
> Jesse
>
> IRC: odyssey4me
>
> --
> 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 ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-ansible] networking services of compute nodes on LXC

[Achi Hamza]

Hello,

I need to install the networking services of the compute nodes into LXC,
just like networking services on the infra nodes (neutron_agents_container)
so that i can leverage eth11 and eth12 interfaces within the container on
the compute nodes for my setup (DVR).

How openstack-ansible should be configured to deploy the the networking
services of the compute nodes on LXC too ?


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

Re: [Openstack-operators] [openstack-ansible] OVS+VLAN Networks Scenario

[Achi Hamza]

Hi Sławek Kapłoński,

Thank you for your response.

1. In br-provider bridge I don't see any interface through which packets
should be send. Is this bridge used as "external bridge"?
Yes, it is used as "External Bridge". i added the interface eth12 within
the *node01_neutron_agents container* to br-brovider bridge. I can now ping
the gateway IP address on the provider network but still unable to ping the
the floating IP of the VM:
root@node01-utility-container-edc0f67a:~# *neutron router-port-list
core-router*
+--+--+---+--+
| id   | name | mac_address   |
fixed_ips|
+--+--+---+--+
| 19ab7b32-198b-4392-a5b3-dc2d323d69a4 |  | fa:16:3e:dd:c9:02 |
{"subnet_id": "63acfd17-55d7-4147-926e-  |
|  |  |   |
6ee75c9e7f55", "ip_address": "*10.1.4.107*"}   |
| 3c527c3c-5e51-489c-80a0-02a3eeba679d |  | fa:16:3e:6c:b5:72 |
{"subnet_id": "b42b5af9-efcf-42df-bb0f-  |
|  |  |   |
e080d606fdf0", "ip_address": "192.168.3.1"}  |
| f67e4a28-f7c5-480b-8343-ff80d8ef4753 |  | fa:16:3e:8d:db:fc |
{"subnet_id": "b42b5af9-efcf-42df-bb0f-  |
|  |  |   |
e080d606fdf0", "ip_address": "192.168.3.5"}  |
+--+--+---+--+
maas-user@ubuntu:~$* ping 10.1.4.107*
PING 10.1.4.107 (10.1.4.107) 56(84) bytes of data.
64 bytes from 10.1.4.107: icmp_seq=1 ttl=64 time=0.996 ms
64 bytes from 10.1.4.107: icmp_seq=2 ttl=64 time=0.715 ms
64 bytes from 10.1.4.107: icmp_seq=3 ttl=64 time=0.699 ms
64 bytes from 10.1.4.107: icmp_seq=4 ttl=64 time=0.730 ms

root@node01-utility-container-edc0f67a:~# *openstack server list*
WARNING: openstackclient.common.utils is deprecated and will be removed
after Jun 2017. Please use osc_lib.utils
+--+--++-++
| ID   | Name | Status |
Networks| Image Name |
+--+--++-++
| b6684532-c1b2-4e18-89bd-28fc7d2d6efb | selfservice-instance | ACTIVE |
project=192.168.3.9, *10.1.4.111* | cirros |
+--+--++-++

root@node01:~# *ping 10.1.4.111*
PING 10.1.4.111 (10.1.4.111) 56(84) bytes of data.
>From 10.1.200.25 icmp_seq=1 Destination Host Unreachable
>From 10.1.200.25 icmp_seq=2 Destination Host Unreachable
>From 10.1.200.25 icmp_seq=3 Destination Host Unreachable


3. From where You are trying to ping this vm? Is it the same host or
another one? Is it connected to same vlan?
Yes, it is the same host and the same VLAN. I forgot to mention that i used
DVR setup.

The problem i have is that i don't know which interface should i add to
br-provider on the compute node. br-vlan bridge is already attached to my
external interface, that is why i got confused.

Can you please advice on this.

Thanks,
Hamza


On 26 November 2016 at 22:48, Sławek Kapłoński  wrote:

> Hello,
>
> 1. In br-provider bridge I don't see any interface through which packets
> should be send. Is this bridge used as "external bridge"?
> 2. Please check also Openflow rules in bridges - it's important to have
> proper rules on bridges
> 3. From where You are trying to ping this vm? Is it the same host or
> another one? Is it connected to same vlan?
> 4. When You are trying to ping Your vm what You see on interfaces on
> Your host?
>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
>
> On Sat, 26 Nov 2016, Achi Hamza wrote:
>
> > Hi All,
> >
> > Context:
> >   openstack-ansible tag:   14.0.1
> >   ML2 plug-in:   OpenvSwitch
> >   Project / External networks:   VLAN
> >   OS:  Ubuntu 16.0.4
> >
> > I would like to implement OVS with VLANs following these 2 docs [1][2]
> but
> > things didn't work for me. I cannot ping my provider network:
> >
> > root@node01-utility-container-edc0f67a:~# *openstack server list*
> > WARNING: openstackclient.common.utils is deprecated and will be removed
> > after Jun 2017. Please use osc_lib.utils
> > +--+---+
> +-++
> > | ID   | Name  | Status |
> > Networks| Image Name |
> > 

[Openstack-operators] [openstack-ansible] OVS+VLAN Networks Scenario

[Achi Hamza]

Hi All,

Context:
  openstack-ansible tag:   14.0.1
  ML2 plug-in:   OpenvSwitch
  Project / External networks:   VLAN
  OS:  Ubuntu 16.0.4

I would like to implement OVS with VLANs following these 2 docs [1][2] but
things didn't work for me. I cannot ping my provider network:

root@node01-utility-container-edc0f67a:~# *openstack server list*
WARNING: openstackclient.common.utils is deprecated and will be removed
after Jun 2017. Please use osc_lib.utils
+--+---++-++
| ID   | Name  | Status |
Networks| Image Name |
+--+---++-++
| ed7e7c76-dcf2-431e-8bb1-0541391f64ed | provider-instance | ACTIVE |
physnet1=10.1.4.103 | cirros |
+--+---++-++

root@node01-utility-container-edc0f67a:~# *ping 10.1.4.103*
PING 10.1.4.103 (10.1.4.103) 56(84) bytes of data.
>From 10.1.200.25 icmp_seq=1 Destination Host Unreachable
>From 10.1.200.25 icmp_seq=2 Destination Host Unreachable
>From 10.1.200.25 icmp_seq=3 Destination Host Unreachable


This is how my OpenvSwitch configuration looks:
root@node01:~# *ovs-vsctl show*
29613dde-944b-4449-ab09-af906a6f74c6
Manager "ptcp:6640:127.0.0.1"
is_connected: true
Bridge br-int
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port int-br-provider
Interface int-br-provider
type: patch
options: {peer=phy-br-provider}
Port br-int
Interface br-int
type: internal
Port "qvobb7afbfb-18"
tag: 1
Interface "qvobb7afbfb-18"
Bridge br-provider
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port phy-br-provider
Interface phy-br-provider
type: patch
options: {peer=int-br-provider}
Port br-provider
Interface br-provider
type: internal
ovs_version: "2.6.0"


Please advice on what might be wrong on my setup.

Thank you,
Hamza

[1]
http://docs.openstack.org/developer/openstack-ansible-os_neutron/app-openvswitch.html
[2]
https://medium.com/@travistruman/configuring-openstack-ansible-for-open-vswitch-b7e70e26009d#.wylhu7pqh
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-ansible] tenant VLAN overlays

[Charles Short]

Hi,

I am looking at openstack-ansible and would like to deploy using tenant 
VLAN overlays rather than VXLAN


I have read here however that the VXLAN bridge is mandatory

http://docs.openstack.org/developer/openstack-ansible/liberty/install-guide/overview-hostnetworking.html
>>
OpenStack Networking tunnel/overlay br-vxlan:

 * Mandatory.

<<

Is this still the case with Newton?


Thanks

Charles

--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205

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

Re: [Openstack-operators] openstack-ansible - recovery of failed infrastructure host

[Ben Lagunilla]

Thanks for the suggestions. We’ll run the openstack-ansible scripts on 
a new infrastructure host. 

-- ben

> On 24 Oct 2016, at 6:40 PM, Melvin Hillsman  wrote:
> 
> Hey Ben,
> 
> Unfortunately I do not have way to confirm with you right now but also 
> suggest you create a backup of your database as a matter of caution and 
> general best practice. If you can backup anything else that would be a good 
> thing to consider as well.
> 
> Kind regards,
> --
> Melvin Hillsman
> Ops Technical Lead
> OpenStack Innovation Center
> 
> mrhills...@gmail.com
> phone: (210) 312-1267
> mobile: (210) 413-1659
> Learner | Ideation | Belief | Responsibility | Command
> http://osic.org
> 
> 
> On 10/24/16, 12:06 PM, "Jesse Pretorius"  
> wrote:
> 
>Hi Ben,
> 
>If you stand up a new infrastructure host with the same IP address and 
> name in openstack_user_config then execute the setup-hosts, 
> setup-infrastructure and setup-openstack plays it should put everything back 
> in place for you without further intervention.
> 
>Jesse
>IRC: odyssey4me
> 
>On 10/24/16, 9:58 AM, "Ben Lagunilla"  wrote:
> 
>Hi All,
> 
>How do we go about restoring a failed infrastructure host? Setup is 
> openstack mitaka with high availability configured on 3 infrastructure hosts.
> 
>Thanks!
> 
> 
> 
>___
>OpenStack-operators mailing list
>OpenStack-operators@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 ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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

Re: [Openstack-operators] openstack-ansible - recovery of failed infrastructure host

[Melvin Hillsman]

Hey Ben,

Unfortunately I do not have way to confirm with you right now but also suggest 
you create a backup of your database as a matter of caution and general best 
practice. If you can backup anything else that would be a good thing to 
consider as well.

Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center
 
mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org
 

On 10/24/16, 12:06 PM, "Jesse Pretorius"  
wrote:

Hi Ben,

If you stand up a new infrastructure host with the same IP address and name 
in openstack_user_config then execute the setup-hosts, setup-infrastructure and 
setup-openstack plays it should put everything back in place for you without 
further intervention.

Jesse
IRC: odyssey4me

On 10/24/16, 9:58 AM, "Ben Lagunilla"  wrote:

Hi All,

How do we go about restoring a failed infrastructure host? Setup is 
openstack mitaka with high availability configured on 3 infrastructure hosts.

Thanks!



___
OpenStack-operators mailing list
OpenStack-operators@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 ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




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

Re: [Openstack-operators] openstack-ansible - recovery of failed infrastructure host

[Jesse Pretorius]

Hi Ben,

If you stand up a new infrastructure host with the same IP address and name in 
openstack_user_config then execute the setup-hosts, setup-infrastructure and 
setup-openstack plays it should put everything back in place for you without 
further intervention.

Jesse
IRC: odyssey4me

On 10/24/16, 9:58 AM, "Ben Lagunilla"  wrote:

Hi All,

How do we go about restoring a failed infrastructure host? Setup is 
openstack mitaka with high availability configured on 3 infrastructure hosts.

Thanks!



___
OpenStack-operators mailing list
OpenStack-operators@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 ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [OpenStack-Ansible] Mitaka Upgrade

[Wade Holler]

Hi All,

If this is RTFM please point me there and I apologize.

If not:

We are testing the Liberty to Mitaka transition with OSAD.  Could someone
please advise if these were the correct general steps.

osad multinode (VMs/instances inside a osad cloud) built with latest 12.X
liberty osad
1. save off config files: openstack_user_config.yml, user_variables,yml,
...hostname..., inventory,  etc.
2. rm -rf /etc/openstack_deploy; rm -rf /opt/openstack-ansible
3. git clone -b stable/mitaka 
4. copy config files back in place
5. ./scripts/bootstrap-ansible.sh
6. openstack-ansible setup-everything.yml

That is the process we ran and it appears to have went well after adding
the "-e rabbit_upgrade=true" flag.

Only straggler process that I found so far was a neutron-ns-metadata-proxy
that was still running 12.X liberty code.  restarted the container and it
didn't start again, but the 13.X mitaka version is running ( and was before
shutdown ).

Is this the correct upgrade process or are there other steps / approaches
that should be taken ?

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

Re: [Openstack-operators] [OpenStack-Ansible] Liberty to Mitaka upgrade?

[Jesse Pretorius]

On 20 April 2016 at 04:27, Dale Baley  wrote:

> Is there a document or guide for upgrading from Liberty to Mitaka yet?
>

Hi Dale,

The active work to test and implement any plays to assist with upgrades has
not yet been implemented for Liberty->Mitaka. We hope to do this work by
Newton Milestone-1. If you wish to participate in the process for getting
this done then please join us in #openstack-ansible to compare notes.

The starting point for this work is always to begin by using the same
process as is used for minor upgrades [1] in a test environment and to see
whether anything breaks, then to prepare patches to resolve that. As our
roles and plays already automatically detect and deal with things like DB
migrations and the software version changes this may actually work
perfectly well - it's just that we've not had the chance to really get down
to testing the upgrades with focal attention yet.

[1]
http://docs.openstack.org/developer/openstack-ansible/install-guide/app-minorupgrade.html

Best regards,

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

[Openstack-operators] [OpenStack-Ansible] Liberty to Mitaka upgrade?

[Dale Baley]

Is there a document or guide for upgrading from Liberty to Mitaka yet?

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

[Openstack-operators] [OpenStack-Ansible] Liberty and Ubuntu 16.04

[Andreas Vallin]

Hi
I am wondering if there will be possible to run Ubuntu 16.04 LTS with 
Liberty and the openstack-ansible project? Are you planning to "support" 
that?


Regards,
Andreas Vallin


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

Re: [Openstack-operators] [Openstack-Ansible] Example of Ceph with Cinder using OpenStack-Ansible

[Salman Toor]

Thanks for your quick response Trueman, will give a try very soon.

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

Re: [Openstack-operators] [Openstack-Ansible] Example of Ceph with Cinder using OpenStack-Ansible

[Truman, Travis]

Salman,

Take a look at: 
https://github.com/openstack/openstack-ansible/blob/master/etc/openstack_deploy/openstack_user_config.yml.example#L602

And at 
https://github.com/openstack/openstack-ansible/blob/master/doc/source/install-guide/configure-ceph.rst

Also, there are probably folks in #openstack-ansible that have worked through 
this.

- Travis Truman

From: Salman Toor <salman.t...@it.uu.se<mailto:salman.t...@it.uu.se>>
Date: Tuesday, February 23, 2016 at 1:08 PM
To: 
"openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>"
 
<openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>>
Cc: Andreas Vallin 
<andreas.wal...@uppmax.uu.se<mailto:andreas.wal...@uppmax.uu.se>>
Subject: [Openstack-operators] [Openstack-Ansible] Example of Ceph with Cinder 
using OpenStack-Ansible

Hi,

Recently we have get started with OpenStack-Ansible. So far things looks good 
but now we want to use Ceph backend for cinder. Can someone show a reference 
configuration of how to get started?

Thanks in advance.

Regards..
Salman.


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se<https://mail.uu.se/owa/redir.aspx?REF=m0Eyh6bAe3V0K5jcrZeIkUVJw4_716jYUS9Yd1fJMFOsyyE71yXTCAFtYWlsdG86c2FsbWFuLnRvb3JAaXQudXUuc2U.>
http://www.it.uu.se/katalog/salto690
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Openstack-Ansible] Example of Ceph with Cinder using OpenStack-Ansible

[Salman Toor]

Hi,

Recently we have get started with OpenStack-Ansible. So far things looks good 
but now we want to use Ceph backend for cinder. Can someone show a reference 
configuration of how to get started?

Thanks in advance.

Regards..
Salman.


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
salman.t...@it.uu.se
http://www.it.uu.se/katalog/salto690
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-ansible] centos support

[Adam Young]

On 02/18/2016 01:01 PM, Abel Lopez wrote:

We talked a bit about making OSAD 'EL' compatible, but we ultimately decided 
against it.
There were various architectural differences that made it not worth the effort.
I don't know if anyone else was seriously considering the work.


Would highly recommend looking at Kolla instead.  It uses Ansible, and 
deploys via containers.  I'm in love with the project, and seriously 
think it is the future of OpenStack.


http://adam.younglogic.com/2016/02/holla-kolla/




On Feb 18, 2016, at 9:41 AM, Wade Holler  wrote:

Hi All,

Could someone let me know if a person / org has taken ownership of this yet? I 
have heard it talked about but haven't seen where it's owned or officially 
happening yet.

My primary customer is will to dedicate a decent chunk of my time investigating 
and I don't want to reinvent the wheel(s).

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



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


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

Re: [Openstack-operators] [openstack-ansible] centos support

[Abel Lopez]

We talked a bit about making OSAD 'EL' compatible, but we ultimately decided 
against it.
There were various architectural differences that made it not worth the effort.
I don't know if anyone else was seriously considering the work.

> On Feb 18, 2016, at 9:41 AM, Wade Holler  wrote:
> 
> Hi All,
> 
> Could someone let me know if a person / org has taken ownership of this yet? 
> I have heard it talked about but haven't seen where it's owned or officially 
> happening yet.
> 
> My primary customer is will to dedicate a decent chunk of my time 
> investigating and I don't want to reinvent the wheel(s).
> 
> Cheers
> Wade
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-ansible]

[Major Hayden]

On 02/17/2016 02:00 PM, Wade Holler wrote:
> Well it almost does. Except on my neutron agents container I ended up with a 
> eth12
> 
> And I do have a flat network plumbed in to the infrastructure host ( on which 
> the neutron agent container resides ) via br-vlan.
> 
> Thoughts?
> 
> Thank you for the engagement and previous prompt rely! I really appreciate 
> the help.

Hmm, I think I'm to the point where I need to know a little more about your 
configuration. ;)

Could you drop as much of your openstack_user_config.yml as you can into a 
pastebin somewhere?  Be sure to obfuscate any information or IP addresses that 
would be problematic if they're made public.

If you want all three network types -- flat, VLAN, and VXLAN -- that's totally 
doable, but a veth might be required on your hypervisors.  Knowing more about 
your configuration and desired state will help.

Feel free to hop into #openstack-ansible on Freenode to talk in real-time.  I'm 
mhayden in the channel.

--
Major Hayden

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

Re: [Openstack-operators] [openstack-ansible]

[Wade Holler]

Hi Major,

Well it almost does. Except on my neutron agents container I ended up with
a eth12

And I do have a flat network plumbed in to the infrastructure host ( on
which the neutron agent container resides ) via br-vlan.

Thoughts?

Thank you for the engagement and previous prompt rely! I really appreciate
the help.

Wade
On Wed, Feb 17, 2016 at 2:33 PM Major Hayden  wrote:

> On 02/17/2016 01:23 PM, Wade Holler wrote:
> > Going to ask this question without much data or background as I hope
> someone very familiar with openstack-ansible will be able to easily answer
> it.
> >
> > I tried to follow the install guide and network config pretty closely.
> >
> > All is well except my physical compute nodes don't have an eth12.
> >
> > What is the best was to change the openstack-ansible config
> (/etc/openstack_deploy/openstack_user_config.yml
> /etc/openstack_deploy/user_variables.yml ) such that this is tolerated.
> i.e., flat:eth12 not placed in the physical_interface_mappings line of
> /etc/neutron/plugins/ml2/linuxbridge_agent.ini ?
>
> Hello Wade,
>
> I ran into this problem as well and it's a bit confusing.  The eth12
> interface is used in the AIO since we need three networks (VLAN, flat, and
> VXLAN), but we have only two bridges (br-vlan and br-vxlan).  You can use
> eth12 in your deployments, but you'll need to create a veth for that.
> There's no requirement to use all three of these network types in your
> production environment.
>
> Which networks do you plan to use?  If you plan to use VLAN and VXLAN
> without flat networking, you can omit the provider network section for the
> flat network.  Here's an excerpt from what I'm using in production:
>
>   https://gist.github.com/major/b8771c99e1274e89bc98
>
> Does that help?
>
> --
> Major Hayden
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-ansible]

[Major Hayden]

On 02/17/2016 01:23 PM, Wade Holler wrote:
> Going to ask this question without much data or background as I hope someone 
> very familiar with openstack-ansible will be able to easily answer it.
> 
> I tried to follow the install guide and network config pretty closely. 
> 
> All is well except my physical compute nodes don't have an eth12.  
> 
> What is the best was to change the openstack-ansible config 
> (/etc/openstack_deploy/openstack_user_config.yml 
> /etc/openstack_deploy/user_variables.yml ) such that this is tolerated.  
> i.e., flat:eth12 not placed in the physical_interface_mappings line of 
> /etc/neutron/plugins/ml2/linuxbridge_agent.ini ?

Hello Wade,

I ran into this problem as well and it's a bit confusing.  The eth12 interface 
is used in the AIO since we need three networks (VLAN, flat, and VXLAN), but we 
have only two bridges (br-vlan and br-vxlan).  You can use eth12 in your 
deployments, but you'll need to create a veth for that.  There's no requirement 
to use all three of these network types in your production environment.

Which networks do you plan to use?  If you plan to use VLAN and VXLAN without 
flat networking, you can omit the provider network section for the flat 
network.  Here's an excerpt from what I'm using in production:

  https://gist.github.com/major/b8771c99e1274e89bc98

Does that help?

--
Major Hayden

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

[Openstack-operators] [openstack-ansible]

[Wade Holler]

Hi All,

Going to ask this question without much data or background as I hope
someone very familiar with openstack-ansible will be able to easily answer
it.

I tried to follow the install guide and network config pretty closely.

All is well except my physical compute nodes don't have an eth12.

What is the best was to change the openstack-ansible config
(/etc/openstack_deploy/openstack_user_config.yml
/etc/openstack_deploy/user_variables.yml ) such that this is tolerated.
 i.e., flat:eth12 not placed in the physical_interface_mappings line of
/etc/neutron/plugins/ml2/linuxbridge_agent.ini ?

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

Re: [Openstack-operators] [openstack-ansible] Mid Cycle Sprint

[Jesse Pretorius]

Hi everyone,

Thank you all for responding and giving your feedback.

Given that the Ops Mid Cycle [1] is in the UK (15-16 Feb) and AnsibleFest
[2] is also in the UK (18 Feb), and also that everyone seems ok with the UK
as a location for the mid cycle then we shall have it in the UK!

The Ops Mid Cycle organisers have also graciously offered for us to be a
part of the Ops Mid Cycle agenda. I would like as many of us as possible to
play a part in the Ops Mid Cycle - listening, learning and contributing
where possible. As such, I'd like us to limit the number of sessions we
have within the Ops Mid Cycle. Let's have a few open design-style sessions.

Thereafter, as discussed in today's community meeting [3], we can break
down into work sessions where we can work on specific goals. This will
happen on the Wednesday 17 Feb and we will be hosted at the Rackspace
offices in Hayes (West London).

I've setup an Etherpad [4] to gather proposals for Fishbowl Sessions (at
the Ops Mid Cycle) and Work Sessions (for 17 Feb). Please add any sessions
you'd like to facilitate/moderate. If there are sessions there, then please
feel free to add your +1 to show that you'd like to see it.

As discussed in the meeting today [3] I'm on holiday until the New Year.
Please all have a wonderful time over the year's end and I'll see you all
bright-eyed and bushy tailed next year!

Best regards,

Jesse
IRC: odyssey4me

[1] https://etherpad.openstack.org/p/MAN-ops-meetup
[2] http://www.ansible.com/ansiblefest
[3]
http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2015/openstack_ansible_meeting.2015-12-17-16.01.log.html
[4] https://etherpad.openstack.org/p/openstack-ansible-mitaka-midcycle
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-ansible] Mid Cycle Sprint

[Jesse Pretorius]

Hi everyone,

At the Mitaka design summit in Tokyo we had some corridor discussions about
doing a mid-cycle meetup for the purpose of continuing some design
discussions and doing some specific sprint work.

***
I'd like indications of who would like to attend and what
locations/dates/topics/sprints would be of interest to you.
***

For guidance/background I've put some notes together below:

Location

We have contributors, deployers and downstream consumers across the globe
so picking a venue is difficult. Rackspace have facilities in the UK
(Hayes, West London) and in the US (San Antonio) and are happy for us to
make use of them.

Dates
-
Most of the mid-cycles for upstream OpenStack projects are being held in
January. The Operators mid-cycle is on February 15-16.

As I feel that it's important that we're all as involved as possible in
these events, I would suggest that we schedule ours after the Operators
mid-cycle.

It strikes me that it may be useful to do our mid-cycle immediately after
the Ops mid-cycle, and do it in the UK. This may help to optimise travel
for many of us.

Format
--
The format of the summit is really for us to choose, but typically they're
formatted along the lines of something like this:

Day 1: Big group discussions similar in format to sessions at the design
summit.

Day 2: Collaborative code reviews, usually performed on a projector, where
the goal is to merge things that day (if a review needs more than a single
iteration, we skip it. If a review needs small revisions, we do them on the
spot).

Day 3: Small group / pair programming.

Topics
--
Some topics/sprints that come to mind that we could explore/do are:
 - Install Guide Documentation Improvement [1]
 - Development Documentation Improvement (best practises, testing, how to
develop a new role, etc)
 - Upgrade Framework [2]
 - Multi-OS Support [3]

[1] https://etherpad.openstack.org/p/oa-install-docs
[2] https://etherpad.openstack.org/p/openstack-ansible-upgrade-framework
[3] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support

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

Re: [Openstack-operators] openstack-ansible virt_type=lxc

[Kevin Carter]

Hello,

On 11/18/2015 08:02 PM, Wade Holler wrote:
> Just a little help needed.
>   on trusty
>
>
> using openstack-ansible ( allinone )
> changed user_variables nova_virt_type to lxc
> re-run os-nova-install
>
> Something else I need to do?
>

I've not played with the LXC hypervisor type in a long while however I 
remember the lxc option was not able to select a specific cpu type which 
the OSA project defaults to "host-type". So to correct this, you'll also 
want to set the following using the config_template options for 
nova.conf within your user_variables.yml file.

nova_nova_conf_overrides:
   libvirt:
 cpu_mode: None
 cpu_model: None

Once set you'll rerun the os-nova-install.yml play to reconfigure your 
hypervisor.


> When launching an instance I get the no hosts found.
> And in nova-conductor log I get the CPU model error
>
> 2015-11-18 20:16:40.041 3139 ERROR nova.scheduler.utils
> [req-3323b36a-cfe3-46b1-b3b7-cb606c77fda8
> 37f9aa000df343d4ad1090a3d8330d67 25158527007e4a1c95a6a4b0c214576e - - -]
> [instance: 0868a44b-79ab-419c-abcb-97a61831d309] Error from last host:
> ubu1 (node ubu1): [u'Traceback (most recent call last):\n', u' File
> "/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/manager.py",
> line 1903, in _do_build_and_run_instance\n filter_properties)\n', u'
> File
> "/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/manager.py",
> line 2063, in _build_and_run_instance\n instance_uuid=instance.uuid,
> reason=six.text_type(e))\n', u"RescheduledException: Build of instance
> 0868a44b-79ab-419c-abcb-97a61831d309 was re-scheduled: Config requested
> an explicit CPU model, but the current libvirt hypervisor 'lxc' does not
> support selecting CPU models\n"]
>
> Thanks!
> Wade
>

Also make sure your images are LXC compatible. There are some steps 
outlined here [0] which may be of use to you.

cheers.

[0] - 
https://ask.openstack.org/en/question/14401/ubuntu-image-for-libvirt_typelxc/

--

Kevin Carter
IRC: cloudnull

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

[Openstack-operators] [openstack-ansible] Documentation update planning

[Jesse Pretorius]

Hi everyone,

In the community meeting [1] this week we'll be having a facilitated
discussion with regards to documentation improvements for OpenStack-Ansible.

If you have any feedback you'd like considered, would like to be part of
the conversation, or are keen to contribute then please add to the etherpad
[2], respond to this email and ideally be in the meeting. :)

[1]
https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
[2] https://etherpad.openstack.org/p/oa-install-docs

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

[Openstack-operators] [openstack-ansible] Fedora/CentOS/other Support

[Jesse Pretorius]

Hi everyone,

There has been interest expressed from various corners to support more than
just Ubuntu in OpenStack-Ansible. While the project is very happy to work
on this, no-one has yet stepped up to take a lead role in the execution of
this work.

The current community has done some research into appropriate patterns to
use and has a general idea of how to do it - but in order to actually
execute there need to be enough people who commit to actually maintaining
the work once it's done. We don't want to carry the extra code if we don't
also pick up extra contributors to maintain the code.

If you're interested in seeing this become a reality and are prepared to
commit some time to making it happen, the project will be happy to work
with you to achieve it.

In this week's community meeting [1] we'll initiate a discussion on the
topic with the purpose of determining who's on board with the work.

In the following week's community meeting we will have a work breakdown
discussion where we'll work on filling out an etherpad [2] with what we
need to get done and who will be doing it. Naturally the etherpad can be
populated already by anyone who's interested. If you're actually happy to
volunteer to assist with the work, please feel free to add a note to that
effect on the etherpad.

[1]
https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
[2] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support

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

[Openstack-operators] openstack-ansible virt_type=lxc

[Wade Holler]

Just a little help needed.
 on trusty


using openstack-ansible ( allinone )
changed user_variables nova_virt_type to lxc
re-run os-nova-install

Something else I need to do?

When launching an instance I get the no hosts found.
And in nova-conductor log I get the CPU model error

2015-11-18 20:16:40.041 3139 ERROR nova.scheduler.utils
[req-3323b36a-cfe3-46b1-b3b7-cb606c77fda8 37f9aa000df343d4ad1090a3d8330d67
25158527007e4a1c95a6a4b0c214576e - - -] [instance:
0868a44b-79ab-419c-abcb-97a61831d309] Error from last host: ubu1 (node
ubu1): [u'Traceback (most recent call last):\n', u' File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/manager.py",
line 1903, in _do_build_and_run_instance\n filter_properties)\n', u' File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/manager.py",
line 2063, in _build_and_run_instance\n instance_uuid=instance.uuid,
reason=six.text_type(e))\n', u"RescheduledException: Build of instance
0868a44b-79ab-419c-abcb-97a61831d309 was re-scheduled: Config requested an
explicit CPU model, but the current libvirt hypervisor 'lxc' does not
support selecting CPU models\n"]

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

[Openstack-operators] [openstack-ansible] Mitaka Summit Summary

[Jesse Pretorius]

Hi everyone,

I've put together some thoughts based on the Mitaka Summit from the
OpenStack-Ansible point of view:
http://odyssey4me.github.io/openstack/ansible/mitaka/summit/2015/11/17/mitaka-summit.html

Please feel free to ping me with any feedback!

Thanks,

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

[Openstack-operators] [openstack-ansible] Mitaka Summit Schedule

[Jesse Pretorius]

Hi everyone,

I've added the final details for the summit sessions to the etherpad:
https://etherpad.openstack.org/p/openstack-ansible-mitaka-summit

Our sessions are open to anyone with an interest in deploying OpenStack
with Ansible.

Note that our two primary topics for discussion are:

Image-based Deployments:
We ask the questions:
 - What benefits are there to using image-based deployments?
 - How are people doing it today?

Production-ready Upgrades
We ask the questions:
 - What does it take to do upgrades in a production OpenStack environment?
 - How can we orchestrate it successfully?

We are very interested in gathering feedback from a broad group of
OpenStack operators based on the above topics and would love to have your
feedback!

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

[Openstack-operators] [openstack-ansible] Mitaka Summit sessions

[Jesse Pretorius]

Hi everyone,

As the Mitaka summit draws nearer, I'd like a broad view of what people
would like to discuss at the summit. This can include anyone's input!
Obviously our space and time will be limited, so any sessions that we don't
get to formally do at the summit we'll either try to do informally during
the summit (in a workgroup session or something like that), or we'll try to
engage at an alternative date (like a midcycle).

Some sessions have already been proposed - please feel free to add to the
list. Try to use the same format so that we know whether you're
facilitating or whether you want someone else to, what preparation
attendees would need, etc.

https://etherpad.openstack.org/p/openstack-ansible-mitaka-summit

It's probably a good idea to review the currently registered blueprints [0]
and specs [1] before adding any proposed sessions - just to make sure that
you're not covering something that's already on the go. For any current
blueprints/specs we're certainly open to more discussion, but it'd be great
to see that discussion happen in the spec reviews. :)

[0] https://blueprints.launchpad.net/openstack-ansible
[1]
https://review.openstack.org/#/q/project:openstack/openstack-ansible-specs+status:open,n,z

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

[Openstack-operators] [openstack-ansible] Release: Kilo 11.1.0

[Jesse Pretorius]

Hi everyone,

The openstack-ansible community is pleased to announce our release of the
Kilo 11.1.0 milestone.

This release fixes 57 bugs and implements 4 major blueprints, including:

* Keystone as a Federated Identity Provider
* Keystone as a Federated Service Provider
* Horizon Federation Single Sign-On
* Multi-Region Swift Clustering
* Ceilometer

For the full details please see launchpad [1].

For 11.2.0 [2] we'll be optionally incorporating Ceph as a back-end for
Glance, Cinder and Nova. Between now and then we expect to release at least
two hotfix releases in our usual cadence of once every two weeks.

If you're looking to kick the tyres to see how we do things or just want to
try OpenStack out and have a test system up and running within around 60
minutes, then try out our all-in-one deployment [3] which is used for
development/testing.

We welcome everyone to give it a try, participate in reviews [4] and get
involved! [5] If you have any questions, contact us in #openstack-ansible.

Best regards,

Jesse
IRC: odyssey4me

[1] https://launchpad.net/openstack-ansible/+milestone/11.1.0
[2] https://launchpad.net/openstack-ansible/+milestone/11.2.0
[3]
https://github.com/stackforge/os-ansible-deployment/blob/kilo/development-stack.rst
[4]
https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment,n,z
[5]
https://github.com/stackforge/os-ansible-deployment/blob/master/CONTRIBUTING.rst
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators