[OpenStack-Infra] [goals][python3][charms] starting migration for charms team

[Doug Hellmann]

The migration of Zuul project settings for the
OpenStack Charms repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/charm-aodh
- openstack/charm-barbican
- openstack/charm-barbican-softhsm
- openstack/charm-ceilometer
- openstack/charm-ceilometer-agent
- openstack/charm-ceph
- openstack/charm-ceph-fs
- openstack/charm-ceph-mon
- openstack/charm-ceph-osd
- openstack/charm-ceph-proxy
- openstack/charm-ceph-radosgw
- openstack/charm-cinder
- openstack/charm-cinder-backup
- openstack/charm-cinder-ceph
- openstack/charm-cloudkitty
- openstack/charm-deployment-guide
- openstack/charm-designate
- openstack/charm-designate-bind
- openstack/charm-glance
- openstack/charm-glance-simplestreams-sync
- openstack/charm-glusterfs
- openstack/charm-gnocchi
- openstack/charm-guide
- openstack/charm-hacluster
- openstack/charm-heat
- openstack/charm-interface-bgp
- openstack/charm-interface-bind-rndc
- openstack/charm-interface-ceph-client
- openstack/charm-interface-ceph-mds
- openstack/charm-interface-designate
- openstack/charm-interface-gnocchi
- openstack/charm-interface-hacluster
- openstack/charm-interface-keystone
- openstack/charm-interface-keystone-admin
- openstack/charm-interface-keystone-credentials
- openstack/charm-interface-keystone-domain-backend
- openstack/charm-interface-manila-plugin
- openstack/charm-interface-mysql-shared
- openstack/charm-interface-neutron-plugin
- openstack/charm-interface-neutron-plugin-api-subordinate
- openstack/charm-interface-odl-controller-api
- openstack/charm-interface-openstack-ha
- openstack/charm-interface-ovsdb-manager
- openstack/charm-interface-rabbitmq
- openstack/charm-interface-service-control
- openstack/charm-ironic
- openstack/charm-keystone
- openstack/charm-keystone-ldap
- openstack/charm-layer-ceph-base
- openstack/charm-layer-openstack
- openstack/charm-layer-openstack-api
- openstack/charm-layer-openstack-principle
- openstack/charm-lxd
- openstack/charm-manila
- openstack/charm-manila-generic
- openstack/charm-manila-glusterfs
- openstack/charm-mistral
- openstack/charm-murano
- openstack/charm-neutron-api
- openstack/charm-neutron-api-genericswitch
- openstack/charm-neutron-api-odl
- openstack/charm-neutron-dynamic-routing
- openstack/charm-neutron-gateway
- openstack/charm-neutron-openvswitch
- openstack/charm-nova-cloud-controller
- openstack/charm-nova-compute
- openstack/charm-nova-compute-proxy
- openstack/charm-odl-controller
- openstack/charm-openstack-dashboard
- openstack/charm-openvswitch-odl
- openstack/charm-panko
- openstack/charm-percona-cluster
- openstack/charm-rabbitmq-server
- openstack/charm-specs
- openstack/charm-swift-proxy
- openstack/charm-swift-storage
- openstack/charm-tempest
- openstack/charm-trove
- openstack/charms.ceph
- openstack/charms.openstack

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

[OpenStack-Infra] [goals][python3][trove] starting zuul migration for trove

[Doug Hellmann]

The migration of Zuul project settings for the
trove repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/python-troveclient
- openstack/trove
- openstack/trove-dashboard
- openstack/trove-specs
- openstack/trove-tempest-plugin

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

[OpenStack-Infra] [goals][python3][nova] starting zuul migration for nova

[Doug Hellmann]

The migration of Zuul project settings for the
nova repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/nova
- openstack/nova-specs
- openstack/os-traits
- openstack/os-vif
- openstack/osc-placement
- openstack/placement
- openstack/python-novaclient

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

Re: [OpenStack-Infra] [sig][goal][python3] starting zuul migration for SIG repos

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-20 17:02:39 -0400:
> The migration of Zuul project settings for the
> SIG repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/governance-sigs
> - openstack/anchor
> - openstack/ossa
> - openstack/security-analysis
> - openstack/security-doc
> - openstack/security-specs
> - openstack/syntribos
> - openstack/syntribos-openstack-templates
> - openstack/syntribos-payloads
> - openstack/self-healing-sig
> - openstack/operations-guide
> - openstack/api-sig

All of the import patches for these repositories have merged and we are
ready to approve the cleanup patch
https://review.openstack.org/#/c/598360

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

[OpenStack-Infra] [goals][python3][cinder] starting zuul migration for cinder

[Doug Hellmann]

The migration of Zuul project settings for the
cinder repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/cinder
- openstack/cinder-specs
- openstack/cinder-tempest-plugin
- openstack/os-brick
- openstack/python-brick-cinderclient-ext
- openstack/python-cinderclient

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

[OpenStack-Infra] [goals][python3][qa] starting zuul migration for qa team

[Doug Hellmann]

The migration of Zuul project settings for the
Quality Assurance repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack-dev/bashate
- openstack-dev/devstack
- openstack-dev/devstack-plugin-cookiecutter
- openstack-dev/devstack-vagrant
- openstack-dev/grenade
- openstack-dev/hacking
- openstack/coverage2sql
- openstack/devstack-plugin-ceph
- openstack/devstack-plugin-container
- openstack/devstack-tools
- openstack/eslint-config-openstack
- openstack/karma-subunit-reporter
- openstack/openstack-health
- openstack/os-performance-tools
- openstack/os-testr
- openstack/patrole
- openstack/qa-specs
- openstack/stackviz
- openstack/tempest
- openstack/tempest-lib
- openstack/tempest-plugin-cookiecutter
- openstack/tempest-stress

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

[OpenStack-Infra] [goals][python3][ec2-api] ready to proceed with cleanup for ec2-api

[Doug Hellmann]

The ec2-api team has merged all of their zuul migration import patches
and we are ready to approve https://review.openstack.org/#/c/597582/

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

[OpenStack-Infra] [goals][python3][kolla] ready to proceed with cleanup for kolla

[Doug Hellmann]

The kolla team has approved all of their zuul migration imports and we
are ready to proceed with approving
https://review.openstack.org/#/c/597590/

Doug

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

[OpenStack-Infra] [goals][python3][release] ready to proceed with release team zuul cleanup

[Doug Hellmann]

The release team has approved all of the zuul migration patches and we
are ready to proceed with approving
https://review.openstack.org/#/c/598314/

Doug

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

Re: [OpenStack-Infra] [goals][python3][adjutant] starting zuul migration for adjutant

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-31 07:57:42 -0400:
> The migration of Zuul project settings for the
> adjutant repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/adjutant
> - openstack/adjutant-ui
> - openstack/python-adjutantclient

The import patches have all merged and we are ready to approve
https://review.openstack.org/#/c/598620/

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

[OpenStack-Infra] [goals][python3][barbican] starting zuul migration for barbican

[Doug Hellmann]

The migration of Zuul project settings for the
barbican repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/barbican
- openstack/barbican-specs
- openstack/barbican-tempest-plugin
- openstack/castellan-ui
- openstack/python-barbicanclient

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

Re: [OpenStack-Infra] [goals][python3][cloudkitty] starting zuul migration for cloudkitty

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-31 09:03:07 -0400:
> The migration of Zuul project settings for the
> cloudkitty repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/cloudkitty
> - openstack/cloudkitty-dashboard
> - openstack/cloudkitty-specs
> - openstack/cloudkitty-tempest-plugin
> - openstack/python-cloudkittyclient

The import patches have all merged and we are ready to proceed with
https://review.openstack.org/#/c/598929/

Doug

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

Re: [OpenStack-Infra] [goals][python3][interop] starting zuul migration for InteropWG

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-30 18:17:42 -0400:
> The migration of Zuul project settings for the
> InteropWG repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/interop
> - openstack/python-tempestconf
> - openstack/refstack
> - openstack/refstack-client

All of the import patches have been merged and we are ready to proceed
with approving https://review.openstack.org/#/c/598377/

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

Re: [OpenStack-Infra] [goals][python3][puppet] starting zuul migration for puppet team

[Doug Hellmann]

> On Aug 31, 2018, at 12:11 PM, Alex Schultz  wrote:
> 
> On Fri, Aug 31, 2018 at 9:42 AM, Doug Hellmann  <mailto:d...@doughellmann.com>> wrote:
>> Excerpts from Doug Hellmann's message of 2018-08-31 08:51:15 -0400:
>>> The migration of Zuul project settings for the
>>> Puppet OpenStack repositories has begun.
>>> Please do not approve any changes to
>>> openstack-infra/project-config/zuul.d/projects.yaml
>>> for the following repositories:
>>> 
>>> - openstack/puppet-aodh
>>> - openstack/puppet-barbican
>>> - openstack/puppet-ceilometer
>>> - openstack/puppet-ceph
>>> - openstack/puppet-cinder
>>> - openstack/puppet-cloudkitty
>>> - openstack/puppet-congress
>>> - openstack/puppet-designate
>>> - openstack/puppet-ec2api
>>> - openstack/puppet-freezer
>>> - openstack/puppet-glance
>>> - openstack/puppet-glare
>>> - openstack/puppet-gnocchi
>>> - openstack/puppet-heat
>>> - openstack/puppet-horizon
>>> - openstack/puppet-ironic
>>> - openstack/puppet-keystone
>>> - openstack/puppet-magnum
>>> - openstack/puppet-manila
>>> - openstack/puppet-mistral
>>> - openstack/puppet-monasca
>>> - openstack/puppet-murano
>>> - openstack/puppet-neutron
>>> - openstack/puppet-nova
>>> - openstack/puppet-octavia
>>> - openstack/puppet-openstack-cookiecutter
>>> - openstack/puppet-openstack-guide
>>> - openstack/puppet-openstack-integration
>>> - openstack/puppet-openstack-specs
>>> - openstack/puppet-openstack_extras
>>> - openstack/puppet-openstack_spec_helper
>>> - openstack/puppet-openstacklib
>>> - openstack/puppet-oslo
>>> - openstack/puppet-ovn
>>> - openstack/puppet-panko
>>> - openstack/puppet-qdr
>>> - openstack/puppet-rally
>>> - openstack/puppet-sahara
>>> - openstack/puppet-senlin
>>> - openstack/puppet-swift
>>> - openstack/puppet-tacker
>>> - openstack/puppet-tempest
>>> - openstack/puppet-trove
>>> - openstack/puppet-vitrage
>>> - openstack/puppet-vswitch
>>> - openstack/puppet-watcher
>>> - openstack/puppet-zaqar
>> 
>> The import patch has merged and we are ready to proceed with the cleanup
>> in https://review.openstack.org/598614
>> 
> 
> That's a chef repo?

