Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Samuel Cassiba]

On Tue, Oct 11, 2016 at 11:32 AM, Alex Schultz  wrote:
> On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold  wrote:
>> Hi,
>>
>> On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
>>> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold  wrote:
>>> > Hi,
>>> >
>>> > in the rpm-packaging project we started to package the services and are
>>> > currently discussing a possible schema for configuration files and
>>> > snippets used by the systemd .service files (but this would also affect
>>> > OCF resource agents).
>>> > This affects packagers, endusers and config management systems (Chef,
>>> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
>>> > the list.
>>>
>>> This also affects deployment tools so you may want to include tripleo,
>>> kolla, fuel as they are downstream consumers and may have their own
>>> assumptions about how services are launched.
>>
>> Done.
>>
>>> > Most services (at least for SUSE and RDO) are using a single config
>>> > (e.g. /etc/nova/nova.conf) when starting the service. Some services
>>> > (e.g. neutron services like neutron-l3-agent) use multiple config files.
>>> >
>>> > There are multiple problems with that approach:
>>> > - when using a config-mgmt-system, users may want to override a config
>>> > option (for a feature that is not yet supported) but the
>>> > config-mgmt-system will override the config later again.
>>>
>>> Just to chime in here from a puppet standpoint, this is not a problem
>>> because we provide a way for a user to add any extra options they wish
>>> using the provider so it always ends up in the correct configuration
>>> file.
>>
>> Does that also work if you need extra configuration files for 3rd party
>> plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
>> party config file content to the needed neutron config but that's ugly imo.
>>
>
> Plugins also have their own .ini files and are handled differently.
> They get weird but we put the service configs in
> /etc/neutron/neutron.conf and agent configs get put in .ini files.
>
>>> > - when users adjust /etc/$service/$service.conf and a release update is
>>> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
>>> > overridden. That's good because the user changed something but otoh the
>>> > file (with all it's config options and comments) is no longer correct.
>>>
>>> Depending on the configuration management tool, the 'default' options
>>> and comments may not even be there so I'm not sure this is actually
>>> that much of a concern.  Also when you upgrade there is usually some
>>> sort of upgrade process that has to go along with your configuration
>>> management tool which should take care of this for you. So i'm not
>>> sure this needs to be a packaging concern.
>>>
>>> > - when config-mgmt-systems use templates for the $service.conf file,
>>> > updating theses templates is a lot of work.
>>>
>>> Yes which is why tools that don't use templates in the configuration
>>> management tool makes this a non-issue.  I'm not sure this needs to be
>>> a concern of packagers as it's an issue with the configuration
>>> management tool of choice and many of these tools have switched away
>>> from templates or are currently handling this.  If the configuration
>>> management tool doesn't support this or is suffering from this, simply
>>> adding conf.d support might help but then you also run into issues
>>> about ensuring things are removed and cleaned up.
>>
>> There *are* config-mgmt-tools still using templates. And having the
>> possibility to add config snippets simplifies the process here without
>> any downside for available solutions. Just don't use it if you don't
>> need it.
>>
>
> Yes there are but that's not a packaging concern other than providing
> a simple way to not have to deal with constantly managing
> $service.conf.  I'm ok with a conf.d folder, but I guess that's more
> of a question for folks who have to manage those templates today as to
> what their prefered method is. Speaking from experience with a tool
> that we try not to use templates, my preference is still to have
> $service.conf but don't have it replaced on package update.

>From the perspective of Chef, we stopped using erubis templates for
the service configs, adopting an attribute-driven config instead. This
got rid of the impossible to manage, thousand line long templates, and
gave us just what is needed to get the service off the ground.

Moving to a snippets model is feasible from our point of view, but it
doesn't make sense if only rpm does this and deb does not follow suit.
Having to maintain different config models would result in having to
maintain two lines of code to achieve the same desired result.

>
>>> > - setting configuration options per service (let's say cinder-volume
>>> > needs other config options than cinder-api) is not possible.
>>>
>>> So I agree this is more likely a real problem, but 

Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS

[Steven Dake (stdake)]

Haikel,

We attempted removing EPEL from our repo lists.  We got build errors on 
cinder-volume.  We have iscsi integration because vendors require it to work 
with their third party plugins.  The package iscsi-target-utils is not in the 
newton repos for RDO.

The package that fails can be seen here:
http://logs.openstack.org/04/385104/1/check/gate-kolla-dsvm-build-centos-source-centos-7-nv/f6cc1d8/console.html#_2016-10-11_19_34_40_662928

If you could fix that up, it would be grand ☺

Thanks
-steve


From: Haïkel 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Saturday, July 2, 2016 at 2:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements 
supported by CentOS

2016-07-02 20:42 GMT+02:00 jason 
>:
Pip Package Name Supported By Centos CentOS Name  Repo Name
==
ansible   yes
ansible1.9.noarchepel
docker-py  yes
python-docker-py.noarchextras
gitdb  yes
python-gitdb.x86_64epel
GitPython  yes
GitPython.noarchepel
oslo.config yes
python2-oslo-config.noarch centos-openstack-mitaka
pbryes
python-pbr.noarch   epel
setuptools yes
python-setuptools.noarchbase
six yes
python-six.noarch base
pycryptoyes
python2-crypto  epel
graphvizno
Jinja2no (Note: Jinja2 2.7.2 will be installed as
dependency by ansible)


As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
It's proven very hard to prevent EPEL pushing broken updates, or push
updates to fit OpenStack requirements.

Actually, all the dependency above but ansible, docker and git python
modules are in CentOS Cloud SIG repositories.
If you are interested to work w/ CentOS Cloud SIG, we can add missing
dependencies in our repositories.



As above table shows, only two (graphviz and Jinja2) are not supported
by centos currently. As those not supported packages are definitly not
used by OpenStack as well as Daisy. So basicaly we can use pip to
install them after installing other packages by yum. But note that
Jinja2 2.7.2 will be installed as dependency while yum install
ansible, so we need to using pip to install jinja2 2.8 after that to
overide the old one. Also note that we must make sure pip is ONLY used
for installing those two not supported packages.

But before you trying to use pip, please consider these:

1) graphviz is just for saving image depend graph text file and is not
used by default and only used in build process if it is configured to
be used.

2) Jinja2 rpm can be found at
http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
think is suitable for CentOS. I have tested it.

So, as far as Kolla deploy process concerned, there is no need to use
pip to install graphviz and Jinja2. Further more, if we do not install
Kolla either then we can get ride of pip totally!

I encourage all of you to think about not using pip any more for
Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
may be overide back and force if not using them carefully. So not
using pip will make things easier and make jump server more cleaner.
Any ideas?


Thanks,
Zhijiang

--
Yours,
Jason

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

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

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

[openstack-dev] [new][ironic] ironic-python-agent 1.0.5 release (liberty)

[no-reply]

We are excited to announce the release of:

ironic-python-agent 1.0.5: Ironic Python Agent Ramdisk

This release is part of the liberty stable release series.

Download the package from:

https://tarballs.openstack.org/ironic-python-agent/

For more details, please see below.

Changes in ironic-python-agent 1.0.4..1.0.5
---

855edf6 Enforce upper-constraints when building ramdisks
819b139 Use constraints for all the things
6acacf6 Fixes programmatic error in _install_grub()


Diffstat (except docs and test files)
-

.gitignore |  3 +
Dockerfile |  4 +-
.../extract_upper_constraints_from_tox_ini.sh  |  9 +++
imagebuild/common/generate_upper_constraints.sh| 79 ++
imagebuild/coreos/docker_build.bash|  7 +-
ironic_python_agent/extensions/image.py|  5 +-
tox.ini| 20 +-
7 files changed, 120 insertions(+), 7 deletions(-)




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

[openstack-dev] [tricircle]design summit schedule

[joehuang]

Hello,

Thanks to community's support, this is the first time for Tricircle to have 
room for design summit sessions.

The design summit schedule for Tricircle is prepared at [1][2].

If you have any question or suggestion, please feel free to reply in the thread.

[1]https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Tricircle%3A

[2]https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Tricircle

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

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[Michał Jastrzębski]

Hello Tom,

I must say I think this is bad news - especially for projects like
Kolla - ops centric.
One of reasons we created PTG in the first place is that Summit became
big and expensive, and project developers had harder and harder time
attending it due to budget issues. PTG would offer many of these devs
opportunity to talk to their peers, other project developers and build
OpenStack dev community. If project attends PTG, and most of them
plans to (again, Kolla included), that is a travel for project team.
If we hold 2 PTGs per year, that's big hit on travel budget (but still
smaller than summit).

PTG becomes very important for project team, summit arguably will
become less important as many of developers will be able to afford
only PTGs. If we say that "Don't expect Ops at PTG", that means
OpenStack dev community will become even more disconnected from Ops
community. Let's not forget that OpenStack is ultimately operators
tool, they need to care for it and in my opinion having close
relationship with them is extremely important for good of project. If
we raise cost of keeping this relationship, that might really hurt
OpenStack.

Cheers,
Michal

On 11 October 2016 at 21:29, Tom Fifield  wrote:
> Hello all,
>
> It's fantastic to see all of the PTG planning that has been going on in
> recent threads. It's clear there's a bit of confusion too, and as mriedem
> notes - us "mere mortals" are probably going to take some time to figure it
> out. Nothing's final of course, and we're going to take a while and iterate
> to success.
>
> With that in mind, I'm going to don the flame-proof suit and try to list a
> few very short, simple things to try and help, particularly to understand
> from the ops-y side of things. Throwing away all the context and nuance here
> that could stave off attacks, so please be nice :)
>
>
> * The OpenStack Summit is the start of a release cycle *
>
> If you do nothing else, please check out the diagram on the PTG site - it's
> good. We're finally acknowledging that a release cycle starts with planning,
> rather than when the code branch opens :) It means that we'll be finalizing
> development on one release while planning another, though we've actually
> been doing that already. The difference is that with this change, we'll have
> the summit in the right place to get decent feedback and ideas from users:
> at the very start of the cycle.
>
>
>
> * The OpenStack Summit is the place where the entire community gets together
> *
>
> Just because there's the PTG, doesn't mean the Summit becomes some marketing
> thing. If you want to have pre-spec brainstorming or feedback discussions
> with users: Summit. If you need to be involved in the strategic direction of
> OpenStack: Summit. If you just want to hang out with your project team and
> talk code only: you're going to love the PTG :)
>
>
> * Don't expect Ops at the PTG *
>
> The PTG has been designed for you to have a space to get stuff done.
> Unless a user is so deep into code that you basically look at them as "one
> of the team", they're not going to be there. If you'd like feedback and
> ideas from users, plan that to happen at the start of the cycle - i.e.
> Summit :)
>
>
>
> Thank you for your exceptional patience as we work all this out! Ready for
> the flame-tan now :)
>
>
>
> Regards,
>
>
> Tom
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Neutron] Design summit schedule

[Armando M.]

Neutrinos,

The design summit schedule for Neutron is getting live and into shape at
[1][2].

For questions/suggestions please feel free to reach out.

Cheers,
Armando

[1]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Neutron%3A
[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Neutron
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] [magnum] Subjects to discuss during the summit

[Qiming Teng]

On Mon, Oct 10, 2016 at 05:11:28PM +0200, Spyros Trigazis wrote:
> Hi heat and magnum.
> 
> Apart from the scalability issues that have been observed, I'd like to
> add few more subjects to discuss during the summit.
> 
> 1. One nested stack per node and linear scale of cluster creation
> time.
> 
> 1.1
> For large stacks, the creation of all nested stack scales linearly. We
> haven't run any tested using the convergence-engine.

Convergence would hopfully help in this scenario, thus definitely worth
a try.

 
> 1.3
> After the stack create API call to heat, magnum's conductor
> busy-waits heat with a thread/cluster. (In case of a magnum conductor
> restart, we lose that thread and we can't update the status in
> magnum). Investigate better ways to sync the status between magnum
> and heat.

Sounds like something to be done when magnum conductor bootstraps
itself.
 
> 2. Next generation magnum clusters
> 
> A need that comes up frequently in magnum is heterogeneous clusters.
> * We want to able to create cluster on different hardware, (e.g. spawn
>   vms on nodes with SSDs and nodes without SSDs or other special
>   hardware available only in some nodes of the cluster FPGA, GPU)
> * Spawn cluster across different AZs

This smells very much like a senlin use case.
> I'll describe briefly our plan here, for further information we have a
> detailed spec under review. [1]
> 
> To address this issue we introduce the node-group concept in magnum.
> Each node-group will correspond to a different heat stack. The master
> nodes can be organized in one or more stacks, so as the worker nodes.

My personal feeling is that modelling a node-group as a heat stack is
feasible though not flexible. It will end up heavy dependency on the
'stack-update' operation for whatever changes needed later. Senlin
provides you more APIs on managing such a group of things, without
masking out any existing features/capabilities from heat template/stack.

> We investigate how to implement this feature. We consider the
> following:
> At the moment, we have three template files, cluster, master and
> node, and all three template files create one stack. The new
> generation of clusters will have a cluster stack containing
> the resources in the cluster template, specifically, networks, lbaas
> floating-ips etc. Then, the output of this stack would be passed as
> input to create the master node stack(s) and the worker nodes
> stack(s).

Before investing resources into this effort, you may want to check if
senlin (can be improved to) meet magnum's requirements:

 - API [1]
 - User Doc [2] 
 - Developer Doc [3]
 - Quick Tutorial [4]

> 4. Finally, a thought under investigation is replacing the nodes one
>by one using a different image. e.g. Upgrade from fedora 24 to 25
>with new versions of packages all in a new qcow2 image. How could
>we update the stack for this?

Emm.. senlin is working on an operation that allows you to replace
existing nodes: 

  POST /v1/clusters//actions

  {
'replace_nodes': {
  'name_or_id_old_node': 'name_or_id_new_node',
  ...
}
  }


References:

[1] http://developer.openstack.org/api-ref/clustering/
[2] http://docs.openstack.org/developer/senlin/user/index.html
[3] http://docs.openstack.org/developer/senlin/developer/index.html
[4] http://docs.openstack.org/developer/senlin/tutorial/index.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-dev] PTG from the Ops Perspective - a few short notes

[Tom Fifield]

Hello all,

It's fantastic to see all of the PTG planning that has been going on in 
recent threads. It's clear there's a bit of confusion too, and as 
mriedem notes - us "mere mortals" are probably going to take some time 
to figure it out. Nothing's final of course, and we're going to take a 
while and iterate to success.


With that in mind, I'm going to don the flame-proof suit and try to list 
a few very short, simple things to try and help, particularly to 
understand from the ops-y side of things. Throwing away all the context 
and nuance here that could stave off attacks, so please be nice :)



* The OpenStack Summit is the start of a release cycle *

If you do nothing else, please check out the diagram on the PTG site - 
it's good. We're finally acknowledging that a release cycle starts with 
planning, rather than when the code branch opens :) It means that we'll 
be finalizing development on one release while planning another, though 
we've actually been doing that already. The difference is that with this 
change, we'll have the summit in the right place to get decent feedback 
and ideas from users: at the very start of the cycle.




* The OpenStack Summit is the place where the entire community gets 
together *


Just because there's the PTG, doesn't mean the Summit becomes some 
marketing thing. If you want to have pre-spec brainstorming or feedback 
discussions with users: Summit. If you need to be involved in the 
strategic direction of OpenStack: Summit. If you just want to hang out 
with your project team and talk code only: you're going to love the PTG :)



* Don't expect Ops at the PTG *

The PTG has been designed for you to have a space to get stuff done.
Unless a user is so deep into code that you basically look at them as 
"one of the team", they're not going to be there. If you'd like feedback 
and ideas from users, plan that to happen at the start of the cycle - 
i.e. Summit :)




Thank you for your exceptional patience as we work all this out! Ready 
for the flame-tan now :)




Regards,


Tom

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Armando M.]

On 11 October 2016 at 18:20, Sean M. Collins  wrote:

> Armando M. wrote:
> > At this point I feel that changing the pool range is even less justified.
> > If I had seen bug [4], I would have been against its fix, because you're
> > absolutely right as the change being not backward compatible.
>
> https://review.openstack.org/#/c/356026 was written by someone on the
> Trove team to
> help them with their CI jobs IIRC.
>
> CC'ing Matthew since he has more context. I went into the Trove channel
> and asked them about reverting 356026. It doesn't seem like an option at
> this point.
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%
> 23openstack-trove.2016-09-30.log.html#t2016-09-30T17:53:08


A revert with no follow up is clearly not a viable option most of the
times, and we clearly dug ourselves too deep now with [1]. Rather than
making the use of subnet pools conditional as done in [1], IMO we should
have made [2] conditional to preserve the existing provisioning behavior
and let Trove override.

[1] Ic89ceca76afda67da5545111972c3348011f294f
[2] https://review.openstack.org/#/c/356026/


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

[openstack-dev] [tricircle]Tricricle cleanning

[joehuang]

Hello, Team,

Understand this period is keeping us quite busy, for the Tricircle cleaning is 
in parallel with newton release period. Fortunately we have made great progress 
for the Tricircle cleaning and Newton release is approaching completeness.

(https://etherpad.openstack.org/p/TricircleSplitting)


  *   DONE 1. update README: https://review.openstack.org/#/c/375218/

  *   DONE 1. local plugin spec: https://review.openstack.org/#/c/368529/

  *   DONE 1. local and central plugin: https://review.openstack.org/#/c/375281/

  *
  *   2.central and local plugin for l3: 
https://review.openstack.org/#/c/378476/

  *   2. remove api gateway code: https://review.openstack.org/#/c/384182/

  *   3.  security group support: https://review.openstack.org/#/c/380054/

  *   3. installation guide update(no api gateway):

  *   Part1: Single Node installation: https://review.openstack.org/#/c/384872/

  *   Part2: Multi nodes installation: WIP

  *

  *   - Try to get these above cleaning patches merged before Oct.19, 
before Barcelona summit.

Except the patch " Multi nodes installation", all other patches are in the 
queue of review for the Tricircle cleaning. After these patches get merged, we 
can have a first clean Tricircle baseline for networking automation, it's good 
to have a tagging for this baseline as a milestone.

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

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

[openstack-dev] [tricircle]tricircle newton release

[joehuang]

Hello, team,

Two patches for the stable/newton branch of Tricircle were prepared.

Update the dependency: https://review.openstack.org/#/c/379966/

Release notes: https://review.openstack.org/#/c/384055/

Let's review and get these two patches merged before Oct.15, so that we can 
have Newton release tagging and published in time.

Thank you.

Best Regards
Chaoyi Huang (joehuang)



From: joehuang
Sent: 30 September 2016 11:41
To: openstack-dev
Subject: [openstack-dev][tricircle]stable/newton branch created

Hello, all

All "must to have" patches have been merged, the "stable/newton" branch was 
just created: https://github.com/openstack/tricircle/tree/stable/newton

Before the newton release, two more patches needed for this branch: one patch 
to update devstack related script to download newton branch code, one patch for 
release note.

The release date for Tricircle Newton will be around Oct.15, after 
Nova/Cinder/Neutron publish their Newton release.

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Sean M. Collins]

Armando M. wrote:
> At this point I feel that changing the pool range is even less justified.
> If I had seen bug [4], I would have been against its fix, because you're
> absolutely right as the change being not backward compatible.

https://review.openstack.org/#/c/356026 was written by someone on the Trove 
team to
help them with their CI jobs IIRC.

CC'ing Matthew since he has more context. I went into the Trove channel
and asked them about reverting 356026. It doesn't seem like an option at
this point.

http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2016-09-30.log.html#t2016-09-30T17:53:08


-- 
Sean M. Collins

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Clark Boylan]

On Tue, Oct 11, 2016, at 05:58 PM, Carl Baldwin wrote:
> On Tue, Oct 11, 2016 at 6:26 PM, Clark Boylan 
> wrote:
> 
> > On Tue, Oct 11, 2016, at 05:14 PM, Carl Baldwin wrote:
> > > I found this [1] added here [2]. Since the provider is using 10.0.0.0/8
> > > on
> > > the public interface, and the subnet pool is also 10.0.0.0/8 the call to
> > > ip
> > > route replace eliminates the route through the public interface.
> >
> > It is also an issue if you have multiple subnets within 10/8 and rely on
> > your default route to route to them (though I don't think we currently
> > have any of these in the gate currently since rackspace sets more
> > specific routes for the subnets used for private networking there). This
> > would be the case if using a neutron setup with tenant networking and
> > floating IPs like we had with the old hpcloud.
> >
> 
> Any time we fiddle with the host's routing table with address ranges that
> we make up, we run the risk of clashing with something "real". What do we
> do? I guess we can try our best to pick ranges that shouldn't clash and
> try
> to minimize how much of the space we use up. Then, for those that get a
> clash, we provide the option to override. That's kind of what we've been
> doing, right? We could try other tricks to pick more obscure IP ranges
> that
> shouldn't be used anywhere (like 100.64.0.0/10 or the ranges reserved for
> documentation, which we do for ipv6) but with so many people competing
> for
> such a small space, I don't know if we can ever pick anything that won't
> ever clash. It just doesn't feel like there is a good answer.

Right my whole argument behind reusing FIXED_RANGE is its the var that
we have set for every devstack test job to avoid such conflicts. Its
value is currently conflict free as far as I know and has been set
intentionally to avoid the various conflicts we have run into over time.
This doesn't mean we will never run into new conflicts but it gives us a
single place to very clearly signal "this is useable". Maybe we need to
add a meta var that FIXED_RANGE and SUBNET POOL ranges are derived from.
Essentially set a value that is a large subnet that isn't conflicting
with anything and have the other ranges split it evenly. Then maintain
backward compat by using any hard set sub ranges that are supplied.

> 
> Could we instead modify devstack to use a different network namespace (as
> in ip nets) to represent the "external" network? I think the real problem
> is that we're trying to use the host's real network as the "external
> network" for our testing. We are combining any combination of real world
> subnets with made up hard-coded default address ranges. If we separated
> the
> two, then there would be no chance for conflict. I'm just thinking out
> loud
> here. There could be all kinds of difficulty with this idea.

Yup that is indeed the problem. Another related issue that makes this
extra turtly is we are running neutron within clouds running neutron. As
a result chance for conflicts is probably higher than if you were just
running on a random host on a random subnet (since we are probably more
likely to leak defaults between neutrons). It would definitely be neat
to separate these things more though. We have been slowly separating the
layer 2 devices (was sort of forced on us initially by OVH's use of /32s
on eth0 and nova nets inability to properly handle that). Probably worth
further exploring that for layer 3 as well though as you say this could
be difficult.

Clark


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

[openstack-dev] [nova] Development policy updates

[Matt Riedemann]

While reviewing specs I've come across several related to adding more or 
exposing existing metrics monitors from nova-compute. At the Newton 
midcycle we discussed how we were going to freeze feature requests like 
this and start deprecating this capability, at least open-ended until 
there is a clear replacement or alternative. None of that is mentioned 
in the devref though, so I've posted a change with wording about that here:


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

You'll also note there is a change below that one:

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

which updates the 'out of tree' section in that same document to 
explicitly point out that hooks/extension points/classloading 
managers/services/drivers are also actively being deprecated and 
removed. That's a topic that has come up several times over the past few 
releases so we need to be clear about it in the documentation.


I've added the nova-core team to both reviews so we're all on the same 
page within the core team, but also sending this out as an FYI so 
everyone working on the project is aware and can raise concerns in the 
reviews if they feel the need.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [ovs-discuss] [ovn][networking-sfc]

[Murali R]

Thanks Cathy, My typo, not sfc. The question was for networking-ovn without
port-security. Anyways, I sent another query with proper title and content,
please ignore this email.

On Tue, Oct 11, 2016 at 12:07 PM, Cathy Zhang 
wrote:

> The guide is the networking-ovn guide. Not sure what is meant by
> “port-security”. From networking-sfc point of view, security group is not
> needed.
>
>
>
> Thanks,
>
> Cathy
>
>
>
> *From:* discuss [mailto:discuss-boun...@openvswitch.org] *On Behalf Of *Murali
> R
> *Sent:* Monday, October 10, 2016 2:47 PM
> *To:* discuss; OpenStack Development Mailing List (not for usage
> questions)
> *Subject:* [ovs-discuss] [ovn][networking-sfc]
>
>
>
> Networking-sfc and ovn install guide says "port_security" must be enabled
> when enabling networkin-sfc  (networking-ovn/doc/source/install.rst --
> line 165)
>
>
>
> In my use cases it gets too complicated if I use port-security, so was
> disabling it.
>
>
>
> Please let me know if there is any hard requirement that this MUST be
> enabled in Neutron?
>
>
>
> -Murali
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Armando M.]

On 11 October 2016 at 17:05, Clark Boylan  wrote:

> On Tue, Oct 11, 2016, at 05:01 PM, Armando M. wrote:
> > On 11 October 2016 at 16:54, Clark Boylan  wrote:
> >
> > > On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> > > > On 11 October 2016 at 16:43, Clark Boylan 
> wrote:
> > > >
> > > > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > > > > On 11 October 2016 at 14:09, Clark Boylan 
> > > wrote:
> > > > > >
> > > > > > > Hello everyone,
> > > > > > >
> > > > > > > Currently multinode testing + neutron is broken in clouds that
> use
> > > > > > > portions of 10.0.0.0/8 for their networking due to route
> conflicts
> > > > > with
> > > > > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > > > > s/1629133
> > > > > > > is tracking the issue for us. I would like to see this get
> resolved
> > > > > > > properly before we do further work on multinode testing as it
> is
> > > > > > > difficult to review and determine what failures are legit vs
> which
> > > > > > > failures are related to this bug and whether or not a specific
> > > > > multinode
> > > > > > > test has decided to workaround the issue.
> > > > > > >
> > > > > > > The change to use subnet pools in devstack is a non backward
> > > compatible
> > > > > > > change for devstack currently and it doesn't appear to have
> been
> > > > > > > documented in devstack at all. Would be great if we can
> finally fix
> > > > > this
> > > > > > > and get testing back to working and however we fix it ensure
> that
> > > > > > > devstack has the appropriate documentation.
> > > > > > >
> > > > > >
> > > > > > What is holding [1] back? Merging that would resolve the issue,
> then
> > > we
> > > > > > can
> > > > > > drill down into why subnetpools interfere with the underlying
> > > networking
> > > > > > setup. I have asked Carl to look into broken build [2]
> > > > > >
> > > > > > [1] https://review.openstack.org/#/c/379543/
> > > > > > [2]
> > > > > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > > > > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> > > > >
> > > > > Yours is one of the two -1's on the change :) I think that devstack
> > > core
> > > > > is probably holding back due to the two -1s there. If we are ok
> with
> > > > > iterating on making it better rather than all in one shot maybe
> that
> > > > > change is good for now and we can update the reviews?
> > > > >
> > > >
> > > > Well, that means the ball is in the contributor's court, who is
> supposed
> > > > to
> > > > address reviewers' concerns :)
> > > >
> > > The comments on the change with -1's are opposed to doing what the
> > > change does. I don't know how I can possibly address them.
> > >
> >
> > Then say so on the review and I am happy to rephrase to make sure I get
> > my
> > message across correctly. If you let the review rot how can you expect it
> > to make progress? That's like Openstack 101
>
> It does say so clearly in the commit itself:
>
> "It turns out that many people have already chosen fixed ranges that
> work for their environments. They have done so to avoid conflicts with
> existing networking ranges and routing. The change to use 10.0.0.0/8 and
> apply routes for this network to neutron interfaces prevents anyone from
> using networks within that range for anything else.
>
> For example imagine you have a cloud provider that provides private IPv4
> addresses allocated out of ranges in 10.0.0.0/8 and they do all public
> networking over ipv6. This change to devstack prevents you from using
> those private networks properly after starting neutron with devstack.
> However, in situations like this FIXED_RANGE should already represent a
> safe range to use so just use it."
>
> The comments both refuse to allow FIXED_RANGE as the default and its the
> only reason I pushed that patch. I personally believe this is the right
> fix, if neutron/devstack disagree they should feel welcome to propose
> alterantives, but I am not going to not use FIXED_RANGE when it was the
> whole point of the change in the first place.
>
>
Okay at least I am glad we got this clarified :)

This discussion gave me the opportunity to drill down further,  and looking
at this more closely, the issue seems to stem from [1], which fiddles with
the routing table and it caused other troubles [2]. The original use of
subnetpools as introduced by [3] should not have side effects whatsoever.
At this point I feel that changing the pool range is even less justified.
If I had seen bug [4], I would have been against its fix, because you're
absolutely right as the change being not backward compatible.

[1] https://review.openstack.org/#/c/356026
[2] https://bugs.launchpad.net/devstack/+bug/1628267
[3] https://review.openstack.org/#/c/282559/
[4] https://bugs.launchpad.net/devstack/+bug/1613717


> Clark
>
> 

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Clark Boylan]

On Tue, Oct 11, 2016, at 05:14 PM, Carl Baldwin wrote:
> I found this [1] added here [2]. Since the provider is using 10.0.0.0/8
> on
> the public interface, and the subnet pool is also 10.0.0.0/8 the call to
> ip
> route replace eliminates the route through the public interface.

It is also an issue if you have multiple subnets within 10/8 and rely on
your default route to route to them (though I don't think we currently
have any of these in the gate currently since rackspace sets more
specific routes for the subnets used for private networking there). This
would be the case if using a neutron setup with tenant networking and
floating IPs like we had with the old hpcloud.

> 
> Carl
> 
> [1] https://github.com/openstack-dev/devstack/blob/
> 6c55227595228bc37b91a1dbc665ec704cbf4c56/lib/neutron_
> plugins/services/l3#L376
> [2] https://review.openstack.org/#/c/356026/4/lib/neutron_
> plugins/services/l3
> 
> On Tue, Oct 11, 2016 at 5:32 PM, Armando M.  wrote:
> 
> >
> >
> > On 11 October 2016 at 14:09, Clark Boylan  wrote:
> >
> >> Hello everyone,
> >>
> >> Currently multinode testing + neutron is broken in clouds that use
> >> portions of 10.0.0.0/8 for their networking due to route conflicts with
> >> devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
> >> is tracking the issue for us. I would like to see this get resolved
> >> properly before we do further work on multinode testing as it is
> >> difficult to review and determine what failures are legit vs which
> >> failures are related to this bug and whether or not a specific multinode
> >> test has decided to workaround the issue.
> >>
> >> The change to use subnet pools in devstack is a non backward compatible
> >> change for devstack currently and it doesn't appear to have been
> >> documented in devstack at all. Would be great if we can finally fix this
> >> and get testing back to working and however we fix it ensure that
> >> devstack has the appropriate documentation.
> >>
> >
> > What is holding [1] back? Merging that would resolve the issue, then we
> > can drill down into why subnetpools interfere with the underlying
> > networking setup. I have asked Carl to look into broken build [2]
> >
> > [1] https://review.openstack.org/#/c/379543/
> > [2] http://logs.openstack.org/78/381278/2/check/gate-tempest-dsvm-neutron-
> > multinode-full-ubuntu-xenial/7f82862/console.html.gz
> >
> >
> >> Thank you,
> >> Clark


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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Carl Baldwin]

I found this [1] added here [2]. Since the provider is using 10.0.0.0/8 on
the public interface, and the subnet pool is also 10.0.0.0/8 the call to ip
route replace eliminates the route through the public interface.

Carl

[1] https://github.com/openstack-dev/devstack/blob/
6c55227595228bc37b91a1dbc665ec704cbf4c56/lib/neutron_
plugins/services/l3#L376
[2] https://review.openstack.org/#/c/356026/4/lib/neutron_
plugins/services/l3

On Tue, Oct 11, 2016 at 5:32 PM, Armando M.  wrote:

>
>
> On 11 October 2016 at 14:09, Clark Boylan  wrote:
>
>> Hello everyone,
>>
>> Currently multinode testing + neutron is broken in clouds that use
>> portions of 10.0.0.0/8 for their networking due to route conflicts with
>> devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
>> is tracking the issue for us. I would like to see this get resolved
>> properly before we do further work on multinode testing as it is
>> difficult to review and determine what failures are legit vs which
>> failures are related to this bug and whether or not a specific multinode
>> test has decided to workaround the issue.
>>
>> The change to use subnet pools in devstack is a non backward compatible
>> change for devstack currently and it doesn't appear to have been
>> documented in devstack at all. Would be great if we can finally fix this
>> and get testing back to working and however we fix it ensure that
>> devstack has the appropriate documentation.
>>
>
> What is holding [1] back? Merging that would resolve the issue, then we
> can drill down into why subnetpools interfere with the underlying
> networking setup. I have asked Carl to look into broken build [2]
>
> [1] https://review.openstack.org/#/c/379543/
> [2] http://logs.openstack.org/78/381278/2/check/gate-tempest-dsvm-neutron-
> multinode-full-ubuntu-xenial/7f82862/console.html.gz
>
>
>> Thank you,
>> Clark
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Clark Boylan]

On Tue, Oct 11, 2016, at 05:01 PM, Armando M. wrote:
> On 11 October 2016 at 16:54, Clark Boylan  wrote:
> 
> > On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> > > On 11 October 2016 at 16:43, Clark Boylan  wrote:
> > >
> > > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > > > On 11 October 2016 at 14:09, Clark Boylan 
> > wrote:
> > > > >
> > > > > > Hello everyone,
> > > > > >
> > > > > > Currently multinode testing + neutron is broken in clouds that use
> > > > > > portions of 10.0.0.0/8 for their networking due to route conflicts
> > > > with
> > > > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > > > s/1629133
> > > > > > is tracking the issue for us. I would like to see this get resolved
> > > > > > properly before we do further work on multinode testing as it is
> > > > > > difficult to review and determine what failures are legit vs which
> > > > > > failures are related to this bug and whether or not a specific
> > > > multinode
> > > > > > test has decided to workaround the issue.
> > > > > >
> > > > > > The change to use subnet pools in devstack is a non backward
> > compatible
> > > > > > change for devstack currently and it doesn't appear to have been
> > > > > > documented in devstack at all. Would be great if we can finally fix
> > > > this
> > > > > > and get testing back to working and however we fix it ensure that
> > > > > > devstack has the appropriate documentation.
> > > > > >
> > > > >
> > > > > What is holding [1] back? Merging that would resolve the issue, then
> > we
> > > > > can
> > > > > drill down into why subnetpools interfere with the underlying
> > networking
> > > > > setup. I have asked Carl to look into broken build [2]
> > > > >
> > > > > [1] https://review.openstack.org/#/c/379543/
> > > > > [2]
> > > > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > > > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> > > >
> > > > Yours is one of the two -1's on the change :) I think that devstack
> > core
> > > > is probably holding back due to the two -1s there. If we are ok with
> > > > iterating on making it better rather than all in one shot maybe that
> > > > change is good for now and we can update the reviews?
> > > >
> > >
> > > Well, that means the ball is in the contributor's court, who is supposed
> > > to
> > > address reviewers' concerns :)
> > >
> > The comments on the change with -1's are opposed to doing what the
> > change does. I don't know how I can possibly address them.
> >
> 
> Then say so on the review and I am happy to rephrase to make sure I get
> my
> message across correctly. If you let the review rot how can you expect it
> to make progress? That's like Openstack 101

It does say so clearly in the commit itself:

"It turns out that many people have already chosen fixed ranges that
work for their environments. They have done so to avoid conflicts with
existing networking ranges and routing. The change to use 10.0.0.0/8 and
apply routes for this network to neutron interfaces prevents anyone from
using networks within that range for anything else.

For example imagine you have a cloud provider that provides private IPv4
addresses allocated out of ranges in 10.0.0.0/8 and they do all public
networking over ipv6. This change to devstack prevents you from using
those private networks properly after starting neutron with devstack.
However, in situations like this FIXED_RANGE should already represent a
safe range to use so just use it."

The comments both refuse to allow FIXED_RANGE as the default and its the
only reason I pushed that patch. I personally believe this is the right
fix, if neutron/devstack disagree they should feel welcome to propose
alterantives, but I am not going to not use FIXED_RANGE when it was the
whole point of the change in the first place.

Clark

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Matt Riedemann]

On 10/11/2016 9:05 AM, Clint Byrum wrote:


Since there seems to be broad based resistance to time boxing anything
project specific, I'd like to propose a compromise: I'd like to ask that
teams allow people to add their IRC nick to the agenda items they'd like
to be included in, and at the beginning of a topic, courtesy pings go
out. No need to block the discussion on that person arriving or not,
but just give them a heads up that it is happening so they can join or
watch the notes.

__
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



This is basically what we already always did at the midcycles. A person 
has an agenda item with their nick. If we're going to talk about their 
thing and they aren't in the room, we ping them (or stick out head out 
in the hallway and tell them to get their arse in the room to talk). If 
they can't at that time, then we move on and come back when that person 
is available.


It's when we have people remote, or in other midcycles, that we need to 
schedule specific times to talk, but for people there in person it's not 
a problem, which it sounds like should be the case with the PTG.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Armando M.]

On 11 October 2016 at 16:54, Clark Boylan  wrote:

> On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> > On 11 October 2016 at 16:43, Clark Boylan  wrote:
> >
> > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > > On 11 October 2016 at 14:09, Clark Boylan 
> wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > Currently multinode testing + neutron is broken in clouds that use
> > > > > portions of 10.0.0.0/8 for their networking due to route conflicts
> > > with
> > > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > > s/1629133
> > > > > is tracking the issue for us. I would like to see this get resolved
> > > > > properly before we do further work on multinode testing as it is
> > > > > difficult to review and determine what failures are legit vs which
> > > > > failures are related to this bug and whether or not a specific
> > > multinode
> > > > > test has decided to workaround the issue.
> > > > >
> > > > > The change to use subnet pools in devstack is a non backward
> compatible
> > > > > change for devstack currently and it doesn't appear to have been
> > > > > documented in devstack at all. Would be great if we can finally fix
> > > this
> > > > > and get testing back to working and however we fix it ensure that
> > > > > devstack has the appropriate documentation.
> > > > >
> > > >
> > > > What is holding [1] back? Merging that would resolve the issue, then
> we
> > > > can
> > > > drill down into why subnetpools interfere with the underlying
> networking
> > > > setup. I have asked Carl to look into broken build [2]
> > > >
> > > > [1] https://review.openstack.org/#/c/379543/
> > > > [2]
> > > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> > >
> > > Yours is one of the two -1's on the change :) I think that devstack
> core
> > > is probably holding back due to the two -1s there. If we are ok with
> > > iterating on making it better rather than all in one shot maybe that
> > > change is good for now and we can update the reviews?
> > >
> >
> > Well, that means the ball is in the contributor's court, who is supposed
> > to
> > address reviewers' concerns :)
> >
> The comments on the change with -1's are opposed to doing what the
> change does. I don't know how I can possibly address them.
>

Then say so on the review and I am happy to rephrase to make sure I get my
message across correctly. If you let the review rot how can you expect it
to make progress? That's like Openstack 101


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

Re: [openstack-dev] [tripleo] website update

[Dan Prince]

On Tue, 2016-10-11 at 18:08 -0500, Ben Nemec wrote:
> 
> On 10/11/2016 02:42 PM, Dan Prince wrote:
> > 
> > A quick update on the tripleo.org website outage today. We are in
> > the
> > process of moving the server to a new host location. Until DNS
> > updates
> > please use the following URL if you want to access the CI status
> > report:
> > 
> > http://66.187.229.219/cistatus.html
> 
> This doesn't seem to be updating for me.  I'm pretty sure I've been 
> seeing the same patches listed there pretty much all day.  Was this 
> maybe driven by a cron job that we're missing on the new server?

