[openstack-dev] [elections] TC candidacy

[Ben Swartzlander]

I'd like to throw my hat in the ring for the TC election.

My name is Ben Swartzlander (bswartz on IRC) and I've been PTL for the 
Manila project for the entire life of the project. I'm also relatively 
active within the Cinder project, and I've been part of the OpenStack 
community since Essex.


My reasons for running for TC are fairly simple. There are some changes 
I'd like to see and I think that I'll have more ability to effect change 
if I'm part of the TC.


The first thing I'd like to change is that I'd like to see OpenStack 
start acting more mature. It *is* fairly mature now but in many ways we 
still have the habits of a shiny new project. I would like to see way 
less time spent on new features and much more time spent on stability 
and quality improvements.


Specifically I'd like to see dramatically more automated testing of 
stuff we already have. Not gate tests that run for every checkin but 
serious automated nightly regression style tests that actually cover 
realistic use cases and take several hours to run.


I would like to see more frequent releases. I hold up the Linux (kernel) 
project as an example to emulate. Linux releases a new major release 
about every 2 months. OpenStack has held to a 6 month release cycle for 
it's whole life but I think we can and should move to shorter cycles. In 
a similar vein I think serious effort needs to be spend on LTS (long 
term support) -- specifically the ability to upgrade across multiple 
releases without anything breaking. The deprecation policy needs to 
change if we want to get this right.


I would like to see fewer new projects and more focus on existing 
projects and possible integration between them. Long ago it was decided 
that OpenStack should be a loose federation of related projects but many 
feel that OpenStack should be a unified product. This has created a 
cognitive dissonance that pervades nearly every discussion I have about 
architectural decisions within OpenStack and I feel the TC owes this 
topic more consideration. If we decide we're all working on a single 
product then we need to change the way we act. If we affirm that we 
really are just working on a bunch of loosely related things then we 
need to disband working groups/and cross-cutting projects that are 
trying to push for uniformity.


Lastly I feel strongly about community and the Python language. I am not 
a language zealot but I know from experience that adding more 
programming languages to an existing project is ALWAYS WRONG and I will 
fight any proposal to add more programming languages to OpenStack.


I don't expect everyone to agree with my ideas but if enough of you do, 
vote me onto the TC and I'll do my best to gradually change things for 
the better.


-Ben Swartzlander

__
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] clean up your git checkout!

[Amrith Kumar]

Thanks to John and Clark Boylan for their help as I tried this setting out and 
tried to propose a change in Trove for this.

In researching this some more, I found this[1] old email thread. I would like 
to submit to you the following set of comments from Mike Bayer, Doug Hellmann 
and Sean Dague.

Mike Mayer wrote (in part),

"Short answer: if you want this feature, put PYTHONDONTWRITEBYTECODE into 
*your* environment. Don't force it on our automated tests or on my environment. 
.pyc files make a difference in behavior, and if we banish them from all 
testing, then our code is never tested within the environment that it will 
normally be run in after shipment."

Doug Hellman wrote (in part),

"I have to agree with Mike here. Cleaning up our dev environments using a 
little automation is better than disabling a feature of the interpreter that 
may have unforeseen consequences in behavior or performance. The more we 
introduce unusual settings like this into our environments and tools, the more 
edge cases and weirdness we're going to find in those tools that keep us from 
doing the work we really want to be doing."

Doug Hellman wrote (in part),

"Adding a command to tox to remove the files would be less intrusive than 
disabling their creation.

We have had bad experiences mixing features to produce unusual dev environments 
that are different from the way the software really runs. All of the issues we 
had with namespace packages were caused by a bug in that implementation exposed 
because we were doing something unusual in devstack, for example.

Adding some variation of "find $(python setup.py --name) --name '*.pyc' | xargs 
rm -f" to tox.ini before running testr solves the problem you have identified 
without introducing any side-effects."

It was this argument that led Sean Dague to amend his patch to Nova[2] from one 
that set this environment variable PYTHONDONTWRITEBYTECODE, to instead use the 
command[3]:

find . -type f -name "*.pyc" -delete

Sean wrote (in part),

"Ok, while I'm not actually convinced that PYTHONDONTWRITEBYTECODE=true is a 
problem (especially after looking at the actual source of the python 
interpreter, where it's pretty clear everything is abstracted through a set of 
AST classes regardless of whether these files are there or not), I changed my 
upstream proposal to just the same purge line we'd be using in Nova 
run_tests.sh forever before every tox run."

I submit to y'all that maybe the proposal provided in this email thread should 
be reconsidered in light of the discussion already had on the ML some years ago.

FWIW, after reading the old thread, and the comments from this email thread 
that I found, I don't believe I'll approve a change to include 
PYTHONDONTWRITEBYTECODE=1 in Trove.

Thanks,

-amrith


[1] http://openstack.markmail.org/thread/3tm4bco3mbu3hq4q
[2] https://review.openstack.org/#/c/121044/
[3] https://review.openstack.org/#/c/121044/5/tox.ini


> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com]
> Sent: Friday, September 30, 2016 5:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> 
> On Fri, Sep 30, 2016 at 12:12 PM, Amrith Kumar  wrote:
> > :)
> >
> > Clark ...
> >
> > If I git clone a brand new repository and edit the tox.ini with the
> proposed change:
> >
> >> > PYTHONDONTWRITEBYTECODE = 1
> >
> > I had assumed that no .pyc's would get created.
> 
> That is correct for 'tox' runs. Doing a: tox -e py27
> Should not generate any *.pyc files.
> 
> Feel free to post a paste.openstack.org of your modified tox.ini file.
> 
> __
> 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] [tricircle]

[joehuang]

Hello, Chandrakant,

Thank you for your interest on Tricircle.

There is no features about monitoring/inventory management yet in Tricircle.

And Tricircle is cleaning to be a project dedicated for networking automation 
across Neutron, and API gateway related function will be moved to a new project 
"Trio2o". You can refer to https://etherpad.openstack.org/p/TricircleSplitting 
for the cleaning, or track the splitting through the blueprint: 
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron

Are you interested in contributing in these projects?

Best Regards
Chaoyi Huang (joehuang)

From: Chandrakant Bagade [chandrakant_bag...@persistent.com]
Sent: 30 September 2016 20:47
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]

Hello ,

Myself Chandrakant Bagade , working at Persistent System Ltd.
I was trying Tricircle with devstack and found it , a very helpful  idea to 
datacenter management.

I can see feature like provisioning , image/vm/volume management therein.
I was wondering if features like monitoring/inventory management is also 
available there or planned for coming released. I read the docs but couldn’t 
find the information.

Can someone from Tricircle team , help me with my query. If these are available 
, then pointer/documents to those would be much appreciated.

Thanks,
Chandrakant

DISCLAIMER == This e-mail may contain privileged and confidential 
information which is the property of Persistent Systems Ltd. It is intended 
only for the use of the individual or entity to which it is addressed. If you 
are not the intended recipient, you are not authorized to read, retain, copy, 
print, distribute or use this message. If you have received this communication 
in error, please notify the sender and delete all copies of this message. 
Persistent Systems Ltd. does not accept any liability for virus infected mails.
__
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][CI] Need more undercloud resources

[Zane Bitter]

On 25/08/16 09:49, James Slagle wrote:

On Thu, Aug 25, 2016 at 5:40 AM, Derek Higgins <der...@redhat.com> wrote:

On 25 August 2016 at 02:56, Paul Belanger <pabelan...@redhat.com> wrote:

On Wed, Aug 24, 2016 at 02:11:32PM -0400, James Slagle wrote:

The latest recurring problem that is failing a lot of the nonha ssl
jobs in tripleo-ci is:

https://bugs.launchpad.net/tripleo/+bug/1616144
tripleo-ci: nonha jobs failing with Unable to establish connection to
https://192.0.2.2:13004/v1/a90407df1e7f4f80a38a1b1671ced2ff/stacks/overcloud/f9f6f712-8e89-4ea9-a34b-6084dc74b5c1

This error happens while polling for events from the overcloud stack
by tripleoclient.

I can reproduce this error very easily locally by deploying with an
ssl undercloud with 6GB ram and 2 vcpus. If I don't enable swap,
something gets OOM killed. If I do enable swap, swap gets used (< 1GB)
and then I hit this error almost every time.

The stack keeps deploying but the client has died, so the job fails.
My investigation so far has only pointed out that it's the swap
allocation that is delaying things enough to cause the failure.

We do not see this error in the ha job even though it deploys more
nodes. As of now, my only suspect is that it's the overhead of the
initial SSL connections causing the error.

If I test with 6GB ram and 4 vcpus I can't reproduce the error,
although much more swap is used due to the increased number of default
workers for each API service.

However, I suggest we just raise the undercloud specs in our jobs to
8GB ram and 4 vcpus. These seem reasonable to me because those are the
default specs used by infra in all of their devstack single and
multinode jobs spawned on all their other cloud providers. Our own
multinode job for the undercloud/overcloud and undercloud only job are
running on instances of these sizes.


Close, our current flavors are 8vCPU, 8GB RAM, 80GB HDD. I'd recommend doing
that for the undercloud just to be consistent.


The HD on most of the compute nodes are 200GB so we've been trying
really hard[1] to keep the disk usage for each instance down so that
we can fit as many instances onto each compute nodes as possible
without being restricted by the HD's. We've also allowed nova to
overcommit on storage by a factor of 3. The assumption is that all of
the instances are short lived and a most of them never fully exhaust
the storage allocated to them. Even the ones that do (the undercloud
being the one that does) hit peak at different times so everything is
tickety boo.

I'd strongly encourage against using a flavor with a 80GB HDD, if we
increase the disk space available to the undercloud to 80GB then we
will eventually be using it in CI. And 3 undercloud on the same
compute node will end up filling up the disk on that host.


I've gone ahead and made the changes to the undercloud flavor in rh1
to use 8GB ram and 4 vcpus. I left the disk at 40. I'd like to see use
the same flavor specs as the default infra flavor, but going up to
8vcpus would require configuring less workers per api service I think.
That's something we can iterate towards I think.

We should start seeing new instances coming online using the specs
from the updated undercloud flavor.


I've just completed an analysis of the memory usage of the 
gate-tripleo-ci-centos-7-ovb-nonha job as run on changes to 
tripleo-heat-templates. (Specifically, this is looking at the "used" 
column in dstat, which IIUC excludes kernel buffers and the page cache.) 
Here's the memory consumption history during the test of all 863 
successful runs of that check job:


https://zaneb.fedorapeople.org/tripleo-memory/20160930/memused.png

There was a step change to the peak usage from around 5.7GiB to around 
7.5GiB some time between a test that started at 12:47Z and one that 
started at 17:01Z on the 25th of August:


https://zaneb.fedorapeople.org/tripleo-memory/20160930/max_memused.png

For reference, the email to which I am replying was sent at 13:49Z on 
the same day.


This suggests to me that there could be some process that endeavours to 
use some large percentage (75%?) of the physical RAM on a box, and that 
short of providing absurd amounts of RAM we may always be in reach of 
the OOM killer on a box without swap. (I have no idea what process that 
might be, but MongoDB is always guilty unless proven innocent. I'm just 
saying.)


Current used memory peaks are around 7.6GiB for master, 6.8GiB for 
stable/mitaka (up from around 5.6GiB) and 6.1GiB for stable/liberty.



The phenomenon where a couple of GB get suddenly freed just before the 
end of the test seems interesting. It suggests that maybe something 
other than a daemon is using a lot of memory - python-tripleoclient 
being the obvious suspect. However a time-based analysis reveals that it 
only ever happened sporadically and only over the time course of about a 
week and a half in late August:


https://zaneb.fedorapeople.org/tripleo-memory/20160930/last_mem

[openstack-dev] [app-catalog] Barcelona summit planning

[Christopher Aedo]

Let's start noting session plans for our working sessions in
Barcelona.  I've started an etherpad here:
https://etherpad.openstack.org/p/app-catalog-ocata-summit

-Christopher

__
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] TC candidacy

[Brad Topol]

I have known Mr. Taylor for many years and I would like to come out as his
first endorser for his big league thoughts and recommendations below.


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Monty Taylor 
To: openstack-dev@lists.openstack.org
Date:   09/29/2016 07:29 PM
Subject:Re: [openstack-dev] TC candidacy



On 09/29/2016 06:14 PM, Clint Byrum wrote:
> https://review.openstack.org/379850
>
> Let's make OpenStack great again.
>
> If you don't know me, I'm very good. The code and designs I make
> are tremendous, and I intend to contribute to the TC bigly. The other
> candidates are sad, and they want OpenStack to be a third world project,
> no good.
>
> OpenStack, could be the greatest cloud in the history of clouds, but to
> get there, you need me, to make sure our clouds are the greatest. We
> need to test the clouds, I'm talking about EXTREME cloud vetting,
> EXTREME cloud vetting. You know the other TC's are laughing at us,
> because we don't have such a great TC.
>
> The biggest problem we have is people rewriting parts of OpenStack in Go.
> They're bringing threads, they're compiled, with errors handled at the
> point of return, and some of them, I assume, are good programmers. So
> when I'm elected to the TC, I will build a wall, and make Go pay for it.
>
> ...
>
> Ok if you're still reading and you don't take things too seriously,
> then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
> serve you on the OpenStack Technical Committee. You may recognize me
> from various scalability and deployment discussions.
>
> OpenStack has a number of challenges that face it in the immediate. There
> is a crisis of identity that we're only just now wrapping our arms
> around, and a question about whether or not this should be something
> decided at a centralized level by the TC or not. Are we a toobox? Are
> we a product? Can we be both?  These are real things, and the TC should
> debate them. However, I don't think the TC should force the community to
> do anything it doesn't want to do as a whole. If the community really
> wants to end the big tent, we should listen, inform, and debate, and
> decide whether or not we think it is in the best interest to do so based
> on our own expertise, the experience thus far, and a plan to go forward.
>
> It is my personal belief that the big tent has largely been a success
> for OpenStack project teams, but created a problem of confusion that we
> should resolve. The recent efforts to more clearly define OpenStack have
> been positive, and I would like to help the TC continue down that road.
>
> In fact, I have recently started an Architecture Working Group to help
> define and shape what OpenStack is at a technical design level. Whether
> pieces have been evolved apart from one another, or specifically designed
> and built to spec, OpenStack hasn't done a good job of writing some
> of those things down. I believe the Architecture Working Group will
> be capable of improving that, and I want the TC to have some of that
> influence built in.
>
> So, if you want to see more design, consensus building, and an eye for
> scaling on the TC, then please consider casting a vote for me.

I nominate this email to be the best email ever sent to an OpenStack
list. In fact, I think we should replace the entire TC with this email.
This email shall be our leader and I, for one, welcome it gladly.

__
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] clean up your git checkout!

[John Villalovos]

On Fri, Sep 30, 2016 at 12:12 PM, Amrith Kumar  wrote:
> :)
>
> Clark ...
>
> If I git clone a brand new repository and edit the tox.ini with the proposed 
> change:
>
>> > PYTHONDONTWRITEBYTECODE = 1
>
> I had assumed that no .pyc's would get created.

That is correct for 'tox' runs. Doing a: tox -e py27
Should not generate any *.pyc files.

Feel free to post a paste.openstack.org of your modified tox.ini file.

__
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][scheduler] Next Scheduler subteam meeting

[Ed Leafe]

The next meeting of the Nova Scheduler subteam will be on Monday, October 3 at 
1400 UTC in #openstack-meeting-alt
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161003T14

As always, the agenda is here: 
https://wiki.openstack.org/wiki/Meetings/NovaScheduler

Please add any items you’d like to discuss to the agenda before the meeting.


-- 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] [tripleo] Getting the UI to talk with Undercloud API service endpoints

[Dan Sneddon]

Thinking about this a little more, creating a new unified endpoint on the same 
port as the UI doesn't solve the problem at hand. The UI will use the service 
catalog to find endpoints, so we would need to change the endpoints in the 
service catalog, which changes the flow for the underlying services as well.

Simply moving the control plane services to the external network won't work 
well in environments where the control plane is isolated and non-routed. The 
Undercloud can forward packets, but then becomes a bottleneck and a SPOF. 

A few approaches come to mind, but none of these are quick fixes:

* Change the UI to get its list of endpoints from somewhere other than the 
service catalog and customize this with URLs that point to the Public VIP. 
Duplicate the services required for the UI on both control plane and external 
network. This might make it possible to make all connections over port 443, 
which is more firewall-friendly (which would be desirable or not depending on 
what kind of firewalling and traffic management is wanted).

* Relax the rp_filter settings on the Controllers so they accept packets 
destined for the external network on their control plane interfaces; add a 
static route to the Public VIP via the control plane VIP on all non-controller 
nodes. Modify the service catalog to point to the public VIP for the services 
the UI needs. This would need to be combined with a security review to 
determine if additional iptables rules are required. 

* Split the service catalog, so we have an internal and an external view 
depending on where the query came from. I'm not sure how feasible this is.

Of these, I think the rp_filter settings are the only ones that could be done 
solely with TripleO code changes. That might be worth investigating.

>> Dan Sneddon  |  Principal OpenStack Engineer  |  dsned...@redhat.com


> On Sep 30, 2016, at 11:36 AM, Dan Sneddon  wrote:
> 
> I don't think we can rely on the Undercloud as an API proxy unless we address 
> the lack of HA on the Undercloud. 
> 
> Wouldn't this be better implemented as as a single, name-based HAProxy 
> instance running SSL on port 443 on the overcloud Public VIP? Then we could 
> have the same endpoint for Horizon and every other API. 
> 
> I actually implemented this scheme in Havana before I joined Red Hat. At the 
> time, we had to have a complex HAProxy config and patch the end points to 
> support name-based URLs. I think some work has been done in OpenStack now to 
> support this model, but I'm not sure where it stands. 
> 
>>> Dan Sneddon  |  Principal OpenStack Engineer  |  dsned...@redhat.com
> 
> 
>> On Sep 30, 2016, at 9:44 AM, Dan Trainor  wrote:
>> 
>> Hi -
>> 
>> I re-read your email a few times and like a few of the things that I see, 
>> but I'd love some more clarification.  As I read it, a few of these things 
>> conflict.  I believe you're suggesting that we don't make these services 
>> listen on a public interface due to security concerns (and of course, 
>> enabling SSL would break this because haproxy would listen on these 
>> interfaces/ports), but this approach would be acceptable if HAProxy was 
>> listening on these ports, terminating SSL, and sending them to each 
>> respective service backend.  Am I correct i understanding this?
>> 
>> Are you suggesting that these endpoint ports would still be externally 
>> accessible on the primary (public) interface of the Undercloud, but just 
>> managed by HAProxy?  I think that's an acceptable approach.  Even if these 
>> endpoints are, like you suggested, listening on a separate network or IP as 
>> the Undercloud's primary interface, at least then it would be easier for 
>> organizations to enforce network access policies to these ports, and 
>> subsequently, these services that UI needs to talk to directly.
>> 
>> I'm also perfectly fine with suggesting that if UI is installed, then this 
>> forces the Undercloud to be SSL enabled.  This would be a good way to move 
>> the idea of a secured, by default SSL-enabled Undercloud forward a little 
>> more, which is something we'd definitely like to see more.
>> 
>> Thoughts?
>> 
>> Thanks
>> -dant
>> 
>> 
>> 
>>> On Thu, Sep 29, 2016 at 9:01 AM, Dan Trainor  wrote:
>>> Hi, Juan -
>>> 
 Actually, the third option is also not an option in the current undercloud 
 setup, since making the services listen in 0.0.0.0 will break HAProxy. So 
 when you're deploying with TLS things will break since we use HAProxy to 
 terminate TLS connections.
>>> 
>>> Ah, that's correct, isn't it.  
>>> 
>>>  
 On the other hand, we also don't want services to listen on 0.0.0.0 since 
 that would become a security concern. We should instead be blocking 
 everything we don't need to have exposed (as we've done with the 
 undercloud's database and rabbitmq).
>>> 
>>> I don't disagree that we want to focus on least privilege, but we do have 

Re: [openstack-dev] [neutron] clean up your git checkout!

[Amrith Kumar]

:)

Clark ...

If I git clone a brand new repository and edit the tox.ini with the proposed 
change:

> > PYTHONDONTWRITEBYTECODE = 1

I had assumed that no .pyc's would get created.

My comment is that even with this setting, .pyc's are getting created.

To get around this, what we've done thus far is to have a:

find ./trove -type f -name "*.pyc" -delete

So, it appears to me that this would have to remain even if the new proposed 
setting is added to tox.ini.

I'm NOT asking about how to recreate my existing virtualenvs and things.

-amrith

> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: Friday, September 30, 2016 3:04 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> 
> Sorry I crossed the streams but the advice is still good. Your existing
> virtualenvs already have .pycs in them so the easy way to clean that up
> is to rebuild your tox venvs using tox -r.
> 
> Clark
> 
> On Fri, Sep 30, 2016, at 12:01 PM, Amrith Kumar wrote:
> > Clark,
> >
> > I'm not sure what question you are answering but my question was more
> > about the
> >
> > PYTHONDONTWRITEBYTECODE = 1
> >
> > setting. I assumed that this meant that the .pyc's wouldn't be created.
> >
> > Did I misunderstand that?
> >
> > git clean -f -x -d
> >
> > does in fact clean out the .tox directory.
> >
> > -amrith
> >
> > > -Original Message-
> > > From: Clark Boylan [mailto:cboy...@sapwetik.org]
> > > Sent: Friday, September 30, 2016 2:50 PM
> > > To: openstack-dev@lists.openstack.org
> > > Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> > >
> > > I want to say this happens if .tox is in your gitignore list. Just run
> > > tox with the -r flag which will rebuild the tox envs.
> > >
> > > Clark
> > >
> > > On Fri, Sep 30, 2016, at 11:22 AM, Amrith Kumar wrote:
> > > > I tried that but even with it in place, a .tox directory with a ton
> of
> > > > .pyc's was left around after the test.
> > > >
> > > > I'm assuming that this is OK?
> > > >
> > > > -amrith
> > > >
> > > > > -Original Message-
> > > > > From: John Villalovos [mailto:openstack@sodarock.com]
> > > > > Sent: Friday, September 30, 2016 1:57 PM
> > > > > To: OpenStack Development Mailing List (not for usage questions)
> > > > > 
> > > > > Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> > > > >
> > > > > Projects may want to add to their tox.ini something like this:
> > > > >
> > > > >
> > >
> https://github.com/openstack/ironic/blob/c445c19285c2f3ee6a099f9f7473dd6fe
> > > > > 087116b/tox.ini#L10
> > > > >
> > > > > Basically add:
> > > > > PYTHONDONTWRITEBYTECODE = 1
> > > > >
> > > > > On Fri, Sep 30, 2016 at 7:20 AM, Ihar Hrachyshka
> 
> > > > > wrote:
> > > > > > Michał Dulko  wrote:
> > > > > >
> > > > > >> On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
> > > > > >>>
> > > > > >>> Ihar Hrachyshka  wrote:
> > > > > >>>
> > > > >  Hi all,
> > > > > 
> > > > >  today we landed https://review.openstack.org/#/c/269658/
> (huge!)
> > > that
> > > > >  removed neutron/objects/network/ directory and replaced it
> with
> > > > >  neutron/objects/network.py file. Though it makes python that
> sees
> > > old
> > > > >  .pyc files sad:
> > > > > 
> > > > >  Failed to import test module:
> > > neutron.tests.unit.objects.test_network
> > > > >  Traceback (most recent call last):
> > > > >    File
> > > > > 
> > > > >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > > > > packages/unittest2/loader.py",
> > > > >  line 456, in _find_test_path
> > > > >  module = self._get_module_from_name(name)
> > > > >    File
> > > > > 
> > > > >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > > > > packages/unittest2/loader.py",
> > > > >  line 395, in _get_module_from_name
> > > > >  __import__(name)
> > > > >    File "neutron/tests/unit/objects/test_network.py", line 23,
> in
> > > > >  
> > > > >  obj_test_base.BaseObjectIfaceTestCase):
> > > > >    File "neutron/tests/unit/objects/test_network.py", line 24,
> in
> > > > >  NetworkPortSecurityIfaceObjTestCase
> > > > >  _test_class = network.NetworkPortSecurity
> > > > >  AttributeError: 'module' object has no attribute
> > > > > 'NetworkPortSecurity'
> > > > >  The test run didn't actually run any tests
> > > > > 
> > > > >  Please run git clean -f -x in your checkout to remove all
> .pyc
> > > files.
> > > > >  This should solve any import issues you may experience due to
> the
> > > new
> > > > >  patch.
> > > > > >>>
> > > > > >>>
> > > > > >>> I hear that -f -x is not enough. Please add -d too:
> > > > > >>>
> > > > > >>> $ git clean -f -x -d
> > > > > >>>
> > > > > >>> Ihar
> > > > > >>
> > > > > >>
> > > > > 

Re: [openstack-dev] [neutron] clean up your git checkout!

[Clark Boylan]

Sorry I crossed the streams but the advice is still good. Your existing
virtualenvs already have .pycs in them so the easy way to clean that up
is to rebuild your tox venvs using tox -r.

Clark

On Fri, Sep 30, 2016, at 12:01 PM, Amrith Kumar wrote:
> Clark,
> 
> I'm not sure what question you are answering but my question was more
> about the 
> 
>   PYTHONDONTWRITEBYTECODE = 1
> 
> setting. I assumed that this meant that the .pyc's wouldn't be created.
> 
> Did I misunderstand that?
> 
>   git clean -f -x -d
> 
> does in fact clean out the .tox directory. 
> 
> -amrith
>  
> > -Original Message-
> > From: Clark Boylan [mailto:cboy...@sapwetik.org]
> > Sent: Friday, September 30, 2016 2:50 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> > 
> > I want to say this happens if .tox is in your gitignore list. Just run
> > tox with the -r flag which will rebuild the tox envs.
> > 
> > Clark
> > 
> > On Fri, Sep 30, 2016, at 11:22 AM, Amrith Kumar wrote:
> > > I tried that but even with it in place, a .tox directory with a ton of
> > > .pyc's was left around after the test.
> > >
> > > I'm assuming that this is OK?
> > >
> > > -amrith
> > >
> > > > -Original Message-
> > > > From: John Villalovos [mailto:openstack@sodarock.com]
> > > > Sent: Friday, September 30, 2016 1:57 PM
> > > > To: OpenStack Development Mailing List (not for usage questions)
> > > > 
> > > > Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> > > >
> > > > Projects may want to add to their tox.ini something like this:
> > > >
> > > >
> > https://github.com/openstack/ironic/blob/c445c19285c2f3ee6a099f9f7473dd6fe
> > > > 087116b/tox.ini#L10
> > > >
> > > > Basically add:
> > > > PYTHONDONTWRITEBYTECODE = 1
> > > >
> > > > On Fri, Sep 30, 2016 at 7:20 AM, Ihar Hrachyshka 
> > > > wrote:
> > > > > Michał Dulko  wrote:
> > > > >
> > > > >> On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
> > > > >>>
> > > > >>> Ihar Hrachyshka  wrote:
> > > > >>>
> > > >  Hi all,
> > > > 
> > > >  today we landed https://review.openstack.org/#/c/269658/ (huge!)
> > that
> > > >  removed neutron/objects/network/ directory and replaced it with
> > > >  neutron/objects/network.py file. Though it makes python that sees
> > old
> > > >  .pyc files sad:
> > > > 
> > > >  Failed to import test module:
> > neutron.tests.unit.objects.test_network
> > > >  Traceback (most recent call last):
> > > >    File
> > > > 
> > > >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > > > packages/unittest2/loader.py",
> > > >  line 456, in _find_test_path
> > > >  module = self._get_module_from_name(name)
> > > >    File
> > > > 
> > > >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > > > packages/unittest2/loader.py",
> > > >  line 395, in _get_module_from_name
> > > >  __import__(name)
> > > >    File "neutron/tests/unit/objects/test_network.py", line 23, in
> > > >  
> > > >  obj_test_base.BaseObjectIfaceTestCase):
> > > >    File "neutron/tests/unit/objects/test_network.py", line 24, in
> > > >  NetworkPortSecurityIfaceObjTestCase
> > > >  _test_class = network.NetworkPortSecurity
> > > >  AttributeError: 'module' object has no attribute
> > > > 'NetworkPortSecurity'
> > > >  The test run didn't actually run any tests
> > > > 
> > > >  Please run git clean -f -x in your checkout to remove all .pyc
> > files.
> > > >  This should solve any import issues you may experience due to the
> > new
> > > >  patch.
> > > > >>>
> > > > >>>
> > > > >>> I hear that -f -x is not enough. Please add -d too:
> > > > >>>
> > > > >>> $ git clean -f -x -d
> > > > >>>
> > > > >>> Ihar
> > > > >>
> > > > >>
> > > > >> Isn't ``find . -name \*.pyc -delete`` enough? That way you won't
> > remove
> > > > >> anything else. In Cinder we have that in tox.ini [1].
> > > > >>
> > > > >> [1]
> > > > >>
> > > > >>
> > > >
> > https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e50
> > > > 39d1748/tox.ini#L21-L21
> > > > >
> > > > >
> > > > > Actually not, because empty directories won’t be cleaned by the
> > command
> > > > you
> > > > > suggested.
> > > > >
> > > > > Ihar
> > > > >
> > > > >
> > > > >
> > > >
> > __
> > > > > 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: 

Re: [openstack-dev] [neutron] clean up your git checkout!

[Amrith Kumar]

Clark,

I'm not sure what question you are answering but my question was more about the 

PYTHONDONTWRITEBYTECODE = 1

setting. I assumed that this meant that the .pyc's wouldn't be created.

Did I misunderstand that?

git clean -f -x -d

does in fact clean out the .tox directory. 

-amrith
 
> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: Friday, September 30, 2016 2:50 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> 
> I want to say this happens if .tox is in your gitignore list. Just run
> tox with the -r flag which will rebuild the tox envs.
> 
> Clark
> 
> On Fri, Sep 30, 2016, at 11:22 AM, Amrith Kumar wrote:
> > I tried that but even with it in place, a .tox directory with a ton of
> > .pyc's was left around after the test.
> >
> > I'm assuming that this is OK?
> >
> > -amrith
> >
> > > -Original Message-
> > > From: John Villalovos [mailto:openstack@sodarock.com]
> > > Sent: Friday, September 30, 2016 1:57 PM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > 
> > > Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> > >
> > > Projects may want to add to their tox.ini something like this:
> > >
> > >
> https://github.com/openstack/ironic/blob/c445c19285c2f3ee6a099f9f7473dd6fe
> > > 087116b/tox.ini#L10
> > >
> > > Basically add:
> > > PYTHONDONTWRITEBYTECODE = 1
> > >
> > > On Fri, Sep 30, 2016 at 7:20 AM, Ihar Hrachyshka 
> > > wrote:
> > > > Michał Dulko  wrote:
> > > >
> > > >> On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
> > > >>>
> > > >>> Ihar Hrachyshka  wrote:
> > > >>>
> > >  Hi all,
> > > 
> > >  today we landed https://review.openstack.org/#/c/269658/ (huge!)
> that
> > >  removed neutron/objects/network/ directory and replaced it with
> > >  neutron/objects/network.py file. Though it makes python that sees
> old
> > >  .pyc files sad:
> > > 
> > >  Failed to import test module:
> neutron.tests.unit.objects.test_network
> > >  Traceback (most recent call last):
> > >    File
> > > 
> > >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > > packages/unittest2/loader.py",
> > >  line 456, in _find_test_path
> > >  module = self._get_module_from_name(name)
> > >    File
> > > 
> > >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > > packages/unittest2/loader.py",
> > >  line 395, in _get_module_from_name
> > >  __import__(name)
> > >    File "neutron/tests/unit/objects/test_network.py", line 23, in
> > >  
> > >  obj_test_base.BaseObjectIfaceTestCase):
> > >    File "neutron/tests/unit/objects/test_network.py", line 24, in
> > >  NetworkPortSecurityIfaceObjTestCase
> > >  _test_class = network.NetworkPortSecurity
> > >  AttributeError: 'module' object has no attribute
> > > 'NetworkPortSecurity'
> > >  The test run didn't actually run any tests
> > > 
> > >  Please run git clean -f -x in your checkout to remove all .pyc
> files.
> > >  This should solve any import issues you may experience due to the
> new
> > >  patch.
> > > >>>
> > > >>>
> > > >>> I hear that -f -x is not enough. Please add -d too:
> > > >>>
> > > >>> $ git clean -f -x -d
> > > >>>
> > > >>> Ihar
> > > >>
> > > >>
> > > >> Isn't ``find . -name \*.pyc -delete`` enough? That way you won't
> remove
> > > >> anything else. In Cinder we have that in tox.ini [1].
> > > >>
> > > >> [1]
> > > >>
> > > >>
> > >
> https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e50
> > > 39d1748/tox.ini#L21-L21
> > > >
> > > >
> > > > Actually not, because empty directories won’t be cleaned by the
> command
> > > you
> > > > suggested.
> > > >
> > > > Ihar
> > > >
> > > >
> > > >
> > >
> __
> > > > 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 

[openstack-dev] OpenStack Developer Mailing List Digest September 24-30

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/09/openstack-developer-mailing-list-digest-20160930/

Candidate Proposals for TC are now open
===
* Candidate proposals for the Technical committee (9 positions) are open and
  will remain open until 2016-10-01, 23:45 UTC.
* Candidacies must submit a text file to the openstack/election repository [1].
* Candidates for the Technical Committee can be any foundation individual
  member, except the seven TC members who were elected for a one year seat in
  April [2].
* The election will be held from October 3rd through to 23:45 October 8th.
* The electorate are foundation individual members that are committers to one of
  the official programs projects [3] over the Mitaka-Newton timeframe
  (September 5, 2015 00:00 UTC to September 4, 2016 23:59 UTC).
* Current accepted candidates [4]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104486.html


Release countdown for week R-0, 3-7 October
===
* Focus: Final release week. Most project teams should be preparing for the
  summit in Barcelona.
* General notes:
  - Release management team will tag the final Newton release on October 6th. 
-- Project teams don't have to do anything. The release management team
will re-tag the commit used in the most recent release candidate listed in
openstack/releases.
  - Projects not following the milestone model will not be re-tagged.
  - Cycle-trailing projects will be skipped until the trailing deadline.
* Release actions
  - Projects not follow the milestone-based release model who want
