[openstack-dev] [kolla][iconic] baremetal network

[Manuel Sopena Ballesteros]

Dear Kolla-ansible team,

I am trying to deploy ironic through kolla-ansible. According to ironic 
documentation 
https://docs.openstack.org/ironic/rocky/install/configure-networking.html we 
need bare metal network with tenant_network_types = flat. However kolla-ansible 
configures:

[root@TEST-openstack-controller ~]# grep -R -i "baremetal" -R /etc/kolla/*
/etc/kolla/neutron-openvswitch-agent/ml2_conf.ini:mechanism_drivers = 
openvswitch,baremetal,l2population
/etc/kolla/neutron-server/ml2_conf.ini:mechanism_drivers = 
openvswitch,baremetal,l2population


[root@TEST-openstack-controller ~]# grep -R -i "tenant_network_types" -R 
/etc/kolla/*
/etc/kolla/neutron-openvswitch-agent/ml2_conf.ini:tenant_network_types = vxlan
/etc/kolla/neutron-server/ml2_conf.ini:tenant_network_types = vxlan

This is my filtered globals.yml:

[root@openstack-deployment ~]# grep -E -i "(^[^#]|ironic)" 
/etc/kolla/globals.yml
---
openstack_release: "rocky"
kolla_internal_vip_address: "192.168.1.51"
neutron_external_interface: "ens161"
enable_cinder: "yes"
enable_cinder_backend_nfs: "yes"
#enable_horizon_ironic: "{{ enable_ironic | bool }}"
enable_ironic: "yes"
#enable_ironic_ipxe: "no"
#enable_ironic_neutron_agent: "no"
#enable_ironic_pxe_uefi: "no"
glance_enable_rolling_upgrade: "no"
# Ironic options
# following value must be set when enable ironic, the value format
ironic_dnsmasq_dhcp_range: "192.168.1.100,192.168.1.150"
# PXE bootloader file for Ironic Inspector, relative to /tftpboot.
ironic_dnsmasq_boot_file: "pxelinux.0"
ironic_cleaning_network: "ens224"
#ironic_dnsmasq_default_gateway: 192.168.1.255
# Configure ironic upgrade option, due to currently kolla support
# two upgrade ways for ironic: legacy_upgrade and rolling_upgrade
# The variable "ironic_enable_rolling_upgrade: yes" is meaning legacy_upgrade
#ironic_enable_rolling_upgrade: "yes"
#ironic_inspector_kernel_cmdline_extras: []
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

ens224 is a my management network for admins to ssh and install and manage the 
physical nodes.

Any idea why tenant_network_types = vxlan and not flat as suggested by the 
ironic documentation?

Thank you

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: 
manuel...@garvan.org.au

NOTICE
Please consider the environment before printing this email. This message and 
any attachments are intended for the addressee named and may contain legally 
privileged/confidential/copyright information. If you are not the intended 
recipient, you should not read, use, disclose, copy or distribute this 
communication. If you have received this message in error please notify us at 
once by return email and then delete both messages. We accept no liability for 
the distribution of viruses or similar in electronic communications. This 
notice should not be removed.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] using molecule to test ansible playbooks and roles

[Paul Belanger]

On Sun, Nov 11, 2018 at 11:29:43AM +, Sorin Sbarnea wrote:
> I recently came across molecule   a 
> project originated at Cisco which recently become an officially Ansible 
> project, at the same time as ansible-lint. Both projects were transferred 
> from their former locations to Ansible github organization -- I guess as a 
> confirmation that they are now officially supported by the core team. I used 
> ansible-lint for years and it did same me a lot of time, molecule is still 
> new to me.
> 
> Few weeks back I started to play with molecule as at least on paper it was 
> supposed to resolve the problem of testing roles on multiple platforms and 
> usage scenarios and while the work done for enabling tripleo-quickstart to 
> support fedora-28 (py3). I was trying to find a faster way to test these 
> changes faster and locally --- and avoid increasing the load on CI before I 
> get the confirmation that code works locally.
> 
> The results of my testing that started about two weeks ago are very positive 
> and can be seen on:
> https://review.openstack.org/#/c/613672/ 
> 
> You can find there a job names opentstack-tox-molecule which runs in 
> ~15minutes but this is only because on CI docker caching does not work as 
> well as locally, locally it re-runs in ~2-3minutes.
> 
> I would like to hear your thoughts on this and if you also have some time to 
> checkout that change and run it yourself it would be wonderful.
> 
> Once you download the change you only have to run "tox -e molecule", (or 
> "make" which also clones sister extras repo if needed)
> 
> Feel free to send questions to the change itself, on #oooq or by email.
> 
I've been doing this for a while with ansible-role-nodepool[1], same
idea you run tox -emolecule and the role will use the docker backend to
validate. I also run it in the gate (with docker backend) however this
is online to validate that end users will not be broken locally if they
run tox -emolecule. There is a downside with docker, no systemd
integration, which is fine for me as I have other tests that are able to
provide coverage.

With zuul, it really isn't needed to run nested docker for linters and
smoke testing, as it mostly creates unneeded overhead.  However, if you
do want to standardize on molecule, I recommend you don't use docker
backend but use the delegated and reused the inventory provided by zuul.
Then you still use molecule but get the bonus of using the VMs presented
by zuul / nodepool.

- Paul

[1] http://git.openstack.org/cgit/openstack/ansible-role-nodepool

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase

[Gilles Dubreuil]

On 10/11/18 12:03 am, Jeremy Stanley wrote:

On 2018-11-09 16:35:22 +1100 (+1100), Gilles Dubreuil wrote:

Could you please provide permission [1] to upload commit merges?

I'm getting the following error after merging HEAD:

$ git review -R feature/graphql
remote:
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
To ssh://review.openstack.org:29418/openstack/neutron.git
  ! [remote rejected]   HEAD -> refs/publish/feature/graphql/bug/1802101
(you are not allowed to upload merges)
error: failed to push some refs to
'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git'

[...]

Per openstack/neutron's ACL[*] you need to be made a member of the
neutron-release group in Gerrit[**]. (This permission is tightly
controlled to avoid people accidentally pushing merge commits, which
is all too easy if you're not careful to keep your branches clean.)


That's fair enough.

I'll ask the neutron-release group then.

Thanks



[*] 
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config
[**] https://review.openstack.org/#/admin/groups/neutron-release

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] using molecule to test ansible playbooks and roles

[Sorin Sbarnea]

I recently came across molecule   a 
project originated at Cisco which recently become an officially Ansible 
project, at the same time as ansible-lint. Both projects were transferred from 
their former locations to Ansible github organization -- I guess as a 
confirmation that they are now officially supported by the core team. I used 
ansible-lint for years and it did same me a lot of time, molecule is still new 
to me.

Few weeks back I started to play with molecule as at least on paper it was 
supposed to resolve the problem of testing roles on multiple platforms and 
usage scenarios and while the work done for enabling tripleo-quickstart to 
support fedora-28 (py3). I was trying to find a faster way to test these 
changes faster and locally --- and avoid increasing the load on CI before I get 
the confirmation that code works locally.

The results of my testing that started about two weeks ago are very positive 
and can be seen on:
https://review.openstack.org/#/c/613672/ 

You can find there a job names opentstack-tox-molecule which runs in ~15minutes 
but this is only because on CI docker caching does not work as well as locally, 
locally it re-runs in ~2-3minutes.

I would like to hear your thoughts on this and if you also have some time to 
checkout that change and run it yourself it would be wonderful.

Once you download the change you only have to run "tox -e molecule", (or "make" 
which also clones sister extras repo if needed)

Feel free to send questions to the change itself, on #oooq or by email.

Cheers
Sorin Sbarnea__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev