date:20170103

Excerpts from Andreas Jaeger's message of 2017-01-03 07:04:51 +0100:
> On 01/03/2017 04:01 AM, Anne Gentle wrote:
> > [...]
> > Doug, I think the include in Sphinx can be a raw txt file? Then we get
> > the best of both worlds - rendered on both docs.openstack.org
> >  and github.com .
> 
> We do not need an rst file, github handles .txt just fine. I see no
> reason to move to txt.
> 
> > I'll give that a shot with these patches as a proof of concept:
> > 
> > 1. Change cookie-cutter file to CONTRIBUTING.txt
> > https://review.openstack.org/416109
> > 2. Update openstack-manuals rendered docs with an included
> > CONTRIBUTING.txt https://review.openstack.org/416112
> > 
> > We won't really know the GitHub UI rendering of the include until
> > merged, but I've tested in other repos and changing the file extension
> > to .txt gives a link to that file.
> 
> Works with RST as well for me - I just created a pull request for
> cookiecutter and got the contributing link as expected. There's no need
> to use txt files.

github renders rst to HTML and makes links active. See
https://github.com/openstack/oslo.config/blob/master/CONTRIBUTING.rst

> 
> > Thoughts? Please comment on the reviews or here. I can work on it if we
> > think it's worthwhile to standardize upon, and/or collaborate with the
> > original contributor who wanted to standardize. I do believe the GitHub
> > experience is worthy of attention, similar in my mind to the recent
> > badges work.
> 
> Andreas

__
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] Fwd: Do you want to ask a project-specific question on the next User Survey?

2017-01-03 Thread Emilien Macchi

(Happy new year folks!)

Forwarding Heidi's email to TripleO folks, so anyone can contribute to it.

Feel free to propose questions on:
https://etherpad.openstack.org/p/tripleo-user-survey-2017

The question with the more voting, will be proposed to the survey.
Please take 2 min and help on $topic, it will be very helpful.

Thanks,

-- Forwarded message --
From: Heidi Joy Tretheway 
Date: Thu, Dec 22, 2016 at 4:58 PM
Subject: Do you want to ask a project-specific question on the next User
Survey?
To: Jimmy McArthur , Lauren Sell 


Greetings,

I wanted to offer you the opportunity to ask a question on the upcoming
User Survey, which launches on or before Feb. 1. Each PTL of a project with
significant adoption can submit one question. You can decide which audience
to serve the question to - those who are USING, TESTING, or INTERESTED in
your project (or some combination of these).

My hope is to gather as much information as possible to help you, and send
it all raw, without commentary, in advance of the Project Team Gathering in
late February.

*The deadline to submit is Jan. 9.*

Feel free to drop me a note if I can answer any questions for you!

Best,
Heidi Joy



[image: photo]
*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: heidi.tretheway

  
  






-- 
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

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

2017-01-03 Thread Alex Xu

Happy new year! Start Nova API meeting again.

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] [MassivelyDistributed] Next meeting - Tomorrow 15:00 UTC

2017-01-03 Thread lebre . adrien

Dear all, 

Let me remind you that Massively Distributed Clouds WG meeting is scheduled 
tomorrow afternoon (15:00 UTC time)
Agenda is available at :  
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017(line 
23). 
Feel free to complete it. 

All the best for 2017!
ad_rien_

__
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] [ironic] [nova] Ironic virt driver resources reporting

2017-01-03 Thread Jay Faulkner

Hey Vdrok, some comments inline.

> On Dec 30, 2016, at 8:40 AM, Vladyslav Drok  wrote:
> 
> Hi all!
> 
> There is a long standing problem of resources reporting in ironic virt 
> driver. It's described in a couple of bugs I've found - [0], [1]. Switching 
> to placement API will make things better, but still there are some problems 
> there. For example, there are cases when ironic needs to say "this node is 
> not available", and it reports the vcpus=memory_mb=local_gb as 0 in this 
> case. Placement API does not allow 0s, so in [2] it is proposed to remove 
> inventory records in this case.
> 
> But the whole logic here [3] seems not that obvious to me, so I'd like to 
> discuss when do we need to report 0s to placement API. I'm thinking about the 
> following (copy-pasted from my comment on [2]):
> 
>   • If there is an instance_uuid on the node, no matter what 
> provision/power state it's in, consider the resources as used. In case it's 
> an orphan, an admin will need to take some manual action anyway.

This won’t work, because of https://bugs.launchpad.net/nova/+bug/1503453 — 
basically the Nova resource tracker checks, decides we’re lying about it being 
used for an instance because Nova’s records don’t show we do, and it reads the 
capacity to the pool.

Generally I agree with Jay Pipes’ comments — we should have available resources 
for nodes that can be scheduled to, used resources for nodes with with a nova 
instance, and report no resources whatsoever for nodes in an unschedulable 
state, such as cleaning, enroll, etc.

-
Jay Faulkner
OSIC

>   • If there is no instance_uuid and a node is in cleaning/clean wait 
> after tear down, it is a part of normal node lifecycle, report all resources 
> as used. This means we need a way to determine if it's a manual or automated 
> clean.
>   • If there is no instance_uuid, and a node:
>   • has a bad power state or
>   • is in maintenance
>   • or actually in any other case, consider it unavailable, 
> report available resources = used resources = 0. Provision state does not 
> matter in this logic, all cases that we wanted to take into account are 
> described in the first two bullets.
> 
> Any thoughts?
> 
> [0]. https://bugs.launchpad.net/nova/+bug/1402658
> [1]. https://bugs.launchpad.net/nova/+bug/1637449
> [2]. https://review.openstack.org/414214
> [3]. 
> https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262
> 
> Happy holidays to everyone!
> -Vlad
> __
> 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] [all] Adding CONTRIBUTING.rst files to projects

2017-01-03 Thread Anne Gentle

On Tue, Jan 3, 2017 at 12:04 AM, Andreas Jaeger  wrote:

> On 01/03/2017 04:01 AM, Anne Gentle wrote:
> > [...]
> > Doug, I think the include in Sphinx can be a raw txt file? Then we get
> > the best of both worlds - rendered on both docs.openstack.org
> >  and github.com .
>
> We do not need an rst file, github handles .txt just fine. I see no
> reason to move to txt.
>
> > I'll give that a shot with these patches as a proof of concept:
> >
> > 1. Change cookie-cutter file to CONTRIBUTING.txt
> > https://review.openstack.org/416109
> > 2. Update openstack-manuals rendered docs with an included
> > CONTRIBUTING.txt https://review.openstack.org/416112
> >
> > We won't really know the GitHub UI rendering of the include until
> > merged, but I've tested in other repos and changing the file extension
> > to .txt gives a link to that file.
>
> Works with RST as well for me - I just created a pull request for
> cookiecutter and got the contributing link as expected. There's no need
> to use txt files.
>

To wrap this up - I saw different behavior when simply clicking "New Pull
Request." The GitHub UI behaves differently for RST files in that
particular scenario, prior to the act of comparing branches. But it's not
worthwhile to pursue, and is probably simply a bug in GitHub's UI, so I've
abandoned the cookie-cutter patch.

Anne


>
> > Thoughts? Please comment on the reviews or here. I can work on it if we
> > think it's worthwhile to standardize upon, and/or collaborate with the
> > original contributor who wanted to standardize. I do believe the GitHub
> > experience is worthy of attention, similar in my mind to the recent
> > badges work.
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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
>



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.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

Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages

2017-01-03 Thread Adrian Otto

Team,

We discussed this in today’s team meeting:

http://eavesdrop.openstack.org/meetings/containers/2017/containers.2017-01-03-16.00.html

Our consensus was to start iterating on this in-tree and break it out later 
into a separate repo once we have reasonably mature drivers, and/or further 
guidance form the TC about handling drivers.

Adrian

On Nov 26, 2016, at 11:31 PM, Yatin Karel 
mailto:yatin.ka...@nectechnologies.in>> wrote:

Hi,

As it will helpful in adoption of Magnum so it's good to seperate drivers 
somehow and make addition/management of new/current cluster drivers easier.

>From Developer's(refering just Myself) point of view i think current approach 
>is Ok as we can manage everything at one place and from Operator perspective i 
>think it should be easier to add/disable drivers.
Keeping above points in mind i think for now we should consider more on current 
contrib drivers development process, as this will lead to how other drivers 
would be developed/added in magnum later on. Currently we have three contrib 
drivers under development:- 
k8s_opensuse_v1/dcos_centos_v1/dcos_centos_ironic_v1. So we can target atleast 
finalizing process for their addition to some extent in this cycle.

Should we focus more on adding new contrib drivers now.  I think Adding new 
cluster drivers should be made more easier and independent whether by 
documenting or by other means. As i believe disabling can just be done by 
updating setup.cfg or manum.conf. May be we can provide some option for 
disabling drivers without manully updating config/setup files.

<< 1. in-tree:  remove the entrypoints from magnum/setup.cfg to not install them
by default. This will require some plumbing to manage them like separate python
packages, but allows magnum's development team to manage the official drivers
inside the service repo.

For this approach, what if we add drivers automatically as it is right now. And 
update doc for operators who want to disable some/all automatically installed 
drivers and on how they can add their custom drivers. I think Murali was 
working on this(process for adding new contrib drivers) so he might have some 
idea on this.

<< 2. separate repo: This option sounds cleaner, but requires more refactoring 
and
will separate more the drivers from service, having significant impact in the
development process.

Yes, This sounds more cleaner but seems not necessary now.
Agree with Ricardo for not moving to this approach now as Drago's concern is 
also valid and it would be difficult to handle that along with other high 
priorities tasks in the Ocata Cycle. So it can be revisited later when we have 
defined process for new drivers and we have more drivers in-tree.

Regards
Yatin Karel

From: Spyros Trigazis [strig...@gmail.com]
Sent: Friday, November 18, 2016 8:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Managing cluster drivers as individual distro 
packages

Hi all,

In magnum, we implement cluster drivers for the different combinations
of COEs (Container Orchestration Engines) and Operating Systems. The
reasoning behind it is to better encapsulate driver-specific logic and to allow
operators deploy custom drivers with their deployment specific changes.

For example, operators might want to:
* have only custom drivers and not install the upstream ones at all
* offer user only some of the available drivers
* create different combinations of  COE + os_distro
* create new experimental/staging drivers

It would be reasonable to manage magnum's cluster drivers as different
packages, since they are designed to be treated as individual entities. To do
so, we have two options:

1. in-tree:  remove the entrypoints from magnum/setup.cfg to not install them
by default. This will require some plumbing to manage them like separate python
packages, but allows magnum's development team to manage the official drivers
inside the service repo.

2. separate repo: This option sounds cleaner, but requires more refactoring and
will separate more the drivers from service, having significant impact in the
development process.

Thoughts?

Spyros
__
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] [neutron-lbaas][octavia]

2017-01-03 Thread Kosnik, Lubosz

In my opinion this patch should be changed. We should start using project_id 
instead of still keeping tenant_id property.
All occurences of project_id in [1] should be fixed.

Lubosz

[1] neutron_lbaas/tests/tempest/v2/scenario/base.py

From: Nir Magnezi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, January 3, 2017 at 3:37 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [neutron-lbaas][octavia]

I would like to emphasize the importance of this issue.

Currently, all te LBaaS/Octavia gates are up on running (touch wood).
Nevertheless, this bug will become more apparent (aka broken gates) in the next 
release of tempest (if we don't merge this fix beforehand).

The reason is that the issue occurs when you use tempest master,
while our gates currently use tempest tag 13.0.0 (as expected).

Nir

On Tue, Jan 3, 2017 at 11:04 AM, Genadi Chereshnya 
mailto:gcher...@redhat.com>> wrote:
When running neutron_lbaas scenarios tests with the latest tempest version we 
fail because of https://bugs.launchpad.net/octavia/+bug/1649083.
I would like if anyone can go over the patch that fixes the problem and merge 
it, so our automation will succeed.
The patch is https://review.openstack.org/#/c/411257/
Thanks in advance,
Genadi

__
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] [all] Adding CONTRIBUTING.rst files to projects

Excerpts from Anne Gentle's message of 2017-01-03 10:26:28 -0600:
> On Tue, Jan 3, 2017 at 12:04 AM, Andreas Jaeger  wrote:
> 
> > On 01/03/2017 04:01 AM, Anne Gentle wrote:
> > > [...]
> > > Doug, I think the include in Sphinx can be a raw txt file? Then we get
> > > the best of both worlds - rendered on both docs.openstack.org
> > >  and github.com .
> >
> > We do not need an rst file, github handles .txt just fine. I see no
> > reason to move to txt.
> >
> > > I'll give that a shot with these patches as a proof of concept:
> > >
> > > 1. Change cookie-cutter file to CONTRIBUTING.txt
> > > https://review.openstack.org/416109
> > > 2. Update openstack-manuals rendered docs with an included
> > > CONTRIBUTING.txt https://review.openstack.org/416112
> > >
> > > We won't really know the GitHub UI rendering of the include until
> > > merged, but I've tested in other repos and changing the file extension
> > > to .txt gives a link to that file.
> >
> > Works with RST as well for me - I just created a pull request for
> > cookiecutter and got the contributing link as expected. There's no need
> > to use txt files.
> >
> 
> To wrap this up - I saw different behavior when simply clicking "New Pull
> Request." The GitHub UI behaves differently for RST files in that
> particular scenario, prior to the act of comparing branches. But it's not
> worthwhile to pursue, and is probably simply a bug in GitHub's UI, so I've
> abandoned the cookie-cutter patch.

Ah, that's a case I didn't look at. So you're saying that if we
call it CONTRIBUTING.txt then it renders on the page where the pull
request is being created? That does seem like something we want.

Doug

> 
> Anne
> 
> >
> > > Thoughts? Please comment on the reviews or here. I can work on it if we
> > > think it's worthwhile to standardize upon, and/or collaborate with the
> > > original contributor who wanted to standardize. I do believe the GitHub
> > > experience is worthy of attention, similar in my mind to the recent
> > > badges work.
> >
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> > __
> > 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] [os-ansible-deployment] Periodic job in infra to test upgrades?

Andy McCrae wrote:
> Hi Sean,
> 
> I assume you're talking about OpenStack-Ansible (was OS-A-D before moving
> to the OpenStack namespace), if not, feel free to ignore my response!

Right.

> This is actually something we're working on - we have in role testing for
> some key OpenStack services (Nova, Neutron, Swift, Keystone, Cinder,
> Glance), and upgrade testing for the rabbitmq_server and galera_server
> roles.
> 
> This is a first pass effort, the testing right now deploys the Newton
> version of the service and then upgrades it and runs a functional test.
> This isn't perfect but should help ensure individual services can upgrade
> successfully - and can be built upon.

OK - is this a job in Zuul ? Where can I find more information?

> 
> The next step is to add an integrated build upgrade test, and we have plans
> to get that done (it's been an action item in our meetings for a few weeks,
> but hasn't landed just yet). If you have any questions or would like to get
> involved feel free to stop by and discuss in the #openstack-ansible channel
> on freenode.
> 

Thanks


-- 
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] [infra][devstack-gate][all]support multi-region gate environment

I don't like how it's adding more conditionals and complexity to an
already fairly complex shell script. I've commented as such on the
review.

-- 
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] [infra][devstack-gate][all]support multi-region gate environment

Jay Pipes wrote:
> I think it's a good idea to have multi-region testing in the gate, yes. How
> does the existing federated Keystone functionality get tested in the gate?
> Perhaps that might be an approach to copy? Just throwing out an idea here;
> I'm actually not familiar with this part of the gate at all.


We have some docs for running multiple regions -

http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup

I don't know how stale they are, but work was done.

So, really I would like to see some work/research done into that
configuration strategy before we start throwing things into
devstack-gate

My $0.02
-- 
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] [all] Adding CONTRIBUTING.rst files to projects

2017-01-03 Thread Anne Gentle

On Tue, Jan 3, 2017 at 10:47 AM, Doug Hellmann 
wrote:

> Excerpts from Anne Gentle's message of 2017-01-03 10:26:28 -0600:
> > On Tue, Jan 3, 2017 at 12:04 AM, Andreas Jaeger  wrote:
> >
> > > On 01/03/2017 04:01 AM, Anne Gentle wrote:
> > > > [...]
> > > > Doug, I think the include in Sphinx can be a raw txt file? Then we
> get
> > > > the best of both worlds - rendered on both docs.openstack.org
> > > >  and github.com .
> > >
> > > We do not need an rst file, github handles .txt just fine. I see no
> > > reason to move to txt.
> > >
> > > > I'll give that a shot with these patches as a proof of concept:
> > > >
> > > > 1. Change cookie-cutter file to CONTRIBUTING.txt
> > > > https://review.openstack.org/416109
> > > > 2. Update openstack-manuals rendered docs with an included
> > > > CONTRIBUTING.txt https://review.openstack.org/416112
> > > >
> > > > We won't really know the GitHub UI rendering of the include until
> > > > merged, but I've tested in other repos and changing the file
> extension
> > > > to .txt gives a link to that file.
> > >
> > > Works with RST as well for me - I just created a pull request for
> > > cookiecutter and got the contributing link as expected. There's no need
> > > to use txt files.
> > >
> >
> > To wrap this up - I saw different behavior when simply clicking "New Pull
> > Request." The GitHub UI behaves differently for RST files in that
> > particular scenario, prior to the act of comparing branches. But it's not
> > worthwhile to pursue, and is probably simply a bug in GitHub's UI, so
> I've
> > abandoned the cookie-cutter patch.
>
> Ah, that's a case I didn't look at. So you're saying that if we
> call it CONTRIBUTING.txt then it renders on the page where the pull
> request is being created? That does seem like something we want.
>

What happens is you get a special notification and link to CONTRIBUTING.txt
(or rst, but only after comparing branches) as in this screenshot:

https://postimg.org/image/wple5yudr/

But, based on testing, it's fine to keep what we have (rst) for the
scenarios that work today.

Anne


>
> Doug
>
> >
> > Anne
> >
> > >
> > > > Thoughts? Please comment on the reviews or here. I can work on it if
> we
> > > > think it's worthwhile to standardize upon, and/or collaborate with
> the
> > > > original contributor who wanted to standardize. I do believe the
> GitHub
> > > > experience is worthy of attention, similar in my mind to the recent
> > > > badges work.
> > >
> > > Andreas
> > > --
> > >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> > >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> > >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> > >HRB 21284 (AG Nürnberg)
> > > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272
> A126
> > >
> > >
> > > 
> __
> > > 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
>



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.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

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

2017-01-03 Thread John Dickinson



On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:

> Folks,
>
> Short Story :
> [1] has merged in devstack, it adds support for a python 3.5 based
> up/down devstack test that just starts services and brings them down.
> see [2] for a test run.
>
> Need help from swift folks:
> Swift still needs work i have gotten as far as [3] UnpicklingError on
> ring data using [4][5][6][7]. Can someone from the swift team pick
> this up?
> Once you get this working, please add "swift" to the white list in [8]
> and remove the disable_service for swift services in [9]

IIRC the issue is the differences between pickle, json, and arrays in py2 vs 
py3 (short summary: you can't deserialize in py3 stuff that was serialized in 
py2 without first changing the py2 code).

We're tracking this at https://bugs.launchpad.net/swift/+bug/1644387 and have a 
patch at https://review.openstack.org/#/c/401397/, but I can't guarantee that 
services will start as soon as that patch lands. (i.e. it's necessary, but 
might not be sufficient)

--John




>
> Other teams:
> Please consider adding DSVM jobs with USE_PYTHON3=True for your
> projects. This will hopefully help us get to our Pike goal for Python
> 3.x [10]
>
> Please stop by #openstack-python3 channel to chat.
>
> Thanks,
> Dims
>
> [1] https://review.openstack.org/#/c/414176/
> [2] 
> http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/
> [3] 
> http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz
> [4] https://review.openstack.org/#/c/412500/
> [5] https://review.openstack.org/#/c/414727/
> [6] https://review.openstack.org/#/c/416064/
> [7] https://review.openstack.org/#/c/416084/
> [8] https://review.openstack.org/#/c/414176/11/inc/python
> [9] https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml
> [10] https://review.openstack.org/#/c/349069/
>
> -- 
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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


signature.asc
Description: OpenPGP digital signature
__
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] [os-ansible-deployment] Periodic job in infra to test upgrades?

2017-01-03 Thread Andy McCrae

Hi Sean,


> OK - is this a job in Zuul ? Where can I find more information?
>

They are Zuul jobs, and are currently non-voting (but should be passing -
we're waiting to ensure the tests are reliably passing before moving to
voting).

The test is essentially:

Deploy infra for testing
Deploy other required services
Deploy "stable/newton" version of project_name
Run "master" version of project_name
Run tests for project_name.

I'm not too sure what further detail you're looking for - but the tests are
run from the "test.yml" play in the "tests" directory of each repository -
and for upgrades we added a "_upgrade" boolean var that is
set when the upgrade job is run via tox - so feel free to take a look there.

Andy
__
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] Adding CONTRIBUTING.rst files to projects

2017-01-03 Thread Andreas Jaeger

On 01/03/2017 05:59 PM, Anne Gentle wrote:
> 
> What happens is you get a special notification and link to
> CONTRIBUTING.txt (or rst, but only after comparing branches) as in this
> screenshot:
> 
> https://postimg.org/image/wple5yudr/
> 
> But, based on testing, it's fine to keep what we have (rst) for the
> scenarios that work today.

I just created pull requests for both a repo with .rst and .md and got
the "contributing link" at exactly the same time in the workflow for
both of them - in both cases when creating the pull request,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800:
> 
> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
> 
> > Folks,
> >
> > Short Story :
> > [1] has merged in devstack, it adds support for a python 3.5 based
> > up/down devstack test that just starts services and brings them down.
> > see [2] for a test run.
> >
> > Need help from swift folks:
> > Swift still needs work i have gotten as far as [3] UnpicklingError on
> > ring data using [4][5][6][7]. Can someone from the swift team pick
> > this up?
> > Once you get this working, please add "swift" to the white list in [8]
> > and remove the disable_service for swift services in [9]
> 
> IIRC the issue is the differences between pickle, json, and arrays in py2 vs 
> py3 (short summary: you can't deserialize in py3 stuff that was serialized in 
> py2 without first changing the py2 code).

Is that right? It seems like it would be the other way around. There
are newer pickle protocols in 3 that aren't available at all for 2.

There are also some new options to the load() function in 3 to do
things like fix imports for standard library modules that were
renamed and set the right default string encoding to make it possible
to change the *3* code to be able to more easily load a pickle
created by 2 [1].  Is that what you meant?

Doug

[1] https://docs.python.org/3.5/library/pickle.html#pickle.load

> 
> We're tracking this at https://bugs.launchpad.net/swift/+bug/1644387 and have 
> a patch at https://review.openstack.org/#/c/401397/, but I can't guarantee 
> that services will start as soon as that patch lands. (i.e. it's necessary, 
> but might not be sufficient)
> 
> --John
> 
> >
> > Other teams:
> > Please consider adding DSVM jobs with USE_PYTHON3=True for your
> > projects. This will hopefully help us get to our Pike goal for Python
> > 3.x [10]
> >
> > Please stop by #openstack-python3 channel to chat.
> >
> > Thanks,
> > Dims
> >
> > [1] https://review.openstack.org/#/c/414176/
> > [2] 
> > http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/
> > [3] 
> > http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz
> > [4] https://review.openstack.org/#/c/412500/
> > [5] https://review.openstack.org/#/c/414727/
> > [6] https://review.openstack.org/#/c/416064/
> > [7] https://review.openstack.org/#/c/416084/
> > [8] https://review.openstack.org/#/c/414176/11/inc/python
> > [9] 
> > https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml
> > [10] https://review.openstack.org/#/c/349069/
> >
> > -- 
> > Davanum Srinivas :: https://twitter.com/dims
> >
> > __
> > 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] [all] Adding CONTRIBUTING.rst files to projects

Excerpts from Andreas Jaeger's message of 2017-01-03 19:29:25 +0100:
> On 01/03/2017 05:59 PM, Anne Gentle wrote:
> > 
> > What happens is you get a special notification and link to
> > CONTRIBUTING.txt (or rst, but only after comparing branches) as in this
> > screenshot:
> > 
> > https://postimg.org/image/wple5yudr/
> > 
> > But, based on testing, it's fine to keep what we have (rst) for the
> > scenarios that work today.
> 
> I just created pull requests for both a repo with .rst and .md and got
> the "contributing link" at exactly the same time in the workflow for
> both of them - in both cases when creating the pull request,
> 
> Andreas

OK, great. I assumed that's how it worked but it's good to have
verification.

Thanks, Andreas & Anne!


__
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] [os-ansible-deployment] Periodic job in infra to test upgrades?

Andy McCrae wrote:
> Hi Sean,
> 
> 
> > OK - is this a job in Zuul ? Where can I find more information?
> >
> The test is essentially:
> 
> Deploy infra for testing
> Deploy other required services
> Deploy "stable/newton" version of project_name
> Run "master" version of project_name
> Run tests for project_name.
> 
> I'm not too sure what further detail you're looking for - but the tests are
> run from the "test.yml" play in the "tests" directory of each repository -
> and for upgrades we added a "_upgrade" boolean var that is
> set when the upgrade job is run via tox - so feel free to take a look there.


Ah OK I see now.

I guess what I'm driving at, is how do we get automated coverage for the
full end-to-end upgrade, so that issues[1] that I uncovered during manual
testing start getting uncovered by automation?

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


-- 
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] [os-ansible-deployment] Periodic job in infra to test upgrades?

2017-01-03 Thread Andy McCrae

>
>
> Ah OK I see now.
>
> I guess what I'm driving at, is how do we get automated coverage for the
> full end-to-end upgrade, so that issues[1] that I uncovered during manual
> testing start getting uncovered by automation?
>
> [1]: https://review.openstack.org/#/c/400847/


Completely agree, the end goal is to have the full end-to-end testing in
the openstack-ansible repository, along with the individual repo tests.
We have an experimental job setup in
project-config:
(gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv)
although no concrete work has gone into adding this to the repo - so that
one is pending.

The idea would be to run the upgrade scripts against an AIO built with
stable/newton, and run tests after the upgrade - I'm hoping to see that
land this cycle.

Andy
__
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][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

2017-01-03 Thread John Dickinson



On 3 Jan 2017, at 10:38, Doug Hellmann wrote:

> Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800:
>>
>> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
>>
>>> Folks,
>>>
>>> Short Story :
>>> [1] has merged in devstack, it adds support for a python 3.5 based
>>> up/down devstack test that just starts services and brings them down.
>>> see [2] for a test run.
>>>
>>> Need help from swift folks:
>>> Swift still needs work i have gotten as far as [3] UnpicklingError on
>>> ring data using [4][5][6][7]. Can someone from the swift team pick
>>> this up?
>>> Once you get this working, please add "swift" to the white list in [8]
>>> and remove the disable_service for swift services in [9]
>>
>> IIRC the issue is the differences between pickle, json, and arrays in py2 vs 
>> py3 (short summary: you can't deserialize in py3 stuff that was serialized 
>> in py2 without first changing the py2 code).
>
> Is that right? It seems like it would be the other way around. There
> are newer pickle protocols in 3 that aren't available at all for 2.
>
> There are also some new options to the load() function in 3 to do
> things like fix imports for standard library modules that were
> renamed and set the right default string encoding to make it possible
> to change the *3* code to be able to more easily load a pickle
> created by 2 [1].  Is that what you meant?

Nah, it's not the pickle protocol. It's the different way (some versions of) 
py27 [de]serializes arrays vs how py3 does it. The following breaks for 
py2.7.10 and works for py2.7.12 (.11 is untested).

python3 -c 'import array, pickle, os, sys; pickle.dump(array.array("I", [0, 0, 
0]), os.fdopen(1, "wb"), protocol=2)' | python -c 'import pickle, os, sys; 
print(pickle.load(os.fdopen(0, "rb")))'

So maybe there are ways to always ensure doing the right thing through some 
combination of try/excepts, "if six.PY3" blocks, plus lots of docs for ops to 
make sure upgrades go smoothly, but the real solution is to not use pickle. 
This is doubly true when considering that the data structure will be used by 
non-python code, too.

This is one of the things to put on the list for py3, and it certainly is not 
the last.

--John




>
> Doug
>
> [1] https://docs.python.org/3.5/library/pickle.html#pickle.load
>
>>
>> We're tracking this at https://bugs.launchpad.net/swift/+bug/1644387 and 
>> have a patch at https://review.openstack.org/#/c/401397/, but I can't 
>> guarantee that services will start as soon as that patch lands. (i.e. it's 
>> necessary, but might not be sufficient)
>>
>> --John
>>
>>>
>>> Other teams:
>>> Please consider adding DSVM jobs with USE_PYTHON3=True for your
>>> projects. This will hopefully help us get to our Pike goal for Python
>>> 3.x [10]
>>>
>>> Please stop by #openstack-python3 channel to chat.
>>>
>>> Thanks,
>>> Dims
>>>
>>> [1] https://review.openstack.org/#/c/414176/
>>> [2] 
>>> http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/
>>> [3] 
>>> http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz
>>> [4] https://review.openstack.org/#/c/412500/
>>> [5] https://review.openstack.org/#/c/414727/
>>> [6] https://review.openstack.org/#/c/416064/
>>> [7] https://review.openstack.org/#/c/416084/
>>> [8] https://review.openstack.org/#/c/414176/11/inc/python
>>> [9] 
>>> https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml
>>> [10] https://review.openstack.org/#/c/349069/
>>>
>>> -- 
>>> Davanum Srinivas :: https://twitter.com/dims
>>>
>>> __
>>> 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


signature.asc
Description: OpenPGP digital signature
__
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] [oslo] Not running for Oslo PTL for Pike

2017-01-03 Thread Joshua Harlow


Hi Oslo folks (and others),

Happy new year!

After serving for about a year I think it's a good opportunity for 
myself to let another qualified individual run for Oslo PTL (seems 
common to only go for two terms and hand-off to another).


So I just wanted to let folks know that I will be doing this, so that we 
can grow others in the community that wish to try out being a PTL.


I don't plan on leaving the Oslo community btw, just want to make sure 
we spread the knowledge (and the fun!) of being a PTL.


Hopefully I've been a decent PTL (with  room to improve) during 
this time :-)


-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] [tripleo] Adding a LateServices ResourceChain

2017-01-03 Thread Lars Kellogg-Stedman

On Fri, Dec 23, 2016 at 02:21:00PM +, Steven Hardy wrote:
> I commented on the bug, I'm not sure about this as it seems to overlap with
> our service_config_settings interface, which IIRC landed slightly after
> your previous patches for opstools things, and potentially provides a
> cleaner way to approach this.

I'm not sure I see how to apply that, but let me further describe the
use case and you can perhaps point me in the right direction.

> Perhaps you can point to some examples of this usage, then we can compare
> with the service_config_settings approach?
> 
> I suspect the main difference is you need to append data for each service
> to e.g the collectd configuration?

Let's take the existing Fluentd support as an example.  We want the
ability for every service to provide a logging source configuation for
Fluentd, which will get aggregated into a logging_sources
list and then ultimately used in puppet-tripleo to populate a series
of ::fluentd::config resources.

Currently, the aggregation happens in a combination of
puppet/services/services.yaml (which aggregates the logging_source
attribute from all the services in the service chain) and in
overcloud.j2.yaml (which actually instantiates the hiera data).

With the LateServiceChain I've proposed, this could all be isolated
inside the fluentd composable service: it would not be necessary to
expose any of this logic in either services.yaml or overcloud.j2.yaml,
leading.  Additionally, it would not require the fluentd service to
have any a priori knowledge of what services were in use; it would
simply aggregate any configuration information that is provided in the
primary service chain.  It would also allow us to get rid of the
"LoggingConfiguration" resource, which only exists as a way to expose
certain parameter_defaults inside services.yaml.

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/

signature.asc
Description: PGP signature
__
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] [swg][tc] An attempt to clarify/discuss: what exactly is the Stewardship Working Group, anyhow?

2017-01-03 Thread John Garbutt

On 8 December 2016 at 15:33, Thierry Carrez  wrote:
> Colette Alexander wrote:
>> [...]
>> What are the sorts of things you'd like to see tackled?
>
> John Garbutt recently proposed that the TC works on defining visions for
> itself[1] and OpenStack in general[2] and started laying out the base
> objectives and requirements around that.
>
> Defining a vision is a significant effort, and the SWG is a great venue
> to collaborate on this, especially with the tooling some of us learned
> about in the training. So we could encourage whoever is interested in
> participating in that effort to join the #openstack-swg IRC channel and
> meetings[3].
>
> We could work on the TC vision first, with an (ambitious) objective to
> have it ready for formal submission to the TC after the PTG in February ?
>
> [1] https://review.openstack.org/401225
> [2] https://review.openstack.org/401226
> [3]
> http://eavesdrop.openstack.org/#OpenStack_Stewardship_Working_Group_Meeting

I have moved my patch for the TC vision to:
https://etherpad.openstack.org/p/AtlantaPTG-SWG-TCVision

I have added some ideas and questions based on the last SWG meeting
log and the current review comments on the patch, but please do add
more!

While we probably can't make real progress on this until the TC vision
is sorted, I have moved the OpenStack vision here:
https://etherpad.openstack.org/p/AtlantaPTG-SWG-OpenStackVision

If we can get all current members of TC behind a vision for the TC, I
believe it will really help us work together. Once its clear what
everyone wants to happen in the future, its certainly easy to step up
an help with things that get us closer to the shared vision.

Thanks,
johnthetubaguy

__
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] [os-ansible-deployment] Periodic job in infra to test upgrades?

Andy McCrae wrote:
> Completely agree, the end goal is to have the full end-to-end testing in
> the openstack-ansible repository, along with the individual repo tests.
> We have an experimental job setup in
> project-config:
> (gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv)
> although no concrete work has gone into adding this to the repo - so that
> one is pending.
> 
> The idea would be to run the upgrade scripts against an AIO built with
> stable/newton, and run tests after the upgrade - I'm hoping to see that
> land this cycle.


OK - is there any way that I can assist?

What about the challenges I discussed in my initial mail related to
long AIO build times etc..?


-- 
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] [keystone] Feedback for upcoming user survey questionnaire

2017-01-03 Thread Boris Bobrov

"What were you trying to accomplish with keystone but failed"
"What functionality in keystone did you try to use but it wasn't good
enough"
"In your opinion, what in keystone requires most attention"
with choices "federation", "performance", "policy", "backend support"
and some other options.

On 12/30/2016 11:54 PM, Steve Martinelli wrote:
> We have the opportunity to ask one question on the
> upcoming user survey and we get to decide the audience to which we serve
> the question.
> 
> __ __
> 
> Our audience options are: USING, TESTING, or INTERESTED in Keystone (I
> think we should aim for USING or TESTING)
> 
> __ __
> 
> The question can take one of several forms; multiple choice (select one
> or more), or short answer.
> 
> __ __
> 
> Post your suggestions here or email them to me privately ASAP so I can
> respond to the team assembling the survey in sufficient time.
> 
> 
> 
> stevemar
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] [tripleo] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

2017-01-03 Thread Harry Rybacki

Greetings All,

Folks have been diligently working on the blueprint[1] to prepare
TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
their transition into TripleO-CI. Presently, our aim is to begin the
actual transition to OOOQ on 4-Feb-2017. We are tracking our work on
the RDO-Infra Trello board[4] and holding public discussion of key
blockers on the team’s scrum etherpad[5].

We are hosting weekly transition update meetings (1600-1700 UTC) and
would like to invite folks to participate. Specifically, we are
looking for at least one stakeholder in the existing TripleO-CI to
join us as we prepare to migrate OOOQ. Attend and map out job/feature
coverage to identify any holes so we can begin plugging them. Please
reply off-list or reach out to me (hrybacki) on IRC to be added to the
transition meeting calendar invite.

[1] - 
https://blueprints.launchpad.net/tripleo/+spec/use-tripleo-quickstart-and-tripleo-quickstart-extras-for-the-tripleo-ci-toolset
[2] - https://github.com/openstack/tripleo-quickstart/
[3] - https://github.com/openstack/tripleo-quickstart-extras/
[4] - https://trello.com/b/HhXlqdiu/rdo
[5] - https://review.rdoproject.org/etherpad/p/rdo-infra-scrum


/R

Harry Rybacki

__
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][networking-*] Attention for upcoming refactoring

2017-01-03 Thread Ian Wells

I see this changes a function's argument types without changing the
function's name - for instance, in the proposed networking-cisco change,
https://review.openstack.org/#/c/409045/ .  This makes it hard to detect
that there's been a change and react accordingly.  What's the recommended
way to write a mechanism driver that is compatible with both pre- and
post-change Neutron versions?
-- 
Ian.

On 27 December 2016 at 02:29, Anna Taraday 
wrote:

> Hello everyone!
>
> Please, note that all changes to Neutron merged.
>
> Changes that needs to be merged for external repos:
> segments db refactor - https://review.openstack.org/#
> /q/status:open+branch:master+topic:segmentsdb
> ml2 db refactor - https://review.openstack.org/#/q/status:open+branch:
> master+topic:refactor_ml2db
>
> Happy holidays for everyone!
>
>
> On Thu, Dec 22, 2016 at 7:36 AM Russell Bryant  wrote:
>
>>
>> On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday <
>> akamyshnik...@mirantis.com> wrote:
>>
>> Hello everyone!
>>
>> I've got two changes with refactor of TypeDriver [1] and segments db [2]
>> which is needed for implementation new engine facade [3].
>>
>> Reviewers of networking-cisco, networking-arista, networking-nec
>> 
>> , networking-midonet
>> 
>> , networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy -
>> pay attention for [4].
>>
>> Also recently merged refactor of ml2/db.py [5]. Fixes
>> for networking-cisco, networking-cisco, networking-cisco - are on review
>> [6]
>>
>> [1] - https://review.openstack.org/#/c/398873/
>> [2] - https://review.openstack.org/#/c/406275/
>> [3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
>> [4] - https://review.openstack.org/#/q/topic:segmentsdb
>> [5] - https://review.openstack.org/#/c/404714/
>> [6] - https://review.openstack.org/#/q/status:open++branch:
>> master+topic:refactor_ml2db
>>
>>
>> Thanks a lot for looking out for the various networking-* projects when
>> working on changes like this.  It's really great to see.
>>
>> --
>> Russell Bryant
>> 
>> __
>> 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
>>
> --
> Regards,
> Ann Taraday
>
> __
> 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] Policy for deprecating metric names

2017-01-03 Thread Mario Villaplana

Hi all,

Recently, Ruby found a patch that modifies the name of a metric
emitted by ironic. [0] After some IRC discussion, we realized that
there is no real deprecation policy regarding changing metric names.
[1]

For anyone not familiar with this feature, ironic has the capability
to emit various metrics to supported backends using metrics support in
ironic-lib. [2] Currently, the only supported backend is statsd. Most
(all?) metrics currently in ironic are implemented as function
decorators, like the following:

@METRICS.timer('my.module.MyClass.my_method')
def my_method(self):
...

This will send a time series datapoint to statsd which will be stored
with the current epoch timestamp, the name of the metric
('my.module.MyClass.my_method'), and the amount of time the method
took to finish.

The primary use case for this that I'm familiar with is generating
graphs with Graphite/Grafana to get a granular look at performance
over time. With Graphite/Grafana, operators can also create graphs
with wildcard matches. For example, a graph that matches on
ironic.conductor.*.* will contain metrics for all methods emitted by
modules in the ironic/conductor subdirectory. Each metric will appear
separately as a line on the same graph by default, if I remember
correctly.

I did some limited research into the way other OpenStack projects emit
metrics to statsd. I was only able to find one example in a short
amount of time - Swift. [3] Swift seems to document each metric
emitted with a short description of what the metric represents, but it
doesn't guarantee anything at all about the naming or semantics of
metrics.

I'd like to solicit the opinion of the community, especially operators
who use this feature, for what a good deprecation policy for metric
names should be.

As a former operator who used a downstream implementation very similar
to the upstream version in production, my recommendation is as
follows:

1. Document the metric name as well as what the metric represents in
the deploy docs, for each metric [2]
2. Guarantee to operators that the docs will be up to date, but don't
guarantee that the metric name won't change without warning between
deploys
3. Maybe document best practices for using metrics in a stable manner.
Things like using wildcards instead of keying off of specific metric
names, checking documentation for critical changes before deploys,
etc.

My reasoning for this is that it's hard to guarantee that a function
name won't change (or be completely removed) in between releases.
Since operators can use wildcards to match on metrics, it won't take
too long to notice any changes, even without staying up-to-date on the
documentation. One alternative that was suggested previously - keeping
both prior and new metric names for some deprecation period - won't
solve for the case where the function is removed. Additionally, that
would unnecessarily increase the amount of storage required for
metrics. In my experience, metric storage can be quite expensive.
There's a calculator for storage requirements for Whisper, one of the
storage backends used with Graphite, that can illustrate this. [4]

I haven't yet scoped the documentation work, but I'm curious about
feedback on this proposal or alternative suggestions from people who
use the feature.

Thank you!

Mario

[0] https://review.openstack.org/#/c/412339
[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2016-12-19.log.html#t2016-12-19T16:16:11
[2] http://docs.openstack.org/developer/ironic/deploy/metrics.html
[3]
http://docs.openstack.org/developer/swift/admin_guide.html#reporting-metrics-to-statsd
[4] http://m30m.github.io/whisper-calculator/

__
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][ml2] Mechanism drivers ! OpenvSwich or Linuxbridge or both of them?

2017-01-03 Thread Sukhdev Kapur

Zhi,

Selection of driver is deployment dependent. You could run or more ML2
drivers simultaneous depending upon your deployment.

Hierarchical Port Binding (HPB) facilitates multi-segmented L2 networks
where the scope of the Segmentation ID is local to a given segment.
For example - if you want to inter-connect two VLAN based network segments
with an overlay network of VXLAN, you would use HPB. With HPB, each VLAN
segment could use the same or different VLAN ID. Therefore, HPB facilitates
the deployments with greater than 4K VLANs.
Without HPB, L2 networks in Neutron are limited to 4K VLANS.

As to the binding information, it is bit tricky in case of HPB. There is no
generic CLI in neutron which lists the binding information. However, this
information is available in the driver. Drivers bind the ports dynamically
(segment by segment)
You can refer to Cisco or Arista ML2 drivers to see how this information is
used/retrieved.

regards..
-Sukhdev

On Fri, Dec 30, 2016 at 5:49 AM, zhi  wrote:

> Hi, all
>
> First of all. Happy New year for everyone!
>
> I have a question about mechanism drivers when using ML2 driver.
>
> When should I use openvswitch mechanism driver ?
>
> When should I use linuxbridge mechanism driver ?
>
> And, when should I use openvswitch and linuxbridge mechanism drivers ?
>
> In my opinion, ML2 driver has supported hierarchical port binding. By
> using hierarchical port binding,
> neutron will know every binding info in network topology, isn't it? If
> yes, where I can found the every binding info. And what the relationship
> between hierarchical port binding and mechanism drivers?
>
>
> Hope for your reply.
>
> Thanks
> Zhi Chang
>
> __
> 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] [nova] Outlook on Ocata blueprints

2017-01-03 Thread Takashi Natsume


Hi Matt.

The following blueprint has been approved for ocata,
but it is not in "nova-ocata-feature-freeze" etherpad.

* 
https://blueprints.launchpad.net/nova/+spec/cold-migration-with-target-ocata

* https://review.openstack.org/#/c/334725/ (spec)

The blueprint's definition is "Approved", but the series goal is still 
"Proposed for ocata".

It should be "Accepted for ocata".

Would you change it to "Accepted for ocata"?

On 2016/12/29 10:19, Matt Riedemann wrote:

Over the last couple of days I've gone over each blueprint targeted for
Ocata [1] which isn't yet implemented. I've categorized each based on
it's current status or what my outlook is for it getting done in this
release before the feature freeze on January 26th. The results are here:

https://etherpad.openstack.org/p/nova-ocata-feature-freeze

We have 69 blueprints targeted for Ocata of which only 14 are already
implemented (complete). That leaves 55 outstanding blueprints.

I've broken them down as such:

- Good progress: there are 16 of these which I'm fairly confident can
get merged before the feature freeze given enough focus. 5 of these are
priorities.

- Slow progress / at risk: there are 19 of these which for one reason or
another are at risk of not getting completed before the feature freeze.
Some just haven't had enough (or any) core reviewer attention yet, or
they are wayward changes that look basically abandoned. 2 of these are
related to priorities.

- Not started / blocked: there are 13 of these. Some don't have any code
proposed yet. Several are blocked because of dependencies on library
releases or other projects (some for os-vif or Ironic for example). 2 of
these are priorities.

- On-going refactor / cleanup series: there are 7 of these. I consider
these lower priority as they are multi-release efforts and what doesn't
get done in Ocata can be worked on in Pike.

--

As you'll see in the etherpad, I have notes on each one. If you own one
of these blueprints and there is a note about something that needs to
get done, please make that a priority if you want to see the blueprint
have a chance of landing in Ocata.

Keep in mind that the non-client library release freeze for Ocata is
January 19th, so if you have dependencies on os-* or oslo libraries
those need to get released before the 19th, and then after that there is
only one week until feature freeze. With most people out until the 3rd,
that only leaves 3 weeks to get library changes released and 4 weeks
until feature freeze.

If you know that you aren't going to have the time to work on something
please let me know and we can look for volunteers to pick up the
remaining work or I'll defer the blueprint out of tracking for Ocata so
reviewers can focus on what's planned to get done.

If by January 12th we still have changes which haven't started I'll
probably just automatically defer them.

Please let me know if there are any questions.

[1] https://blueprints.launchpad.net/nova/ocata


Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



__
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] quick reminder on review policy

2017-01-03 Thread Emilien Macchi

I've noticed some TripleO core reviewers self approving patch without
respecting our review policy, specially in tripleo-quickstart.

Here are some quick reminder:
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html#single-2-approvals
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html#self-approval

Please take some time to read it again and let us know any concern if
the policy is not enough.
If some projects do not have enough reviewers, that's a problem we
need to solve as a team, but self approving patches is definitely not
how our project work, we develop in the open, we have policies, let's
respect them.

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] [infra][devstack-gate][all]support multi-region gate environment

2017-01-03 Thread joehuang

Not found any gate/check test for federated KeyStone job yet, this also makes 
me confused that such a feature was not tested in gate/check job, or I am 
missing something. So I have to build the multi-region job based on the guide 
http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup,
 which is to setup multi-region devstack manually(or say offline).

Best Regards
Chaoyi Huang (joehuang)


From: Jay Pipes [jaypi...@gmail.com]
Sent: 03 January 2017 21:37
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra][devstack-gate][all]support multi-region 
gate environment

On 01/02/2017 09:06 PM, joehuang wrote:
> Hello,
>
> Currently only one region is supported in devstack-gate, there are lots
> of projects providing multi-region involved features, for example, heat
> multi-region, tacker multi-vim, shadow multi-cloud, tricircle networking
> across multi-region, kingbird resource sync and so on.
>
> Thanks to the patch "Introduce roles into the feature matrix", it's
> possible to assign the sub-node in devstack-gate with a new role
> "subnode_multi_region", so that all services will start and share same
> keystone in the primary node, this is the typical devstack multi-region
> mode. One environment variable MULTI_REGION is introduced to enable the
> sub-node running as the second region(currently the first step is to
> setup two-node two-region environment).
>
> One patch was prepared to enhance
> devstack-gate: https://review.openstack.org/#/c/412777/
> And Tricircle will begin to try the multi-region gate/check
> job: https://review.openstack.org/#/c/414909/
> The devstack plugin of Tricircle is also enhanced to support
> multi-region job: https://review.openstack.org/#/c/414860/
>
> How do you think about this idea? It's basic requirement to have
> multi-region gate/check job for Tricricle, hope this could be on board
> before Ocata release. once Tricircle can be tested through such a
> multi-region job, other projects can also benefit from the same
> infrastructure.

I think it's a good idea to have multi-region testing in the gate, yes.
How does the existing federated Keystone functionality get tested in the
gate? Perhaps that might be an approach to copy? Just throwing out an
idea here; I'm actually not familiar with this part of the gate at all.

Best,
-jay

__
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] [infra][devstack-gate][all]support multi-region gate environment

2017-01-03 Thread joehuang

If you run the multi-region offline(manually) with devstack, it works according 
to the guide 
http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup.
 That's the script from line 551~567 
https://review.openstack.org/#/c/412777/2/devstack-vm-gate.sh

Unfortunately there is no way to setup multi-region job in gate/check job until 
now, no script to enable this, that's why I submitted a patch to try to address 
the need.

I saw your comments "Honestly I don't like how this adds yet another flag to 
check, and complicates d-g. The idea of roles was to start to *eliminate* all 
these flags flying around in DevStack and make it more readable. This goes in 
the other direction." 

In multi-region environment(for example, two regions RegionOne and RegionTwo), 
KeyStone will be shared in RegionOne and RegionTwo, so the primary node and 
subnode should use different role, one role to enable the keystone, while 
another role is to use the keystone in another node, only one role to support 
multi-region setup seems to be not possible.  The flag "MULTI_REGION" is to 
make the subnode play with the role where no keystone will run. If we don't use 
the flag, or maybe use DEVSTACK_GATE_MULTI_REGION?

This is the first patch in devstack-gate for me, any help or guide will be 
appreciated.

Best Regards
Chaoyi Huang (joehuang)

From: Sean M. Collins [s...@coreitpro.com]
Sent: 04 January 2017 0:58
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [infra][devstack-gate][all]support multi-region 
gate environment

Jay Pipes wrote:
> I think it's a good idea to have multi-region testing in the gate, yes. How
> does the existing federated Keystone functionality get tested in the gate?
> Perhaps that might be an approach to copy? Just throwing out an idea here;
> I'm actually not familiar with this part of the gate at all.

We have some docs for running multiple regions -

http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup

I don't know how stale they are, but work was done.

So, really I would like to see some work/research done into that
configuration strategy before we start throwing things into
devstack-gate

My $0.02
--
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] [tripleo][ci] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

2017-01-03 Thread Wesley Hayutin

adding [ci] to the subject.

On Tue, Jan 3, 2017 at 4:04 PM, Harry Rybacki  wrote:

> Greetings All,
>
> Folks have been diligently working on the blueprint[1] to prepare
> TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
> their transition into TripleO-CI. Presently, our aim is to begin the
> actual transition to OOOQ on 4-Feb-2017. We are tracking our work on
> the RDO-Infra Trello board[4] and holding public discussion of key
> blockers on the team’s scrum etherpad[5].
>
> We are hosting weekly transition update meetings (1600-1700 UTC) and
> would like to invite folks to participate. Specifically, we are
> looking for at least one stakeholder in the existing TripleO-CI to
> join us as we prepare to migrate OOOQ. Attend and map out job/feature
> coverage to identify any holes so we can begin plugging them. Please
> reply off-list or reach out to me (hrybacki) on IRC to be added to the
> transition meeting calendar invite.
>
> [1] - https://blueprints.launchpad.net/tripleo/+spec/use-tripleo-
> quickstart-and-tripleo-quickstart-extras-for-the-tripleo-ci-toolset
> [2] - https://github.com/openstack/tripleo-quickstart/
> [3] - https://github.com/openstack/tripleo-quickstart-extras/
> [4] - https://trello.com/b/HhXlqdiu/rdo
> [5] - https://review.rdoproject.org/etherpad/p/rdo-infra-scrum
>
>
> /R
>
> Harry Rybacki
>
> __
> 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] [all][QA][goals] Proposed Pike Goal Split Out Tempest Plugins

2017-01-03 Thread Matthew Treinish


Hi Everyone,

I pushed out a proposed OpenStack-wide goal for the Pike cycle to split all
tempest plugins into separate repos:

https://review.openstack.org/369749

At a high level all that is being proposed is that we split out any tempest
plugins that are bundled in a service repo into a separate standalone
project/git repository. There are several reasons for doing this which are
outlined in the review and also are in the tempest documentation
(although we probably need to clean up the wording in the tempest docs a bit):

http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin

I encourage everyone to take a look at the review and provide feedback.

Thanks,

Matt Treinish


signature.asc
Description: PGP signature
__
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] [kolla][kolla-kubernetes] microservices api status

2017-01-03 Thread Fox, Kevin M

I was asked to brief everyone with where we were at with the kolla-kubernetes
microservices api.

Config of the Kubernetes objects (not talking about openstack config files) is
done through Helm values as all good Helm packages do. Defaults come from the
Helm packages values.yaml file (1) and can be overridden by the user via their
own Values.yaml file or on the command line with --set. (ex: helm install
--values mycloud.yaml --set docker_registry=local-a)

When rolled up into service packages, the same still holds, but the values for
each microservice are just prefixed with the microservices name. (2)

This has allowed the most flexibility in the configuration allowing
kolla-kubernetes to be used my the most number of operators over the most
varied amount of use cases.

This arrangement does have the drawback of being overly verbose to use though.
So, we've come up with an additional set of values using some of the brand new
features in Helm 2.1.2 (deep globals) and Helm 2.1.3 (set function). Thanks
Helm Devs! :)

With these, its possible to use the Helm global values mechanism to make it
easy to set a value that affects multiple packages, while still being able to
override more specific package settings.

For example, this value file can change the default docker registry to pull
from local-a for all packages except all neutron ones pull from local-b and all
nova from local-c:
global:
kolla:
all:
docker_registry: local-a
neutron:
all:
docker_registry: local-b
nova:
all:
docker_registry: local-b

The following should then do the right thing:
helm install kolla/cinder --values mycloud.yaml
helm install kolla/nova--values mycloud.yaml
helm install kolla/neutron --values mycloud.yaml
...

It also leaves room for openstack to be embedded in bigger Helm packages yet,
as all the rest of the global space should not conflict.

Thoughts?

Thanks,
Kevin

-
references

1. values files:

https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/values_files.md#values-files

2. subchart value overriding behavior:

https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/subcharts_and_globals.md#overriding-values-from-a-parent-chart
__
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] python 3 tests hate my exception handling

2017-01-03 Thread Michael Still

So...

Our python3 tests hate [1] my exception handling for continued vendordata
implementation [2].

Basically, it goes a bit like this -- I need to move from using requests to
keystoneauth1 for external vendordata requests. This is because we're
adding support for sending keystone headers with the request so that the
external service can verify that it is nova talking. That bit isn't too
hard.

However, keystoneauth1 uses different exceptions to report errors.
Conveniently, it has variables which list all of the connection and http
exceptions which it might raise. Inconveniently, they're listed as strings,
so I have to construct a list of them like this:

# NOTE(mikal): keystoneauth makes me jump through hoops to get these
# exceptions, which are listed as strings. Mutter.
KEYSTONEAUTH_EXCEPTIONS = [TypeError, ValueError]
for excname in ks_exceptions.connection.__all__ +
ks_exceptions.http.__all__:
KEYSTONEAUTH_EXCEPTIONS.append(getattr(ks_exceptions, excname))

Then when it comes time to catch exceptions from keystoneauth1, we can just
do this thing:

except tuple(KEYSTONEAUTH_EXCEPTIONS) as e:
LOG.warning(_LW('Error from dynamic vendordata service '
'%(service_name)s at %(url)s: %(error)s'),
{'service_name': service_name,
'url': url,
'error': e},
instance=self.instance)
return {}