stable/newton branches created should talk to the release team about their
needs. Unbranched projects include:
-- cloudkitty
-- fuel
-- monasca
-- openstackansible
-- senlin
-- solum
-- tripleo
* Important dates:
  - Newton final release: October 6th
  - Newton cycle-trailing deadline: October 20th
  - Ocata Design Summit: October 24-28
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104809.html


Removal of Security and OpenStackSalt Project Teams From the Big Tent (cont.)
=
* The change to remove Astara from the big tent was approval by the TC [4].
* The TC has appointed Piet Kruithof as PTL of the UX team [5].
* Based on the thread discussion [6] and engagements of the team, the Security
  project team will be kept as is and Rob Clark continuing as PTL [7].
* The OpenStackSalt team did not produce any deliverable within the Newton
  cycle. The removal was approved by the current Salt team PTL and the TC [8].
* Full thread:
  
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#104170


[1] - http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] - https://wiki.openstack.org/wiki/TC_Elections_April_2016#Results
[3] - 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections
[4] - https://review.openstack.org/#/c/376609/
[5] - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#104170
[7] - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html
[8] - https://review.openstack.org/#/c/377906/

__
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] [release][ptl] please review versions for final newton release

[Doug Hellmann]

I have prepared a patch to openstack/releases to re-tag all of the
current release candidates using their final release version numbers.

I could use some assistance reviewing the results to ensure that I
have not left anything out and that the version numbers are all
correct.

This patch also includes a "diff-start" value for each release so
that the release announcement emails will include the full history
of a release. The values should match the tag used to create the
stable/mitaka branch for each repository (so that all of the DAG
content between that point and the tip of stable/newton are included).

Please take a few minutes between now and Thursday to look over the
deliverable file changes for your projects, and comment on the patch
if you spot anything that looks off.

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

Thanks!
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] clean up your git checkout!

[Clark Boylan]

I want to say this happens if .tox is in your gitignore list. Just run
tox with the -r flag which will rebuild the tox envs.

Clark

On Fri, Sep 30, 2016, at 11:22 AM, Amrith Kumar wrote:
> I tried that but even with it in place, a .tox directory with a ton of
> .pyc's was left around after the test.
> 
> I'm assuming that this is OK?
> 
> -amrith
> 
> > -Original Message-
> > From: John Villalovos [mailto:openstack@sodarock.com]
> > Sent: Friday, September 30, 2016 1:57 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> > 
> > Projects may want to add to their tox.ini something like this:
> > 
> > https://github.com/openstack/ironic/blob/c445c19285c2f3ee6a099f9f7473dd6fe
> > 087116b/tox.ini#L10
> > 
> > Basically add:
> > PYTHONDONTWRITEBYTECODE = 1
> > 
> > On Fri, Sep 30, 2016 at 7:20 AM, Ihar Hrachyshka 
> > wrote:
> > > Michał Dulko  wrote:
> > >
> > >> On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
> > >>>
> > >>> Ihar Hrachyshka  wrote:
> > >>>
> >  Hi all,
> > 
> >  today we landed https://review.openstack.org/#/c/269658/ (huge!) that
> >  removed neutron/objects/network/ directory and replaced it with
> >  neutron/objects/network.py file. Though it makes python that sees old
> >  .pyc files sad:
> > 
> >  Failed to import test module: neutron.tests.unit.objects.test_network
> >  Traceback (most recent call last):
> >    File
> > 
> >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > packages/unittest2/loader.py",
> >  line 456, in _find_test_path
> >  module = self._get_module_from_name(name)
> >    File
> > 
> >  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> > packages/unittest2/loader.py",
> >  line 395, in _get_module_from_name
> >  __import__(name)
> >    File "neutron/tests/unit/objects/test_network.py", line 23, in
> >  
> >  obj_test_base.BaseObjectIfaceTestCase):
> >    File "neutron/tests/unit/objects/test_network.py", line 24, in
> >  NetworkPortSecurityIfaceObjTestCase
> >  _test_class = network.NetworkPortSecurity
> >  AttributeError: 'module' object has no attribute
> > 'NetworkPortSecurity'
> >  The test run didn't actually run any tests
> > 
> >  Please run git clean -f -x in your checkout to remove all .pyc files.
> >  This should solve any import issues you may experience due to the new
> >  patch.
> > >>>
> > >>>
> > >>> I hear that -f -x is not enough. Please add -d too:
> > >>>
> > >>> $ git clean -f -x -d
> > >>>
> > >>> Ihar
> > >>
> > >>
> > >> Isn't ``find . -name \*.pyc -delete`` enough? That way you won't remove
> > >> anything else. In Cinder we have that in tox.ini [1].
> > >>
> > >> [1]
> > >>
> > >>
> > https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e50
> > 39d1748/tox.ini#L21-L21
> > >
> > >
> > > Actually not, because empty directories won’t be cleaned by the command
> > you
> > > suggested.
> > >
> > > Ihar
> > >
> > >
> > >
> > __
> > > 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] [tripleo] Getting the UI to talk with Undercloud API service endpoints

[Dan Sneddon]

I don't think we can rely on the Undercloud as an API proxy unless we address 
the lack of HA on the Undercloud. 

Wouldn't this be better implemented as as a single, name-based HAProxy instance 
running SSL on port 443 on the overcloud Public VIP? Then we could have the 
same endpoint for Horizon and every other API. 

I actually implemented this scheme in Havana before I joined Red Hat. At the 
time, we had to have a complex HAProxy config and patch the end points to 
support name-based URLs. I think some work has been done in OpenStack now to 
support this model, but I'm not sure where it stands. 

>> Dan Sneddon  |  Principal OpenStack Engineer  |  dsned...@redhat.com


> On Sep 30, 2016, at 9:44 AM, Dan Trainor  wrote:
> 
> Hi -
> 
> I re-read your email a few times and like a few of the things that I see, but 
> I'd love some more clarification.  As I read it, a few of these things 
> conflict.  I believe you're suggesting that we don't make these services 
> listen on a public interface due to security concerns (and of course, 
> enabling SSL would break this because haproxy would listen on these 
> interfaces/ports), but this approach would be acceptable if HAProxy was 
> listening on these ports, terminating SSL, and sending them to each 
> respective service backend.  Am I correct i understanding this?
> 
> Are you suggesting that these endpoint ports would still be externally 
> accessible on the primary (public) interface of the Undercloud, but just 
> managed by HAProxy?  I think that's an acceptable approach.  Even if these 
> endpoints are, like you suggested, listening on a separate network or IP as 
> the Undercloud's primary interface, at least then it would be easier for 
> organizations to enforce network access policies to these ports, and 
> subsequently, these services that UI needs to talk to directly.
> 
> I'm also perfectly fine with suggesting that if UI is installed, then this 
> forces the Undercloud to be SSL enabled.  This would be a good way to move 
> the idea of a secured, by default SSL-enabled Undercloud forward a little 
> more, which is something we'd definitely like to see more.
> 
> Thoughts?
> 
> Thanks
> -dant
> 
> 
> 
>> On Thu, Sep 29, 2016 at 9:01 AM, Dan Trainor  wrote:
>> Hi, Juan -
>> 
>>> Actually, the third option is also not an option in the current undercloud 
>>> setup, since making the services listen in 0.0.0.0 will break HAProxy. So 
>>> when you're deploying with TLS things will break since we use HAProxy to 
>>> terminate TLS connections.
>> 
>> Ah, that's correct, isn't it.  
>> 
>>  
>>> On the other hand, we also don't want services to listen on 0.0.0.0 since 
>>> that would become a security concern. We should instead be blocking 
>>> everything we don't need to have exposed (as we've done with the 
>>> undercloud's database and rabbitmq).
>> 
>> I don't disagree that we want to focus on least privilege, but we do have 
>> documentation that talks about how to deal with this.  I addressed this in 
>> my previous message, even if only to illustrate my understanding that there 
>> would be concerns around this.  See more comments about this down below...
>>  
>>> 
>>> Now, as we're trying to move to have more convergence between the 
>>> undercloud and the overcloud (trying to deploy the undercloud via heat 
>>> also, as Dan Prince has mentioned), I think some aspecs of this will bring 
>>> a solution to this problem. for instance, just like we already do in the 
>>> overcloud, we could have the undercloud's HAProxy always terminate the 
>>> endpoints, which I'm attempting with these two patches: 
>>> https://review.openstack.org/#/c/360366  
>>> https://review.openstack.org/#/c/360368 . Furthermore, we could have the 
>>> public endpoints in HAProxy listen on a separate network that's accessible 
>>> externally, also as we do in the overcloud. That way we don't need to 
>>> change the actual interfaces the services are listening on, and rely on 
>>> HAProxy, getting closer to how we do things in the overcloud. It seems to 
>>> me that it would help solve the problem.
>> 
>> I like that idea.  Though, this effectively shifts the process of having 
>> these services themselves listen on different IPs/ports and offloads that to 
>> HAProxy.  Whatever security concerns we have with opening up network 
>> communications would still exist, but I think that would be more broadly 
>> accepted considering these connections are now managed by HAProxy which 
>> *only* listens for SSL connections.  
>> 
>> Another challenge with isolating this traffic on a separate network is that 
>> we introduce a new dependency that's going to take administrative time to 
>> set up and configure outside of OpenStack - do we really want that?
>> 
>> Thanks!
>> -dant
>> 
>> 
>>  
>>> 
 On Wed, Sep 28, 2016 at 7:24 PM, Dan Trainor  wrote:
 Hi -
 
 I want to bring up a subject that needs a little 

[openstack-dev] [release][horizon] horizon Newton RC3 available

[Doug Hellmann]

Hello everyone,

A new release candidate for horizon for the end of the Newton cycle
is available!  You can find the source code tarball at:

https://tarballs.openstack.org/horizon/horizon-10.0.0.0rc3.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/horizon/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/horizon/+filebug

and tag it *newton-rc-potential* to bring it to the horizon release
crew's attention.

Thanks,
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] clean up your git checkout!

[Amrith Kumar]

I tried that but even with it in place, a .tox directory with a ton of .pyc's 
was left around after the test.

I'm assuming that this is OK?

-amrith

> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com]
> Sent: Friday, September 30, 2016 1:57 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron] clean up your git checkout!
> 
> Projects may want to add to their tox.ini something like this:
> 
> https://github.com/openstack/ironic/blob/c445c19285c2f3ee6a099f9f7473dd6fe
> 087116b/tox.ini#L10
> 
> Basically add:
> PYTHONDONTWRITEBYTECODE = 1
> 
> On Fri, Sep 30, 2016 at 7:20 AM, Ihar Hrachyshka 
> wrote:
> > Michał Dulko  wrote:
> >
> >> On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
> >>>
> >>> Ihar Hrachyshka  wrote:
> >>>
>  Hi all,
> 
>  today we landed https://review.openstack.org/#/c/269658/ (huge!) that
>  removed neutron/objects/network/ directory and replaced it with
>  neutron/objects/network.py file. Though it makes python that sees old
>  .pyc files sad:
> 
>  Failed to import test module: neutron.tests.unit.objects.test_network
>  Traceback (most recent call last):
>    File
> 
>  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> packages/unittest2/loader.py",
>  line 456, in _find_test_path
>  module = self._get_module_from_name(name)
>    File
> 
>  "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-
> packages/unittest2/loader.py",
>  line 395, in _get_module_from_name
>  __import__(name)
>    File "neutron/tests/unit/objects/test_network.py", line 23, in
>  
>  obj_test_base.BaseObjectIfaceTestCase):
>    File "neutron/tests/unit/objects/test_network.py", line 24, in
>  NetworkPortSecurityIfaceObjTestCase
>  _test_class = network.NetworkPortSecurity
>  AttributeError: 'module' object has no attribute
> 'NetworkPortSecurity'
>  The test run didn't actually run any tests
> 
>  Please run git clean -f -x in your checkout to remove all .pyc files.
>  This should solve any import issues you may experience due to the new
>  patch.
> >>>
> >>>
> >>> I hear that -f -x is not enough. Please add -d too:
> >>>
> >>> $ git clean -f -x -d
> >>>
> >>> Ihar
> >>
> >>
> >> Isn't ``find . -name \*.pyc -delete`` enough? That way you won't remove
> >> anything else. In Cinder we have that in tox.ini [1].
> >>
> >> [1]
> >>
> >>
> https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e50
> 39d1748/tox.ini#L21-L21
> >
> >
> > Actually not, because empty directories won’t be cleaned by the command
> you
> > suggested.
> >
> > Ihar
> >
> >
> >
> __
> > 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] [neutron] clean up your git checkout!

[John Villalovos]

Projects may want to add to their tox.ini something like this:

https://github.com/openstack/ironic/blob/c445c19285c2f3ee6a099f9f7473dd6fe087116b/tox.ini#L10

Basically add:
PYTHONDONTWRITEBYTECODE = 1

On Fri, Sep 30, 2016 at 7:20 AM, Ihar Hrachyshka  wrote:
> Michał Dulko  wrote:
>
>> On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
>>>
>>> Ihar Hrachyshka  wrote:
>>>
 Hi all,

 today we landed https://review.openstack.org/#/c/269658/ (huge!) that
 removed neutron/objects/network/ directory and replaced it with
 neutron/objects/network.py file. Though it makes python that sees old
 .pyc files sad:

 Failed to import test module: neutron.tests.unit.objects.test_network
 Traceback (most recent call last):
   File

 "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
 module = self._get_module_from_name(name)
   File

 "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
 __import__(name)
   File "neutron/tests/unit/objects/test_network.py", line 23, in
 
 obj_test_base.BaseObjectIfaceTestCase):
   File "neutron/tests/unit/objects/test_network.py", line 24, in
 NetworkPortSecurityIfaceObjTestCase
 _test_class = network.NetworkPortSecurity
 AttributeError: 'module' object has no attribute 'NetworkPortSecurity'
 The test run didn't actually run any tests

 Please run git clean -f -x in your checkout to remove all .pyc files.
 This should solve any import issues you may experience due to the new
 patch.
>>>
>>>
>>> I hear that -f -x is not enough. Please add -d too:
>>>
>>> $ git clean -f -x -d
>>>
>>> Ihar
>>
>>
>> Isn't ``find . -name \*.pyc -delete`` enough? That way you won't remove
>> anything else. In Cinder we have that in tox.ini [1].
>>
>> [1]
>>
>> https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e5039d1748/tox.ini#L21-L21
>
>
> Actually not, because empty directories won’t be cleaned by the command you
> suggested.
>
> Ihar
>
>
> __
> 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] Getting the UI to talk with Undercloud API service endpoints

[Dan Trainor]

Hi -

I re-read your email a few times and like a few of the things that I see,
but I'd love some more clarification.  As I read it, a few of these things
conflict.  I believe you're suggesting that we don't make these services
listen on a public interface due to security concerns (and of course,
enabling SSL would break this because haproxy would listen on these
interfaces/ports), but this approach would be acceptable if HAProxy was
listening on these ports, terminating SSL, and sending them to each
respective service backend.  Am I correct i understanding this?

Are you suggesting that these endpoint ports would still be externally
accessible on the primary (public) interface of the Undercloud, but just
managed by HAProxy?  I think that's an acceptable approach.  Even if these
endpoints are, like you suggested, listening on a separate network or IP as
the Undercloud's primary interface, at least then it would be easier for
organizations to enforce network access policies to these ports, and
subsequently, these services that UI needs to talk to directly.

I'm also perfectly fine with suggesting that if UI is installed, then this
forces the Undercloud to be SSL enabled.  This would be a good way to move
the idea of a secured, by default SSL-enabled Undercloud forward a little
more, which is something we'd definitely like to see more.

Thoughts?

Thanks
-dant



On Thu, Sep 29, 2016 at 9:01 AM, Dan Trainor  wrote:

> Hi, Juan -
>
> Actually, the third option is also not an option in the current undercloud
>> setup, since making the services listen in 0.0.0.0 will break HAProxy. So
>> when you're deploying with TLS things will break since we use HAProxy to
>> terminate TLS connections.
>>
>
> Ah, that's correct, isn't it.
>
>
>
>> On the other hand, we also don't want services to listen on 0.0.0.0 since
>> that would become a security concern. We should instead be blocking
>> everything we don't need to have exposed (as we've done with the
>> undercloud's database and rabbitmq).
>>
>
> I don't disagree that we want to focus on least privilege, but we do have
> documentation that talks about how to deal with this.  I addressed this in
> my previous message, even if only to illustrate my understanding that there
> would be concerns around this.  See more comments about this down below...
>
>
>>
>> Now, as we're trying to move to have more convergence between the
>> undercloud and the overcloud (trying to deploy the undercloud via heat
>> also, as Dan Prince has mentioned), I think some aspecs of this will bring
>> a solution to this problem. for instance, just like we already do in the
>> overcloud, we could have the undercloud's HAProxy always terminate the
>> endpoints, which I'm attempting with these two patches:
>> https://review.openstack.org/#/c/360366  https://review.openstack.org/#
>> /c/360368 . Furthermore, we could have the public endpoints in HAProxy
>> listen on a separate network that's accessible externally, also as we do in
>> the overcloud. That way we don't need to change the actual interfaces the
>> services are listening on, and rely on HAProxy, getting closer to how we do
>> things in the overcloud. It seems to me that it would help solve the
>> problem.
>>
>
> I like that idea.  Though, this effectively shifts the process of having
> these services themselves listen on different IPs/ports and offloads that
> to HAProxy.  Whatever security concerns we have with opening up network
> communications would still exist, but I think that would be more broadly
> accepted considering these connections are now managed by HAProxy which
> *only* listens for SSL connections.
>
> Another challenge with isolating this traffic on a separate network is
> that we introduce a new dependency that's going to take administrative time
> to set up and configure outside of OpenStack - do we really want that?
>
> Thanks!
> -dant
>
>
>
>
>>
>> On Wed, Sep 28, 2016 at 7:24 PM, Dan Trainor  wrote:
>>
>>> Hi -
>>>
>>> I want to bring up a subject that needs a little more attention.  There
>>> are a few ideas floating around but it's important that we get this done
>>> right.
>>>
>>> UI is unique in the sense that it operates almost entirely in a browser,
>>> talking directly to service API endpoints which it either figures out from
>>> they Keystone service catalog as using the publicURL endpoint for each
>>> service, or by specifying these API endpoints in a configuration file.
>>> Though overriding the API endpoints in the UI's local configuration file is
>>> an option that's available, I understand that we want to move towards
>>> relying exclusively on Keystone for accurate and correct endpoint
>>> configuration.
>>>
>>> Right now, all of the service API endpoints that UI needs to talk with
>>> are only listening on the ctlplane network.
>>>
>>> We've had several iterations of testing and development of the UI over
>>> time and as a result of that, three different 

Re: [openstack-dev] [nova][libvirt] Lets make libvirt's domain XML canonical

[Murray, Paul (HP Cloud)]

From: Matthew Booth
Reply-To: 
"openstack-dev@lists.openstack.org"
Date: Friday, 30 September 2016 at 17:03
To: 
"openstack-dev@lists.openstack.org"
Subject: Re: [openstack-dev] [nova][libvirt] Lets make libvirt's domain XML 
canonical

On Fri, Sep 30, 2016 at 4:38 PM, Murray, Paul (HP Cloud) 
> wrote:





On 27/09/2016, 18:12, "Daniel P. Berrange" 
> wrote:

>On Tue, Sep 27, 2016 at 10:40:34AM -0600, Chris Friesen wrote:
>> On 09/27/2016 10:17 AM, Matthew Booth wrote:
>>
>> > I think we should be able to create a domain, but once created we should 
>> > never
>> > redefine a domain. We can do adding and removing devices dynamically using
>> > libvirt's apis, secure in the knowledge that libvirt will persist this for 
>> > us.
>> > When we upgrade the host, libvirt can ensure we don't break guests which 
>> > are on
>> > it. Evacuate should be pretty much the only reason to start again.
>>
>> Sounds interesting.  How would you handle live migration?
>>
>> Currently we regenerate the XML file on the destination from the nova DB.  I
>> guess in your proposal we'd need some way of copying the XML file from the
>> source to the dest, and then modifying the appropriate segments to adjust
>> things like CPU/NUMA pinning?
>
>Use the flag VIR_MIGRATE_PERSIST_XML and libvirt will write out the
>new persistent XML on the target host automatically.

We have a problem migrating rescued instances that has a fix in progress based
on regenerating the xml on unrescue, see:

 https://blueprints.launchpad.net/nova/+spec/live-migrate-rescued-instances

That might be another case for generating the xml.

I thought it was a counter-argument (unless I've misunderstood). If you migrate 
the instance as-is without modification, you don't need to worry about whether 
it's currently a rescue instance. This problem goes away.

The major complication I can think of is things which genuinely must change 
during a migration, for example cpu pinning.

Rescue currently saves the libvirt xml in a separate file and replaces it with 
new xml to define a vm with a rescue boot disk; to unrescue it replaces the 
libvirt xml used for the rescue with the saved file to go back to the original 
state. On migration that saved xml would be lost because its an arbitrary file 
that is not handled in the migration. The spec above relies on the fact that we 
do not need to save it or copy it because we can recreate it from nova. So yes, 
the migration just works for the rescued vm, but when it is unrescued the 
original libvirt xml would be regenerated.

Paul

__
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] [release] project documentation updates not RC-worthy

[Andreas Jaeger]

On 09/30/2016 05:32 PM, Anne Gentle wrote:
> Will you backport those doc changes to stable/newton so the published
> version is accurate? Or does everyone only publish from master anyway?
> We can start working on "stable branch" publishing next, if teams want it.

We only publish from master.

And for the api-ref - since we keep compatibility - we discussed already
earlier that publishing from the branch is not really needed or desired.
Have several documents only confuses, it's an API,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: 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] [nova][libvirt] Lets make libvirt's domain XML canonical

[Matthew Booth]

On Fri, Sep 30, 2016 at 4:38 PM, Murray, Paul (HP Cloud) 
wrote:

>
>
>
>
>
> On 27/09/2016, 18:12, "Daniel P. Berrange"  wrote:
>
> >On Tue, Sep 27, 2016 at 10:40:34AM -0600, Chris Friesen wrote:
> >> On 09/27/2016 10:17 AM, Matthew Booth wrote:
> >>
> >> > I think we should be able to create a domain, but once created we
> should never
> >> > redefine a domain. We can do adding and removing devices dynamically
> using
> >> > libvirt's apis, secure in the knowledge that libvirt will persist
> this for us.
> >> > When we upgrade the host, libvirt can ensure we don't break guests
> which are on
> >> > it. Evacuate should be pretty much the only reason to start again.
> >>
> >> Sounds interesting.  How would you handle live migration?
> >>
> >> Currently we regenerate the XML file on the destination from the nova
> DB.  I
> >> guess in your proposal we'd need some way of copying the XML file from
> the
> >> source to the dest, and then modifying the appropriate segments to
> adjust
> >> things like CPU/NUMA pinning?
> >
> >Use the flag VIR_MIGRATE_PERSIST_XML and libvirt will write out the
> >new persistent XML on the target host automatically.
>
> We have a problem migrating rescued instances that has a fix in progress
> based
> on regenerating the xml on unrescue, see:
>
>  https://blueprints.launchpad.net/nova/+spec/live-migrate-
> rescued-instances
>
> That might be another case for generating the xml.
>

I thought it was a counter-argument (unless I've misunderstood). If you
migrate the instance as-is without modification, you don't need to worry
about whether it's currently a rescue instance. This problem goes away.

The major complication I can think of is things which genuinely must change
during a migration, for example cpu pinning.

Matt

-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
__
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] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Thierry Carrez]

Thierry Carrez wrote:
> As announced previously[1][2], there were no PTL candidates within the
> election deadline for a number of official OpenStack project teams:
> Astara, UX, OpenStackSalt and Security.
> 
> In the Astara case, the current team working on it would like to abandon
> the project (and let it be available for any new team who wishes to take
> it away). A change should be proposed really soon now to go in that
> direction.

The change was proposed, +1ed by past PTLs and approved by the TC
members at the last TC meeting:
https://review.openstack.org/#/c/376609/

> In the UX case, the current PTL (Piet Kruithof) very quickly reacted,
> explained his error and asked to be considered for the position for
> Ocata. The TC will officialize his nomination at the next meeting,
> together with the newly elected PTLs.

This was confirmed at the TC meeting:
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html

> That leaves us with OpenStackSalt and Security, where nobody reacted to
> the announcement that we are missing PTL candidates. [...]

Following the discussion on this thread and the engagements of the team,
the Security project team was kept as-is, with Rob Clark continuing as PTL:
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html

As hinted toward on this thread, the Salt team was removed, while the
team members there reassess their priorities. The team did not produce
any deliverable within the Newton cycle. The removal was proposed, +1ed
by the current Salt team PTL and approved by TC members:
https://review.openstack.org/#/c/377906/

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

Re: [openstack-dev] [nova][libvirt] Lets make libvirt's domain XML canonical

[Murray, Paul (HP Cloud)]

On 27/09/2016, 18:12, "Daniel P. Berrange"  wrote:

>On Tue, Sep 27, 2016 at 10:40:34AM -0600, Chris Friesen wrote:
>> On 09/27/2016 10:17 AM, Matthew Booth wrote:
>> 
>> > I think we should be able to create a domain, but once created we should 
>> > never
>> > redefine a domain. We can do adding and removing devices dynamically using
>> > libvirt's apis, secure in the knowledge that libvirt will persist this for 
>> > us.
>> > When we upgrade the host, libvirt can ensure we don't break guests which 
>> > are on
>> > it. Evacuate should be pretty much the only reason to start again.
>> 
>> Sounds interesting.  How would you handle live migration?
>> 
>> Currently we regenerate the XML file on the destination from the nova DB.  I
>> guess in your proposal we'd need some way of copying the XML file from the
>> source to the dest, and then modifying the appropriate segments to adjust
>> things like CPU/NUMA pinning?
>
>Use the flag VIR_MIGRATE_PERSIST_XML and libvirt will write out the
>new persistent XML on the target host automatically.

We have a problem migrating rescued instances that has a fix in progress based
on regenerating the xml on unrescue, see:

 https://blueprints.launchpad.net/nova/+spec/live-migrate-rescued-instances 

That might be another case for generating the xml.

Paul


>
>Regards,
>Daniel
>-- 
>|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org  -o- http://virt-manager.org :|
>|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
>
>__
>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] [release] project documentation updates not RC-worthy

[Anne Gentle]

On Fri, Sep 30, 2016 at 10:23 AM, Brian Rosmaita <
brian.rosma...@rackspace.com> wrote:

> Just want to send out a quick recap of a discussion in #openstack-meeting
> during the release team meeting this morning, in case any other projects
> are in a similar situation.
>
> As you're aware, the api-ref was moved out of docs and into the source
> code tree for each project this cycle.  Since the api-ref on openstack.org
> is published from master, my plan for Glance was to make sure all
> revisions for newton were merged into master before 6 Oct ... but I did
> not make it a priority for RC time.  Thus we have a not completely
> up-to-date api-ref in the stable/newton source tree, and this morning I
> panicked, thinking that maybe we need a new RC.
>
> The consensus was that fixing the in-tree docs is not a critical issue, so
> no new RC.  Instead, the update should be addressed later in a newton
> point release.
>
>
Thanks for communicating this point. I will add it to the API guides
contributor information for future reference.

Will you backport those doc changes to stable/newton so the published
version is accurate? Or does everyone only publish from master anyway? We
can start working on "stable branch" publishing next, if teams want it.

Anne


> cheers,
> brian
>
>
> __
> 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
>



-- 
Anne Gentle
www.justwriteclick.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] [release] project documentation updates not RC-worthy

[Ian Cordasco]

On Fri, Sep 30, 2016 at 10:23 AM, Brian Rosmaita
 wrote:
> Just want to send out a quick recap of a discussion in #openstack-meeting
> during the release team meeting this morning, in case any other projects
> are in a similar situation.
>
> As you're aware, the api-ref was moved out of docs and into the source
> code tree for each project this cycle.  Since the api-ref on openstack.org
> is published from master, my plan for Glance was to make sure all
> revisions for newton were merged into master before 6 Oct ... but I did
> not make it a priority for RC time.  Thus we have a not completely
> up-to-date api-ref in the stable/newton source tree, and this morning I
> panicked, thinking that maybe we need a new RC.
>
> The consensus was that fixing the in-tree docs is not a critical issue, so
> no new RC.  Instead, the update should be addressed later in a newton
> point release.

Thanks for keeping us all in the loop, Brian.

__
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] [release] project documentation updates not RC-worthy

[Brian Rosmaita]

Just want to send out a quick recap of a discussion in #openstack-meeting
during the release team meeting this morning, in case any other projects
are in a similar situation.

As you're aware, the api-ref was moved out of docs and into the source
code tree for each project this cycle.  Since the api-ref on openstack.org
is published from master, my plan for Glance was to make sure all
revisions for newton were merged into master before 6 Oct ... but I did
not make it a priority for RC time.  Thus we have a not completely
up-to-date api-ref in the stable/newton source tree, and this morning I
panicked, thinking that maybe we need a new RC.

The consensus was that fixing the in-tree docs is not a critical issue, so
no new RC.  Instead, the update should be addressed later in a newton
point release.

cheers,
brian


__
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] [release][ceilometer] ceilometer Newton RC3 available

[Doug Hellmann]

Hello everyone,

A new release candidate for ceilometer for the end of the Newton cycle
is available!  You can find the source code tarball at:

https://tarballs.openstack.org/ceilometer/ceilometer-7.0.0.0rc3.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/ceilometer/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *newton-rc-potential* to bring it to the ceilometer release
crew's attention.

Thanks,
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] [cinder][db] lazy loading of an attribute impossible

[Roman Podoliaka]

Michał,

You are absolutely right: this exception is raised when you try to
lazy-load instance attributes outside a Session scope. There is an
obvious problem with that - instances do not communicate with a DB on
their own - it's left up to Session [1].

Unfortunately, it does not play nicely with the "classic" DB access
layer we have in Cinder and other projects, when you have a notion of
pluggable DB APIs and SQLAlchemy implementation that looks like:

@require_context
@handle_db_data_error
def snapshot_create(context, values):
values['snapshot_metadata'] = _metadata_refs(values.get('metadata'),
 models.SnapshotMetadata)
if not values.get('id'):
values['id'] = str(uuid.uuid4())

session = get_session()
with session.begin():
snapshot_ref = models.Snapshot()
snapshot_ref.update(values)
session.add(snapshot_ref)

return _snapshot_get(context, values['id'], session=session)

In this case a Session (and transaction) scope is bound to "public" DB
API functions. There are a few problems with this:

1) once a public DB function returns an instance, it becomes prone to
lazy-load errors, as the corresponding session (and DB transaction) is
already gone and it's not possible to load missing data (without
establishing a new session/transaction)

2) you have to carefully pass a Session object when doing calls to
"private" DB API functions to ensure they all participate in the very
same DB transaction. Otherwise snapshot_get() above would not see the
row created by snapshot_create() due to isolation of transactions in
RDBMS

3) if you do multiple calls to "public" DB API functions when handling
a single HTTP request it's not longer easy to do a rollback as every
function creates its own DB transaction

Mixing of Session objects creation with the actual business logic is
considered to be an anti-pattern in SQLAlchemy [2] due to problems
mentioned above.

At this point I suggest you take a look at [3] and start using in
Cinder: in Kilo we did a complete redesign of EngineFacade in oslo.db
- it won't solve all you problems with lazy-loading automatically, but
what it can do is provide a tool for declarative definition of session
(and transaction) scope, so that it's not longer limited to one
"public" DB API function and you can extend it when needed: you no
longer create a Session object explicitly, but rather mark methods
with a decorator, that will inject a session into the context, and all
callees will participate in the established session (thus, DB
transaction) rather than create a new one (my personal opinion is that
for web-services it's preferable to bind session/transaction scope to
the scope of one HTTP request, so that it's easy to roll back changes
on errors - we are not there yet, but some projects like Nova are
already moving the session scope up the stack, e.g. to objects layer).

Thanks,
Roman

[1] 
http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#what-does-the-session-do
[2] 
http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#when-do-i-construct-a-session-when-do-i-commit-it-and-when-do-i-close-it
[3] 
https://specs.openstack.org/openstack/oslo-specs/specs/kilo/make-enginefacade-a-facade.html

On Thu, Sep 22, 2016 at 4:45 PM, Michał Dulko  wrote:
> Hi,
>
> I've just noticed another Cinder bug [1], similar to past bugs [2], [3].
> All of them have a common exception causing them:
>
> sqlalchemy.orm.exc.DetachedInstanceError: Parent instance
> <{$SQLAlchemyObject} at {$MemoryLocation}> is not bound to a Session;
> lazy load operation of attribute '{$ColumnName}' cannot proceed
>
> We've normally fixed them by simply making the $ColumnName eager-loaded,
> but as there's another similar bug report, I'm starting to think that we
> have some issue with how we're managing our DB connections and
> SQLAlchemy objects are losing their sessions too quickly, before we'll
> manage to lazy-load required stuff.
>
> I'm not too experienced with SQLAlchemy session management, so I would
> welcome any help with investigation.
>
> Thanks,
> Michal
>
>
> [1] https://bugs.launchpad.net/cinder/+bug/1626499
> [2] https://bugs.launchpad.net/cinder/+bug/1517763
> [3] https://bugs.launchpad.net/cinder/+bug/1501838
>
> __
> 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] Mirror issues with Intel NFV CI?

[Matt Riedemann]

On 9/30/2016 7:46 AM, Znoinski, Waldemar wrote:

We've fixed the subnet pools issue and left all the jobs in non-voting for 
testing yesterday. There are issues with cinder volumes highlighted by tempest 
tests but we'll skip them for the time they're being trobuleshooted and we've 
put the jobs back to voting.

Thanks


 >-Original Message-
 >From: Znoinski, Waldemar
 >Sent: Tuesday, September 27, 2016 9:27 PM
 >To: OpenStack Development Mailing List (not for usage questions)
 >
 >Subject: RE: [openstack-dev] [nova] Mirror issues with Intel NFV CI?
 >
 >Hi Matt,
 >
 >Introduction of using subnetpools in devstack [1] is causing issues like
 >'Connection to proxy timed out. ' in our setup. We are working on it and
 >will update ML soon. Thanks for pinging.
 >
 >[1] https://review.openstack.org/#/c/356026/
 >
 >
 > >-Original Message-
 > >From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
 > >Sent: Tuesday, September 27, 2016 2:34 PM
 > >To: OpenStack Development Mailing List (not for usage questions)
 >>
 > >Subject: [openstack-dev] [nova] Mirror issues with Intel NFV CI?
 > >
 > >I'm seeing a pretty high failure rate with some of the Intel NFV CI jobs
 >today,  >the pattern looks like a pypi mirror issue getting packages to setup
 >tempest:
 > >
 > >http://intel-openstack-ci-logs.ovh/94/375894/2/check/tempest-dsvm-
 >intel-
 > >nfv-xenial/a0bffb3/logs/devstacklog.txt.gz
 > >
 > >2016-09-27 02:11:52.127 | Collecting hacking<0.12,>=0.11.0 (from -r
 >>/opt/stack/new/tempest/test-requirements.txt (line 4))
 > >2016-09-27 02:12:07.144 |   Retrying (Retry(total=4, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca5b7fd10>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:12:22.654 |   Retrying (Retry(total=3, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca5b7fe10>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:12:38.657 |   Retrying (Retry(total=2, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca5b7ff10>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:12:55.674 |   Retrying (Retry(total=1, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca59e9050>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:13:14.682 |   Retrying (Retry(total=0, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca59e9150>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:13:29.687 |   Could not find a version that satisfies the
 > >requirement hacking<0.12,>=0.11.0 (from -r
 >/opt/stack/new/tempest/test-  >requirements.txt (line 4)) (from versions: )
 > >2016-09-27 02:13:29.687 | No matching distribution found for
 > >hacking<0.12,>=0.11.0 (from -r
 > >/opt/stack/new/tempest/test-requirements.txt (line 4))  >  >Is this a
 >known issue that the CI maintainers are fixing?
 > >
 > >--
 > >
 > >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
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
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



Thanks, I've noticed things got more stable, or at least less noisy, in 
the past couple of days. Thanks for being quick to address this.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List 

[openstack-dev] [tripleo] TripleO RC3

[Emilien Macchi]

We have been granted to release a last release candidate (RC3) by next
Friday (October 7th).

Please use this milestone for the bugs targeted for Newton.
https://launchpad.net/tripleo/+milestone/newton-rc3

Some reminders:
- assign the bug if you're working on it.
- update it when you can, we need to know bug status before final RC.
- use tripleo/rc3 Gerrit topic to help in reviews:
https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
- don't forget to backport patches from master to stable/newton branch
otherwise they'll not be part of the release.

By next Friday, we'll proceed to final RC, any question or feedback is
welcome, please let me or shardy know any critical blockers we might
have missed.

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

[openstack-dev] [openstack-ansible] What's Happening in OpenStack-Ansible (WHOA) - September 2016

[Major Hayden]

Hey there,

The September edition of the What's Happening in OpenStack-Ansible (WHOA) 
report is here!

  
https://major.io/2016/09/30/whats-happening-in-openstack-ansible-whoa-september-2016/

The report includes the latest developments in Liberty, Mitaka, and Newton 
along with some news about OpenStack-Ansible training from Hastexo!

Previous reports are always available via the 'whoa' tag:

  https://major.io/tag/whoa/

Please send over any feedback you have.  I wish everyone safe travels to 
Barcelona in a few weeks! :)

--
Major Hayden



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] [tripleo] os-*-config branching

[Emilien Macchi]

Just a quick FYI for TripleO team:

Until now we didn't branch os-*-config projects but since we changed
the release model to release:cycle-with-milestones, we are now
producing milestones and RCs during the cycle.
Which means we also need to start branching the projects.

So starting from newton, we'll have stable/newton based on latest Newton RC.

Any question or feedback is highly 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] [neutron] clean up your git checkout!

[Ihar Hrachyshka]

Michał Dulko  wrote:


On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:

Ihar Hrachyshka  wrote:


Hi all,

today we landed https://review.openstack.org/#/c/269658/ (huge!) that
removed neutron/objects/network/ directory and replaced it with
neutron/objects/network.py file. Though it makes python that sees old
.pyc files sad:

Failed to import test module: neutron.tests.unit.objects.test_network
Traceback (most recent call last):
  File
"/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
line 456, in _find_test_path
module = self._get_module_from_name(name)
  File
"/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name
__import__(name)
  File "neutron/tests/unit/objects/test_network.py", line 23, in

obj_test_base.BaseObjectIfaceTestCase):
  File "neutron/tests/unit/objects/test_network.py", line 24, in
NetworkPortSecurityIfaceObjTestCase
_test_class = network.NetworkPortSecurity
AttributeError: 'module' object has no attribute 'NetworkPortSecurity'
The test run didn't actually run any tests

Please run git clean -f -x in your checkout to remove all .pyc files.
This should solve any import issues you may experience due to the new
patch.


I hear that -f -x is not enough. Please add -d too:

$ git clean -f -x -d

Ihar


Isn't ``find . -name \*.pyc -delete`` enough? That way you won't remove
anything else. In Cinder we have that in tox.ini [1].

[1]
https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e5039d1748/tox.ini#L21-L21


Actually not, because empty directories won’t be cleaned by the command you  
suggested.


Ihar

__
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] clean up your git checkout!

[Michał Dulko]

On 09/30/2016 04:06 PM, Ihar Hrachyshka wrote:
> Ihar Hrachyshka  wrote:
>
>> Hi all,
>>
>> today we landed https://review.openstack.org/#/c/269658/ (huge!) that
>> removed neutron/objects/network/ directory and replaced it with
>> neutron/objects/network.py file. Though it makes python that sees old
>> .pyc files sad:
>>
>> Failed to import test module: neutron.tests.unit.objects.test_network
>> Traceback (most recent call last):
>>   File
>> "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
>> line 456, in _find_test_path
>> module = self._get_module_from_name(name)
>>   File
>> "/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
>> line 395, in _get_module_from_name
>> __import__(name)
>>   File "neutron/tests/unit/objects/test_network.py", line 23, in
>> 
>> obj_test_base.BaseObjectIfaceTestCase):
>>   File "neutron/tests/unit/objects/test_network.py", line 24, in
>> NetworkPortSecurityIfaceObjTestCase
>> _test_class = network.NetworkPortSecurity
>> AttributeError: 'module' object has no attribute 'NetworkPortSecurity'
>> The test run didn't actually run any tests
>>
>> Please run git clean -f -x in your checkout to remove all .pyc files.
>> This should solve any import issues you may experience due to the new
>> patch.
>
> I hear that -f -x is not enough. Please add -d too:
>
> $ git clean -f -x -d
>
> Ihar
>

Isn't ``find . -name \*.pyc -delete`` enough? That way you won't remove
anything else. In Cinder we have that in tox.ini [1].

[1]
https://github.com/openstack/cinder/blob/792108f771607b75a25e9c4cfaaa26e5039d1748/tox.ini#L21-L21

__
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] clean up your git checkout!

[Ihar Hrachyshka]

Ihar Hrachyshka  wrote:


Hi all,

today we landed https://review.openstack.org/#/c/269658/ (huge!) that  
removed neutron/objects/network/ directory and replaced it with  
neutron/objects/network.py file. Though it makes python that sees old  
.pyc files sad:


Failed to import test module: neutron.tests.unit.objects.test_network
Traceback (most recent call last):
  File 
"/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "neutron/tests/unit/objects/test_network.py", line 23, in 
obj_test_base.BaseObjectIfaceTestCase):
  File "neutron/tests/unit/objects/test_network.py", line 24, in 
NetworkPortSecurityIfaceObjTestCase
_test_class = network.NetworkPortSecurity
AttributeError: 'module' object has no attribute 'NetworkPortSecurity'
The test run didn't actually run any tests

Please run git clean -f -x in your checkout to remove all .pyc files.  
This should solve any import issues you may experience due to the new  
patch.


I hear that -f -x is not enough. Please add -d too:

$ git clean -f -x -d

Ihar

__
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] clean up your git checkout!

[Ihar Hrachyshka]

Hi all,

today we landed https://review.openstack.org/#/c/269658/ (huge!) that  
removed neutron/objects/network/ directory and replaced it with  
neutron/objects/network.py file. Though it makes python that sees old .pyc  
files sad:


Failed to import test module: neutron.tests.unit.objects.test_network
Traceback (most recent call last):
  File 
"/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/home/vagrant/git/neutron/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "neutron/tests/unit/objects/test_network.py", line 23, in 
obj_test_base.BaseObjectIfaceTestCase):
  File "neutron/tests/unit/objects/test_network.py", line 24, in 
NetworkPortSecurityIfaceObjTestCase
_test_class = network.NetworkPortSecurity
AttributeError: 'module' object has no attribute 'NetworkPortSecurity'
The test run didn't actually run any tests

Please run git clean -f -x in your checkout to remove all .pyc files. This  
should solve any import issues you may experience due to the new patch.


Cheers,
Ihar

__
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] ARP spoofing in VLAN aware VMs

[Jakub Libosvar]

Hi all,

I promised Armando a braindump of this issue so here it comes:
During my work on fullstack test for VLAN aware VMs I ran into issues 
with ARP spoofing. The issue was with subports having different MAC 
addresses than MAC address of the parent port. Packets leaving virtual 
instance via VLAN interfaces (e.g. eth0.1) have always source MAC 
address of VLAN parent interface (e.g. eth0).


This doesn't play nice when arp spoofing from OVS agent is used.

For example here parent port has MAC fa:16:3e:8d:4d:45 and VLAN 
interface has fa:16:3e:8d:5d:13. Trunk patch port is port 2 and subport 
patch port is 3. Tagged outgoing packet from VM will have source MAC set 
to fa:16:3e:8d:4d:45 but will come to integration bridge from port 3. 
And thus marked rule below won't get matched.


 cookie=0xa849678518c226b1, duration=545.317s, table=24, n_packets=2, 
n_bytes=92, idle_age=530, priority=2,arp,in_port=3,arp_spa=192.168.0.11 
actions=resubmit(,25)
 cookie=0xa849678518c226b1, duration=545.080s, table=24, n_packets=4, 
n_bytes=168, idle_age=531, priority=2,arp,in_port=2,arp_spa=10.0.0.3 
actions=resubmit(,25)
 cookie=0xa849678518c226b1, duration=554.554s, table=24, n_packets=5, 
n_bytes=230, idle_age=525, priority=0 actions=drop


 cookie=0xa849678518c226b1, duration=545.437s, table=25, n_packets=0, 
n_bytes=546, idle_age=530, priority=2,in_port=3,dl_src=fa:16:3e:8d:5d:13 
actions=NORMAL<--- This rule won't be matched.
 cookie=0xa849678518c226b1, duration=545.204s, table=25, n_packets=19, 
n_bytes=1430, idle_age=520, 
priority=2,in_port=2,dl_src=fa:16:3e:8d:4d:45 actions=NORMAL



The current fullstack test creates all ports attached to VM with the 
same MAC addresses and it works fine. But this doesn't work fine when 
OVS firewall is used as it contains a bug [1][2] where there can't be 
two same MAC addresses from different network used on a single hypervisor.



There was a second issue with port binding race but that turned up to be 
PEBKAC as update_port() was called before OVS port has been created.


Kuba

[1] https://bugs.launchpad.net/neutron/+bug/1626010
[2] https://bugs.launchpad.net/neutron/+bug/1593760

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

[Chandrakant Bagade]

Hello ,

Myself Chandrakant Bagade , working at Persistent System Ltd.
I was trying Tricircle with devstack and found it , a very helpful  idea to 
datacenter management.

I can see feature like provisioning , image/vm/volume management therein.
I was wondering if features like monitoring/inventory management is also 
available there or planned for coming released. I read the docs but couldn't 
find the information.

Can someone from Tricircle team , help me with my query. If these are available 
, then pointer/documents to those would be much appreciated.

Thanks,
Chandrakant

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Ltd. does not accept any liability for virus infected mails.

__
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] Mirror issues with Intel NFV CI?

[Znoinski, Waldemar]

We've fixed the subnet pools issue and left all the jobs in non-voting for 
testing yesterday. There are issues with cinder volumes highlighted by tempest 
tests but we'll skip them for the time they're being trobuleshooted and we've 
put the jobs back to voting.

Thanks


 >-Original Message-
 >From: Znoinski, Waldemar
 >Sent: Tuesday, September 27, 2016 9:27 PM
 >To: OpenStack Development Mailing List (not for usage questions)
 >
 >Subject: RE: [openstack-dev] [nova] Mirror issues with Intel NFV CI?
 >
 >Hi Matt,
 >
 >Introduction of using subnetpools in devstack [1] is causing issues like
 >'Connection to proxy timed out. ' in our setup. We are working on it and
 >will update ML soon. Thanks for pinging.
 >
 >[1] https://review.openstack.org/#/c/356026/
 >
 >
 > >-Original Message-
 > >From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
 > >Sent: Tuesday, September 27, 2016 2:34 PM
 > >To: OpenStack Development Mailing List (not for usage questions)
 >>
 > >Subject: [openstack-dev] [nova] Mirror issues with Intel NFV CI?
 > >
 > >I'm seeing a pretty high failure rate with some of the Intel NFV CI jobs
 >today,  >the pattern looks like a pypi mirror issue getting packages to setup
 >tempest:
 > >
 > >http://intel-openstack-ci-logs.ovh/94/375894/2/check/tempest-dsvm-
 >intel-
 > >nfv-xenial/a0bffb3/logs/devstacklog.txt.gz
 > >
 > >2016-09-27 02:11:52.127 | Collecting hacking<0.12,>=0.11.0 (from -r
 >>/opt/stack/new/tempest/test-requirements.txt (line 4))
 > >2016-09-27 02:12:07.144 |   Retrying (Retry(total=4, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca5b7fd10>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:12:22.654 |   Retrying (Retry(total=3, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca5b7fe10>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:12:38.657 |   Retrying (Retry(total=2, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca5b7ff10>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:12:55.674 |   Retrying (Retry(total=1, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca59e9050>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:13:14.682 |   Retrying (Retry(total=0, connect=None,
 > >read=None, redirect=None)) after connection broken by
 >>'ConnectTimeoutError(V
 > >erifiedHTTPSConnection
 > >object at 0x7faca59e9150>, 'Connection to proxy.ir.intel.com timed out.
 > >(connect timeout=15)')': /simple/hacking/
 > >2016-09-27 02:13:29.687 |   Could not find a version that satisfies the
 > >requirement hacking<0.12,>=0.11.0 (from -r
 >/opt/stack/new/tempest/test-  >requirements.txt (line 4)) (from versions: )
 > >2016-09-27 02:13:29.687 | No matching distribution found for
 > >hacking<0.12,>=0.11.0 (from -r
 > >/opt/stack/new/tempest/test-requirements.txt (line 4))  >  >Is this a
 >known issue that the CI maintainers are fixing?
 > >
 > >--
 > >
 > >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
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
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][cinder] reason(s) for not booting instances from (bootable) volumes

[Matthew Booth]

Nothing architectural that I can think of, we just don't support it.
Rebuild current takes an image, but I guess it could reasonable take most
of the arguments to spawn. We'd have to think hard about what it meant for
arguments to be present/omitted, i.e. are we specifying new disks, or
redefining old ones, but if the intent could be represented in the api it
could certainly be implemented.

Matt

On Fri, Sep 30, 2016 at 12:32 PM, Tikkanen, Viktor (Nokia - FI/Espoo) <
viktor.tikka...@nokia.com> wrote:

> Hi!
>
> I refer here to my question sent earlier to AskOpenstack:
>
> https://ask.openstack.org/en/question/97425/why-it-is-not-
> possible-to-rebuild-an-instance-from-a-bootable-volume/
>
> Are there some (architectural, performance, security etc.) reasons why
> rebuilding instances from (bootable) volumes is not implemented/supported?
>
> -Viktor
>
> __
> 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
>



-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
__
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] TC Candidacy

[Monty Taylor]

I would like to serve the community on the Technical Committee again.

For those of you who don't know me:

* I've served on the TC since it was the PPB.

* I founded and am past-PTL of OpenStack Infra.

* I also serve on the OpenStack Board of Directors as an Individual
Member, which is a position I've held since the formation of the Foundation.

Our culture and our commonality define us and draw us together, and
that's a good thing. We are one of the world's most successful Open
Source projects. The reason we're so successful is that we've always
valued the we over the I. We've always made choices that maxmize our
ability to work with each other, even if those choices might dimish the
ability of some 'Brilliant Jerk' to amaze us with their brilliance and
just how big of a jerk they can be.

We should continue to hold strong to our idea of an environment where
we're all equal, where we can all work together regardless of background
and where collaboration is valued in its own right.

** OpenStack is One Project. **

Together we are much greater than the sum of our parts. It's vital that
we all understand that and actively look for ways to work together. It's
hard, of course. It's much easier to hunker down with a few close
friends and shut out all the noise as distraction. However, our primary
advantage is that there are a lot of us, and that we work together. The
world is replete with projects that are tightly controlled by a single
person or a single company. We're different, and it can give us
strength. But it will only be a strength when we all pull together and
actively look for ways in which we can align with each other, rather
than looking for legalistic lists of ways in which we are required to.

As our community is one of our greatest strengths, we need to become
better at being steadfast in our adherence to each other. When our
friends get tired and decide that all of this community crap is too
hard, we need to provide them support and help them to understand that
not only is the community part not a waste of time, it is, in fact, one
of the most important aspects of who we are.

** OpenStack delivers computers via an API, not VMs. **

Any positioning that our primary unit of operation is a VM is antiquated
and wrong. Bare metal, VMs and Containers are all essential building
blocks - and more importantly each of those being able to exist in a
shared networking context able to access the same storage resources is
the ballgame. Any time any part of our community wants to suggest that
one of the three have primacy over the others, we need to lovingly but
firmly put our foot down and stand up for our users.

We are not in competition with Kubernetes, Mesos or Docker. They're all
wonderful projects that solve problems for their users. All three of
them need to run on an Infrastructure. We should be the friendliest
Infrastructure for them.

** Success is defined by empowering our Users to solve their problems. **

OpenStack has IPv6 support. None of the closed-source Public Clouds do.
We should be more proud of that. OpenStack can give you a direct L2 IP
that isn't forced to pass through a NAT layer. None of the closed-source
Public Clouds can do that. Oracle just announced that as an "exciting"
thing that would set their new Public Cloud apart. It's not exciting,
it's basic functionality that the other clouds lack, and they're late to
the party. We've had it for years, and we should be proud of that. We
should not chase mediocrity by accepting the premise that the feature
definitions in a set of existing closed-source Public Clouds are the
gospel. We should instead empower our end-users by putting the tools of
computing that they actually want in their hands, not just the tools
someone else thinks they should want.

NAT is a hack, it's not a feature. We should treat it as the lame
second-class citizen it truly is, and we should make all the other
clouds who are not us ashamed that it's the only crappy networking they
give their users. We should continue to love our users.

** The world is a really big place with a bunch of really wonderful
people. **

We have OpenStack Public Clouds all over the world, in more geographical
locations than any of the closed-source Public Clouds. We should all be
proud of that. There is not a US-centric single giant OpenStack Public
Cloud ... but that's a good thing, not a failure. Single clouds are
single points of failure, both from a technology standpoint and from a
'random executive has an agenda' standpoint. An ecosystem of clouds
running the same software but run by different operators with different
needs and goals is an ecosystem we should all be proud of - and we can
be proud of that today.

We have grassroots OpenStack communities world-wide full of amazing
people. We have people all over the world who are solving problems with
OpenStack. We should all be proud of that.

** There are still plenty of challenges ahead of us. **

The end user experience with 

Re: [openstack-dev] [ceilometer] [Congress] ceilometer client `alarms.list()` HTTPException (HTTP N/A)

[Eric K]

Got it. Thanks for the refresher.Maybe it got re-enabled in the switch to 
support lazy polling.
If you get a chance, would you mind disabling it again for Newton?



_
From: Anusha Ramineni 
Sent: Friday, September 30, 2016 4:26 AM
Subject: Re: [openstack-dev] [ceilometer] [Congress] ceilometer client 
`alarms.list()` HTTPException (HTTP N/A)
To: Eric K , OpenStack Development Mailing List (not 
for usage questions) 


Hi Eric,
alarm list is not working from before. I have disabled the same in Mitaka 
https://review.openstack.org/#/c/254650/We need to support Aodh to get it 
working I suppose 
(https://blueprints.launchpad.net/congress/+spec/add-aodh-datasource-driver)

Best Regards,Anusha
On 29 September 2016 at 19:28, Julien Danjou  wrote:
On Mon, Sep 26 2016, Eric K wrote:

> On a fresh devstack install with ceilometer clients version 2.6.1,
> client.alarms.list() errors when other things (like client.events.list())
> succeeds.

Do you have Aodh installed?
Why not switching to aodhclient?

--
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info

__
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][cinder] reason(s) for not booting instances from (bootable) volumes

[Tikkanen, Viktor (Nokia - FI/Espoo)]

Hi!

I refer here to my question sent earlier to AskOpenstack:

https://ask.openstack.org/en/question/97425/why-it-is-not-possible-to-rebuild-an-instance-from-a-bootable-volume/

Are there some (architectural, performance, security etc.) reasons why 
rebuilding instances from (bootable) volumes is not implemented/supported?

-Viktor

__
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] [ceilometer] [Congress] ceilometer client `alarms.list()` HTTPException (HTTP N/A)

[Anusha Ramineni]

Hi Eric,

alarm list is not working from before.
I have disabled the same in Mitaka https://review.openstack.org/#/c/254650/
We need to support Aodh to get it working I suppose (
https://blueprints.launchpad.net/congress/+spec/add-aodh-datasource-driver)


Best Regards,
Anusha

On 29 September 2016 at 19:28, Julien Danjou  wrote:

> On Mon, Sep 26 2016, Eric K wrote:
>
> > On a fresh devstack install with ceilometer clients version 2.6.1,
> > client.alarms.list() errors when other things (like client.events.list())
> > succeeds.
>
> Do you have Aodh installed?
> Why not switching to aodhclient?
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
>
> __
> 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] notifications: searching for an optimal solution

[Yuriy Zveryanskyy]

Hi,

If you interested in ironic notifications
welcome to the discussion on

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

Should we limit CRUD notifications to CRUD API requests?
What ironic node's fields set should be in CRUD notifications?
Your opinion is important for us.

Yuriy Zveryanskyy



__
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] [telemetry] Barcelona summit session proposals

[Julien Danjou]

Hi team,

It's time to propose your session ideas at:
  https://etherpad.openstack.org/p/ocata-telemetry-summit-planning

Be reminded that we he have 5 slots allocated.

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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] [ironic] Next API meeting cancelled

[Dmitry Tantsur]

On 09/22/2016 05:38 PM, Jim Rollenhagen wrote:

We decided in the last meeting to cancel next week's meeting. So we'll
meet again October 4.

Side question: should we just make this meeting biweekly always?


+1 for biweekly. This way I'll maybe find courage to stay until 9pm :)



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




__
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] [charms] 16.10 release feature freeze

[James Page]

Hi Charmers

Just a reminder that as of the end of yesterday, we're in feature freeze
for the 16.10 charm release in two weeks time;  if you have a compelling
feature that you feel should be considered, please email openstack-dev with
a request for a freeze exception with details of the change (and preferably
a link to the review(s) as well).

Cheers

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