Oops, wrong thread.

We’re not ready with the puppet cleanup and I still have a W-1 on that patch.

> 
>> Doug
>> 
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org 
>> <mailto:OpenStack-Infra@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [goals][python3][puppet] starting zuul migration for puppet team

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-31 08:51:15 -0400:
> The migration of Zuul project settings for the
> Puppet OpenStack repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/puppet-aodh
> - openstack/puppet-barbican
> - openstack/puppet-ceilometer
> - openstack/puppet-ceph
> - openstack/puppet-cinder
> - openstack/puppet-cloudkitty
> - openstack/puppet-congress
> - openstack/puppet-designate
> - openstack/puppet-ec2api
> - openstack/puppet-freezer
> - openstack/puppet-glance
> - openstack/puppet-glare
> - openstack/puppet-gnocchi
> - openstack/puppet-heat
> - openstack/puppet-horizon
> - openstack/puppet-ironic
> - openstack/puppet-keystone
> - openstack/puppet-magnum
> - openstack/puppet-manila
> - openstack/puppet-mistral
> - openstack/puppet-monasca
> - openstack/puppet-murano
> - openstack/puppet-neutron
> - openstack/puppet-nova
> - openstack/puppet-octavia
> - openstack/puppet-openstack-cookiecutter
> - openstack/puppet-openstack-guide
> - openstack/puppet-openstack-integration
> - openstack/puppet-openstack-specs
> - openstack/puppet-openstack_extras
> - openstack/puppet-openstack_spec_helper
> - openstack/puppet-openstacklib
> - openstack/puppet-oslo
> - openstack/puppet-ovn
> - openstack/puppet-panko
> - openstack/puppet-qdr
> - openstack/puppet-rally
> - openstack/puppet-sahara
> - openstack/puppet-senlin
> - openstack/puppet-swift
> - openstack/puppet-tacker
> - openstack/puppet-tempest
> - openstack/puppet-trove
> - openstack/puppet-vitrage
> - openstack/puppet-vswitch
> - openstack/puppet-watcher
> - openstack/puppet-zaqar

The import patch has merged and we are ready to proceed with the cleanup
in https://review.openstack.org/598614

Doug

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

[OpenStack-Infra] [goals][python3][packaging-rpm] starting zuul migration for packaging-rpm team

[Doug Hellmann]

The migration of Zuul project settings for the
Packaging-rpm repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/pymod2pkg
- openstack/renderspec
- openstack/rpm-packaging
- openstack/rpm-packaging-tools

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

[OpenStack-Infra] [goals][python3][cloudkitty] starting zuul migration for cloudkitty

[Doug Hellmann]

The migration of Zuul project settings for the
cloudkitty repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/cloudkitty
- openstack/cloudkitty-dashboard
- openstack/cloudkitty-specs
- openstack/cloudkitty-tempest-plugin
- openstack/python-cloudkittyclient

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

[OpenStack-Infra] [goals][python3][puppet] starting zuul migration for puppet team

[Doug Hellmann]

The migration of Zuul project settings for the
Puppet OpenStack repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/puppet-aodh
- openstack/puppet-barbican
- openstack/puppet-ceilometer
- openstack/puppet-ceph
- openstack/puppet-cinder
- openstack/puppet-cloudkitty
- openstack/puppet-congress
- openstack/puppet-designate
- openstack/puppet-ec2api
- openstack/puppet-freezer
- openstack/puppet-glance
- openstack/puppet-glare
- openstack/puppet-gnocchi
- openstack/puppet-heat
- openstack/puppet-horizon
- openstack/puppet-ironic
- openstack/puppet-keystone
- openstack/puppet-magnum
- openstack/puppet-manila
- openstack/puppet-mistral
- openstack/puppet-monasca
- openstack/puppet-murano
- openstack/puppet-neutron
- openstack/puppet-nova
- openstack/puppet-octavia
- openstack/puppet-openstack-cookiecutter
- openstack/puppet-openstack-guide
- openstack/puppet-openstack-integration
- openstack/puppet-openstack-specs
- openstack/puppet-openstack_extras
- openstack/puppet-openstack_spec_helper
- openstack/puppet-openstacklib
- openstack/puppet-oslo
- openstack/puppet-ovn
- openstack/puppet-panko
- openstack/puppet-qdr
- openstack/puppet-rally
- openstack/puppet-sahara
- openstack/puppet-senlin
- openstack/puppet-swift
- openstack/puppet-tacker
- openstack/puppet-tempest
- openstack/puppet-trove
- openstack/puppet-vitrage
- openstack/puppet-vswitch
- openstack/puppet-watcher
- openstack/puppet-zaqar

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

[OpenStack-Infra] [goals][python3][telemetry] starting zuul migration for telemetry

[Doug Hellmann]

The migration of Zuul project settings for the
Telemetry repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/aodh
- openstack/ceilometer
- openstack/ceilometermiddleware
- openstack/panko
- openstack/python-aodhclient
- openstack/python-pankoclient
- openstack/telemetry-specs
- openstack/telemetry-tempest-plugin

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

[OpenStack-Infra] [goals][python3][chef] starting zuul migration for chef team

[Doug Hellmann]

The migration of Zuul project settings for the
Chef OpenStack repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/cookbook-openstack-application-catalog
- openstack/cookbook-openstack-block-storage
- openstack/cookbook-openstack-client
- openstack/cookbook-openstack-common
- openstack/cookbook-openstack-compute
- openstack/cookbook-openstack-dashboard
- openstack/cookbook-openstack-dns
- openstack/cookbook-openstack-identity
- openstack/cookbook-openstack-image
- openstack/cookbook-openstack-integration-test
- openstack/cookbook-openstack-network
- openstack/cookbook-openstack-ops-database
- openstack/cookbook-openstack-ops-messaging
- openstack/cookbook-openstack-orchestration
- openstack/cookbook-openstack-telemetry
- openstack/cookbook-openstackclient
- openstack/openstack-chef
- openstack/openstack-chef-repo
- openstack/openstack-chef-specs

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

[OpenStack-Infra] [goals][python3][interop] starting zuul migration for InteropWG

[Doug Hellmann]

The migration of Zuul project settings for the
InteropWG repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/interop
- openstack/python-tempestconf
- openstack/refstack
- openstack/refstack-client

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

[OpenStack-Infra] [goal][python3][neutron] starting zuul migration for neutron

[Doug Hellmann]

The migration of Zuul project settings for the
neutron repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/networking-bagpipe
- openstack/networking-bgpvpn
- openstack/networking-midonet
- openstack/networking-odl
- openstack/networking-ovn
- openstack/networking-sfc
- openstack/neutron
- openstack/neutron-dynamic-routing
- openstack/neutron-fwaas
- openstack/neutron-fwaas-dashboard
- openstack/neutron-lib
- openstack/neutron-specs
- openstack/neutron-tempest-plugin
- openstack/neutron-vpnaas
- openstack/neutron-vpnaas-dashboard
- openstack/ovsdbapp
- openstack/python-neutronclient

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

[OpenStack-Infra] [goal][python3][tripleo] starting zuul migration for tripleo

[Doug Hellmann]

The migration of Zuul project settings for the
tripleo repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack-infra/tripleo-ci
- openstack/ansible-role-container-registry
- openstack/ansible-role-k8s-cinder
- openstack/ansible-role-k8s-cookiecutter
- openstack/ansible-role-k8s-glance
- openstack/ansible-role-k8s-keystone
- openstack/ansible-role-k8s-mariadb
- openstack/ansible-role-k8s-rabbitmq
- openstack/ansible-role-k8s-tripleo
- openstack/ansible-role-openstack-operations
- openstack/ansible-role-redhat-subscription
- openstack/ansible-role-tripleo-aodh
- openstack/ansible-role-tripleo-barbican
- openstack/ansible-role-tripleo-ceilometer
- openstack/ansible-role-tripleo-cinder
- openstack/ansible-role-tripleo-cookiecutter
- openstack/ansible-role-tripleo-designate
- openstack/ansible-role-tripleo-glance
- openstack/ansible-role-tripleo-gnocchi
- openstack/ansible-role-tripleo-haproxy
- openstack/ansible-role-tripleo-heat
- openstack/ansible-role-tripleo-horizon
- openstack/ansible-role-tripleo-ironic
- openstack/ansible-role-tripleo-keepalived
- openstack/ansible-role-tripleo-keystone
- openstack/ansible-role-tripleo-manila
- openstack/ansible-role-tripleo-memcached
- openstack/ansible-role-tripleo-mistral
- openstack/ansible-role-tripleo-modify-image
- openstack/ansible-role-tripleo-neutron
- openstack/ansible-role-tripleo-nova
- openstack/ansible-role-tripleo-octavia
- openstack/ansible-role-tripleo-opendaylight
- openstack/ansible-role-tripleo-ovn
- openstack/ansible-role-tripleo-panko
- openstack/ansible-role-tripleo-qdrouterd
- openstack/ansible-role-tripleo-rabbitmq
- openstack/ansible-role-tripleo-rsyslog-sidecar
- openstack/ansible-role-tripleo-sahara
- openstack/ansible-role-tripleo-sensu
- openstack/ansible-role-tripleo-swift
- openstack/ansible-role-tripleo-tacker
- openstack/ansible-role-tripleo-tempest
- openstack/ansible-role-tripleo-ui
- openstack/ansible-role-tripleo-zaqar
- openstack/dib-utils
- openstack/instack
- openstack/instack-undercloud
- openstack/os-apply-config
- openstack/os-collect-config
- openstack/os-net-config
- openstack/os-refresh-config
- openstack/paunch
- openstack/puppet-pacemaker
- openstack/puppet-tripleo
- openstack/python-tripleoclient
- openstack/tempest-tripleo-ui
- openstack/tripleo-ansible
- openstack/tripleo-common
- openstack/tripleo-common-tempest-plugin
- openstack/tripleo-docs
- openstack/tripleo-ha-utils
- openstack/tripleo-heat-templates
- openstack/tripleo-image-elements
- openstack/tripleo-ipsec
- openstack/tripleo-puppet-elements
- openstack/tripleo-quickstart
- openstack/tripleo-quickstart-extras
- openstack/tripleo-repos
- openstack/tripleo-specs
- openstack/tripleo-ui
- openstack/tripleo-upgrade
- openstack/tripleo-validations

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

Re: [OpenStack-Infra] [tc][goal][python3][election] starting migration of zuul settings for TC repos

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-20 13:22:26 -0400:
> The migration of Zuul project settings for the
> Technical Committee repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/api-wg
> - openstack/election
> - openstack/goal-tools
> - openstack/governance
> - openstack/openstack-specs
> - openstack/project-navigator-data
> - openstack/project-team-guide
> - openstack/service-types-authority

The import patches for these repositories have all merged and we are
ready to proceed with approving https://review.openstack.org/#/c/593706

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

[OpenStack-Infra] [goal][python3][heat] starting zuul migration for heat

[Doug Hellmann]

The migration of Zuul project settings for the
heat repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack-dev/heat-cfnclient
- openstack/heat
- openstack/heat-agents
- openstack/heat-cfntools
- openstack/heat-dashboard
- openstack/heat-specs
- openstack/heat-tempest-plugin
- openstack/heat-templates
- openstack/heat-translator
- openstack/python-heatclient
- openstack/tosca-parser

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

Re: [OpenStack-Infra] starting zuul migration for Oslo team repositories

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-06 11:54:35 -0400:
> The Zuul project settings for the Oslo repositories
> has begun. Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml for
> the following repositories:
> 
> - openstack-dev/cookiecutter
> - openstack-dev/oslo-cookiecutter
> - openstack-dev/pbr
> - openstack/automaton
> - openstack/castellan
> - openstack/debtcollector
> - openstack/devstack-plugin-amqp1
> - openstack/devstack-plugin-kafka
> - openstack/devstack-plugin-pika
> - openstack/devstack-plugin-zmq
> - openstack/futurist
> - openstack/mox3
> - openstack/oslo-specs
> - openstack/oslo.cache
> - openstack/oslo.concurrency
> - openstack/oslo.config
> - openstack/oslo.context
> - openstack/oslo.db
> - openstack/oslo.i18n
> - openstack/oslo.limit
> - openstack/oslo.log
> - openstack/oslo.messaging
> - openstack/oslo.middleware
> - openstack/oslo.policy
> - openstack/oslo.privsep
> - openstack/oslo.reports
> - openstack/oslo.rootwrap
> - openstack/oslo.serialization
> - openstack/oslo.service
> - openstack/oslo.tools
> - openstack/oslo.utils
> - openstack/oslo.versionedobjects
> - openstack/oslo.vmware
> - openstack/oslosphinx
> - openstack/oslotest
> - openstack/osprofiler
> - openstack/sphinx-feature-classification
> - openstack/stevedore
> - openstack/taskflow
> - openstack/tooz

All of the patches to import the zuul settings into these repositories
are approved and we are ready to proceed with
https://review.openstack.org/#/c/588842

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

Re: [OpenStack-Infra] starting zuul migration for mistral team repositories

[Doug Hellmann]

Excerpts from Nguyễn Trí Hải's message of 2018-08-23 18:04:39 +0900:
> All of the migration patches for the mistral team have merged
> and we are ready to approve https://review.openstack.org/#/c/593264/

https://review.openstack.org/593232 has not merged yet.

> 
> On Sat, Aug 18, 2018 at 3:08 PM Nguyễn Trí Hải 
> wrote:
> 
> > The Zuul project settings for the mistral repositories
> > has begun. Please do not approve any changes to
> > openstack-infra/project-config/zuul.d/projects.yaml for
> > the following repositories:
> >
> > - openstack/mistral
> > - openstack/mistral-dashboard
> > - openstack/mistral-extra
> > - openstack/mistral-lib
> > - openstack/mistral-specs
> > - openstack/mistral-tempest-plugin
> > - openstack/python-mistralclient
> >
> > --
> >
> > Nguyen Tri Hai / Ph.D. Student
> >
> > ANDA Lab., Soongsil Univ., Seoul, South Korea
> >
> > 
> > 
> > *[image:
> > http://link.springer.com/chapter/10.1007/978-3-319-26135-5_4]
> > * 
> >
> 

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

Re: [OpenStack-Infra] [powervmstackers][goal][python3] starting zuul migration for powervmstackers

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-22 09:30:21 -0400:
> The migration of Zuul project settings for the
> PowerVMStackers repositories has begun.
> Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml
> for the following repositories:
> 
> - openstack/ceilometer-powervm
> - openstack/networking-powervm
> - openstack/nova-powervm

All of the migration patches for the PowerVMStackers team have merged
and we are ready to approve https://review.openstack.org/#/c/595004/

Doug

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

[OpenStack-Infra] [powervmstackers][goal][python3] starting zuul migration for powervmstackers

[Doug Hellmann]

The migration of Zuul project settings for the
PowerVMStackers repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/ceilometer-powervm
- openstack/networking-powervm
- openstack/nova-powervm

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

[OpenStack-Infra] [kuryr][goal][python3] starting zuul migration for kuryr

[Doug Hellmann]

The migration of Zuul project settings for the
kuryr repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/fuxi
- openstack/fuxi-golang
- openstack/fuxi-kubernetes
- openstack/kuryr
- openstack/kuryr-kubernetes
- openstack/kuryr-libnetwork
- openstack/kuryr-tempest-plugin

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

[OpenStack-Infra] [sig][goal][python3] starting zuul migration for SIG repos

[Doug Hellmann]

The migration of Zuul project settings for the
SIG repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/governance-sigs
- openstack/anchor
- openstack/ossa
- openstack/security-analysis
- openstack/security-doc
- openstack/security-specs
- openstack/syntribos
- openstack/syntribos-openstack-templates
- openstack/syntribos-payloads
- openstack/self-healing-sig
- openstack/operations-guide
- openstack/api-sig

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

[OpenStack-Infra] [sahara][goal][python3] beginning zuul migration for sahara

[Doug Hellmann]

The migration of Zuul project settings for the
sahara repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/python-saharaclient
- openstack/sahara
- openstack/sahara-dashboard
- openstack/sahara-extra
- openstack/sahara-image-elements
- openstack/sahara-specs
- openstack/sahara-tests

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

[OpenStack-Infra] [tc][goal][python3][election] starting migration of zuul settings for TC repos

[Doug Hellmann]

The migration of Zuul project settings for the
Technical Committee repositories has begun.
Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml
for the following repositories:

- openstack/api-wg
- openstack/election
- openstack/goal-tools
- openstack/governance
- openstack/openstack-specs
- openstack/project-navigator-data
- openstack/project-team-guide
- openstack/service-types-authority

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

[OpenStack-Infra] [requirements][goal][python3] starting requirements repo zuul settings migration

[Doug Hellmann]

The migration of Zuul project settings for the requirements
repositories has begun. Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml for the following
repositories:

- openstack/requirements

Doug

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

[OpenStack-Infra] [goal][python3][ironic] starting ironic team migration

[Doug Hellmann]

The Zuul project settings for the ironic repositories
has begun. Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml for
the following repositories:

- openstack/bifrost
- openstack/ironic
- openstack/ironic-inspector
- openstack/ironic-inspector-specs
- openstack/ironic-lib
- openstack/ironic-python-agent
- openstack/ironic-python-agent-builder
- openstack/ironic-specs
- openstack/ironic-tempest-plugin
- openstack/ironic-ui
- openstack/molteniron
- openstack/networking-baremetal
- openstack/networking-generic-switch
- openstack/networking-generic-switch-tempest-plugin
- openstack/python-ironic-inspector-client
- openstack/python-ironicclient
- openstack/sushy
- openstack/sushy-tools
- openstack/virtualbmc

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

Re: [OpenStack-Infra] [goal][python3] starting zuul migration for Documentation team repositories

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-14 11:27:18 -0400:
> The Zuul project settings for the Documentation repositories
> has begun. Please do not approve any changes to
> openstack-infra/project-config/zuul.d/projects.yaml for
> the following repositories:
> 
> - openstack/constellations
> - openstack/contributor-guide
> - openstack/docs-specs
> - openstack/openstack-doc-tools
> - openstack/openstack-manuals
> - openstack/openstackdocstheme
> - openstack/os-api-ref
> - openstack/rst2bash
> - openstack/training-guides
> - openstack/training-labs
> - openstack/whereto

The Documentation team has merged all of the patches to import the zuul
settings into their repository, and we are ready to proceed with
removing them from the project-config repo by approving
https://review.openstack.org/#/c/591760.

Doug

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

[OpenStack-Infra] [goal][python3] starting zuul migration for Documentation team repositories

[Doug Hellmann]

The Zuul project settings for the Documentation repositories
has begun. Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml for
the following repositories:

- openstack/constellations
- openstack/contributor-guide
- openstack/docs-specs
- openstack/openstack-doc-tools
- openstack/openstack-manuals
- openstack/openstackdocstheme
- openstack/os-api-ref
- openstack/rst2bash
- openstack/training-guides
- openstack/training-labs
- openstack/whereto

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

[OpenStack-Infra] starting zuul migration for Oslo team repositories

[Doug Hellmann]

The Zuul project settings for the Oslo repositories
has begun. Please do not approve any changes to
openstack-infra/project-config/zuul.d/projects.yaml for
the following repositories:

- openstack-dev/cookiecutter
- openstack-dev/oslo-cookiecutter
- openstack-dev/pbr
- openstack/automaton
- openstack/castellan
- openstack/debtcollector
- openstack/devstack-plugin-amqp1
- openstack/devstack-plugin-kafka
- openstack/devstack-plugin-pika
- openstack/devstack-plugin-zmq
- openstack/futurist
- openstack/mox3
- openstack/oslo-specs
- openstack/oslo.cache
- openstack/oslo.concurrency
- openstack/oslo.config
- openstack/oslo.context
- openstack/oslo.db
- openstack/oslo.i18n
- openstack/oslo.limit
- openstack/oslo.log
- openstack/oslo.messaging
- openstack/oslo.middleware
- openstack/oslo.policy
- openstack/oslo.privsep
- openstack/oslo.reports
- openstack/oslo.rootwrap
- openstack/oslo.serialization
- openstack/oslo.service
- openstack/oslo.tools
- openstack/oslo.utils
- openstack/oslo.versionedobjects
- openstack/oslo.vmware
- openstack/oslosphinx
- openstack/oslotest
- openstack/osprofiler
- openstack/sphinx-feature-classification
- openstack/stevedore
- openstack/taskflow
- openstack/tooz

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

Re: [OpenStack-Infra] Moving logs into swift (redux)

[Doug Hellmann]

Excerpts from corvus's message of 2018-07-16 15:27:10 -0700:

> The Zuul dashboard makes finding the location of logs for jobs
> (especially post jobs) simpler.  So we no longer need logs.o.o to find
> the storage location (files or swift) for post jobs -- a user can just
> follow the link from the build history in the dashboard.

Is that information available through an API? I could update git-os-job
to use the API to get the URL (it knows how to construct the URL from
the commit ID today).

Doug

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

Re: [OpenStack-Infra] What's the future for git-review?

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-07-05 17:34:59 +:
> On 2018-07-05 13:23:57 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > I wonder if it would be useful to move that step of determining the
> > topic out to a hook, so that project-specific logic could be applied
> > as part of submitting a patch?
> 
> In the way of spitballing some alternatives, we could have it refuse
> to update the topic if it sees that the change already has a topic
> set in Gerrit (unless -t is used). That would address most of my
> gripes about the autotopic functionality. I find it especially
> annoying if I've stacked two changes in series for procedural
> reasons but want to maintain separate change topics for them in
> Gerrit.
> 
> We could of course also make it possible to disable topic inference
> with a configuration option.

Both of those ideas seem reasonable.

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

Re: [OpenStack-Infra] What's the future for git-review?

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-07-05 16:13:16 +:
> On 2018-07-05 09:03:44 -0700 (-0700), Andrew Grimberg wrote:
> > On 07/04/2018 06:57 PM, Jeremy Stanley wrote:
> [...]
> > > For that matter, setting the topic based on the local branch
> > > name could also get tossed while we're at it, and just keep the
> > > -t option for directly specifying a change topic when people
> > > really want to do it at time of upload.
> > 
> > Personally I would find this a regression. We inform our
> > communities to use local branches and git-review all the time and
> > tell them it will take care of setting the topic as long as they
> > do that. It's an extremely useful feature and I rely upon it
> > daily! I would hate to have to add an extra flag to my review
> > pushes.
> 
> Very helpful feedback, thanks! I'm on the fence about that one
> simply because the only reason git-review cared to set review topics
> at all originally was that at the time Gerrit only allowed you to do
> that when pushing a new commit. They've since separated topic
> modification out into its own action which can be done from the
> WebUI or API on an existing change without altering anything else
> about it. I do find the topic-branch-sets-change-topic behavior sort
> of unclean from an idempotency standpoint, as `git-review -d`
> followed by `git review` will alter the topic of your existing
> change to be the change index number when I'd rather it just left
> the topic alone.
> 
> My bigger concern is that git-review attempts to autodetect possible
> topic names based on (at this point increasingly outmoded)
> OpenStack-community-specific commit message footer contents like
> Implements and Closes-Bug. These I see as a nuisance and
> codification of OpenStackisms we should cleanse from the codebase.

I also rely heavily on the use of branch names to set the topic.
The bug and blueprint detection logic is less important to me
personally.

I wonder if it would be useful to move that step of determining the
topic out to a hook, so that project-specific logic could be applied
as part of submitting a patch?

Doug

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

Re: [OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

[Doug Hellmann]

Excerpts from corvus's message of 2018-05-30 09:25:14 -0700:
> Hi,
> 
> With recent changes implemented by the OpenStack Foundation to include
> projects other than "OpenStack" under its umbrella, it has become clear
> that the "Project Infrastructure Team" needs to change.
> 
> The infrastructure that is run for the OpenStack project is valued by
> other OpenStack Foundation projects (and beyond).  Our community has not
> only produced an amazing cloud infrastructure system, but it has also
> pioneered new tools and techniques for software development and
> collaboration.
> 
> For some time it's been apparent that we need to alter the way we run
> services in order to accommodate other Foundation projects.  We've been
> talking about this informally for at least the last several months.  One
> of the biggest sticking points has been a name for the effort.  It seems
> very likely that we will want a new top-level domain for hosting
> multiple projects in a neutral environment (so that people don't have to
> say "hosted on OpenStack's infrastructure").  But finding such a name is
> difficult, and even before we do, we need to talk about it.
> 
> I propose we call the overall effort "winterscale".  In the best
> tradition of code names, it means nothing; look for no hidden meaning
> here.  We won't use it for any actual services we provide.  We'll use it
> to refer to the overall effort of restructuring our team and
> infrastructure to provide services to projects beyond OpenStack itself.
> And we'll stop using it when the restructuring effort is concluded.
> 
> This is my first proposal: that we acknowledge this effort is underway
> and name it as such.
> 
> My second proposal is an organizational structure for this effort.
> First, some goals:
> 
> * The infrastructure should be collaboratively run as it is now, and
>   the operational decisions should be made by the core reviewers as
>   they are now.
> 
> * Issues of service definition (i.e., what services we offer and how
>   they are used) should be made via a collaborative process including
>   the infrastructure operators and the projects which use it.
> 
> To that end, I propose that we:
> 
> * Work with the Foundation to create a new effort independent of the
>   OpenStack project with the goal of operating infrastructure for the
>   wider OpenStack Foundation community.
> 
> * Work with the Foundation marketing team to help us with the branding
>   and marketing of this effort.
> 
> * Establish a "winterscale infrastructure team" (to be renamed)
>   consisting of the current infra-core team members to operate this
>   effort.
> 
> * Move many of the git repos currently under the OpenStack project
>   infrastructure team's governance to this new team.

I'm curious about the "many" in that sentence. Which do you anticipate
not moving, and if this new team replaces the existing team then who
would end up owning the ones that do not move?

> 
> * Establish a "winterscale infrastructure council" (to be renamed) which
>   will govern the services that the team provides by vote.  The council
>   will consist of the PTL of the winterscale infrastructure team and one
>   member from each official OpenStack Foundation project.  Currently, as
>   I understand it, there's only one: OpenStack.  But we expect kata,
>   zuul, and others to be declared official in the not too distant
>   future.  The winterscale representative (the PTL) will have
>   tiebreaking and veto power over council decisions.

That structure seems sound, although it means the council is going
to be rather small (at least in the near term).  What sorts of
decisions do you anticipate needing to be addressed by this council?

> 
>   (This is structured loosely based on the current Infrastructure
>   Council used by the OpenStack Project Infrastructure Team.)
> 
> None of this is obviously final.  My goal here is to give this effort a
> name and a starting point so that we can discuss it and make progress.
> 
> -Jim
> 

Thanks for starting this thread! I've replied to both mailing lists
because I wasn't sure which was more appropriate. Please let me
know if I should focus future replies on one list.

Doug

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

Re: [OpenStack-Infra] Zuul project evolution

[Doug Hellmann]

Excerpts from corvus's message of 2018-03-15 14:57:05 -0700:
> Hi,
> 
> To date, Zuul has (perhaps rightly) often been seen as an
> OpenStack-specific tool.  That's only natural since we created it
> explicitly to solve problems we were having in scaling the testing of
> OpenStack.  Nevertheless, it is useful far beyond OpenStack, and even
> before v3, it has found adopters elsewhere.  Though as we talk to more
> people about adopting it, it is becoming clear that the less experience
> they have with OpenStack, the more likely they are to perceive that Zuul
> isn't made for them.
> 
> At the same time, the OpenStack Foundation has identified a number of
> strategic focus areas related to open infrastructure in which to invest.
> CI/CD is one of these.  The OpenStack project infrastructure team, the
> Zuul team, and the Foundation staff recently discussed these issues and
> we feel that establishing Zuul as its own top-level project with the
> support of the Foundation would benefit everyone.
> 
> It's too early in the process for me to say what all the implications
> are, but here are some things I feel confident about:
> 
> * The folks supporting the Zuul running for OpenStack will continue to
>   do so.  We love OpenStack and it's just way too fun running the
>   world's most amazing public CI system to do anything else.
> 
> * Zuul will be independently promoted as a CI/CD tool.  We are
>   establishing our own website and mailing lists to facilitate
>   interacting with folks who aren't otherwise interested in OpenStack.
>   You can expect to hear more about this over the coming months.
> 
> * We will remain just as open as we have been -- the "four opens" are
>   intrinsic to what we do.
> 
> As a first step in this process, I have proposed a change[1] to remove
> Zuul from the list of official OpenStack projects.  If you have any
> questions, please don't hesitate to discuss them here, or privately
> contact me or the Foundation staff.
> 
> -Jim
> 
> [1] https://review.openstack.org/552637
> 

Thanks for posting this, Jim. I look forward to watching (and
participating in) the evolution of Zuul through this change!

Doug

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

Re: [OpenStack-Infra] Some branch issues with Zuul

[Doug Hellmann]

Excerpts from corvus's message of 2017-10-24 15:22:51 -0700:
> Hi,
> 
> A number of issues related to how jobs are defined and run on projects
> with stable branches have come up recently.  I believe they are all
> related, and they, as well as the solutions to them, must be considered
> together.
> 
> 
> The Problems
> 
> 
> I've identified the following five problems:
> 
> 1) Parents should have variants applied
> 
> Currently inheritance and variance are distinct.  Inheritance modifies a
> job's configuration statically at the time the configuration is loaded.
> Variants are applied dynamically right before the job runs.
> 
> That means that when a job starts, we pick a single job to start with,
> then apply variants of that particular job.  But since the inheritance
> has already been applied, any variants which a user may expect to apply
> to a parent job will not be applied.  When the inheritance chain is
> created at configuration time, only the "reference" definition of the
> job is used -- that is, the first appearance of the job.
> 
> In other words, more than likely, most jobs defined in a stable branch
> are going to inherit from a parent job defined on the master branch --
> even if that parent job has a stable branch variant.
> 
> 2) Variants may cause parents to be ignored
> 
> We currently ignore the parent attribute on a job variant.  If we did
> not, then when the variant is applied, it would pull in all of the
> attributes of its parent, which is likely to be on the master branch
> (since its parent will, as in #1, be the reference definition).
> 
> This ignoring of the parent attribute happens at configuration time
> (naturally, since that is when inheritance is applied).
> 
> This means that if the first job that matches a change is a variant
> (i.e., the reference definition of a job has a non-matching branch
> matcher), this top-level variant job will not actually have a parent.

In the discussion yesterday, and in the emails today, you've implied
that there is an ordering to job definitions beyond inheritance. Is that
discovery order documented somewhere? If not, is it simple enough to
describe in a few sentences here? Are repositories scanned in a
particular order, for example? Or is it based on something else?

Doug

> 
> 3) Variants may add duplicate pre/post playbooks
> 
> Currently, the master branch does not have an implied branch matcher, so
> jobs that exist on master and stable branches will generally be derived
> from both.
> 
> If such a job adds a pre or post playbook, the job that is ultimately
> created and run for a change on the stable branch may have those added
> by both the variant defined on the master branch as well as that defined
> on the stable branch (since pre and post playbooks are cumulative).
> 
> 4) Variants on branches without explicit playbooks should use branch
>playbooks
> 
> Whenever a job includes a pre-run, run (including the implicit run), or
> post-run playbook, Zuul remembers where and uses that branch of that
> repo to run that playbook.  If a job were constructed from the master
> branch, and then had a stable branch variant applied but did not repeat
> the pre-run, run, or post-run attributes from the master, then Zuul
> would end up attempting to run the playbook from the master branch
> rather than the stable.
> 
> 5) The master branch should have implied branch matchers
> 
> Currently jobs defined in an untrusted project on any branch other than
> 'master' have an implicit branch matcher applied to them.  This is what
> allows the version of a job in a stable branch to only affect the stable
> branch.  The fact that there is no implicit branch matcher applied to
> the master branch is what allows jobs defined in zuul-jobs to run on
> changes to any branch.
> 
> However, this also means that jobs on stable branches are frequently
> built from variants on both the master and stable branch.  This may work
> for a short while, but will fail as soon as someone wants to add
> something to the master branch which should not exist on the stable
> branch (e.g., enabling a new service by default).
> 
> 
> The Design Considerations
> =
> 
> In looking at these, I believe they have come about because of two
> design goals which we did not appreciate were in moderate tension with
> each other:
> 
> A) In-repo configuration for a project should apply to that branch.
> Changing the behavior of a job on a stable branch should merely involve
> changing the configuration or playbook in that stable branch.  When a
> project branches master to create a new stable branch, both branches
> should initially have the same content and behavior, but then evolve
> independently.
> 
> B) We should be able to define jobs not only in a central repository
> such as project-config, but a central *untrusted* repository such as
> zuul-jobs or openstack-zuul-jobs.
> 
> I think these are valid and important to keep in mind as we 

Re: [OpenStack-Infra] Moving docs-draft to logs.o.o

[Doug Hellmann]

Excerpts from corvus's message of 2017-09-20 15:23:21 -0700:
> Hi,
> 
> We originally created the docs-draft site (and filesystem partition)
> because doc builds were *big* and we had to expire them much more
> quickly than build logs.  The expiration times were 21 days for
> docs-draft and 6 months for build logs.
> 
> The tables have turned.
> 
> Docs-draft expiration is still 21 days, but build logs have gotten so
> large we've reduced expiration there to 30 days.
> 
> Since they are more closely matched now, we can fold docs-draft back
> into the logs volume and gain several benefits.  We're currently using
> 299G of space for docs-draft.  Accounting for the extra 9 days of
> retention would bring us to about 427G of space.  Our current headroom
> on logs is 3.0T, so we can handle that change immediately with no ill
> effect.
> 
> Once the existing retention period has expired, we can reclaim the space
> from the doc-draft volume and gain an additional 1.5T of capacity in
> logs.  Once that is done, accounting for the increased use from
> docs-draft jobs, we'll have an overall net gain of 1T of free space.
> 
> On top of all that, we will improve the UX of the docs-draft system by
> making it easier to switch to the build logs on a successful build.
> Currently we have to edit the hostname in the URL to do so; but in the
> future, we can simply remove trailing path components.
> 
> Assuming there aren't any objections, we can effect this change during
> the v3 transition, then perform the volume reclamation 3 weeks later.
> 
> -Jim
> 

+1


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

Re: [OpenStack-Infra] There is a problem while fallowing Project creator`s guide

[Doug Hellmann]

Excerpts from Kevin L. Mitchell's message of 2017-05-11 14:14:56 -0500:
> On Wed, 2017-05-10 at 08:29 -0400, Doug Hellmann wrote:
> > > When I click the link (https://pypi.python.org/pypi?%3Aaction=submit_form)
> > > It shows
> > > 
> > > 
> > > 
> > > 1. Use twine!
> > > 
> > > 2. Use the setup.py "register" command.
> > > 
> > > 3. Or upload your PKG-INFO file (generated by distutils) here:
> > > 
> > > 
> > > 
> > > Am I doing right? or did I miss something?
> > 
> > It looks like the PyPI maintainers have removed the web form for
> > registering projects. If you already have a project, and a PyPI account,
> > you can run "python setup.py register" in the root directory of your
> > project to submit the data to register the project. The rest of the
> > instructions for adding the openstackci user should be the same after
> > that.
> 
> No, they've also disabled the endpoint that's hit by "register"; it
> returns a response telling you to just upload your project.  I hit that
> about a month or so ago…

Oh, joy. So someone has to actually upload a release before they can
give openstackci permission to do the same?

Doug

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

Re: [OpenStack-Infra] There is a problem while fallowing Project creator`s guide

[Doug Hellmann]

Excerpts from Jea-Min Lim's message of 2017-05-09 17:18:48 -0400:
> There is a problem while fallowing Project creator`s guide
> 
> 
> 
> Hi, I`m following Project creator`s guide to create own OpenStack related
> project.
> 
> I have problem while following ‘Give OpenStack Permission to Publish
> Releases’ section(URL: https://docs.openstack.org/
> infra/manual/creators.html#give-openstack-permission-to-publish-releases).
> 
> 
> 
> This doc says ‘Once you have PyPI credentials visit https://pypi.python.org/
> pypi?%3Aaction=submit_form and fill in only the required fields.’
> 
> 
> 
> But I can`t see ‘the required fields.'
> 
> 
> 
> When I click the link (https://pypi.python.org/pypi?%3Aaction=submit_form)
> It shows
> 
> 
> 
> 1. Use twine!
> 
> 2. Use the setup.py "register" command.
> 
> 3. Or upload your PKG-INFO file (generated by distutils) here:
> 
> 
> 
> Am I doing right? or did I miss something?

It looks like the PyPI maintainers have removed the web form for
registering projects. If you already have a project, and a PyPI account,
you can run "python setup.py register" in the root directory of your
project to submit the data to register the project. The rest of the
instructions for adding the openstackci user should be the same after
that.

Doug


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

Re: [OpenStack-Infra] [Release-job-failures] Release of openstack/diskimage-builder failed

[Doug Hellmann]

pabelanger and clarkb helped debug this failure today, but because the
release was tagged manually the release team will let the project owners
handle addressing the failure, too.

Clark determined that the files on PyPI do not exactly match the
files on our tarballs server. One of the JSON metadata files was
regenerated, and because dictionaries are unordered it came out in
a different order.

Clark also checked the MD5 sum on PyPI and found that the signatures
match.

It's not clear why the job failed. Subsequent jobs have passed. One
course of action you could take is to retag the same commit with a
new version number to get new packages, just to be safe.

If you choose to stick with the existing packages, you will need
to manually submit the constraint update, since that job was skipped
after the upload job reported a failure.

Please also file the update in the releases repository, so that
there is a record of the fact that the release was made.

Excerpts from jenkins's message of 2017-04-12 03:52:00 +:
> Build failed.
> 
> - diskimage-builder-docs-ubuntu-xenial 
> http://logs.openstack.org/1f/1f200386061fe145645c9f8ffde627829cf998c9/release/diskimage-builder-docs-ubuntu-xenial/1e76d31/
>  : SUCCESS in 37s
> - diskimage-builder-tarball 
> http://logs.openstack.org/1f/1f200386061fe145645c9f8ffde627829cf998c9/release/diskimage-builder-tarball/6bf2ca2/
>  : SUCCESS in 43s
> - diskimage-builder-tarball-signing 
> http://logs.openstack.org/1f/1f200386061fe145645c9f8ffde627829cf998c9/release/diskimage-builder-tarball-signing/f219fb0/
>  : SUCCESS in 11s
> - diskimage-builder-pypi-both-upload 
> http://logs.openstack.org/1f/1f200386061fe145645c9f8ffde627829cf998c9/release/diskimage-builder-pypi-both-upload/077722e/
>  : FAILURE in 11s
> - diskimage-builder-announce-release diskimage-builder-announce-release : 
> SKIPPED
> - propose-diskimage-builder-update-constraints 
> propose-diskimage-builder-update-constraints : SKIPPED
> 

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

Re: [OpenStack-Infra] [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2017-01-13 12:43:54 +0900:
> hi,
> 
> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> > Hi
> >
> > As of today, the project neutron-vpnaas is no longer part of the neutron
> > governance. This was a decision reached after the project saw a dramatic
> > drop in active development over a prolonged period of time.
> >
> > What does this mean in practice?
> >
> > From a visibility point of view, release notes and documentation will no
> > longer appear on openstack.org as of Ocata going forward.
> > No more releases will be published by the neutron release team.
> > The neutron team will stop proposing fixes for the upstream CI, if not
> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >
> > How does it affect you, the user or the deployer?
> >
> > You can continue to use vpnaas and its CLI via the python-neutronclient and
> > expect it to work with neutron up until the newton
> > release/python-neutronclient 6.0.0. After this point, if you want a release
> > that works for Ocata or newer, you need to proactively request a release
> > [5], and reach out to a member of the neutron release team [3] for approval.
> 
> i want to make an ocata release. (and more importantly the stable branch,
> for the benefit of consuming subprojects)
> for the purpose, the next step would be ocata-3, right?

I'll be happy to help you get the tags and branches set up this cycle,
to give you time to either learn to do it next cycle or to apply for
official status so the release team can manage it.

To work out the details, we can either talk in #openstack-release
or you can email me to let me know what SHA you want to use for the
third milestone tag for Ocata.

Doug

> 
> > Assuming that the vpnaas CI is green, you can expect to have a working
> > vpnaas system upon release of its package in the foreseeable future.
> > Outstanding bugs and new bug reports will be rejected on the basis of lack
> > of engineering resources interested in helping out in the typical OpenStack
> > review workflow.
> > Since we are freezing the development of the neutron CLI in favor of the
> > openstack unified client (OSC), the lack of a plan to make the VPN commands
> > available in the OSC CLI means that at some point in the future the neutron
> > client CLI support for vpnaas may be dropped (though I don't expect this to
> > happen any time soon).
> >
> > Can this be reversed?
> >
> > If you are interested in reversing this decision, now it is time to step up.
> > That said, we won't be reversing the decision for Ocata. There is quite a
> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
> > neutron stadium project, and that means addressing all the gaps identified
> > in [6]. If you are interested, please reach out, and I will work with you to
> > add your account to [4], so that you can drive the neutron-vpnaas agenda
> > going forward.
> >
> > Please do not hesitate to reach out to ask questions and/or clarifications.
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/392010/
> > [2] https://review.openstack.org/#/c/397924/
> > [3] https://review.openstack.org/#/admin/groups/150,members
> > [4] https://review.openstack.org/#/admin/groups/502,members
> > [5] https://github.com/openstack/releases
> > [6]
> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
> >
> > __
> > 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-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-12-14 08:37:10 -0500:
> Excerpts from Joshua Hesketh's message of 2016-12-14 23:54:20 +1100:
> > The repos listed[0] have had stable/liberty branch removed and replaced
> > with a liberty-eol tag. Any open reviews have been abandoned.
> > 
> > Please let me know if there are any mistakes or latecomers to the list.
> > 
> > Cheers,
> > Josh
> 
> Projects seeing release note build failures with errors like:
> 
>   Command '(['git', 'log', '--simplify-by-decoration', '--pretty="%d"',
>   'origin/stable/liberty'],)' returned non-zero exit status 128
> 
> Should remove the liberty.rst page from their release notes builds.

I've posted https://review.openstack.org/410792 to teach reno about our
EOL process, but it may be some time before we have a release that
includes that fix because it relies on a significant rewrite of reno's
internals.

Rather than removing the liberty.rst file, it may also be possible
to just change "stable/liberty" in that file to "liberty-eol", since
the fix linked above should support that form, too. vdrok is going
to try this in ironic.

Doug

> 
> Where do I go to add this step to our branch EOL process documentation?
> 
> Doug
> 
> > 
> > [0]
> > https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> > 
> > On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh 
> > wrote:
> > 
> > > Hey Tony and all,
> > >
> > > I'm happy to take care of these retirements. However I probably can't get
> > > to it until Tuesday next week. So assuming no other infra root beats me to
> > > it I'll look at it then.
> > >
> > > Cheers,
> > > Josh
> > >
> > > On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
> > > wrote:
> > >
> > >> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
> > >>
> > >> > I'll batch the removal of the stable/liberty branches between Nov 28th
> > >> and Dec
> > >> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
> > >> zuul/layout.yaml
> > >> > to remove liberty exclusions and jobs.
> > >>
> > >> This took longer as there are a few repos that are scheduled for EOL that
> > >> were a
> > >> little problematic during the kilo cycle.  I've updated the list at [1]
> > >>
> > >> Can the infra team please run eol_branch.sh [2] over the repos listed at
> > >> that
> > >> URL [1] and flagged with 'Please EOL'.  The others will need to be done
> > >> later.
> > >>
> > >> eol_branch.sh needs just the repo names what can be generated with
> > >> something like:
> > >> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa4
> > >> 6269456f56649f0a4ac/raw/liberty_eol_data.txt
> > >> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
> > >>
> > >> The data format is a balance between human and machine readable.
> > >>
> > >> Yours Tony.
> > >>
> > >> [1] https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0
> > >> a4ac#file-liberty_eol_data-txt
> > >> [2] http://git.openstack.org/cgit/openstack-infra/release-tools/
> > >> tree/eol_branch.sh
> > >>
> > >> ___
> > >> OpenStack-Infra mailing list
> > >> OpenStack-Infra@lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> > >>
> > >
> > >

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

Re: [OpenStack-Infra] Release of networking-sfc for Newton - no stable/newton branch

[Doug Hellmann]

Excerpts from Henry Fourie's message of 2016-11-21 19:36:39 +:
> This patch merged but the stable/newton branch is not  created:
> 
> Release of networking-sfc for Newton https://review.openstack.org/#/c/396380/
> 
> -Louis

Sorry about that, I've just taken care of it.

Doug

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

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

[Doug Hellmann]

Excerpts from Tom Fifield's message of 2016-02-12 11:33:46 +0800:
> Hi,
> 
> Since about 11th January, wiki.o.o has been under attack by spammers.
> 
> They're creating new pages at a rate of more than 50 a day, with titles 
> that hint at calling certain phone numbers for various services. As a 
> result, google has started de-ranking o.o :)
> 
> If you look at
> 
> https://wiki.openstack.org/w/index.php?title=Special:NewPages
> 
> you'll see them.
> 
> It's across more than a dozen user accounts. I'm going to attempt some 
> manual cleaning, but we probably need to look for an extension to do 
> something about this pro-actively.

Doesn't this also mean that we have spam accounts in our OpenID
provider?

Doug

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

Re: [OpenStack-Infra] Translation setup challenges

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2015-12-28 22:28:46 +0100:
> Reading some IRC backlog and an incoming review with a new suggestion on 
> how to do translations in the project, I decided to write some problems 
> our current scripts have, together with questions and proposals. With 
> the growing big tent and the automatic way to setup translations, we get 
> more repos requesting translations - and more support requests.
> 
> Please read the description below and tell me what's wrong,what's 
> missing, where you disagree - and how to move forward.
> 
> thanks,
> Andreas
> 
> Setting up translations for new projects currently has the following
> challenges:
> 
> a) For "python" repositories, we expect that the locale file is
> located at $repo/locale/$repo.pot - without any change possible.
> This leads to python-novaclient/locale/python-novaclient.pot and
> oslo.log/locale/oslo.log.i18n - in both cases the python module has
> a different name, novaclient and oslo_log.
> 
> Currently everybody makes it wrong and we have to help them using
> the proper file names.
> 
> Proposal:
> * Simplify location to use $modulename/locale/$modulename
>   Can we determine modulename easily from the name in setup.cfg like
>   in jenkins/scripts/pypi-extract-name.py?
> 
> b) For dashboard repos, there's no common entry point yet and some are
> even setup like "python" repositories (designate-dashboard).
> 
> There's also no naming pattern on how to name files and everybody
> does it differently.
> 
> Currently the django component is called djangjo.pot, the
> javascript one djangojs.pot.
> 
> Question: Do we really need to do it this way or can we change it?
> 
> We should have a single entrypoint for projects and a standard way
> to call them.
> 
> Proposal: Define standard tox environement "extractmessages", it
> places translation files in (if django/djangojs are really the best
> names, I prefer to change them):
> * $modulename/locale/django.pot
> * $modulename/locale/djangojs.pot
> 
> Can we determine modulename easily from the name in setup.cfg like
> in jenkins/scripts/pypi-extract-name.py? At least
> django_openstack_auth is setup differently..
> 
> c) Projects currently need to add the pot file initially, our scripts
> fail if the directory does not exist.
> 
> Proposal: Make scripts robust so that they work even without
> initial pot file.

Having the scripts create the file with the right name seems like it
would solve (a) as well.

For (b), we've had some good luck with getting release-related
things right by setting up dependent changes to make it easier for
us to review the content going into the project repository before
a change goes into the control repo. For example, release requests
must have a related change to the global requirements list that
depends on the release request.  This lets us ensure that the
requirements update is/will be correct before creating the release.
We used a similar process to remove the version settings from
setup.cfg in projects for the first milestone tags.

You could require that patches to add translation jobs have a comment
linking to a change within the target project that adds the required
settings to tox.ini and whatever other config files can't be
auto-generated. If the patch to add those files depends on the
project-config patch, you can ensure that the files are present
with the correct names before enabling the job.

Doug

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

Re: [OpenStack-Infra] Stackforge projects: Manila Image Project and licensing considerations

[Doug Hellmann]

 On Jan 13, 2015, at 1:47 PM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2015-01-13 18:28:04 + (+), Csaba Henk wrote:
 [...]
 What we are puzzled on is the license. This is something we have
 to figure out before we think of setting up the project. In
 general it's understood that Apache License (v2) is preferred.
 Question: is that a strict requirement on Stackforge or just a
 suggestion?
 [...]
 
 As far as I know we've no formalized license policy for StackForge
 hosting, though I think there's an assumption that it needs to be
 redistributable under an OSI/DFSG/FSF recognized license variant.
 Certainly hosting a derivative work of software which is under a
 more copyleft license brings those additional license terms with
 it, and seems like a reasonably pragmatic choice to me (compared
 with the alternative of reinventing the wheel entirely in a
 clean-room effort to avoid the original license terms).
 
 http://ci.openstack.org/stackforge.html

The foundation does have some rules that apply to official projects, though. I 
don’t know how the current big-tent discussions will affect projects that are 
not using an Apache license. It has come up in the context of existing 
projects, and things that would not be expected to be included in an OpenStack 
release, but I don’t know if we’ve discussed it for projects that might want to 
be part of a release. You may want to check with the TC before choosing 
something other than Apache, just to make sure it isn’t going to turn into a 
problem for you in the future.

Doug

 
 -- 
 Jeremy Stanley
 
 ___
 OpenStack-Infra mailing list
 OpenStack-Infra@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


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

Re: [OpenStack-Infra] Stackforge projects: Manila Image Project and licensing considerations

[Doug Hellmann]

 On Jan 13, 2015, at 3:05 PM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2015-01-13 14:15:17 -0500 (-0500), Doug Hellmann wrote:
 The foundation does have some rules that apply to official
 projects, though.
 [...]
 
 Yes, definitely. I interpreted the question to be specifically about
 a project which was not intending to try for official inclusion in
 OpenStack. Obviously if the project wants to target official status
 then that's a different matter license-choice-wise.

Sure, I didn’t mean to imply you thought otherwise. I just wanted to point out 
the other side of the equation.

Doug

 -- 
 Jeremy Stanley


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

Re: [OpenStack-Infra] Error while stackforge project setup request

[Doug Hellmann]

A new version of python-daemon was released that doesn’t properly declare its 
dependency on docutils. I’ve reported the problem to the author, but if you 
want to work around the problem you could add docutils to the requirements list 
for the virtualenv being used in that build step.

 On Jan 10, 2015, at 3:03 PM, Mohammad Hanif mha...@brocade.com wrote:
 
 Hi all,
 
 Not sure if this is the right forum to ask this question.  I have submitted a 
 spec (https://review.openstack.org/#/c/145160/ 
 https://review.openstack.org/#/c/145160/) to request the creation of the 
 stackforge project.  The Jenkins review is failing on it and am not sure what 
 might be going wrong here.  Any help on resolving/guiding will be greatly 
 appreciated.
 
 To look at the error, you can either follow the link above or use the 
 following link.
 
 http://logs.openstack.org/60/145160/3/check/gate-project-config-layout/50ca1c9/console.html
  
 http://logs.openstack.org/60/145160/3/check/gate-project-config-layout/50ca1c9/console.html
 
 Thanks,
 --Hanif. 
 ___
 OpenStack-Infra mailing list
 OpenStack-Infra@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

[OpenStack-Infra] oslo summit sessions of interest to the infra team

[Doug Hellmann]

We have two sessions in the Oslo track for which we would like input from the 
infra team. I’ve tried to schedule them so they do not overlap with any other 
infra sessions. I hope to see some of you there!

2014-11-06 13:40  - Using alpha versioning for Oslo libraries 
2014-11-06 17:20  - Moving Oslo away from namespace packages 

Doug


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

Re: [OpenStack-Infra] How to get new package requirements into the CI system using a PPA and EPEL?

[Doug Hellmann]

On Tue, Jul 15, 2014 at 9:55 AM, Ken Giusti kgiu...@gmail.com wrote:
 On Tue, Jul 15, 2014 at 1:32 AM, Ian Wienand iwien...@redhat.com wrote:
 On 07/15/2014 02:23 AM, Ken Giusti wrote:
 So now my question - the unit tests (tox) require these libraries be
 installed on the machine the tests are running on in order for the
 tests to pass.  Is it possible to have these packages installed to the
 CI systems?  This would require adding EPEL or the Qpid PPA to these
 systems.  Is this something I can do?  If so, are there any guides to
 doing this?

 These packages would also need to be installed onto any systems that
 will run the gate tests for oslo.messaging.

 Fedora/CentOS nodes will have EPEL available, not much works without
 it :)

 I think you'd best look at puppet setup for hosts in [1].  Your jobs
 like gate-oslo.messaging-python27 run on the bare-* nodes which use
 this setup.  So it would need to add a section to add your repo and
 install the packages.

 -i

 [1] 
 https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/manifests/thick_slave.pp

 Ah, thanks for the pointer Ian, I'll look into this a bit (I'm not
 very familiar with this body of code).

 Good to hear about epel's availability.  But on the Ubuntu/Debian side
 - is it possible to add the Qpid project's PPA to the config project?
 From a quick 'grep' of the sources, it appears as if Pypy requires a
 PPA.  It's configured in
 modules/openstack_project/manifests/slave_common.pp).  Can I use this
 as an example for adding Qpid's PPA?

 thanks for your help - I'm a complete noob here :)

We should probably add these requirements to devstack to support
developer systems as well. I think that means this discussion should
happen on the openstack-dev mailing list, instead of just the -infra
mailing list (there is some cross-over but the devstack team is
separate from the infra team). Having the discussion there will also
give us a better chance of getting the attention of the folks from the
distros who work on ensuring the packages needed to run OpenStack are
easily available for all platforms, which is the larger question here.

Would you mind reposting over on openstack-dev so we can ensure
everyone involved will see the conversation?

Thanks,
Doug


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

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

Re: [OpenStack-Infra] Introducing Richard Jones

[Doug Hellmann]

That's great news!

Doug

 On Jun 22, 2014, at 7:23 PM, Michael Still mi...@stillhq.com wrote:
 
 Hey peoples,
 
 So, I've had a bit of a win and hired the primary author of pypi to
 work on OpenStack stuff for Rackspace Australia. His first day is
 today.
 
 I know we've had some pain with pypi in the past, but I think they're
 mostly resolved now. Regardless, I want you to know that Richard is
 around as a resource if you need him.
 
 Cheers,
 Michael
 
 -- 
 Rackspace Australia
 
 ___
 OpenStack-Infra mailing list
 OpenStack-Infra@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

Re: [OpenStack-Infra] FYI: today's propose translation run failures