Which might be a bit horrible, but is nice in that if keystoneauth1 adds
new connection or http exceptions, we get to catch them for free.

This all works and is tested. However, it causes the py3 tests to fail with
this exception:

'TypeError: catching classes that do not inherit from BaseException is not
allowed'

Which is bemusing to me because I'm not very smart.

So, could someone smarter than me please look at [1] and tell me why I get
[2] and how to not get that thing? Answers involving manually listing many
exceptions will result in me making a sad face and sarcastic comment in the
code, so something more elegant than that would be nice.

Discuss.

Thanks,
Michael

1:
http://logs.openstack.org/91/416391/1/check/gate-nova-python35-db/7835df3/console.html#_2017-01-04_01_10_35_520409
2:
https://review.openstack.org/#/c/415597/3/nova/api/metadata/vendordata_dynamic.py

--
Rackspace Australia
__
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] python 3 tests hate my exception handling

2017-01-03 Thread Tim Burke

Looks like keystoneauth1.exceptions.http.__all__ includes a from_response 
function. Maybe add a if isinstance(..., BaseException) before appending?

Tim

> On Jan 3, 2017, at 6:48 PM, Michael Still  wrote:
> 
> So...
> 
> Our python3 tests hate [1] my exception handling for continued vendordata 
> implementation [2].
> 
> Basically, it goes a bit like this -- I need to move from using requests to 
> keystoneauth1 for external vendordata requests. This is because we're adding 
> support for sending keystone headers with the request so that the external 
> service can verify that it is nova talking. That bit isn't too hard.
> 
> However, keystoneauth1 uses different exceptions to report errors. 
> Conveniently, it has variables which list all of the connection and http 
> exceptions which it might raise. Inconveniently, they're listed as strings, 
> so I have to construct a list of them like this:
> 
> # NOTE(mikal): keystoneauth makes me jump through hoops to get these
> # exceptions, which are listed as strings. Mutter.
> KEYSTONEAUTH_EXCEPTIONS = [TypeError, ValueError]
> for excname in ks_exceptions.connection.__all__ + ks_exceptions.http.__all__:
> KEYSTONEAUTH_EXCEPTIONS.append(getattr(ks_exceptions, excname))
> 
> Then when it comes time to catch exceptions from keystoneauth1, we can just 
> do this thing:
> 
> except tuple(KEYSTONEAUTH_EXCEPTIONS) as e:
> LOG.warning(_LW('Error from dynamic vendordata service '
> '%(service_name)s at %(url)s: %(error)s'),
> {'service_name': service_name,
>  'url': url,
>  'error': e},
> instance=self.instance)
> return {}
> 
> Which might be a bit horrible, but is nice in that if keystoneauth1 adds new 
> connection or http exceptions, we get to catch them for free.
> 
> This all works and is tested. However, it causes the py3 tests to fail with 
> this exception:
> 
> 'TypeError: catching classes that do not inherit from BaseException is not 
> allowed'
> 
> Which is bemusing to me because I'm not very smart.
> 
> So, could someone smarter than me please look at [1] and tell me why I get 
> [2] and how to not get that thing? Answers involving manually listing many 
> exceptions will result in me making a sad face and sarcastic comment in the 
> code, so something more elegant than that would be nice.
> 
> Discuss.
> 
> Thanks,
> Michael
> 
> 
> 1: 
> http://logs.openstack.org/91/416391/1/check/gate-nova-python35-db/7835df3/console.html#_2017-01-04_01_10_35_520409
>  
> 
> 2: 
> https://review.openstack.org/#/c/415597/3/nova/api/metadata/vendordata_dynamic.py
>  
> 
> 
> -- 
> Rackspace Australia
> __
> 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] [Nova] python 3 tests hate my exception handling

On 1/3/2017 8:48 PM, Michael Still wrote:

So...

Our python3 tests hate [1] my exception handling for continued
vendordata implementation [2].

Basically, it goes a bit like this -- I need to move from using requests
to keystoneauth1 for external vendordata requests. This is because we're
adding support for sending keystone headers with the request so that the
external service can verify that it is nova talking. That bit isn't too
hard.

However, keystoneauth1 uses different exceptions to report errors.
Conveniently, it has variables which list all of the connection and http
exceptions which it might raise. Inconveniently, they're listed as
strings, so I have to construct a list of them like this:

Then when it comes time to catch exceptions from keystoneauth1, we can
just do this thing:

Which might be a bit horrible, but is nice in that if keystoneauth1 adds
new connection or http exceptions, we get to catch them for free.

This all works and is tested. However, it causes the py3 tests to fail
with this exception:

'TypeError: catching classes that do not inherit from BaseException is
not allowed'

Which is bemusing to me because I'm not very smart.

So, could someone smarter than me please look at [1] and tell me why I
get [2] and how to not get that thing? Answers involving manually
listing many exceptions will result in me making a sad face and
sarcastic comment in the code, so something more elegant than that would
be nice.

Discuss.

Thanks,
Michael

--
Rackspace Australia

My first question is, does the KSA team consider the 'connection' and
'http' variables as public / contractual to the KSA API in the library?
If not, they could change/remove those and break nova which wouldn't be
cool.

For what it's worth, this is what we handle when making requests to the
placement service using KSA:

https://github.com/openstack/nova/blob/34f4b1bd68d6011da76e68c4ddae9f28e37eed9a/nova/scheduler/client/report.py#L37

If nothing else, maybe that's all you'd need?

Another alternative is building whatever you need into KSA itself with
the types you need, get that released before 1/19 (non-client library
release freeze), and then use that in nova with a minimum required
version bump in global-requirements.

Or try to hack this out some other magical way.

Thanks,

Matt Riedemann

Re: [openstack-dev] [nova] Outlook on Ocata blueprints


On 1/3/2017 6:03 PM, Takashi Natsume wrote:

Hi Matt.

The following blueprint has been approved for ocata,
but it is not in "nova-ocata-feature-freeze" etherpad.

*
https://blueprints.launchpad.net/nova/+spec/cold-migration-with-target-ocata

* https://review.openstack.org/#/c/334725/ (spec)

The blueprint's definition is "Approved", but the series goal is still
"Proposed for ocata".
It should be "Accepted for ocata".

Would you change it to "Accepted for ocata"?



Thanks for pointing this one out Takashi. I don't think I've ever had to 
change the series on the blueprint to get it to switch from proposed to 
accepted, at least not that I remember. Anyway, that's fixed now and 
I've added an entry to the etherpad.


I think later in the week I'm going to try and go through the etherpad 
again and start pulling things out which aren't started yet or otherwise 
don't really have a chance of getting in at this point. There are some 
others, like the one above, that are ready for review but just haven't 
gotten any serious review yet, and I'll start tagging those as needing 
review or somehow highlight those.


We may also consider having a review day on things in that etherpad next 
week. I'll mention something along those lines in the team meeting this 
week.


--

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] Planning for the Pike PTG

I haven't been living under a rock but I'm not aware of any major 
announcements regarding session planning for the PTG - has that happened 
somewhere and I'm just in the dark?


I'm mostly wondering about the Monday and Tuesday cross-project sessions 
- are those time-boxed sessions like at the summit and will have a 
schedule? Or are we just playing fast and loose and hoping someone will 
lead us out of a hallway and into a room for Major Synergy (tm)?


I see project teams are working on getting etherpads together for 
topics, including myself, which got me thinking about how to plan the 
Wed-Friday sessions which for a midcycle meetup would normally be a list 
of topics that we'd go through in order (or by priority) but not 
time-boxed or scheduled. But then I got thinking about how the PTG is 
right before we start working on Pike, so I'm now thinking we need more 
structure than what we did at the midcycles, and more like what we do at 
the design summit with respect to scheduled discussions about things 
that are going to be worked on in the upcoming release, figuring out 
goals, determining review priorities, etc - which is actually a lot more 
work to plan and schedule ahead of time, especially when we consider 
(vertical) cross-project sessions like between nova/cinder or nova/neutron.


In other words, the fact I haven't had anxiety yet about planning the 
PTG makes me anxious that I'm falling way behind already.


--

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] [nova] Planning for the Pike PTG