Thanks for pointing this out Ben. The script was in place to re-run it
but I had a pushd without a popd. I've always had mixed feelings about
pushd/popd rather preferring to just directly 'cd' to the directory
explicitly. Anyway, it is all fixed up now so I think automatic updates
should be back now.

Dan

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

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

gordon chung wrote:


On 11/10/16 05:38 PM, Joshua Harlow wrote:

Yes yes, normalization would be nice to, though a little beyond what I
am (or was) thinking of currently. Going back to how
event_definitions.yaml is the best 'source' we have currently, is it
possible to rip out (for now) event_definitions.yaml  and I assume the
python code-gen part from ceilometer into a new library (and/or repo);
at least this would be a small step forward (I think).



i don't have a problem with it but i'll be honest, the definition file
and yaml->python object code is tailored to an extent to "normalise
notification into Ceilometer data models" use case.


Right, I'm assuming this is primarily what's in:

https://github.com/openstack/ceilometer/blob/master/ceilometer/event/

That and the event_definitions.yaml seems like they could just be in a 
new location (not sure what to call that location, someone else can pick 
a cool name, ha).





Perhaps this may have already been planned to?


we did plan on making Ceilometer notification agent more generic where
it's essentially just a notification listener and you can enable
different plugins to convert to meters or events where as right now they
are both pretty much baked in and always on. maybe this generalisation
can be tied into what you are tryin to do.




Right this is one option, though it still ties people into ceilometer 
for events, which feels odd, vs just being a generic tool/library/tiny 
entrypoint that could be provided without needing ceilometer (that 
ceilometer could itself also use).


-Josh

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Clark Boylan]

On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> On 11 October 2016 at 16:43, Clark Boylan  wrote:
> 
> > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > On 11 October 2016 at 14:09, Clark Boylan  wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > Currently multinode testing + neutron is broken in clouds that use
> > > > portions of 10.0.0.0/8 for their networking due to route conflicts
> > with
> > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > s/1629133
> > > > is tracking the issue for us. I would like to see this get resolved
> > > > properly before we do further work on multinode testing as it is
> > > > difficult to review and determine what failures are legit vs which
> > > > failures are related to this bug and whether or not a specific
> > multinode
> > > > test has decided to workaround the issue.
> > > >
> > > > The change to use subnet pools in devstack is a non backward compatible
> > > > change for devstack currently and it doesn't appear to have been
> > > > documented in devstack at all. Would be great if we can finally fix
> > this
> > > > and get testing back to working and however we fix it ensure that
> > > > devstack has the appropriate documentation.
> > > >
> > >
> > > What is holding [1] back? Merging that would resolve the issue, then we
> > > can
> > > drill down into why subnetpools interfere with the underlying networking
> > > setup. I have asked Carl to look into broken build [2]
> > >
> > > [1] https://review.openstack.org/#/c/379543/
> > > [2]
> > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> >
> > Yours is one of the two -1's on the change :) I think that devstack core
> > is probably holding back due to the two -1s there. If we are ok with
> > iterating on making it better rather than all in one shot maybe that
> > change is good for now and we can update the reviews?
> >
> 
> Well, that means the ball is in the contributor's court, who is supposed
> to
> address reviewers' concerns :)
> 
The comments on the change with -1's are opposed to doing what the
change does. I don't know how I can possibly address them.

Clark

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Armando M.]

On 11 October 2016 at 16:43, Clark Boylan  wrote:

> On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > On 11 October 2016 at 14:09, Clark Boylan  wrote:
> >
> > > Hello everyone,
> > >
> > > Currently multinode testing + neutron is broken in clouds that use
> > > portions of 10.0.0.0/8 for their networking due to route conflicts
> with
> > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> s/1629133
> > > is tracking the issue for us. I would like to see this get resolved
> > > properly before we do further work on multinode testing as it is
> > > difficult to review and determine what failures are legit vs which
> > > failures are related to this bug and whether or not a specific
> multinode
> > > test has decided to workaround the issue.
> > >
> > > The change to use subnet pools in devstack is a non backward compatible
> > > change for devstack currently and it doesn't appear to have been
> > > documented in devstack at all. Would be great if we can finally fix
> this
> > > and get testing back to working and however we fix it ensure that
> > > devstack has the appropriate documentation.
> > >
> >
> > What is holding [1] back? Merging that would resolve the issue, then we
> > can
> > drill down into why subnetpools interfere with the underlying networking
> > setup. I have asked Carl to look into broken build [2]
> >
> > [1] https://review.openstack.org/#/c/379543/
> > [2]
> > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
>
> Yours is one of the two -1's on the change :) I think that devstack core
> is probably holding back due to the two -1s there. If we are ok with
> iterating on making it better rather than all in one shot maybe that
> change is good for now and we can update the reviews?
>

Well, that means the ball is in the contributor's court, who is supposed to
address reviewers' concerns :)


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

[openstack-dev] [nova][vmware][ci] The VMware NSX CI has been removed from the nova-ci group

[Matt Riedemann]

I've dropped the vmware CI from the nova-ci group in Gerrit. The CI is 
failing all over everything today and -1ing changes, e.g.:


http://208.91.1.172/logs/ext-nova-dsvm/385202/1/439/

So until it's fixed it's now non-voting.

--

Thanks,

Matt Riedemann


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

[openstack-dev] [tripleo] Scaling-up the team with Squads

[Emilien Macchi]

It has been some weeks I have been thinking how TripleO project could
scale-up the way we work together.
Over the cycles, we have more contributors, more projects, I think
it's time to revisit our organization.

Here's the proposal: https://review.openstack.org/385201

Feel free to review it prior the Summit, so we can have a productive
"Growing the team" session in Barcelona.

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] requests-mock

[Clay Gerrard]

On Tue, Oct 11, 2016 at 4:24 PM, Jamie Lennox  wrote:

>
> So I'm not going to comment too much on the quality of the library as i
> obviously think it's good
>

acahcpahch, no worries.

Your insights are invaluable - thanks for taking the time to connect some
dots for me - i'm starting to get up to speed.

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Clark Boylan]

On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> On 11 October 2016 at 14:09, Clark Boylan  wrote:
> 
> > Hello everyone,
> >
> > Currently multinode testing + neutron is broken in clouds that use
> > portions of 10.0.0.0/8 for their networking due to route conflicts with
> > devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
> > is tracking the issue for us. I would like to see this get resolved
> > properly before we do further work on multinode testing as it is
> > difficult to review and determine what failures are legit vs which
> > failures are related to this bug and whether or not a specific multinode
> > test has decided to workaround the issue.
> >
> > The change to use subnet pools in devstack is a non backward compatible
> > change for devstack currently and it doesn't appear to have been
> > documented in devstack at all. Would be great if we can finally fix this
> > and get testing back to working and however we fix it ensure that
> > devstack has the appropriate documentation.
> >
> 
> What is holding [1] back? Merging that would resolve the issue, then we
> can
> drill down into why subnetpools interfere with the underlying networking
> setup. I have asked Carl to look into broken build [2]
> 
> [1] https://review.openstack.org/#/c/379543/
> [2]
> http://logs.openstack.org/78/381278/2/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz

Yours is one of the two -1's on the change :) I think that devstack core
is probably holding back due to the two -1s there. If we are ok with
iterating on making it better rather than all in one shot maybe that
change is good for now and we can update the reviews?

Clark

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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Armando M.]

On 11 October 2016 at 14:09, Clark Boylan  wrote:

> Hello everyone,
>
> Currently multinode testing + neutron is broken in clouds that use
> portions of 10.0.0.0/8 for their networking due to route conflicts with
> devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
> is tracking the issue for us. I would like to see this get resolved
> properly before we do further work on multinode testing as it is
> difficult to review and determine what failures are legit vs which
> failures are related to this bug and whether or not a specific multinode
> test has decided to workaround the issue.
>
> The change to use subnet pools in devstack is a non backward compatible
> change for devstack currently and it doesn't appear to have been
> documented in devstack at all. Would be great if we can finally fix this
> and get testing back to working and however we fix it ensure that
> devstack has the appropriate documentation.
>

What is holding [1] back? Merging that would resolve the issue, then we can
drill down into why subnetpools interfere with the underlying networking
setup. I have asked Carl to look into broken build [2]

[1] https://review.openstack.org/#/c/379543/
[2]
http://logs.openstack.org/78/381278/2/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz


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

Re: [openstack-dev] requests-mock

[Jamie Lennox]

On 11 October 2016 at 16:23, Clay Gerrard  wrote:

> Greetings!
>
> Anyone have any experience to share positive or negative using
> requests-mock?  I see it's been used to replace another dependency that had
> some problems in many of the OpenStack python client libraries:
>
> Added to global requirements -> https://review.openstack.org/#/c/104067
> Added to novaclient -> https://review.openstack.org/#/c/112179/
> Added to cinderclient -> https://review.openstack.org/#/c/106665/
> Added to keystoneclient -> https://review.openstack.org/#/c/106659/
>
> But I'm not sure how folks other than Jamie are getting on with it?  When
> writing new tests do you tend to instinctively grab for requests-mock - or
> do you mostly not notice it's there?  Any unexpected behaviors ever have
> you checking it out with bzr and reading over the source?  Do you recall
> ever having any bumps or bruises in the gate or in your development
> workflow because of a new release from requests-mock?  No presumed fault on
> Jamie!  It seems like he's doing a Herculean one-man job there; but it can
> be difficult go it alone:
>
> https://bugs.launchpad.net/requests-mock/+bug/1616690
>
> It looks like the gate on this project is configured to run nova &
> keystone client tests; so that may be sufficient to catch any sort of issue
> that might come up in something that depends on it?  Presumably once he
> lands a change - he does the update to global-requirements and then all of
> OpenStack get's it from there?
>
> I ask of course because I really don't understand how this works [1] :D
>
> But anyway - Jamie was kind enough to offer to refactor some tests for us
> - but in the process seems to require to bring in these new dependencies -
> so I'm trying to evaluate if I can recommend requiring this code in order
> to develop on swiftclient [2].
>
> Any feedback is greatly appreciated!
>
> -Clay
>
> 1. As you may know (thanks to some recently publicity) swift & swiftclient
> joined OpenStack in the time of dinosaurs with a general policy of trying
> to keep dependencies to a *minimum* - but then one day the policy changed
> to... *always* add dependencies whenever possible?  j/k I'm not acctually
> sure what the OpenStack policy is on dependency hygiene :D  Anyway, I can't
> say *exactly* where that "general policy" came from originally?  Presumably
> crieht or gholt just had some first hand experience that the dependencies
> you choose to add have a HUGE impact on your project over it's lifetime -
> or read something from Joel on Software - http://www.joelonsoftware.com/
> articles/fog07.html - or traveled into the future and read the
> "go proverbs" and google'd "npm breaks internet, again".  Of course they've
> since moved on from OpenStack but the general idea is still something that
> new contributors to swift & swiftclient get acclimated to and the circle of
> confusion continues https://github.com/openstack/swift/blob/master/
> CONTRIBUTING.rst#swift-design-principles - but hey!  maybe I can educate
> myself about the OpenStack policy/process; add this dependency and maybe
> the next one too; then someday break the cycle!?!?
>
> 2. https://review.openstack.org/#/c/360298
>
>
> __
> 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
>
>
Clay,

So I'm not going to comment too much on the quality of the library as i
obviously think it's good (and AFAIK we've never broken an API).

The only thing I'd like to clarify is that I'm never coming to clients with
the intent of converting tests to use requests-mock to promote the library.
I'm probably the main person behind most of the keystoneauth work and one
of the biggest problems I've had with trying to convert projects to work
with keystoneauth (and keystoneclient before that) is that mocking out the
request.request function, or the whole keystoneclient Client as swiftclient
does has made the unit tests very strictly locked to the current way things
are done. By converting the clients to a request level mock I've been able
to change the way the clients authenticate whilst proving there are no
change in the requests made.

The same is true of swiftclient, though it's a longer and slower process
there as i've discussed with people in the past - and would like to try
again at summit. Patches [1][2] exists to bring some support of
keystoneauth to swiftclient (which would make the hacking i'm currently
trying to do on glance_store much easier), but ideally i would like to go
further because there is existing and proven support for things like
reauthenticating a token on 401 via keystoneauth rather than the current,
somewhat hacky method, that would greatly simplify the interaction between
the openstack services and swift.

Swiftclient is 

[openstack-dev] Barcelona Summit -- Monday -- openings in command-presence-workshop

[Bhandaru, Malini K]

Hello Everyone!

We have a few slots still available on Monday's Command Presence workshop and 
are opening out to a broader audience. Please register if interested. Past 
attendees, despite their many skills and experience, vouched that they had 
learned a trick or two.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16888/command-presence-workshop

Regards,
Malini

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

Re: [openstack-dev] [tripleo] website update

[Ben Nemec]

On 10/11/2016 02:42 PM, Dan Prince wrote:

A quick update on the tripleo.org website outage today. We are in the
process of moving the server to a new host location. Until DNS updates
please use the following URL if you want to access the CI status
report:

http://66.187.229.219/cistatus.html


This doesn't seem to be updating for me.  I'm pretty sure I've been 
seeing the same patches listed there pretty much all day.  Was this 
maybe driven by a cron job that we're missing on the new server?


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

Re: [openstack-dev] [OpenStack-docs] [ironic] Admin guide in-tree?

[Lana Brindley]

Hi Jay,

I think that's a perfectly reasonable solution for the moment, and hopefully 
we'll have the new solution up and running as soon as possible.

Please let us know if there's anything you could use a hand with.

Lana

On 12/10/16 09:00, Jay Faulkner wrote:
> We are eager to improve our documentation, but I think quite a few of us who 
> work on Ironic documentation have a strong preference to keeping those 
> documents in-tree. This allows us to enforce contributors having 
> documentation changes or additions merge at the same time or in close 
> proximity to the code changes and is much easier for us to interact with. I 
> have the willingness to help implement admin guides in-tree sooner, but if 
> the docs team doesn't want this yet obviously there's nothing to help with.
> 
> As for what to do today today; I agree with Ruby on this entirely. I'm adding 
> an item to Monday's Ironic meeting agenda to reach consensus on what our 
> project will do in the meantime. My recommendation will be option B as listed 
> by Ruby; build out a better admin-guide in tree as part of our developer 
> docs, and migrate them over, just like we did for the install guide, when the 
> work to allow in-tree admin guides is complete.
> 
> Thanks,
> Jay Faulkner
> 
>> On Oct 11, 2016, at 9:38 AM, Ruby Loo > > wrote:
>>
>> From my point of view, the rush is so that we can be more efficient with all 
>> of our time/efforts. In ironic, we have a bit of a mess. We now have 
>> duplicated (and perhaps out-of-sync) admin-related information in our 
>> developer docs [1] as well as in the official admin guide [2] -- the latter 
>> content was added but I am unaware of that knowledge/coordination being done 
>> with the ironic community :-(
>>
>> Should we :
>> A. move our admin-related information from our developer docs to the 
>> existing admin guide; then move the admin guide to the new in-tree solution 
>> later
>>
>> B. replace what is in the existing admin guide with a pointer to the 
>> developer docs; then move the admin content to the new in-tree solution later
>>
>> C. status quo until the new in-tree solution is available
>>
>> --ruby
>>
>> [1] http://docs.openstack.org/developer/ironic/
>> [2] http://docs.openstack.org/admin-guide/baremetal.html
>>
>>
>> On Mon, Oct 10, 2016 at 7:07 PM, Lana Brindley > > wrote:
>>
>> On 10/10/16 16:25, Andreas Jaeger wrote:
>> > On 2016-10-10 01:37, Steve Martinelli wrote:
>> >> On Oct 9, 2016 6:57 PM, "Lana Brindley" > 
>> >> > >> wrote:
>> >>>
>> >>> Why the rush?
>> >>
>> >> I think its more eagerness than rush. Project teams made a lot of head
>> >> way with the API ref and install guides being in-tree that they want 
>> to
>> >> keep the momentum with the admin guide.
>> >
>> > Those teams are more than welcome to contribute today to the
>> > openstack-manuals repository! Is there anything we can help these?
>> >
>> > Andreas
>> >
>>
>> Yes, Andreas makes a good point. If there's content you want in the 
>> guides now, we can help you with that.
>>
>> Lana
>>
>> --
>> Lana Brindley
>> Technical Writer
>> Rackspace Cloud Builders Australia
>> http://lanabrindley.com 
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack 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
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [OpenStack-docs] [ironic] Admin guide in-tree?

[Jay Faulkner]

We are eager to improve our documentation, but I think quite a few of us who 
work on Ironic documentation have a strong preference to keeping those 
documents in-tree. This allows us to enforce contributors having documentation 
changes or additions merge at the same time or in close proximity to the code 
changes and is much easier for us to interact with. I have the willingness to 
help implement admin guides in-tree sooner, but if the docs team doesn't want 
this yet obviously there's nothing to help with.

As for what to do today today; I agree with Ruby on this entirely. I'm adding 
an item to Monday's Ironic meeting agenda to reach consensus on what our 
project will do in the meantime. My recommendation will be option B as listed 
by Ruby; build out a better admin-guide in tree as part of our developer docs, 
and migrate them over, just like we did for the install guide, when the work to 
allow in-tree admin guides is complete.

Thanks,
Jay Faulkner

On Oct 11, 2016, at 9:38 AM, Ruby Loo 
> wrote:

>From my point of view, the rush is so that we can be more efficient with all 
>of our time/efforts. In ironic, we have a bit of a mess. We now have 
>duplicated (and perhaps out-of-sync) admin-related information in our 
>developer docs [1] as well as in the official admin guide [2] -- the latter 
>content was added but I am unaware of that knowledge/coordination being done 
>with the ironic community :-(

Should we :
A. move our admin-related information from our developer docs to the existing 
admin guide; then move the admin guide to the new in-tree solution later

B. replace what is in the existing admin guide with a pointer to the developer 
docs; then move the admin content to the new in-tree solution later

C. status quo until the new in-tree solution is available

--ruby

[1] http://docs.openstack.org/developer/ironic/
[2] http://docs.openstack.org/admin-guide/baremetal.html


On Mon, Oct 10, 2016 at 7:07 PM, Lana Brindley 
> wrote:
On 10/10/16 16:25, Andreas Jaeger wrote:
> On 2016-10-10 01:37, Steve Martinelli wrote:
>> On Oct 9, 2016 6:57 PM, "Lana Brindley" 
>> 
>> >> 
>> wrote:
>>>
>>> Why the rush?
>>
>> I think its more eagerness than rush. Project teams made a lot of head
>> way with the API ref and install guides being in-tree that they want to
>> keep the momentum with the admin guide.
>
> Those teams are more than welcome to contribute today to the
> openstack-manuals repository! Is there anything we can help these?
>
> Andreas
>

Yes, Andreas makes a good point. If there's content you want in the guides now, 
we can help you with that.

Lana

--
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com


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


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

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[gordon chung]

On 11/10/16 05:38 PM, Joshua Harlow wrote:
> Yes yes, normalization would be nice to, though a little beyond what I
> am (or was) thinking of currently. Going back to how
> event_definitions.yaml is the best 'source' we have currently, is it
> possible to rip out (for now) event_definitions.yaml  and I assume the
> python code-gen part from ceilometer into a new library (and/or repo);
> at least this would be a small step forward (I think).
>

i don't have a problem with it but i'll be honest, the definition file 
and yaml->python object code is tailored to an extent to "normalise 
notification into Ceilometer data models" use case.

> Perhaps this may have already been planned to?

we did plan on making Ceilometer notification agent more generic where 
it's essentially just a notification listener and you can enable 
different plugins to convert to meters or events where as right now they 
are both pretty much baked in and always on. maybe this generalisation 
can be tied into what you are tryin to do.


-- 
gord

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

Re: [openstack-dev] requests-mock

[Clay Gerrard]

On Tue, Oct 11, 2016 at 10:44 AM, Clay Gerrard 
wrote:

>  I'm not really sure what a fixture is this context?
>

Answered my own question in this case!

http://requests-mock.readthedocs.io/en/latest/fixture.html

It's one of *these* of course:

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

gordon chung wrote:


On 11/10/16 04:18 PM, Joshua Harlow wrote:

To be productive here, would there be any problem if I (or someone I
know) just split that yaml off into a new git repository, and started
iterating on figuring out how to turn the yaml into something that can
generate code for [python, java, go(?)] and then say ceilometer can use
the python parts/objects (and then others can use the java stuff and
so-on and so forth). If at some point we can get that same schema (and
leave the generators somewhere else) into the various projects that
publish the notifications; that'd be super to...


i should add that i have no idea how accurate those definitions are. i
can only guarantee that at some point in time they were correct which
sort of goes back to why i don't think we (consumers) should be handling it.

i should also add, in addition to event definitions, we have meter
definitions[1] which essentially does same thing but just pulls out
measurement data. so maybe what you're trying to achieve is a stage
before what Ceilometer is trying to achieve aka normalisation.

from Ceilometer POV, we use these yaml files and convert them into
definition python objects[2]. i don't know if this use case can be
covered by your proposal or if it's something you want to target.


[1]
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml
[2]
https://github.com/openstack/ceilometer/blob/master/ceilometer/declarative.py#L149

cheers,


Yes yes, normalization would be nice to, though a little beyond what I 
am (or was) thinking of currently. Going back to how 
event_definitions.yaml is the best 'source' we have currently, is it 
possible to rip out (for now) event_definitions.yaml  and I assume the 
python code-gen part from ceilometer into a new library (and/or repo); 
at least this would be a small step forward (I think).


Perhaps this may have already been planned to?

Assuming that at some point nova has its notifications in object format 
(which allows for getting a json schema) then nova could make that 
schema set fetchable (and the other projects do the same thing) then we 
could see where that ship goes and adjust this new repo to accommodate that.


-JOsh

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

Re: [openstack-dev] [keystone][horizon] keystone/horizon integration session in barcelona

[Richard Jones]

Thanks, Steve, this will be a valuable session!

On 12 October 2016 at 08:14, Steve Martinelli 
wrote:

> The keystone team had a spare fishbowl session, and we decided to use it
> to collaborate with the horizon team on a few long standing issues we've
> had between the two projects.
>
> You can view the session online:
> https://www.openstack.org/summit/barcelona-2016/summit-
> schedule/events/16907
>
> Details here:
> Wed 26, 3:55pm-4:35pm
> Keystone: Keystone/Horizon integration session (Fishbowl)
> https://etherpad.openstack.org/p/ocata-keystone-horizon
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][horizon] keystone/horizon integration session in barcelona

[Steve Martinelli]

The keystone team had a spare fishbowl session, and we decided to use it to
collaborate with the horizon team on a few long standing issues we've had
between the two projects.

You can view the session online:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16907

Details here:
Wed 26, 3:55pm-4:35pm
Keystone: Keystone/Horizon integration session (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-horizon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[gordon chung]

On 11/10/16 04:18 PM, Joshua Harlow wrote:
>
> To be productive here, would there be any problem if I (or someone I
> know) just split that yaml off into a new git repository, and started
> iterating on figuring out how to turn the yaml into something that can
> generate code for [python, java, go(?)] and then say ceilometer can use
> the python parts/objects (and then others can use the java stuff and
> so-on and so forth). If at some point we can get that same schema (and
> leave the generators somewhere else) into the various projects that
> publish the notifications; that'd be super to...

i should add that i have no idea how accurate those definitions are. i 
can only guarantee that at some point in time they were correct which 
sort of goes back to why i don't think we (consumers) should be handling it.

i should also add, in addition to event definitions, we have meter 
definitions[1] which essentially does same thing but just pulls out 
measurement data. so maybe what you're trying to achieve is a stage 
before what Ceilometer is trying to achieve aka normalisation.

from Ceilometer POV, we use these yaml files and convert them into 
definition python objects[2]. i don't know if this use case can be 
covered by your proposal or if it's something you want to target.


[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/declarative.py#L149

cheers,
-- 
gord

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

[openstack-dev] Multinode testing with devstack and neutron broken

[Clark Boylan]

Hello everyone,

Currently multinode testing + neutron is broken in clouds that use
portions of 10.0.0.0/8 for their networking due to route conflicts with
devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
is tracking the issue for us. I would like to see this get resolved
properly before we do further work on multinode testing as it is
difficult to review and determine what failures are legit vs which
failures are related to this bug and whether or not a specific multinode
test has decided to workaround the issue.

The change to use subnet pools in devstack is a non backward compatible
change for devstack currently and it doesn't appear to have been
documented in devstack at all. Would be great if we can finally fix this
and get testing back to working and however we fix it ensure that
devstack has the appropriate documentation.

Thank you,
Clark

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

Chris Dent wrote:

On Tue, 11 Oct 2016, Joshua Harlow wrote:


Damn, that's crazy that the projects emitting events don't want to own
the formats and versions (and schemas) that they emit. That is ummm,
like ummm, what the, ha, words can't describe... And the fact that
nothing much has changed since kilo, ya, also a what the...


Nova started with versioning and schematizing notifications with
this blueprint:

https://blueprints.launchpad.net/nova/+spec/versioned-notification-api

That's sort of in the realm of what's being discussed here, but
centralized in nova for now.

I agree that siloing the stuff in the code is bad in the long term,
but I guess it is good that it has started somewhere.



Thanks for sharing, didn't recall that work being done.

From glancing at it, it seems to be nova versioning its notifications 
(which is good) but I'm unclear what the objectification of those 
notifications means to the outside world (the actual consumers of 
notifications). Said outside world uses more than just python so it 
feels like some other intermediary format should be exposed to consumers 
as the schema that various python and non-python languages can consume 
(either via auto-generation of code or other).


Perhaps just jsonschema is enough (though it doesn't feel like it)? Has 
anyone tried 'to_json_schema' on those objects and outputting that 
schema into a nova/schema/notifications folder (or equivalent)?


-Josh

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[Chris Dent]

On Tue, 11 Oct 2016, Joshua Harlow wrote:

Damn, that's crazy that the projects emitting events don't want to own the 
formats and versions (and schemas) that they emit. That is ummm, like ummm, 
what the, ha, words can't describe... And the fact that nothing much has 
changed since kilo, ya, also a what the...


Nova started with versioning and schematizing notifications with
this blueprint:

   https://blueprints.launchpad.net/nova/+spec/versioned-notification-api

That's sort of in the realm of what's being discussed here, but
centralized in nova for now.

I agree that siloing the stuff in the code is bad in the long term,
but I guess it is good that it has started somewhere.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

gordon chung wrote:


On 11/10/16 01:14 PM, Joshua Harlow wrote:

Ah, right, nearly forgot about that yaml. Thanks gordon!

Has there been any ideas from folks to split those
'event_definitions.yaml' into something else (a notifications schema
repo?)? I'd be up for helping do that (nice to have would be an included
ability/code-gen(?) to turn those schemas into code for various
languages [starting with the typical ones, python, go(?), java,...]).


a few years back there was discussion to house them in a completely
separate service but no work was really done on that beyond the initial
discussion[1]

from Ceilometer pov, i wanted the projects to own their own definitions
but others said it was not their job[2]. having the projects own their
own schema/definitions allowed everything to be decoupled but i don't
think we figured out how to make it discoverable without having to
import the entire package.


Then we could also hold the emitting projects accountable for there
events being emitted (and the formats and versions they emit), because
overall I'd like to get away from 'the payload format OpenStack services
emit could be described as the Wild West' (found on that events.html
site, lol).



i'd like this to but it doesn't seem like we can figure out who's
responsibility it is to own format.

[1] https://etherpad.openstack.org/p/kilo-crossproject-notifications
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080063.html

cheers,



Damn, that's crazy that the projects emitting events don't want to own 
the formats and versions (and schemas) that they emit. That is ummm, 
like ummm, what the, ha, words can't describe... And the fact that 
nothing much has changed since kilo, ya, also a what the...


To be productive here, would there be any problem if I (or someone I 
know) just split that yaml off into a new git repository, and started 
iterating on figuring out how to turn the yaml into something that can 
generate code for [python, java, go(?)] and then say ceilometer can use 
the python parts/objects (and then others can use the java stuff and 
so-on and so forth). If at some point we can get that same schema (and 
leave the generators somewhere else) into the various projects that 
publish the notifications; that'd be super to...


Thoughts?

-Josh

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

Re: [openstack-dev] [Tacker] Presence at PTG Atlanta

[Sripriya Seetharam]

Hi,

Based on team’s decision in tacker weekly meeting [1], Tacker team has decided 
to have a virtual developer meetup and not have PTG presence in Atlanta. Given, 
most of our contributors are geographically spread out, it was decided that the 
virtual midcycle format would be more appropriate in getting the maximum number 
of contributors together to conduct the design meetup.

Thanks,
Sripriya

[1] 
http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-10-11-16.00.html


From: Sripriya Seetharam 
Date: Monday, October 10, 2016 at 12:05 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev][Tacker] Presence at PTG Atlanta

Hi Tackers,

As you all know, the first PTG meetup (Pike cycle) is happening at Atlanta, Feb 
20-24, 2017. This is as per the new format starting after Barcelona conference, 
where design summit happens in between two OpenStack conferences. Please read 
[1] for more details. I believe our traditional virtual mid cycle meetups have 
been effective for project scoping and discussions and we could have something 
similar for design summit. We can discuss in the upcoming Tacker weekly meeting 
and also in mailing list to provide our decision.

Thanks,
Sripriya

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

[openstack-dev] [tripleo] website update

[Dan Prince]

A quick update on the tripleo.org website outage today. We are in the
process of moving the server to a new host location. Until DNS updates
please use the following URL if you want to access the CI status
report:

http://66.187.229.219/cistatus.html

Dan

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[gordon chung]

On 11/10/16 01:14 PM, Joshua Harlow wrote:
>
> Ah, right, nearly forgot about that yaml. Thanks gordon!
>
> Has there been any ideas from folks to split those
> 'event_definitions.yaml' into something else (a notifications schema
> repo?)? I'd be up for helping do that (nice to have would be an included
> ability/code-gen(?) to turn those schemas into code for various
> languages [starting with the typical ones, python, go(?), java,  your own>...]).

a few years back there was discussion to house them in a completely 
separate service but no work was really done on that beyond the initial 
discussion[1]

from Ceilometer pov, i wanted the projects to own their own definitions 
but others said it was not their job[2]. having the projects own their 
own schema/definitions allowed everything to be decoupled but i don't 
think we figured out how to make it discoverable without having to 
import the entire package.

>
> Then we could also hold the emitting projects accountable for there
> events being emitted (and the formats and versions they emit), because
> overall I'd like to get away from 'the payload format OpenStack services
> emit could be described as the Wild West' (found on that events.html
> site, lol).
>

i'd like this to but it doesn't seem like we can figure out who's 
responsibility it is to own format.

[1] https://etherpad.openstack.org/p/kilo-crossproject-notifications
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080063.html

cheers,
-- 
gord

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

Re: [openstack-dev] [all][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Sean McGinnis]

On Tue, Oct 11, 2016 at 08:34:12AM +1100, Tony Breeds wrote:
> On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:
> 
> > I think it would also make sense to *release* on the boundary of the switch;
> > so that it’s clear which phase a release followed.
> 
> I agree, I don't really have a mechanism for do that though.  I didn't state
> this but my plan was to reach out the PTLs that have the stable:follows-policy
> tag and ask them to release.  I suppose I could go one step further and
> propose the change in openstack/releases but that seems a little like over
> reach to me.
> 
> What do PTLs / stable CPLs think?

That makes sense to me. I tried to do that for the last go around as a
final official release for the stable branch.

> 
> BTW: I see you've done this for neutron :)   Thanks!
> 
> Yours Tony.



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


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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Adam Lawson]

My personal opinion, speaking as a non-candidate, is that it's very likely
true name recognition plays a role. In fact if I was to vote I would do so
and probably vote for Monty or Doug cause I like how they operate and I'm
familiar with them. And if I don't like someone, I won't vote for them.
Selection decisions are influenced by human nature and as such we might
want to at least consider whether name recognition is important or not
versus the actual positions candidates hold or the experience they bring to
the table.

I heard (can't recall who it was) someone say they like names being
attached to positions because they lean towards voting for people who
they've seen or know can get the work done. Interestingly, work as a PTL is
*much* different than the work as a TC member. One question I've often
asked myself is about the role of the TC itself is what *should* these
dudes and dudettes be focusing on? If it's governance, getting out code is
miles apart from working through and making evangelizing decisions.
Experience and approach should, I feel, take utmost precedence over
community popularity. it should if we want a stronger TC anyway.

Strangely, I'll bet some of the top names voted in would continue to be
voted in without a name being attached because they are good at what they
do and don't need to rely on name recognition to draw votes.

I support the blind voting idea personally. Just my two cents.

//adam




*Adam Lawson*

Principal Architect, CEO
Office: +1-916-794-5706

On Tue, Oct 11, 2016 at 11:45 AM, Anita Kuno  wrote:

> On 2016-10-11 02:35 PM, Thiago da Silva wrote:
>
>>
>>
>> On 10/11/2016 01:21 PM, Anita Kuno wrote:
>>
>>> On 2016-10-11 12:57 PM, Thiago da Silva wrote:
>>>


 On 10/11/2016 12:00 PM, Ed Leafe wrote:

> On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:
>
> Just in case folks care, now is the best time to discuss our election
>> process and suggest options or changes for the next round of elections. 
>> I'm
>> not adverse to discussing it I just think the best time for doing so is
>> from the time the last election is over up to milestone one. Then we have
>> lots of time for ideas and debate and any suggestions, if accepted, have
>> time to be implemented and communicated so the process is fair for all,
>> candidates and electorate.
>>
> Agreed.
>
> During the election is a wonderful time for posing questions to
>> candidates in order to clarify their position or stance such that the
>> electorate can make an informed choice.
>>
> To me, that’s the crux: “during the election”. When exactly should
> that be? Candidates can (and do) declare up to the very last minute of the
> nomination window, and ballots go out immediately after that, and voting
> starts. There really needs to be a period when a) we know who all the
> candidates are, and b) voting has not yet begun. I would like to see that
> period be created so that the kind of question/answer/clarify process you
> mention can happen.
>
 +1
 Just to add on to that, it would also be nice to have a better place
 for the questions/answers to be stored.

>>>
>>> Have you a suggestion for where you would like to see them?
>>>
>>> Also regardless of what is formally set up, anyone can ask questions via
>>> the mailing list, that option has been used every election that I have
>>> witnessed, I don't see that changing. I don't think it is reasonable to ask
>>> officials to curate mailing list posts. I think what we are discussing is
>>> something in addition to mailing list discussions. I don't think anything
>>> ever would (or should) replace what comes up on the mailing list.
>>>
>> Anita,
>>
>> Agree that the mailing list is irreplaceable, a lot of of the discussion
>> would continue to happen here. I also don't think asking anyone to curate
>> the answers is scalable.
>>
>
> Great, we agree.
>
>
>> A *suggestion* would be to come up with a set of questions prior to
>> nomination so that candidates could answer in their self-nomination. Of
>> course, how we would come up with those questions is then another issue.
>> Maybe the questions could even be proposed to the election repo[0],
>> starting with an initial set of questions that are then added on by others
>> in the community ??? I'm trying to come up with a way to repeat what you
>> provided in the '14 election without the burden...
>>
>> Thiago
>>
>> [0] - https://github.com/openstack/election/tree/master/candidates
>> /ocata/TC
>>
>
> I think the format would be up to whomever administrates it since they
> would have to do the work, accept the stress and pressure and be answerable
> to the community for the choices they make. That is what worked best for me.
>
> Thanks Thiago,
> Anita.
>
>
>
>>> Thanks,
>>> Anita.
>>>
>>> During last week there was a ton of great discussion, but when it came

Re: [openstack-dev] [Trove] trove core team

[Mariam John]

Thank you Craig for your leadership and hard work in helping shape and
guide the Trove community. Wish you good luck and success in everything you
do.

Regards,
Mariam.




From:   Craig Vyvial 
To: OpenStack Development Mailing List

Date:   10/07/2016 10:25 PM
Subject:[openstack-dev] [Trove] trove core team



Whats up yall.

So I've changed my focus over the last couple months to working on some new
technology and do not have time to fulfill my duties as Trove Core any
longer. I think its time to move on and step down from trove core.

I have been around for a while and seen the Trove community grow and seen
great strides of development within Trove. I look forward to seeing the
future of what Trove will offer within the OpenStack ecosystem. I've truly
enjoyed my time hanging out, working with, and getting to know everyone.
Feel free to contact me if you have wanna chat or just hang out if you
around around the Austin area.

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

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

Re: [openstack-dev] [ovs-discuss] [ovn][networking-sfc]

[Cathy Zhang]

The guide is the networking-ovn guide. Not sure what is meant by 
“port-security”. From networking-sfc point of view, security group is not 
needed.

Thanks,
Cathy

From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of Murali R
Sent: Monday, October 10, 2016 2:47 PM
To: discuss; OpenStack Development Mailing List (not for usage questions)
Subject: [ovs-discuss] [ovn][networking-sfc]

Networking-sfc and ovn install guide says "port_security" must be enabled when 
enabling networkin-sfc  (networking-ovn/doc/source/install.rst -- line 165)

In my use cases it gets too complicated if I use port-security, so was 
disabling it.

Please let me know if there is any hard requirement that this MUST be enabled 
in Neutron?

-Murali

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

[openstack-dev] [tripleo] PTG space request

[Emilien Macchi]

Greetings,

I would like to request for some space dedicated to TripleO project
for the first OpenStack PTG.

https://www.openstack.org/ptg/

The event will happen in February 2017 during the next PTG in Atlanta.

Any feedback is welcome,
-- 
Emilien Macchi

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 02:07 PM, Clay Gerrard wrote:

On Tue, Oct 11, 2016 at 10:52 AM, Anita Kuno  wrote:


On 2016-10-11 01:40 PM, Ed Leafe wrote:


On Oct 11, 2016, at 12:17 PM, Anita Kuno  wrote:

There really needs to be a period when a) we know who all the candidates

are, and b) voting has not yet begun.


Why?

The voting period is open for a period of several days, voters have the
ability to vote at any time during that voting period.


   Because many people vote as soon as they receive their ballot.


That is their choice.



Anita,

I agree, that voters may choose to refrain from voting.  I don't hear
anyone saying "people *can not* make time for thoughtful reflection on the
candidates" - but suggestion that perhaps they *did not*?  Is there anyway
we could get numbers about how many voters waited until the end of week
like I did?


No, there is no report from the service that outputs timestamps of when 
votes were submitted.


Now, if the supervisor of the election choose to monitor the status page 
of the poll whilst the poll was happening that person could track how 
many votes were submitted at the time the status page was rendered, 
however it wouldn't be possible to independently verify this information 
and I personally feel asking an election official to add this to their 
duties (what happens if they got pulled onto a more important task?) 
isn't something I would feel comfortable with. Administering elections 
is already stressful enough.




If most voters did wait until later in the week, I think we can reject the
premise as false and accept that the week while voting is open *is* the
time in the process that most of the electorate uses for reflection on the
candidates.

If many *did* vote early in the week before some policy/platform points
were discussed one might even assume these voters have some remorse -
perhaps they will behave differently next time?  Not known.


Agreed, this is not known. What also is unknown is the number of people 
that voted early, followed the discussions and didn't feel any remorse 
in their voting choices.




OTOH, if we actively broadcast a period of time with the expressed purpose
of facilitating this discussion I think it sends a message that we as a
community expect this discussion to happen and have an impact on the
results of the election.  Is there a *downside* to a 3 week election period
as proposed by Ed, Chris and others?


Yes, there is a downside. As I have said several times already in this 
thread, expanding the duration of the election from beginning to end 
increases the time commitment and stress for the election officials. The 
job already takes a lot of planning and a minimum of one month per 
release for the ptl and tc elections, for the nomination period and the 
voting.


Now if people want to explore other opportunities for how candidates are 
differentiated that is fine, so far we seem to be circling around 
different versions of what I had offered. I do think we can come up with 
other ideas. I also think that implementing other ideas can be done in 
the given time frame.


The option I offered was completed during the election timeframe, I 
didn't need to expand the election timeframe to offer additional 
communication about candidates.


Thank you,
Anita.



-Clay





   I know that I typically do so that it doesn’t get lost under the flood

of email.


I have found putting a star on the email when it comes it helps to ensure
I don't lose it, but everyone has a different email organizing workflow.

   This wouldn’t be so bad if you could later change your vote, but once it

is cast, it can’t be changed. What that means is that if a candidate I knew
little about says something that either interests me or turns me off, I can
*use* that information.


You still can now, you just have to choose to listen to candidates prior
to voting.

Monty suggested somewhere that we reissue the email ballots everyday
(since we had email issues this time, I have no idea if that would result
in us being kicked off the service we currently use or not). If the issue
is, I want to ensure I can find my ballot when I need it, I think we can
explore options that don't include requiring election officials to expand
their commitment for an additional week.



A voter can ask the panel of candidates any question they wish such that

they are satisfied prior to voting.


Of course; no one has said otherwise. But if someone else asks a question
that may not have occurred to me to ask, the answers given can still be
influential on my choices. Look at Gordon Chung’s question in this recent
cycle: I’m sure that there were lots of people who benefited from that
question and the many answers, not just Gordon.


I know I benefited from Gord's question, both as a candidate and as a
voter. Thank you, Gord.

Again, I feel the choice exists.



Additionally should the decision be made to go forward with some form of

the 

[openstack-dev] [ovn][neutron] networking-ovn 1.0.0 release (newton) -- port-security

[Murali R]

Hi,

Please clarify if port security is required to be enabled with newton
release when installing OVN. The install.rst says it must be. In many of my
use cases I want to disable port security which is how I do currently with
devstack. I would like to know if either ovn or neutron will have
contentions if port-security disabled at neutron server.

Thanks
Murali


-- Forwarded message --
From: 
Date: Thu, Oct 6, 2016 at 6:21 AM
Subject: [openstack-announce] [new][neutron] networking-ovn 1.0.0 release
(newton)
To: openstack-annou...@lists.openstack.org


We are jazzed to announce the release of:

networking-ovn 1.0.0: OpenStack Neutron integration with OVN

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/networking-ovn

With package available at:

https://pypi.python.org/pypi/networking-ovn

Please report issues through launchpad:

http://bugs.launchpad.net/networking-ovn

For more details, please see below.

1.0.0
^

New Features

* Initial release of the OpenStack Networking service (neutron)
  integration with Open Virtual Network (OVN), a component of the the
  Open vSwitch (http://openvswitch.org/) project. OVN provides the
  following features either via native implementation or conventional
  agents:

  * Layer-2 (native OVN implementation)

  * Layer-3 (native OVN implementation or conventional layer-3
agent) The native OVN implementation supports distributed routing.
However, it currently lacks support for floating IP addresses,
NAT, and the metadata proxy.

  * DHCP (native OVN implementation or conventional DHCP agent) The
native implementation supports distributed DHCP. However, it
currently lacks support for IPv6, internal DNS, and metadata
proxy.

  * Metadata (conventional metadata agent)

  * DPDK - Usable with OVS via either the Linux kernel datapath or
the DPDK datapath.

  * Trunk driver - Driver to back the neutron's 'trunk' service
plugin

  The initial release also supports the following Networking service
  API extensions:

  * "agent"

  * "Address Scopes" *

  * "Allowed Address Pairs"

  * "Auto Allocated Topology Services"

  * "Availability Zone"

  * "Default Subnetpools"

  * "DHCP Agent Scheduler" **

  * "Distributed Virtual Router" *

  * "DNS Integration" *

  * "HA Router extension" *

  * "L3 Agent Scheduler" *

  * "Network Availability Zone" **

  * "Network IP Availability"

  * "Neutron external network"

  * "Neutron Extra DHCP opts"

  * "Neutron Extra Route"

  * "Neutron L3 Configurable external gateway mode" *

  * "Neutron L3 Router"

  * "Network MTU"

  * "Port Binding"

  * "Port Security"

  * "Provider Network"

  * "Quality of Service"

  * "Quota management support"

  * "RBAC Policies"

  * "Resource revision numbers"

  * "Router Availability Zone" *

  * "security-group"

  * "standard-attr-description"

  * "Subnet Allocation"

  * "Tag support"

  * "Time Stamp Fields"

  (*) Only applicable if using the conventional layer-3 agent.

  (**) Only applicable if using the conventional DHCP agent.

Changes in networking-ovn 1.0.0.0rc1..1.0.0
---

16ab14c Fix for vtep port
8721389 Fix test waiting for ovn-northd to start
cc52860 Update port provisioning block registration
faaa45e Updated from global requirements
1335653 Update .gitreview for stable/newton


Diffstat (except docs and test files)
-

.gitreview|  1 +
devstack/lib/networking-ovn   |  2 +-
networking_ovn/common/constants.py|  4 +-
networking_ovn/ml2/mech_driver.py | 42 +-
requirements.txt  |  2 +-
7 files changed, 119 insertions(+), 32 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 2650d84..5fc068d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-netaddr!=0.7.16,>=0.7.12 # BSD
+netaddr!=0.7.16,>=0.7.13 # BSD



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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 02:35 PM, Thiago da Silva wrote:



On 10/11/2016 01:21 PM, Anita Kuno wrote:

On 2016-10-11 12:57 PM, Thiago da Silva wrote:



On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:

Just in case folks care, now is the best time to discuss our 
election process and suggest options or changes for the next round 
of elections. I'm not adverse to discussing it I just think the 
best time for doing so is from the time the last election is over 
up to milestone one. Then we have lots of time for ideas and 
debate and any suggestions, if accepted, have time to be 
implemented and communicated so the process is fair for all, 
candidates and electorate.

Agreed.

During the election is a wonderful time for posing questions to 
candidates in order to clarify their position or stance such that 
the electorate can make an informed choice.
To me, that’s the crux: “during the election”. When exactly should 
that be? Candidates can (and do) declare up to the very last minute 
of the nomination window, and ballots go out immediately after 
that, and voting starts. There really needs to be a period when a) 
we know who all the candidates are, and b) voting has not yet 
begun. I would like to see that period be created so that the kind 
of question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place 
for the questions/answers to be stored.


Have you a suggestion for where you would like to see them?

Also regardless of what is formally set up, anyone can ask questions 
via the mailing list, that option has been used every election that I 
have witnessed, I don't see that changing. I don't think it is 
reasonable to ask officials to curate mailing list posts. I think 
what we are discussing is something in addition to mailing list 
discussions. I don't think anything ever would (or should) replace 
what comes up on the mailing list.

Anita,

Agree that the mailing list is irreplaceable, a lot of of the 
discussion would continue to happen here. I also don't think asking 
anyone to curate the answers is scalable.


Great, we agree.



A *suggestion* would be to come up with a set of questions prior to 
nomination so that candidates could answer in their self-nomination. 
Of course, how we would come up with those questions is then another 
issue. Maybe the questions could even be proposed to the election 
repo[0], starting with an initial set of questions that are then added 
on by others in the community ??? I'm trying to come up with a way to 
repeat what you provided in the '14 election without the burden...


Thiago

[0] - 
https://github.com/openstack/election/tree/master/candidates/ocata/TC


I think the format would be up to whomever administrates it since they 
would have to do the work, accept the stress and pressure and be 
answerable to the community for the choices they make. That is what 
worked best for me.


Thanks Thiago,
Anita.



Thanks,
Anita.

During last week there was a ton of great discussion, but when it 
came to voting time (towards end of the week) it was difficult/time 
consuming to find what each person had said.


-- Ed Leafe








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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Thiago da Silva]

On 10/11/2016 01:21 PM, Anita Kuno wrote:

On 2016-10-11 12:57 PM, Thiago da Silva wrote:



On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:

Just in case folks care, now is the best time to discuss our 
election process and suggest options or changes for the next round 
of elections. I'm not adverse to discussing it I just think the 
best time for doing so is from the time the last election is over 
up to milestone one. Then we have lots of time for ideas and debate 
and any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and 
electorate.

Agreed.

During the election is a wonderful time for posing questions to 
candidates in order to clarify their position or stance such that 
the electorate can make an informed choice.
To me, that’s the crux: “during the election”. When exactly should 
that be? Candidates can (and do) declare up to the very last minute 
of the nomination window, and ballots go out immediately after that, 
and voting starts. There really needs to be a period when a) we know 
who all the candidates are, and b) voting has not yet begun. I would 
like to see that period be created so that the kind of 
question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place 
for the questions/answers to be stored.


Have you a suggestion for where you would like to see them?

Also regardless of what is formally set up, anyone can ask questions 
via the mailing list, that option has been used every election that I 
have witnessed, I don't see that changing. I don't think it is 
reasonable to ask officials to curate mailing list posts. I think what 
we are discussing is something in addition to mailing list 
discussions. I don't think anything ever would (or should) replace 
what comes up on the mailing list.

Anita,

Agree that the mailing list is irreplaceable, a lot of of the discussion 
would continue to happen here. I also don't think asking anyone to 
curate the answers is scalable.


A *suggestion* would be to come up with a set of questions prior to 
nomination so that candidates could answer in their self-nomination. Of 
course, how we would come up with those questions is then another issue. 
Maybe the questions could even be proposed to the election repo[0], 
starting with an initial set of questions that are then added on by 
others in the community ??? I'm trying to come up with a way to repeat 
what you provided in the '14 election without the burden...


Thiago

[0] - https://github.com/openstack/election/tree/master/candidates/ocata/TC


Thanks,
Anita.

During last week there was a ton of great discussion, but when it 
came to voting time (towards end of the week) it was difficult/time 
consuming to find what each person had said.


-- Ed Leafe






__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Alex Schultz]

On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold  wrote:
> Hi,
>
> On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
>> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold  wrote:
>> > Hi,
>> >
>> > in the rpm-packaging project we started to package the services and are
>> > currently discussing a possible schema for configuration files and
>> > snippets used by the systemd .service files (but this would also affect
>> > OCF resource agents).
>> > This affects packagers, endusers and config management systems (Chef,
>> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
>> > the list.
>>
>> This also affects deployment tools so you may want to include tripleo,
>> kolla, fuel as they are downstream consumers and may have their own
>> assumptions about how services are launched.
>
> Done.
>
>> > Most services (at least for SUSE and RDO) are using a single config
>> > (e.g. /etc/nova/nova.conf) when starting the service. Some services
>> > (e.g. neutron services like neutron-l3-agent) use multiple config files.
>> >
>> > There are multiple problems with that approach:
>> > - when using a config-mgmt-system, users may want to override a config
>> > option (for a feature that is not yet supported) but the
>> > config-mgmt-system will override the config later again.
>>
>> Just to chime in here from a puppet standpoint, this is not a problem
>> because we provide a way for a user to add any extra options they wish
>> using the provider so it always ends up in the correct configuration
>> file.
>
> Does that also work if you need extra configuration files for 3rd party
> plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
> party config file content to the needed neutron config but that's ugly imo.
>

Plugins also have their own .ini files and are handled differently.
They get weird but we put the service configs in
/etc/neutron/neutron.conf and agent configs get put in .ini files.

>> > - when users adjust /etc/$service/$service.conf and a release update is
>> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
>> > overridden. That's good because the user changed something but otoh the
>> > file (with all it's config options and comments) is no longer correct.
>>
>> Depending on the configuration management tool, the 'default' options
>> and comments may not even be there so I'm not sure this is actually
>> that much of a concern.  Also when you upgrade there is usually some
>> sort of upgrade process that has to go along with your configuration
>> management tool which should take care of this for you. So i'm not
>> sure this needs to be a packaging concern.
>>
>> > - when config-mgmt-systems use templates for the $service.conf file,
>> > updating theses templates is a lot of work.
>>
>> Yes which is why tools that don't use templates in the configuration
>> management tool makes this a non-issue.  I'm not sure this needs to be
>> a concern of packagers as it's an issue with the configuration
>> management tool of choice and many of these tools have switched away
>> from templates or are currently handling this.  If the configuration
>> management tool doesn't support this or is suffering from this, simply
>> adding conf.d support might help but then you also run into issues
>> about ensuring things are removed and cleaned up.
>
> There *are* config-mgmt-tools still using templates. And having the
> possibility to add config snippets simplifies the process here without
> any downside for available solutions. Just don't use it if you don't
> need it.
>

Yes there are but that's not a packaging concern other than providing
a simple way to not have to deal with constantly managing
$service.conf.  I'm ok with a conf.d folder, but I guess that's more
of a question for folks who have to manage those templates today as to
what their prefered method is. Speaking from experience with a tool
that we try not to use templates, my preference is still to have
$service.conf but don't have it replaced on package update.

>> > - setting configuration options per service (let's say cinder-volume
>> > needs other config options than cinder-api) is not possible.
>>
>> So I agree this is more likely a real problem, but i'm not sure this
>> should be solved by packaging as this probably needs to be addressed
>> in upstream.  Unless this is already a thing and it's just never been
>> properly implemented when deployed via packages. The issue I have with
>> only solving this via rpm packaging is that for tools that support
>> both rpms and debs this would lead to 2 different configuration
>> mechanisms.  So I would vote not to do anything different then what
>> debs also do unless both packaging methods are updated at the same
>> time.
>
> Don't you have already a lot of different implementations for rpm
> vs. deb, different apache config dir styles, different package name, ...
> Improving the rpm side only if the deb side also 

Re: [openstack-dev] [neutron] proper cleanup of l3 resources (neutron-netns-cleanup)

[Bhatia, Manjeet S]

Hi,

Approach I am following is not cleaning blindly, there is utility in cleanup 
which I’ll use
To get eligible namespace candidates for cleanup (need to deep dive this logic 
how effective is that)
Then will extract id from namespace either using namespace manager or l3 agent 
code,
And call on l3 agent to cleanup respective namespaces.

and to check cleanup, I am creating a router and setting just a gateway which 
create namespace,
don’t add any interface, I see it cleans up qrouter-namespace but and I can 
still see router when I do router-list, which shouldn’t be there, people having 
knowledge on this pls correct me if I am wrong ?

Thanks and Regards !
Manjeet Singh Bhatia

From: Sergey Belous [mailto:sbel...@mirantis.com]
Sent: Tuesday, October 11, 2016 3:54 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] proper cleanup of l3 resources 
(neutron-netns-cleanup)

Hi, Miguel.

As I can see, Manjeet Singh Bhatia already proposed the change on review 
[1]—this patch adds the invoking a cleanup provided by l3-agent.
Actually, I like the option 2. And I'm going to implement it and compare to 
Manjeet's solution.
But can anybody suggest me, how can I manually reproduce the situation where 
netns-clean is needed to run for cleanup l3 namespaces? In which state should 
be these namespaces?

[1] https://review.openstack.org/#/c/383936/

On 7 Oct 2016, at 15:38, Miguel Angel Ajo Pelayo 
> wrote:

Hi Sergey!,

This was my point of view on a possible solution:

https://bugs.launchpad.net/neutron/+bug/1403455/comments/12

"""
After much thinking (and quite little doing) I believe the option "2"
I proposed is a rather reasonable one:

2) Before cleaning a namespace blindly in the end, identify any
network service in the namespace (via netstat), kill those processes,
so they aren't orphaned, and then, kill the namespace.

Any process should be safely killed that way, and if it's not, we can
complicate our lifes and code with "1":
1) Use stevedore HookManager to let out-of-tree repos register netns
prefixes declaration, and netns cleaners,
   so every piece of code (in-tree or out-of-tree) declare which
netns prefixes they use, and provide a netns cleanup
   hook to be called.

"""

Let me know what you think

On Fri, Oct 7, 2016 at 2:15 PM, Sergey Belous 
> wrote:

Hello everyone.

I’m very interesting in this one
https://bugs.launchpad.net/neutron/+bug/1403455
Can anybody tell me, what is the current status of this bug? Is anybody
working on it now?
And as I can see, there are some options, that was discussed in comments to
this bug and… did anybody decide which solution is the best?


--
Best Regards,
Sergey Belous


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

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

--
Best Regards,
Sergey Belous

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

Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Andrew Woodward]

On Tue, Oct 11, 2016 at 12:40 AM Thomas Bechtold  wrote:

> Hi,
>
>
>
> On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
>
> > On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold 
> wrote:
>
> > > Hi,
>
> > >
>
> > > in the rpm-packaging project we started to package the services and are
>
> > > currently discussing a possible schema for configuration files and
>
> > > snippets used by the systemd .service files (but this would also affect
>
> > > OCF resource agents).
>
> > > This affects packagers, endusers and config management systems (Chef,
>
> > > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
>
> > > the list.
>
> >
>
> > This also affects deployment tools so you may want to include tripleo,
>
> > kolla, fuel as they are downstream consumers and may have their own
>
> > assumptions about how services are launched.
>
>
>
> Done.
>
>
>
> > > Most services (at least for SUSE and RDO) are using a single config
>
> > > (e.g. /etc/nova/nova.conf) when starting the service. Some services
>
> > > (e.g. neutron services like neutron-l3-agent) use multiple config
> files.
>
> > >
>
> > > There are multiple problems with that approach:
>
> > > - when using a config-mgmt-system, users may want to override a config
>
> > > option (for a feature that is not yet supported) but the
>
> > > config-mgmt-system will override the config later again.
>
> >
>
> > Just to chime in here from a puppet standpoint, this is not a problem
>
> > because we provide a way for a user to add any extra options they wish
>
> > using the provider so it always ends up in the correct configuration
>
> > file.
>
>
>
> Does that also work if you need extra configuration files for 3rd party
>
> plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
>
> party config file content to the needed neutron config but that's ugly imo.
>
>
>
> > > - when users adjust /etc/$service/$service.conf and a release update is
>
> > > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
>
> > > overridden. That's good because the user changed something but otoh the
>
> > > file (with all it's config options and comments) is no longer correct.
>
> >
>
> > Depending on the configuration management tool, the 'default' options
>
> > and comments may not even be there so I'm not sure this is actually
>
> > that much of a concern.  Also when you upgrade there is usually some
>
> > sort of upgrade process that has to go along with your configuration
>
> > management tool which should take care of this for you. So i'm not
>
> > sure this needs to be a packaging concern.
>
> >
>
> > > - when config-mgmt-systems use templates for the $service.conf file,
>
> > > updating theses templates is a lot of work.
>
> >
>
> > Yes which is why tools that don't use templates in the configuration
>
> > management tool makes this a non-issue.  I'm not sure this needs to be
>
> > a concern of packagers as it's an issue with the configuration
>
> > management tool of choice and many of these tools have switched away
>
> > from templates or are currently handling this.  If the configuration
>
> > management tool doesn't support this or is suffering from this, simply
>
> > adding conf.d support might help but then you also run into issues
>
> > about ensuring things are removed and cleaned up.
>
>
>
> There *are* config-mgmt-tools still using templates. And having the
>
> possibility to add config snippets simplifies the process here without
>
> any downside for available solutions. Just don't use it if you don't
>
> need it.
>
>
>
> > > - setting configuration options per service (let's say cinder-volume
>
> > > needs other config options than cinder-api) is not possible.
>
> >
>
> > So I agree this is more likely a real problem, but i'm not sure this
>
> > should be solved by packaging as this probably needs to be addressed
>
> > in upstream.  Unless this is already a thing and it's just never been
>
> > properly implemented when deployed via packages. The issue I have with
>
> > only solving this via rpm packaging is that for tools that support
>
> > both rpms and debs this would lead to 2 different configuration
>
> > mechanisms.  So I would vote not to do anything different then what
>
> > debs also do unless both packaging methods are updated at the same
>
> > time.
>
>
>
> Don't you have already a lot of different implementations for rpm
>
> vs. deb, different apache config dir styles, different package name, ...
>
> Improving the rpm side only if the deb side also changes is not going to
>
> work I think.
>
>
That isn't the issue here, both sides need to agree that this is a good
path forward and agree on some general structure here, and to a large
extent this is an upstream openstack issue to break the service configs
apart. As a config-mgmt-system collaborator, I can tell you that we have to
cover what ever deviation either side comes up with, and roughly gauging
what you are 

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Clay Gerrard]

On Tue, Oct 11, 2016 at 10:52 AM, Anita Kuno  wrote:

> On 2016-10-11 01:40 PM, Ed Leafe wrote:
>
>> On Oct 11, 2016, at 12:17 PM, Anita Kuno  wrote:
>>
>> There really needs to be a period when a) we know who all the candidates
 are, and b) voting has not yet begun.

>>> Why?
>>>
>>> The voting period is open for a period of several days, voters have the
>>> ability to vote at any time during that voting period.
>>>
>>   Because many people vote as soon as they receive their ballot.
>>
>
> That is their choice.
>
>
Anita,

I agree, that voters may choose to refrain from voting.  I don't hear
anyone saying "people *can not* make time for thoughtful reflection on the
candidates" - but suggestion that perhaps they *did not*?  Is there anyway
we could get numbers about how many voters waited until the end of week
like I did?

If most voters did wait until later in the week, I think we can reject the
premise as false and accept that the week while voting is open *is* the
time in the process that most of the electorate uses for reflection on the
candidates.

If many *did* vote early in the week before some policy/platform points
were discussed one might even assume these voters have some remorse -
perhaps they will behave differently next time?  Not known.

OTOH, if we actively broadcast a period of time with the expressed purpose
of facilitating this discussion I think it sends a message that we as a
community expect this discussion to happen and have an impact on the
results of the election.  Is there a *downside* to a 3 week election period
as proposed by Ed, Chris and others?

-Clay




>   I know that I typically do so that it doesn’t get lost under the flood
>> of email.
>>
>
> I have found putting a star on the email when it comes it helps to ensure
> I don't lose it, but everyone has a different email organizing workflow.
>
>   This wouldn’t be so bad if you could later change your vote, but once it
>> is cast, it can’t be changed. What that means is that if a candidate I knew
>> little about says something that either interests me or turns me off, I can
>> *use* that information.
>>
>
> You still can now, you just have to choose to listen to candidates prior
> to voting.
>
> Monty suggested somewhere that we reissue the email ballots everyday
> (since we had email issues this time, I have no idea if that would result
> in us being kicked off the service we currently use or not). If the issue
> is, I want to ensure I can find my ballot when I need it, I think we can
> explore options that don't include requiring election officials to expand
> their commitment for an additional week.
>
>
>> A voter can ask the panel of candidates any question they wish such that
>>> they are satisfied prior to voting.
>>>
>> Of course; no one has said otherwise. But if someone else asks a question
>> that may not have occurred to me to ask, the answers given can still be
>> influential on my choices. Look at Gordon Chung’s question in this recent
>> cycle: I’m sure that there were lots of people who benefited from that
>> question and the many answers, not just Gordon.
>>
>
> I know I benefited from Gord's question, both as a candidate and as a
> voter. Thank you, Gord.
>
> Again, I feel the choice exists.
>
>
>> Additionally should the decision be made to go forward with some form of
>>> the candidate answers as I offered to the electorate in October 2014, those
>>> answers could be available as platforms are posted such that all responses
>>> are available as soon as the poll begins.
>>>
>> I think that this is a great idea, and would be willing to help in the
>> effort to make that happen again.
>>
>
> Thanks Ed, it felt satisfying to offer it when I did it. I hope others
> feel the same as you.
>
> Thanks,
> Anita.
>
>
>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 01:43 PM, Ed Leafe wrote:

On Oct 11, 2016, at 12:26 PM, Anita Kuno  wrote:

Instead of two week process, make it three:

Again as I replied to Ed's post, I think we can find options that fit in the 
current timeframe.

Why do we need a week to nominate? Open it up a month before the election, and 
close it a week before. Or open it for two days, and close it a week before. I 
don’t understand why, other than procrastination, we need such a long period. 
If you’re serious about serving, throw you hat into the ring.


-- Ed Leafe

To be honest with you I also questioned why the nomination period had to 
be the length it did, until I was running elections. Turns out people's 
lives, vacation, travel, all those meetings, are such that they need it 
to be at least the length it is in order to run if they want to run. I 
had an instance where someone posted their nomination 10 minutes prior 
to the deadline. I pm'd them and asked, were you just being lazy or 
what? Turns out their work schedule that week was such that the only 
time they could take to compose their nomination and post it was just 
before the deadline. So now I understand firsthand about why it has to 
be at least that long of a period for nomination.


If you make the nomination period longer, you require a longer 
commitment from the election officials. Officiating an election is a 
commitment. The election is top priority at that time. Given the 
expectation around officiating I personally don't think it is fair to 
extend that expectation without it being an actual solution to an actual 
problem.


I don't know what issue we would be fixing by changing the nomination 
period.


Thanks,
Anita.

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Clay Gerrard]

On Tue, Oct 11, 2016 at 9:57 AM, Thiago da Silva  wrote:

>
> it would also be nice to have a better place for the questions/answers to
> be stored. During last week there was a ton of great discussion, but when
> it came to voting time (towards end of the week) it was difficult/time
> consuming to find what each person had said.
>
>
I *also* found the process of ranking difficult and time consuming for
candidates I was less familiar with - toward then end I was keeping a set
of notes with my interpretation of the short version of peoples attitudes
on my self selected set of platform/policy points that I cared about.

I think the only reasonable way to do this is ad-hoc; during the discussion
period (which I think we *really* should "leave some breathing room" in the
process to encourage that reflection and discussion) individuals in the
community that feel compelled to do so should try to share some
summarizations of the candidates.  I think ultimately it will be borderline
campaign propaganda (it's hard to reduce a lengthy nuanced response to a
complex subject into a pithy one-line summary) - but the hope or assumption
would be that our electorate is trying to make informed decisions and
someone putting in effort to sharing the results of their research is
trying to help with that goal.

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 01:42 PM, Chris Dent wrote:

On Tue, 11 Oct 2016, Anita Kuno wrote:


* Getting rid of self nomination. Nominations come from the
  electorate at large. They can be refused of course.


What is the current problem with self nomination?


(I almost missed this since it was after your valediction)


Yeah sorry about that, bad formatting on my part. Glad you caught it.



I guess the least roundabout but perhaps insufficiently nuanced way
to put it is: Anyone who wants the job is probably not suited.

The Douglas Adams version of this is:
http://www.brainyquote.com/quotes/quotes/d/douglasada125021.html

Please accept this with the humor with which you would expect given
that author, and also that I'm in this class of self nominated folk.

I think, however, that given the massive commitment required and the
need to balance the role with employment constraints and all the
economic constraints associated with working on OpenStack being work
means that self-nomimation is probably the only realistic way to go. I
mention it more as a way jumping off point for further thinking than
a concrete proposal.

Oh okay, well thanks for clarifying.

I'll let others jump off this one with you, I don't think I'll join in. 
Thanks for the offer though.


Thanks Chris,
Anita.

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 01:40 PM, Ed Leafe wrote:

On Oct 11, 2016, at 12:17 PM, Anita Kuno  wrote:


There really needs to be a period when a) we know who all the candidates are, 
and b) voting has not yet begun.

Why?

The voting period is open for a period of several days, voters have the ability 
to vote at any time during that voting period.
  
Because many people vote as soon as they receive their ballot.


That is their choice.


  I know that I typically do so that it doesn’t get lost under the flood of 
email.


I have found putting a star on the email when it comes it helps to 
ensure I don't lose it, but everyone has a different email organizing 
workflow.



  This wouldn’t be so bad if you could later change your vote, but once it is 
cast, it can’t be changed. What that means is that if a candidate I knew little 
about says something that either interests me or turns me off, I can *use* that 
information.


You still can now, you just have to choose to listen to candidates prior 
to voting.


Monty suggested somewhere that we reissue the email ballots everyday 
(since we had email issues this time, I have no idea if that would 
result in us being kicked off the service we currently use or not). If 
the issue is, I want to ensure I can find my ballot when I need it, I 
think we can explore options that don't include requiring election 
officials to expand their commitment for an additional week.





A voter can ask the panel of candidates any question they wish such that they 
are satisfied prior to voting.

Of course; no one has said otherwise. But if someone else asks a question that 
may not have occurred to me to ask, the answers given can still be influential 
on my choices. Look at Gordon Chung’s question in this recent cycle: I’m sure 
that there were lots of people who benefited from that question and the many 
answers, not just Gordon.


I know I benefited from Gord's question, both as a candidate and as a 
voter. Thank you, Gord.


Again, I feel the choice exists.




Additionally should the decision be made to go forward with some form of the 
candidate answers as I offered to the electorate in October 2014, those answers 
could be available as platforms are posted such that all responses are 
available as soon as the poll begins.

I think that this is a great idea, and would be willing to help in the effort 
to make that happen again.


Thanks Ed, it felt satisfying to offer it when I did it. I hope others 
feel the same as you.


Thanks,
Anita.




-- Ed Leafe






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



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

Re: [openstack-dev] [networking-sfc][devstack][mitaka]

[Cathy Zhang]

Hi Navdeep,

Please see inline.

Cathy

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Tuesday, October 11, 2016 5:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?

Cathy> You only need to include VM2 in a port pair group. Traffic source and 
traffic destination do not need to be included in the chain's port pair group, 
instead their IP addresses should be included in the flow classifier so that 
the system knows which flow needs to go through the chain. Here is a link to 
thw wiki.
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Cathy




Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB | Registered in England 2832014
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Ed Leafe]

On Oct 11, 2016, at 12:31 PM, Anita Kuno  wrote:

> I think one would get a much better sense asking people if they voted when 
> they see them at summit or other live events and ask them why not if they say 
> no.

As I said in an earlier email, I have done such unscientific polling at recent 
summits. It was the answers I got to these questions that made me start 
thinking about how to improve the process.

-- Ed Leafe






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

Re: [openstack-dev] requests-mock

[Clay Gerrard]

On Tue, Oct 11, 2016 at 5:40 AM, Ian Cordasco 
wrote:

> So, as a core developer
> of Requests, I would endorse requests-mock for this category of
> dependency.
>

Excellent; exactly the kind of feedback I was hoping to solicit.  If you're
looking to add this catagory of dependency - requests-mock is best-of-breed.

Although, honestly, I was also hoping to get some input from the
perspective of maintaining a client library specifically to address the
question of if this category of dependency is something that makes sense?

e.g.

Ian, you've worked on glance - so I went looking how glanceclient uses
requests_mock and found another change from Jamie:

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

In this change, it *seems* like instead of glanceclient maintaining some
stubs that are used to set explicit expectations about the external
behavior of the other system - glaceclient has *outsourced* it's
expectations to implicitly couple with whatever keystoneclient provides.
On one hand this seems like it might reduce some maintenance burden.  OTOH,
the burden of maintaining some of the expectations about the behavior of
the external system you depend on seems *related* to maintaining the glance
client?  I'm not sure if this is a great tradeoff?  Maybe?  I'm not sure if
this gets into what you were talking about wrt integration tests?  The
change I'm currently evaluating doesn't import an external fixture I don't
think... I'm not really sure what a fixture is this context?

http://requests-mock.readthedocs.io/en/latest/api/requests_mock.html?highlight=fixture#requests-mock-fixture-module

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Ed Leafe]

On Oct 11, 2016, at 12:26 PM, Anita Kuno  wrote:
> 
>> Instead of two week process, make it three:
> 
> Again as I replied to Ed's post, I think we can find options that fit in the 
> current timeframe.

Why do we need a week to nominate? Open it up a month before the election, and 
close it a week before. Or open it for two days, and close it a week before. I 
don’t understand why, other than procrastination, we need such a long period. 
If you’re serious about serving, throw you hat into the ring.


-- Ed Leafe

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Chris Dent]

On Tue, 11 Oct 2016, Anita Kuno wrote:


* Getting rid of self nomination. Nominations come from the
  electorate at large. They can be refused of course.


What is the current problem with self nomination?


(I almost missed this since it was after your valediction)

I guess the least roundabout but perhaps insufficiently nuanced way
to put it is: Anyone who wants the job is probably not suited.

The Douglas Adams version of this is:
   http://www.brainyquote.com/quotes/quotes/d/douglasada125021.html

Please accept this with the humor with which you would expect given
that author, and also that I'm in this class of self nominated folk.

I think, however, that given the massive commitment required and the
need to balance the role with employment constraints and all the
economic constraints associated with working on OpenStack being work
means that self-nomimation is probably the only realistic way to go. I
mention it more as a way jumping off point for further thinking than
a concrete proposal.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Ed Leafe]

On Oct 11, 2016, at 12:17 PM, Anita Kuno  wrote:

>> There really needs to be a period when a) we know who all the candidates 
>> are, and b) voting has not yet begun.
> 
> Why?
> 
> The voting period is open for a period of several days, voters have the 
> ability to vote at any time during that voting period.
 
Because many people vote as soon as they receive their ballot. I know that I 
typically do so that it doesn’t get lost under the flood of email. This 
wouldn’t be so bad if you could later change your vote, but once it is cast, it 
can’t be changed. What that means is that if a candidate I knew little about 
says something that either interests me or turns me off, I can *use* that 
information.

> A voter can ask the panel of candidates any question they wish such that they 
> are satisfied prior to voting.

Of course; no one has said otherwise. But if someone else asks a question that 
may not have occurred to me to ask, the answers given can still be influential 
on my choices. Look at Gordon Chung’s question in this recent cycle: I’m sure 
that there were lots of people who benefited from that question and the many 
answers, not just Gordon.

> Additionally should the decision be made to go forward with some form of the 
> candidate answers as I offered to the electorate in October 2014, those 
> answers could be available as platforms are posted such that all responses 
> are available as soon as the poll begins.

I think that this is a great idea, and would be willing to help in the effort 
to make that happen again.


-- Ed Leafe






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

[openstack-dev] [new][oslo] oslo.policy 1.15.0 release (ocata)

[no-reply]

We are glowing to announce the release of:

oslo.policy 1.15.0: Oslo Policy library

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/oslo.policy

Download the package from:

https://pypi.python.org/pypi/oslo.policy

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.policy

For more details, please see below.

1.15.0
^^

New Features

* Add "sphinxpolicygen" Sphinx plugin, which can be used to generate
  a sample policy file for use in documentation.

Changes in oslo.policy 1.14.0..1.15.0
-

e4ecd85 Updated from global requirements
47d8960 Update docs on policy sample generator
b6d3131 Updated from global requirements
aa29c1e doc: Add introduction to index page
fb1e987 Add sphinx extension to build sample policy
9c3236a Updated from global requirements
8f5f35e Updated from global requirements
9b4d7d0 Doc: declare YAML/JSON support
e0999c2 Remove oslo.utils from requirements
3cd4d43 Update reno for stable/newton


Diffstat (except docs and test files)
-

oslo_policy/opts.py|  4 +-
oslo_policy/policy.py  |  2 +-
oslo_policy/sphinxpolicygen.py | 73 ++
.../add-sphinxpolicygen-39e2f8fa24930b0c.yaml  |  5 ++
releasenotes/source/index.rst  |  5 +-
releasenotes/source/newton.rst |  6 ++
requirements.txt   |  3 +-
test-requirements.txt  |  6 +-
12 files changed, 208 insertions(+), 15 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index bdd7366..6a89628 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9,2 +9 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.16.0 # Apache-2.0
-PyYAML>=3.1.0 # MIT
+PyYAML>=3.10.0 # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index eb9c954..5eb10f2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +7 @@ oslotest>=1.10.0 # Apache-2.0
-requests-mock>=1.0 # Apache-2.0
+requests-mock>=1.1 # Apache-2.0
@@ -13,2 +13,2 @@ coverage>=3.6 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 12:55 PM, Ruby Loo wrote:

On Tue, Oct 11, 2016 at 12:08 PM, Chris Dent  wrote:


Based on the turnout numbers and a bit of unscientific number
crunching on the voting results it seems that the electorate was
rather more engaged this time around. That's _great_.

As others have said I imagine some significant part of that was
because of more than one mailing of the ballots to help everyone
remember. I think there were probably other factors too:


  Would it be useful to have a not-so-scientific poll, to find out from
folks why they voted and why they didn't vote in previous elections?
Assuming folks respond to the poll :)

--ruby
The likelihood that someone who choose not to do something is going to 
tell you why they choose not to do something via a poll is going to be 
fairly small would be my guess.


I think one would get a much better sense asking people if they voted 
when they see them at summit or other live events and ask them why not 
if they say no. (Given you have first of all qualified the questions as 
allowable for conversation, with the person you are talking to. Voting 
is anonymous on purpose. Also you would have to be clear in your heart 
that you aren't interested in _who_ they voted for, as that information 
is immaterial to them choosing to vote or not, in my opinion.)


Thanks,
Anita.

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

[openstack-dev] [nova] Options for using trusted certificates in Nova image signature verification

[Hamilton, Peter A.]

Hi everyone,

We are interested in improving user trust in the cloud and are
currently working on certificate validation for image signatures in
Nova. Users can upload signed images to Glance and then boot them via
Nova, with Nova validating the image signature when it downloads the
image. Adding certificate validation to this process helps users be
confident that the signed image they are booting is the image they
expect it to be.

For clarity, here is a brief description about how the feature works:

1. User signs an image with their signing certificate
2. User uploads the cert to a certificate manager (e.g. Barbican)
3. User uploads the signed image to Glance with signature metadata
4. User tells Nova to create a new server using the signed image
5. Nova retrieves the image and image metadata
6. Nova retrieves the signing certificate
7. Nova conducts signature verification
8. If successful, Nova creates the new server

With the addition of certificate validation, this workflow changes
slightly. 

...
6. Nova retrieves the signing certificate
7. Nova obtains the trusted certificate (which signed the signing cert)
8. Nova conducts certificate validation
9. If successful, Nova conducts signature verification
10. If successful, Nova creates the new server

Given that this is a feature that spans services and has an impact on
the end-user, we want to get as much feedback from the community as
possible, including from developers and operators.

Here are the current options for supporting certificate validation in
Nova, specifically dealing with how to obtain the trusted certificate:

1. Update the Nova API to let the user pass in the certificate ID

The current proposed approach is to update the Nova API for the server
create call to allow the user to specify the ID of the trusted
certificate to use when validating the image signature. This places
the user in-the-loop, requiring them to provide a new specific piece
of information to successfully boot a signed image. However, there are
no easy ways to find the trusted certificate ID for an arbitrary
signed image. If different users sign and boot the same image,
out-of-band communication and metadata storage would be needed.

2. Add support for a certificate trust store to define trusted certs

Another approach adds support for a certificate trust store, which
contains a set of trusted signing certificates that are accessed
when verifying the image signature. When Nova conducts image
signature verification, it would pull in the certificates in the trust
store and search through them until it finds the certificate that
signed the image's signing certificate. If Nova cannot find it, boot
fails.

3. Use a hybrid approach of both #1 and #2

A third approach is a hybridization of the above two approaches,
leveraging the benefits of both while minimizing their drawbacks. The
Nova API would be updated to allow the user to pass the trusted
certificate ID when creating a new server. However, if the user did
not provide this ID Nova would pull the trusted certificates from the
certificate trust store to fill the gap. Either the user-provided
trusted certificate (preferred) or the set of certificates pulled from
the certificate trust store (backup) can then be used as needed.