[Doug Hellmann]

 On Jun 1, 2014, at 5:46 AM, Andreas Jaeger a...@suse.com wrote:
 
 On 05/30/2014 08:31 AM, Andreas Jaeger wrote:
 FYI, today's upstream translation proposal runs failed due to the
 changes from yesterday for log level extraction.
 
 The installed transifex client handles non-existing resources on the
 server differently than the version I tested with- it aborts instead of
 ignoring them ;(
 
 I have created now all missing resources and expect that the run
 tomorrow will be fine again,
 
 Everything is fine now on the jobs side,
 
 cheers,
 Andreas

\o/

Thanks, Andreas!


 -- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
 
 ___
 OpenStack-Infra mailing list
 OpenStack-Infra@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

Re: [OpenStack-Infra] establishing a standing policy for approving new oslo library imports

[Doug Hellmann]

 On Apr 23, 2014, at 4:39 AM, Thierry Carrez thie...@openstack.org wrote:
 
 Doug Hellmann wrote:
 Can we establish a standing policy that imports for new oslo libraries
 won't happen until I vote +1 the changeset? I can try to keep up and
 -1 until the team has a chance to review it, but I'm worried that I
 may miss an update to a changeset.
 
 You mean for the requirements repository ?

No, sorry I wasn't clear. I mean for the config repo for changes that create 
new oslo source repositories. 

Doug

 
 -- 
 Thierry Carrez (ttx)
 
 ___
 OpenStack-Infra mailing list
 OpenStack-Infra@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

[OpenStack-Infra] establishing a standing policy for approving new oslo library imports

[Doug Hellmann]

Can we establish a standing policy that imports for new oslo libraries
won't happen until I vote +1 the changeset? I can try to keep up and
-1 until the team has a chance to review it, but I'm worried that I
may miss an update to a changeset.

Doug

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

Re: [OpenStack-Infra] Moving some projects around

[Doug Hellmann]

On Wed, Mar 26, 2014 at 1:50 PM, James E. Blair jebl...@openstack.orgwrote:

 We've been discussing the thoroughly interesting problem of project
 taxonomy recently, and I'd like to describe what I think we've mostly
 decided we should do and make sure we're on the same page.  If we are,
 I'll invite the TC to weigh in and if they think we're completely wrong,
 we can work on some policy.

 Move the following projects to the openstack-attic/ org (because they
 are no longer active projects though they had some degree of
 officialness about them at the time they were active):

  * openstack-dev/openstack-qa
  * openstack/melange
  * openstack/python-melangeclient
  * openstack/openstack-chef

 We should make these read-only as well.

 Leave openstack-dev/sandbox where it is.  It's a useful tool for new
 openstack developers and third party CI systems -- it should be
 considered part of the openstack development process.

 Move openstack/python-openstackclient to stackforge.  It's apparently a
 project without an official program.  (Incidentally, this makes me sad.)


Dean may be ready to propose that as a program. Have you asked? It might
save moving it twice.

Doug




 Leave openstack/gantt where it is, but make it read-only.  The current
 state of development is considered a dead end, but there is likely to be
 a future attempt (and therefore future openstack/gantt repository).
 Rather than rename it and rename it back, or rename it to something like
 openstack-attic/gant-mark-one, we think mothballing it and then
 replacing the entire branch with a merge commit for the second forklift
 attempt (like we did with keystone-lite) is the least silly option and
 actually faithfully represents development history.

 -Jim

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

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

Re: [OpenStack-Infra] Using MySQL for unit tests in storyboard

[Doug Hellmann]

On Wed, Mar 26, 2014 at 4:30 PM, James E. Blair jebl...@openstack.orgwrote:

 Hi,

 I recently started looking into running the unit tests with MySQL.  I
 pushed the start of a change here to do that:

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

 In particular, that change implements something we've wanted to do for a
 long time elsewhere in OpenStack -- create a dedicated MySQL database
 for each test so that tests can safely run in parallel.  However, that
 has uncovered the following issues:

  * The tests do not use alembic, except for the migration test. This
could lead to variations in what the unit tests are testing against
as compared to production.

  * The model does not specify an engine for MySQL (this is a difference
between the model and the alembic migrations). So when the unit tests
are run on MySQL, they may end up on MyISAM (they do in the gate).

  * The two errors that show up in the test results for my patch relate
to how timestamps are stored differently between MySQL and SQLite.

  * The errors that you can not see in the test report from Jenkins but
would if you ran in an environment with InnoDB as the default engine
for MySQL are several instances of foreign key constraint errors.

 I think it is desirable to run the unit tests with MySQL largely because
 I think we should be testing it in the way we intend to use it in
 production.  Note especially the last point above -- our unit tests have
 significant problems with MySQL.  That suggests one of two things to me:
 either the tests aren't testing real behavior, or our system is actually
 broken in production.  Neither one seems like a good situation.

 My inclination would be to use MySQL for unit tests, use alembic to
 create the schema, and fix the errors currently uncovered by this.

 It's not going to be a trivial change, but I think it's worth doing.
 Before embarking on it, I'd like to see if we can get consensus.  We can
 talk about it here or possibly at the meeting tomorrow.

 Ruslan has commented in that review with the following:

  But, I think that we should consider work done in major OpenStack
  projects. They don't use real MySQL to run unit-tests. Here is what
  the do (or plan to do):
 
  * Run unit-tests on SQLite. DB schema is created from SQLA metadata
  * Run DB migration tests on MySQL and Postgres
  * Run tests to compare SQLA metadata and DB migrations to make sure
that they're in sync. Here is WIP patch
https://review.openstack.org/#/c/
 
  I'm not opposed to this direction, I just want to make sure we're
  aligned with the common practices in OpenStack

 (That last link doesn't seem to be correct.)

 That's a good point, but I personally find testing as close to
 production as possible desirable -- MySQL and SQLite are not compatible
 so we shouldn't pretend that they are.  If we prove this is a viable
 strategy, then I think we should recommend OpenStack projects adopt it
 as well.


Some of the folks from Mirantis who are working on oslo.db are working on
making it so we can use the models to create a database in our unit tests,
and then compare the resulting database with what the migrations do. That
*should* speed up tests, since we don't have to apply a set of migrations,
while still ensuring that we are testing using the same schema. It also has
the benefit of ensuring that our models represent what the migrations
create. I've copied Victor and Roman on this so they can add more detail.

Doug




 -Jim

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

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

Re: [OpenStack-Infra] Using MySQL for unit tests in storyboard

[Doug Hellmann]

On Wed, Mar 26, 2014 at 6:24 PM, Doug Hellmann
doug.hellm...@dreamhost.comwrote:




 On Wed, Mar 26, 2014 at 4:30 PM, James E. Blair jebl...@openstack.orgwrote:

 Hi,

 I recently started looking into running the unit tests with MySQL.  I
 pushed the start of a change here to do that:

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

 In particular, that change implements something we've wanted to do for a
 long time elsewhere in OpenStack -- create a dedicated MySQL database
 for each test so that tests can safely run in parallel.  However, that
 has uncovered the following issues:

  * The tests do not use alembic, except for the migration test. This
could lead to variations in what the unit tests are testing against
as compared to production.

  * The model does not specify an engine for MySQL (this is a difference
between the model and the alembic migrations). So when the unit tests
are run on MySQL, they may end up on MyISAM (they do in the gate).

  * The two errors that show up in the test results for my patch relate
to how timestamps are stored differently between MySQL and SQLite.

  * The errors that you can not see in the test report from Jenkins but
would if you ran in an environment with InnoDB as the default engine
for MySQL are several instances of foreign key constraint errors.

 I think it is desirable to run the unit tests with MySQL largely because
 I think we should be testing it in the way we intend to use it in
 production.  Note especially the last point above -- our unit tests have
 significant problems with MySQL.  That suggests one of two things to me:
 either the tests aren't testing real behavior, or our system is actually
 broken in production.  Neither one seems like a good situation.

 My inclination would be to use MySQL for unit tests, use alembic to
 create the schema, and fix the errors currently uncovered by this.

 It's not going to be a trivial change, but I think it's worth doing.
 Before embarking on it, I'd like to see if we can get consensus.  We can
 talk about it here or possibly at the meeting tomorrow.

 Ruslan has commented in that review with the following:

  But, I think that we should consider work done in major OpenStack
  projects. They don't use real MySQL to run unit-tests. Here is what
  the do (or plan to do):
 
  * Run unit-tests on SQLite. DB schema is created from SQLA metadata
  * Run DB migration tests on MySQL and Postgres
  * Run tests to compare SQLA metadata and DB migrations to make sure
that they're in sync. Here is WIP patch
https://review.openstack.org/#/c/
 
  I'm not opposed to this direction, I just want to make sure we're
  aligned with the common practices in OpenStack

 (That last link doesn't seem to be correct.)

 That's a good point, but I personally find testing as close to
 production as possible desirable -- MySQL and SQLite are not compatible
 so we shouldn't pretend that they are.  If we prove this is a viable
 strategy, then I think we should recommend OpenStack projects adopt it
 as well.


 Some of the folks from Mirantis who are working on oslo.db are working on
 making it so we can use the models to create a database in our unit tests,
 and then compare the resulting database with what the migrations do. That
 *should* speed up tests, since we don't have to apply a set of migrations,
 while still ensuring that we are testing using the same schema. It also has
 the benefit of ensuring that our models represent what the migrations
 create. I've copied Victor and Roman on this so they can add more detail.


And, that's the same work Ruslan was linking to based on his follow-up
message.

Doug




 Doug




 -Jim

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



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

[OpenStack-Infra] what is the state of wheel publishing?

[Doug Hellmann]

One of the things I've been thinking about for Juno and beyond is how Oslo
will make new features available to consuming projects safely (i.e.,
without publishing official releases weekly in a way that might break
stable branches). I know that at one point we talked about publishing alpha
releases as wheels to PyPI so that developers could see them when they run
their unit tests locally. Is that still the best solution to the problem?
Do we have the tools we need to make that work?

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

Re: [OpenStack-Infra] taskflow requirements

[Doug Hellmann]

On Mon, Nov 11, 2013 at 7:53 AM, Joshua Harlow harlo...@yahoo-inc.comwrote:

 I can put an upper bound on the version, that's fine with me. I'd rather
 not avoid adding taskflow to wait until some new preemptive gating process
 is in place. That doesn't exactly feel fair to the people creating taskflow
 or the people using it, especially since people are integrating it at this
 moment and it would be sad for their work to be lost due to a requirement
 line.

 As for part of oslo, cc'ing Doug since from my talks with him seem to be
 that it's just a library and to encourage the growth of useful libraries
 the red tape isn't needed (aka, taskflow has no strong ties to oslo and I'm
 not sure it should).


Right. Taskflow is new work and with an existing development team and
without any dependencies on the rest of Oslo, so I don't think it needs to
go through the Oslo processes. Josh and I agreed it should just live on
stackforge.

Doug



 Sent from my really tiny device...

  On Nov 11, 2013, at 7:33 PM, Monty Taylor mord...@inaugust.com
 wrote:
 
  There is a change up to add taskflow to the global requirements. I have
  no problem with this in principle, but it's one more that's in the set
  of things like pecan, wsme and friends that are in the set of things
  that Sean talked about in preemptively gate the universe.
 
  I'd like to not add it until we have a plan for at least assymetrical
  gating, so that changes to taskflow at least can't break cinder and
 friends.
 
  Further, I think we might need to discuss how to include libraries such
  as this. Should taskflow be a part of oslo?

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