There are benefits and downsides to each approach. If you are
interested in further details, we are in the process of updating an
Ocata Nova spec for this feature, linked below:

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

We are interested in your thoughts on certificate validation,
specifically on which of the above three options you prefer and why.

Thank you for your time,
Peter Hamilton

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 12:08 PM, Chris Dent wrote:


Based on the turnout numbers and a bit of unscientific number
crunching on the voting results it seems that the electorate was
rather more engaged this time around. That's _great_.

As others have said I imagine some significant part of that was
because of more than one mailing of the ballots to help everyone
remember. I think there were probably other factors too:

* There was a large pool of candidates this time around from several
  different places on the OpenStack map. That makes for some happy:
  it wasn't the same old thing.

* The questioning and other discussion that happened last week was
  engaging and interesting and made the process something more than
  "I've heard of this person before".

Therefore I think next time around we should have that week of
discussion before the week of voting. Its impact may be greater
when people have time to reflect on the discussion before voting.

Instead of two week process, make it three:


Again as I replied to Ed's post, I think we can find options that fit in 
the current timeframe.


http://lists.openstack.org/pipermail/openstack-dev/2016-October/105449.html

Thank you,
Anita.



1. nominations
2. discussion
3. voting

I don't think we need to make the second week super formal. I hope
we can rely on at least some people to step up with interesting
questions.

Aside from that, more radical things we may want to consider
include:

* Getting rid of self nomination. Nominations come from the
  electorate at large. They can be refused of course.


What is the current problem with self nomination?



* Term limits, either absolute or consecutive. The principles[1]
  enshrine regular handover of power but since that's not always
  been demonstrated, perhaps it needs to be formalized?

* [your idea here please]


[1] 
http://governance.openstack.org/reference/principles.html#changes-in-leadership-are-good




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


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

[openstack-dev] [ironic] weekly subteam report

[Loo, Ruby]

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 03 Oct 2016 and 10 Oct 2016)
- Ironic: 216 bugs (+11) + 212 wishlist items. 15 new (+9), 173 in progress 
(+4), 2 critical (+2), 30 high (-2) and 19 incomplete (+1)
- Inspector: 11 bugs (-3) + 19 wishlist items. 1 new, 10 in progress (-3), 0 
critical, 1 high (-3) and 1 incomplete
- Nova bugs with Ironic tag: 10. 0 new, 0 critical, 1 high
- critical bugs:
- https://bugs.launchpad.net/ironic-python-agent/+bug/1629133 external 
connectivity broken by neutron, temporary worked around in IPA
- https://bugs.launchpad.net/ironic/+bug/1631875 move to Xenial is blocked by 
misbehaving iSCSI deploy, temporary worked around by reverting move to Xenial, 
still needs urgent fixing

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- now we run all combinations of drivers and image types in ironic-lib gate
- our move to Xenial is BLOCKED by 
https://bugs.launchpad.net/ironic/+bug/1631875 and we need someone looking into 
it (Lucas volunteered, but we could use more eyes on it as well)

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- No updates, still need reviews

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- no updates, still needs review in nova

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- no updates, some spec review is happening
- resulting maybe in an API WG suggestion: 
https://review.openstack.org/#/c/383862/

Bifrost (TheJulia)
==
- Reviews to allow a bifrost deployment to leverage keystone have been posted.

.

Until next week,
--ruby



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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 12:57 PM, Thiago da Silva wrote:



On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:

Just in case folks care, now is the best time to discuss our 
election process and suggest options or changes for the next round 
of elections. I'm not adverse to discussing it I just think the best 
time for doing so is from the time the last election is over up to 
milestone one. Then we have lots of time for ideas and debate and 
any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and electorate.

Agreed.

During the election is a wonderful time for posing questions to 
candidates in order to clarify their position or stance such that 
the electorate can make an informed choice.
To me, that’s the crux: “during the election”. When exactly should 
that be? Candidates can (and do) declare up to the very last minute 
of the nomination window, and ballots go out immediately after that, 
and voting starts. There really needs to be a period when a) we know 
who all the candidates are, and b) voting has not yet begun. I would 
like to see that period be created so that the kind of 
question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place 
for the questions/answers to be stored.


Have you a suggestion for where you would like to see them?

Also regardless of what is formally set up, anyone can ask questions via 
the mailing list, that option has been used every election that I have 
witnessed, I don't see that changing. I don't think it is reasonable to 
ask officials to curate mailing list posts. I think what we are 
discussing is something in addition to mailing list discussions. I don't 
think anything ever would (or should) replace what comes up on the 
mailing list.


Thanks,
Anita.

During last week there was a ton of great discussion, but when it came 
to voting time (towards end of the week) it was difficult/time 
consuming to find what each person had said.


-- Ed Leafe






__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [new][openstackclient] osc-lib 1.2.0 release (ocata)

[no-reply]

We are delighted to announce the release of:

osc-lib 1.2.0: OpenStackClient Library

This release is part of the ocata release series.

The source is available from:

https://git.openstack.org/cgit/openstack/osc-lib

Download the package from:

https://pypi.python.org/pypi/osc-lib

Please report issues through launchpad:

https://bugs.launchpad.net/python-openstackclient

For more details, please see below.

1.2.0
^

Security Issues

* This release contains the fix for bug 1630822 so that passwords
  are no longer leaked when using the "--debug" or "-vv" options.

   (https://bugs.launchpad.net/python-openstackclient/+bug/1630822)

Changes in osc-lib 1.1.0..1.2.0
---

455eb36 Add release note for security bug 1630822
a9e8aae Improve output of supported client versions
fbe6b95 Enable release notes translation
824c66e Updated from global requirements
0a82bd7 Mask passwords in debug logs for auth_config_hook
1833c66 Updated from global requirements
c14bba3 Fix a tiny typo in documentation
32cab47 Updated from global requirements
58dd24f Updated from global requirements
647ed96 TrivilalFix: Using assertIsNone() instead of assertEqual(None)
433ddf0 Updated from global requirements
944a668 Update docstring to match params
e65d4f7 Incorrect usage message when no auth param passed
c1adac6 standardize release note page ordering
198b71c Update reno for stable/newton
9915041 Updated from global requirements
7ca698a Prompt for auth options
c1a81af Clean imports in code
00a50bf TrivialFix: Remove logging import unused
66482bf Updated from global requirements


Diffstat (except docs and test files)
-

osc_lib/api/auth.py| 42 --
osc_lib/cli/client_config.py   | 18 +++---
osc_lib/clientmanager.py   |  2 --
osc_lib/utils.py   |  4 ++-
...22-mask-password-on-debug-20dcdf1c54e84fa1.yaml |  7 
releasenotes/source/conf.py|  3 ++
releasenotes/source/index.rst  |  1 +
releasenotes/source/newton.rst |  6 
requirements.txt   |  6 ++--
test-requirements.txt  |  8 ++---
12 files changed, 69 insertions(+), 38 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 93fe65d..d3809ae 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ Babel>=2.3.4 # BSD
-cliff!=1.16.0,!=1.17.0,>=1.15.0 # Apache-2.0
+cliff>=2.2.0 # Apache-2.0
@@ -10 +10 @@ keystoneauth1>=2.10.0 # Apache-2.0
-os-client-config!=1.19.0,!=1.19.1,!=1.20.0,>=1.13.1 # Apache-2.0
+os-client-config!=1.19.0,!=1.19.1,!=1.20.0,!=1.20.1,!=1.21.0,>=1.13.1 # 
Apache-2.0
@@ -14 +14 @@ simplejson>=2.2.0 # MIT
-stevedore>=1.16.0 # Apache-2.0
+stevedore>=1.17.1 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index bec18dc..0a11e42 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10,3 +10,3 @@ oslotest>=1.10.0 # Apache-2.0
-requests-mock>=1.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-os-testr>=0.7.0 # Apache-2.0
+requests-mock>=1.1 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+os-testr>=0.8.0 # Apache-2.0
@@ -19 +19 @@ bandit>=1.1.0 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][senlin] senlin-dashboard 0.5.0 release (newton)

[no-reply]

We are amped to announce the release of:

senlin-dashboard 0.5.0: Senlin Dashboard

This release is part of the newton release series.

Download the package from:

https://tarballs.openstack.org/senlin-dashboard/

Please report issues through launchpad:

https://bugs.launchpad.net/senlin-dashboard

For more details, please see below.

Changes in senlin-dashboard 0.4.0..0.5.0


c6595fd Server-side filtering policy
319f7df Server-side filtering receivers
d75cb87 Server-side filtering nodes
c46a416 Server-side filtering clusters
626ad88 Server-side filtering profile
32a40e6 Use name as the sort key while list nodes
418ba1c Fix policy update error
87b93f0 Update the help text of profile update
43f29bf Use type rather type_name for profile
2082d6b Use generated_at for event list
101c5ce Enable release notes translation
5bb8612 Ignore cover directory which is generated by karma coverageReporter
ddf8b00 Fix Django 1.10 Compatibility
44c214a Fix the issue 'no-pep8' option is ignored
ca3aac6 Updated from global requirements
9f08d81 Updated from global requirements
17a6244 Updated from global requirements
5a005bc Update package.json and karma.conf.js
7cf8358 Use isotime format in senlin-dashboard
83dad39 Imported Translations from Zanata
5221ae7 Remove unnecessary spaces
31a1455 Imported Translations from Zanata
8e0a4b2 Add angular-schema-form into karma.conf
f772ee2 Remove *openstack/common* in tox.ini
c94ca42 [TrivialFix] Remove unnecessary context in template
d53ed2e Add initial senlin policy file
7455859 Add yesno and capfirst for cluster policy 'Enable' column
f534370 Add private function to populate request and page size
4ef2c20 Add "Status Reason" in cluster detail page
870567e Modify the 'update' help text in some forms
7861363 Provide "Update Policy" in the tables actions on the Policies panel
d44f71d Add "Status Reason" in node detail page


Diffstat (except docs and test files)
-

.gitignore |  1 +
package.json   | 10 +--
releasenotes/source/conf.py|  3 +
.../source/locale/ja/LC_MESSAGES/releasenotes.po   | 30 ++-
.../locale/zh_CN/LC_MESSAGES/releasenotes.po   | 22 +++--
requirements.txt   |  2 +-
senlin_dashboard/api/senlin.py | 99 ++
senlin_dashboard/cluster/clusters/tables.py| 20 -
senlin_dashboard/cluster/clusters/tabs.py  |  2 +-
.../templates/clusters/_detail_overview.html   |  8 +-
senlin_dashboard/cluster/clusters/views.py |  5 +-
senlin_dashboard/cluster/nodes/event_tables.py |  6 +-
senlin_dashboard/cluster/nodes/tables.py   | 15 +++-
senlin_dashboard/cluster/nodes/tabs.py |  2 +-
.../nodes/templates/nodes/_detail_overview.html|  8 +-
.../cluster/nodes/templates/nodes/_update.html |  2 +-
senlin_dashboard/cluster/nodes/views.py|  5 +-
senlin_dashboard/cluster/policies/forms.py | 25 ++
senlin_dashboard/cluster/policies/tables.py| 24 +-
.../templates/policies/_detail_overview.html   |  4 +-
.../policies/templates/policies/_update.html   | 14 +++
.../policies/templates/policies/update.html|  7 ++
senlin_dashboard/cluster/policies/urls.py  |  2 +
senlin_dashboard/cluster/policies/views.py | 38 -
senlin_dashboard/cluster/profiles/forms.py |  2 +-
senlin_dashboard/cluster/profiles/tables.py| 14 ++-
.../templates/profiles/_detail_overview.html   |  6 +-
.../profiles/templates/profiles/_update.html   |  2 +-
senlin_dashboard/cluster/profiles/views.py |  7 +-
senlin_dashboard/cluster/receivers/tables.py   | 15 +++-
.../templates/receivers/_detail_overview.html  |  4 +-
senlin_dashboard/cluster/receivers/views.py|  5 +-
senlin_dashboard/conf/README.rst   |  7 ++
senlin_dashboard/conf/senlin_policy.json   | 49 +++
senlin_dashboard/karma.conf.js |  9 +-
senlin_dashboard/locale/ja/LC_MESSAGES/django.po   | 28 +-
senlin_dashboard/locale/ja/LC_MESSAGES/djangojs.po | 88 +++
.../locale/zh_CN/LC_MESSAGES/django.po | 28 +-
test-requirements.txt  |  4 +-
tox.ini| 12 ++-
43 files changed, 550 insertions(+), 109 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index c3f35bd..0dc4cae 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ python-senlinclient>=0.3.0 # Apache-2.0
-PyYAML>=3.1.0 # MIT
+PyYAML>=3.10.0 # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index e412dfa..959166f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -23,2 +23,2 @@ xvfbwrapper>=0.1.3 #license: MIT
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-11 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:


Just in case folks care, now is the best time to discuss our election process 
and suggest options or changes for the next round of elections. I'm not adverse 
to discussing it I just think the best time for doing so is from the time the 
last election is over up to milestone one. Then we have lots of time for ideas 
and debate and any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and electorate.

Agreed.


During the election is a wonderful time for posing questions to candidates in 
order to clarify their position or stance such that the electorate can make an 
informed choice.

To me, that’s the crux: “during the election”. When exactly should that be? 
Candidates can (and do) declare up to the very last minute of the nomination 
window, and ballots go out immediately after that, and voting starts. There 
really needs to be a period when a) we know who all the candidates are, and b) 
voting has not yet begun.


Why?

The voting period is open for a period of several days, voters have the 
ability to vote at any time during that voting period. A voter can ask 
the panel of candidates any question they wish such that they are 
satisfied prior to voting. Additionally should the decision be made to 
go forward with some form of the candidate answers as I offered to the 
electorate in October 2014, those answers could be available as 
platforms are posted such that all responses are available as soon as 
the poll begins.


I think there are many options that are available to enable the 
electorate to make an informed choice that doesn't require the expansion 
of the length of time of the entire voting season. Currently voting for 
both ptl and tc elections are a month in duration, which is an extremely 
stressful time for election officials. I think we can come up with 
options that don't include increasing the time commitment election 
officials already spend on elections.




  I would like to see that period be created so that the kind of 
question/answer/clarify process you mention can happen.


I think we can create the process and still use the current timeframe. I 
didn't need to expand the time for elections in October 2014.


Thank you,
Anita.





-- Ed Leafe






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



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

Re: [openstack-dev] dependency hygiene [was requests-mock]

[Clay Gerrard]

On Tue, Oct 11, 2016 at 4:02 AM, Davanum Srinivas  wrote:

> Clay,
>
> Apologies for the top post.


Oh goodness, none needed my friend!


> https://github.com/openstack/requirements#global-
> requirements-for-openstack-projects
>
>
Eternal wells of gratitude for that read!  There was so many good gems in
the review guidelines section!

Loved this bit:

Everyone likes everyone else to use the latest version of their code.
However, deployers really don't like to be constantly updating things.
Unless it's actually impossible to use the minimum version specified in
global-requirements.txt, it should not be changed.

Leave that decision to deployers and distros.


https://github.com/openstack/requirements#for-upgrading-requirements-versions

There is a requirements team, you can reach them on the
> #openstack-requirements channel
>

Cool I might stop by... Seems like there's some good knowledge to glean
from the requirement team's experience and focus.

Even simple stuff like the links to different distro packaging
search/status:

https://github.com/openstack/requirements#finding-distro-status

... is very helpful!


> https://wiki.openstack.org/wiki/Requirements


Hrmm...

minor upstream version updates should be considered routine/cursory review


https://wiki.openstack.org/wiki/Requirements#Review_Criteria

Maybe my lens is off - seems like there's some conflicting attitudes on the
wiki and the published guidelines on at least version bumps?

Also those guidelines focus mostly on the requirements team - not the
program teams (which is more what I'm looking for right now).

There's the bit on the bot updates to requirements.txt:

This is intended as a time saving device for projects, as they can fast
approve requirements syncs and not have to manually worry about whether or
not they are up to date with the global definition.

https://github.com/openstack/requirements#automatic-sync-of-accepted-requirements

But if it *is* just a connivence function what's the big deal that some
projects (only swift?) are particularly sensitive to the minimum dependency
version issue?

There's the bit on the *process* of projects electing to participate in the
very welcome and helpful requriements team review:

This job ensures that a project can not change any dependencies to versions
not compatible with global-requirements.txt


https://github.com/openstack/requirements#enforcement-in-projects

... but  beyond "dependencies must meet the global requirements teams
minimum bar and be added to global-requirements *first*" (which based on
that teams review guidelines is *great* service to the community btw) -
it's obviously meant to be just the starting point?  A proposed change to
global requirements is supposed to reference the already in review change
on the program code and the discussion about the appropriateness of
outsourcing this impossible to live without functionality and coupling your
project's fate to the dependency is obviously meant to happen by the
program team?

Is there any other information out there that's more focused on consistent
guidelines for the *program* teams wrt to dependency hygiene - or is it
cool everyone just sorta does their own thing within the bounds of reason
(which are kept in check by the global requirements process)?

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[Joshua Harlow]

gordon chung wrote:


On 10/10/16 04:48 PM, Joshua Harlow wrote:

So the question started to be raised of is there a documented
format/schema for the events that are being emitted from  (there seems to be some at
http://docs.openstack.org/developer/nova/notifications.html)?


we have something to this extent in Ceilometer Events[1]. it's basically
some version of StackTach as it was the original work to integrate the two.


the actual schemas are housed in a giant definition file[2]. this was
suppose to be split into multiple files but see: "bigger issues, no
resources". originally, i had hoped that the services could each manage
their own file but we got some push back on that[3] but it's still
something i'd hope we could do.

[1] http://docs.openstack.org/developer/ceilometer/events.html
[2]
https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/event_definitions.yaml
[3] can't find it.

cheers



Ah, right, nearly forgot about that yaml. Thanks gordon!

Has there been any ideas from folks to split those 
'event_definitions.yaml' into something else (a notifications schema 
repo?)? I'd be up for helping do that (nice to have would be an included 
ability/code-gen(?) to turn those schemas into code for various 
languages [starting with the typical ones, python, go(?), java, your own>...]).


Then we could also hold the emitting projects accountable for there 
events being emitted (and the formats and versions they emit), because 
overall I'd like to get away from 'the payload format OpenStack services 
emit could be described as the Wild West' (found on that events.html 
site, lol).


-Josh

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Thiago da Silva]

On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:


Just in case folks care, now is the best time to discuss our election process 
and suggest options or changes for the next round of elections. I'm not adverse 
to discussing it I just think the best time for doing so is from the time the 
last election is over up to milestone one. Then we have lots of time for ideas 
and debate and any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and electorate.

Agreed.


During the election is a wonderful time for posing questions to candidates in 
order to clarify their position or stance such that the electorate can make an 
informed choice.

To me, that’s the crux: “during the election”. When exactly should that be? 
Candidates can (and do) declare up to the very last minute of the nomination 
window, and ballots go out immediately after that, and voting starts. There 
really needs to be a period when a) we know who all the candidates are, and b) 
voting has not yet begun. I would like to see that period be created so that 
the kind of question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place for 
the questions/answers to be stored. During last week there was a ton of 
great discussion, but when it came to voting time (towards end of the 
week) it was difficult/time consuming to find what each person had said.


-- Ed Leafe






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



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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Ruby Loo]

On Tue, Oct 11, 2016 at 12:08 PM, Chris Dent  wrote:

>
> Based on the turnout numbers and a bit of unscientific number
> crunching on the voting results it seems that the electorate was
> rather more engaged this time around. That's _great_.
>
> As others have said I imagine some significant part of that was
> because of more than one mailing of the ballots to help everyone
> remember. I think there were probably other factors too:
>

 Would it be useful to have a not-so-scientific poll, to find out from
folks why they voted and why they didn't vote in previous elections?
Assuming folks respond to the poll :)

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

[openstack-dev] [nova] Bug triage and tag owner list

[Timofei Durakov]

Hi team,

I'd like to share a link [1] to Nova Bug Triage wiki page. This page
contains a tag owner list and instructions that allow subscribing not for
all nova bugs, but for a certain tag. It would be great if all tags in a
table have an owner, so if you are interested in some of them, and could
help triaging certain tagged bugs, you are welcome to edit the page and
subscribe to a tag.

Timofey

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

Re: [openstack-dev] [OpenStack-docs] Admin guide in-tree?

[Ruby Loo]

>From my point of view, the rush is so that we can be more efficient with
all of our time/efforts. In ironic, we have a bit of a mess. We now have
duplicated (and perhaps out-of-sync) admin-related information in our
developer docs [1] as well as in the official admin guide [2] -- the latter
content was added but I am unaware of that knowledge/coordination being
done with the ironic community :-(

Should we :
A. move our admin-related information from our developer docs to the
existing admin guide; then move the admin guide to the new in-tree solution
later

B. replace what is in the existing admin guide with a pointer to the
developer docs; then move the admin content to the new in-tree solution
later

C. status quo until the new in-tree solution is available

--ruby

[1] http://docs.openstack.org/developer/ironic/
[2] http://docs.openstack.org/admin-guide/baremetal.html


On Mon, Oct 10, 2016 at 7:07 PM, Lana Brindley 
wrote:

> On 10/10/16 16:25, Andreas Jaeger wrote:
> > On 2016-10-10 01:37, Steve Martinelli wrote:
> >> On Oct 9, 2016 6:57 PM, "Lana Brindley"  >> > wrote:
> >>>
> >>> Why the rush?
> >>
> >> I think its more eagerness than rush. Project teams made a lot of head
> >> way with the API ref and install guides being in-tree that they want to
> >> keep the momentum with the admin guide.
> >
> > Those teams are more than welcome to contribute today to the
> > openstack-manuals repository! Is there anything we can help these?
> >
> > Andreas
> >
>
> Yes, Andreas makes a good point. If there's content you want in the guides
> now, we can help you with that.
>
> Lana
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Setting up to 3rd party CI OVB jobs

[Derek Higgins]

On 7 October 2016 at 14:03, Paul Belanger  wrote:
> Greetings,
>
> I wanted to propose a work item, that I am happy to spearhead, about setting 
> up
> a 3rd party CI system for tripleo project. The work I am proposing, wouldn't
> actually affect anything today about tripleo-ci but provider a working example
> of how 3rd party CI will work and potential migration path.

Great, if we are to transition to 3rd party CI this getting a trial up
and running first would be great to minimize down time if we are to
move jobs in future

>
> This is just one example of how it would work, obviously everything is open 
> for
> discussions but I think you'll find the plan to be workable. Additionally, 
> this
> topic would only apply to OVB jobs, existing jobs already running on cloud
> providers from openstack-infra would not be affected.
>
> What I am proposing is we move tripleo-test-cloud-rh2 (currently disabled) 
> from
> openstack-infra (nodepool) to rdoproject (nodepool).  This give us a cloud we
> can use for OVB; we know it works because OVB jobs have run on it before.

+1, there are some user currently on RH2 using it as a dev
environment, but if we start small this wont be a problem and those
users should eventually be moving too a different cloud

>
> There is a few issues we'd first need to work on, specifically since
> rdoproject.org is currently using SoftwareFactory[1] we'd need to have them
> adding support for nodepool-builder. This is needed so we can use the existing
> DIB elements that openstack-infra does to create centos-7 images (which 
> tripleo
> uses today). We have 2 options, wait for SF team to add support for this (I
> don't know how long that is, but they know of the request) or we manually 
> setup
> a external nodepool-builder instance for rdoproject.org, which connects to
> nodepool.rdoproject.org via gearman (I suggest we do this).

As a 3rd option, is it possible to just use the centos cloud image
directly? The majority of the data cached on the DIB built image isn't
actually used by tripleo-ci?

>
> Once that issue is solved, things are a little easier.  It would just be a
> matter of porting upstream CI configuration to rdoproject.org and validating
> images, JJB jobs and test validation. Cloud credentials removed from
> openstack-infra and added to rdoproject.org.
>
> I'd basically need help from rdoproject (eg: dmsimard) with some of the admin
> tasks, a long with a VM for nodepool-builder. We already have the 3rdparty CI
> bits setup in rdoproject.org, we are actually running DLRN builds on
> python-tripleoclient / python-openstackclient upstream patches.

Sounds good(assuming the RDO community are ok with allowing us to add
jobs over there)

>
> I think the biggest step is getting nodepool-builder working with Software
> Factory, but once that is done, it should be straightforward work.
>
> Now, if SoftwareFactory is the long term home for this system is open for
> debate.  Obviously, rdoproject has the majority of this infrastructure in 
> plan,
> so it makes for a good place to run tripleo-ci OVB jobs.  Other wise, if there
> are issue, then tripleo would have to stand up their own jenkins/nodepool/zuul
> infrastructure and maintain it.
>
> I'm happy to answer questions,
> Paul
>
> [1] http://softwarefactory-project.io/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

[gordon chung]

On 10/10/16 04:48 PM, Joshua Harlow wrote:
>
> So the question started to be raised of is there a documented
> format/schema for the events that are being emitted from  various services> (there seems to be some at
> http://docs.openstack.org/developer/nova/notifications.html)?

we have something to this extent in Ceilometer Events[1]. it's basically 
some version of StackTach as it was the original work to integrate the two.


the actual schemas are housed in a giant definition file[2]. this was 
suppose to be split into multiple files but see: "bigger issues, no 
resources". originally, i had hoped that the services could each manage 
their own file but we got some push back on that[3] but it's still 
something i'd hope we could do.

[1] http://docs.openstack.org/developer/ceilometer/events.html
[2] 
https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/event_definitions.yaml
[3] can't find it.

cheers

-- 
gord

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Chris Dent]

Based on the turnout numbers and a bit of unscientific number
crunching on the voting results it seems that the electorate was
rather more engaged this time around. That's _great_.

As others have said I imagine some significant part of that was
because of more than one mailing of the ballots to help everyone
remember. I think there were probably other factors too:

* There was a large pool of candidates this time around from several
  different places on the OpenStack map. That makes for some happy:
  it wasn't the same old thing.

* The questioning and other discussion that happened last week was
  engaging and interesting and made the process something more than
  "I've heard of this person before".

Therefore I think next time around we should have that week of
discussion before the week of voting. Its impact may be greater
when people have time to reflect on the discussion before voting.

Instead of two week process, make it three:

1. nominations
2. discussion
3. voting

I don't think we need to make the second week super formal. I hope
we can rely on at least some people to step up with interesting
questions.

Aside from that, more radical things we may want to consider
include:

* Getting rid of self nomination. Nominations come from the
  electorate at large. They can be refused of course.

* Term limits, either absolute or consecutive. The principles[1]
  enshrine regular handover of power but since that's not always
  been demonstrated, perhaps it needs to be formalized?

* [your idea here please]


[1] 
http://governance.openstack.org/reference/principles.html#changes-in-leadership-are-good

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kosmos] meetings canceled until post summit

[Doug Wiegley]

We will pick back up on 11/1. 

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

Re: [openstack-dev] [neutron] [classifier] Common Classifier + OVS Flow Management Meeting

[Duarte Cardoso, Igor]

Reminder that the meeting is in 1 hour,

Best regards,
Igor.

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, October 10, 2016 5:14 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] [classifier] Common Classifier + OVS Flow 
Management Meeting

Hi Common Classifier and OVS Flow Management community,

Feel free to add topics to the next meeting's agenda at:
https://wiki.openstack.org/w/index.php?title=Neutron/CommonFlowClassifier=edit=5

Time, location and recurrence are unchanged, so the next meeting will be 
tomorrow (11th October) at 17:00 UTC [1] on #openstack-meeting [2].

Current agenda:

Important links about the Common Classifier / Common Classification Framework:
-  https://review.openstack.org/#/q/topic:bug/1476527
-  https://bugs.launchpad.net/networking-sfc/+bug/1476527
-  https://github.com/openstack/neutron-classifier
-  [3] included in topic above as well

Important links about OVS Flow Management:
-  https://review.openstack.org/#/q/topic:bug/1563967
-  https://bugs.launchpad.net/neutron/+bug/1563967


The spec in [3] seems to have reached a very stable state. If you haven't yet 
reviewed it to understand if and how your use cases fit there, be sure to do it 
as soon as possible.

[1] 
http://eavesdrop.openstack.org/calendars/neutron-common-classifier-meeting.ics
[2] http://eavesdrop.openstack.org/#Neutron_Common_Classifier_meeting
[3] https://review.openstack.org/#/c/320439/

Best regards,
Igor.

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Ed Leafe]

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:

> Just in case folks care, now is the best time to discuss our election process 
> and suggest options or changes for the next round of elections. I'm not 
> adverse to discussing it I just think the best time for doing so is from the 
> time the last election is over up to milestone one. Then we have lots of time 
> for ideas and debate and any suggestions, if accepted, have time to be 
> implemented and communicated so the process is fair for all, candidates and 
> electorate.

Agreed.

> During the election is a wonderful time for posing questions to candidates in 
> order to clarify their position or stance such that the electorate can make 
> an informed choice.

To me, that’s the crux: “during the election”. When exactly should that be? 
Candidates can (and do) declare up to the very last minute of the nomination 
window, and ballots go out immediately after that, and voting starts. There 
really needs to be a period when a) we know who all the candidates are, and b) 
voting has not yet begun. I would like to see that period be created so that 
the kind of question/answer/clarify process you mention can happen.


-- Ed Leafe






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

Re: [openstack-dev] [devstack] devstack-plugin additional-pkg-repos: ocata summit working session?

[Thomas Goirand]

On 10/11/2016 02:09 PM, Markus Zoeller wrote:
> * How to create a "*.deb" package out of the source code of
> libvirt/qemu? (surprisingly enough, I'm still struggling with this)

What version of libvirt / qemu are you trying to build? libvirt 2.3.0
was released 6 days ago, and uploaded to Debian unstable 3 days ago. I
don't think you need to manage the packaging yourself, but maybe just
backport it to your distribution of choice (Ubuntu?). It is probably the
same for Qemu (Debian unstable has a fairly recent version). If you see
any packaging problem, best would be to deal with it with the package
maintainer (probably best through the Debian BTS).

Cheers,

Thomas Goirand (zigo)


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

[openstack-dev] [networking-cisco] Meeting Reminder, 11th Oct 2016

[Sam Betts (sambetts)]

Just a quick reminder that the first networking-cisco IRC meeting will be 
happening on #openstack-meeting-3 at 16:00 UTC.

See you there,

Sam

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Anita Kuno]

On 2016-10-04 04:53 PM, Anita Kuno wrote:

On 16-10-04 12:54 PM, Thierry Carrez wrote:

Doug Hellmann wrote:

John Davidge wrote:

Thierry, I'm surprised by your open hostility towards candidates.
Accusing
people of 'pretending' to care about things that they've taken the
time to

This is an excellent example of needing to know the speaker, as
well as their words, and why anonymous elections for leaders
are a bad idea generally and favor native English speakers over
other members of our community.

In this case, I know that Thierry is French and, while his English
is better than I could ever hope my French to be, he sometimes makes
"interesting" word choices, especially where the French and English
words are close in spelling or pronunciation, if not quite so close in
meaning.

In French, "prétendre" has a connotation of "profess" or simply
"say", which is very different from the more negative connotation
of "pretend" in English where common use implies some false intent.
Knowing Thierry and his past contributions well enough to trust his
good intentions, I was able to look past the awkward phrasing to
ask what message he was trying to convey.

Yeah, sorry for the poor choice of words, I didn't mean that candidates
are trying to deceive anyone. I only meant that in my experience, past
members of the TC were overly optimistic in their campaign emails about
how much they thought they would be able to achieve. So looking at the
past track record is important.


A poll in the weeks leading to the self-nomination period could
be used to identify the issues people are most concerned about, and
candidates could be encouraged to address those issues directly in 
their
self-nominations. This would reduce the reliance on a potentially 
messy

question and answer period by pre-empting the greatest concerns.

If my memory serves well, I think Anita (anteaya) drove such a
structured discussion in a past election (identify key issues and ask
candidates to address those questions in their candidacy email). Maybe
she can give us a summary of how well that went.




I had hoped to stay out of this discussion since I consider it poor 
form to discuss the way a race is run whilst the race is being run, 
however here we are.


tl;dr the idea seems sound, my method doesn't scale, other tooling 
needs to be considered if this is something folks want in future


Indeed when I was an election official in the past one of the items 
that both myself and my co-election official identified was the 
difficulty the electorate was having identifying the differences 
between the candidates (some of whom they did not know, since we were 
and have scaled so much in such a short period of time). We felt that 
it was important to do the best we could to give the electorate an 
opportunity (so hard to find a window of time to consume information 
and contemplate it anymore) to compare candidates in a neutral and 
equal way.


The wikipage for the TC election for 2014 has the information: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014
I also would suggest looking at the history of edits to the page to 
get a sense of the work involved in offering this information in this 
way.


I came up with the questions myself: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions 
Tristan signed off on them but he didn't have as much knowledge of the 
community as I did at the time so I composed them. We debated on 
asking the mailing list for input but since I knew I would be doing 
the lions share of the work on this one I didn't want to have to 
filter through questions and then appear to either pick favourites or 
snub someone should I select or not select their offered question. I 
felt I had enough pressure on myself already taking this on, I didn't 
want to dig myself a deeper hole.


As you can see from the edits to the wikipage (I basically spent 4 
straight days adding answers and reordering existing answers on the 
wikipage - I had a bowl of names in my home and every time a new 
response came in I shook the names and selected them out of the bowl 
to create an order and then did it again for the next question - it 
was time consuming but I felt it was worth it in terms of serving the 
community's interests) I reordered the responses often to ensure that 
preference in response order was moved around. I value the opportunity 
for people to make their own decision very highly and didn't want my 
choices in terms of how the information was presented to play a role 
in how they perceived the information. So I shuffled the answers a lot.


Now in the post mortem of the election tooling discussion in the infra 
meeting we did discuss options for tooling to ensure the responses are 
shuffled when rendered in subsequent elections (I think that may have 
been the time I also presented the idea of moving to a git repo, I 
can't remember) but it wasn't picked up on and I decided in fairness 
to let others take a 

Re: [openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

[Jordan Pittier]

On Tue, Oct 11, 2016 at 4:23 AM, Ken'ichi Ohmichi 
wrote:

> Thanks for pointing this up, Jordan
>
> Before removing volume v1 API tests, it is nice to make the v2 API the
> default of Tempest scenario tests.
> Now the v1 and v2 is set as True on the default in the
> configuration[1], and the v1 API is used in the scenario like [2].
> So it is better to switch using v2 API on the default.
>
https://review.openstack.org/#/c/385050/

2016-10-10 11:37 GMT-07:00 Matt Riedemann :

> >
> > So make it conditional in Tempest via a config option, disable volume v1
> > tests by default for the integrated gate, and then add a new job that
> runs
> > only on cinder changes (and maybe only in the experimental queue) that
> > enables volume v1 tests. You could run it on cinder in the check/gate and
> > skip the job from running unless something in the v1 API path is changed,
> > there are examples of that in project-config.
> >
> > Nova used to have the v2 API in tree and this was kind of the eventual
> path
> > to phasing out the Tempest testing on that code and got us to the point
> of
> > removing the v2 *code*.  The compute v2 API itself is still honored via
> the
> > v2.1 base microversion.
>
Yeah that could work. But I'd rather we completely remove the Cinder v1
part in Tempest, I am tired of the "if cinder_v1 is True ... elif cinder_v2
is True ...", not to mention the name vs display name thing. Anyway, that's
not my call.

I understand from Sean and Duncan reply that Cinder v1 is going to live on
for a while, I'll see how we can react to this in Tempest.


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

-- 
 

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

Re: [openstack-dev] [Zun] ERROR: Not Authorized

[Hongbin Lu]

Courage,

If you follow the instruction [1] to setup the development environment, the
files should be there. All the logs can be found under /opt/stack/logs .
Alternatively, you could check the screen output by "screen -r stack".

[1]
https://github.com/openstack/zun/blob/master/doc/source/dev/quickstart.rst#exercising-the-services-using-devstack

Best regards,
Hongbin

On Tue, Oct 11, 2016 at 12:57 AM, courage angeh 
wrote:

> All the files you specified, i don't have them. i searched using find from
> root but got nothing
>
> On Tue, Oct 11, 2016 at 5:13 AM, courage angeh 
> wrote:
>
>> Here is the url of the error i get when i run zun --debug create --name
>> test --image cirros --command "ping -c 4 8.8.8.8"  :
>> http://paste.openstack.org/show/585268/
>>
>> On Tue, Oct 11, 2016 at 3:28 AM, courage angeh 
>> wrote:
>>
>>> Thanks bu i hav No folder zun found under /etc But i did find a folder
>>> keystone but no log file found in the folder
>>>
>>> On Tue, Oct 11, 2016 at 3:07 AM, Hongbin Lu 
>>> wrote:
>>>
 Several things to check:

 * Run “zun –debug create …” and check the output

 * Make sure your Keystone is running on 192.168.8.101

 * Check the Keystone log

 * Check the zun-api log

 * Check the config file under /etc/zun

 If you cannot figure it out, feel free to send me the outputs/logs
 above.



 Best regards,

 Hongbin



 *From:* courage angeh [mailto:couragean...@gmail.com]
 *Sent:* October-10-16 9:09 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Zun] ERROR: Not Authorized



 i did source the file before running that command,

 This are the environment that are set:

 OS_REGION_NAME=RegionOne
 OS_PROJECT_NAME=admin
 OS_IDENTITY_API_VERSION=2.0
 OS_PASSWORD=password
 OS_AUTH_URL=http://192.168.8.101:5000/v2.0
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 OS_VOLUME_API_VERSION=2
 OS_NO_CACHE=1

 Yet still when i run that command i still get thesame error msg and i
 have talking to the irc channel nut not reply from any one.



 On Mon, Oct 10, 2016 at 9:04 PM, Hongbin Lu 
 wrote:

 Courage,



 As suggested by Denis in another reply, you might need to source the
 credential before issuing the command. If it doesn’t help, please feel free
 to ping us in the IRC channel (#openstack-zun).



 Best regards,

 Hongbin



 *From:* courage angeh [mailto:couragean...@gmail.com]
 *Sent:* October-10-16 10:40 AM
 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] ERROR: Not Authorized



 i have problems running zun. When i try to run comaands lik:

 zun start test or
 zun create --name test --image cirros --command "ping -c 4 8.8.8.8"

 I get the error: ERROR: Not Authorized

 Futher searching it seem like i cann't connect to 
 http://192.168.8.101:5000/v2.0

 Please can someone help me?

 Thanks


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



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


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

[openstack-dev] [ironic] Meeting logs for October 12, 2016

[Jim Rollenhagen]

Hi all,

Since meetbot was down yesterday, thought I'd send out the
meeting logs for the ironic meeting.

http://paste.openstack.org/show/585338/

// jim

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Thierry Carrez]

Clint Byrum wrote:
> [...]
> Since there seems to be broad based resistance to time boxing anything
> project specific, I'd like to propose a compromise: I'd like to ask that
> teams allow people to add their IRC nick to the agenda items they'd like
> to be included in, and at the beginning of a topic, courtesy pings go
> out. No need to block the discussion on that person arriving or not,
> but just give them a heads up that it is happening so they can join or
> watch the notes.

Good idea. We could set up some #openstack-ptg channel where we'd
recommend that attendees hang out so that PSAs can be sent out there
("SpamapS, please join the Nova room for immediate boarding"). Or just
reuse #openstack-dev for those.

-- 
Thierry Carrez (ttx)

__
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