Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

2014-11-16 Thread Irena Berezovsky
Hi Steve,
Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal node 
with Mellanox SR-IOV NIC.  This job is reporting on neutron patches. Currently 
API tests are executed. 
The contact person for SRIOV CI job is listed at driverlog:
https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1439

The following items are in progress:
 - SR-IOV functional testing 
 - Reporting CI job on nova patches
 - Multi-node setup
It worth to mention that we   want to start the collaboration on SR-IOV testing 
effort as part of the pci pass-through subteam activity.
Please join the weekly meeting if you want to collaborate or have some inputs: 
https://wiki.openstack.org/wiki/Meetings/Passthrough

BR,
Irena

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com] 
Sent: Wednesday, November 12, 2014 9:11 PM
To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells); Irena 
Berezovsky; ba...@cisco.com
Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List (not for 
usage questions)
Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other 
features that can't be tested on current infra.

Hi all,

We had some discussions last week - particularly in the Nova NFV design session 
[1] - on the subject of ensuring that telecommunications and NFV-related 
functionality has adequate continuous integration testing. In particular the 
focus here is on functionality that can't easily be tested on the public clouds 
that back the gate, including:

- NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device locality)
- SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)
  
In each case we need to confirm where we are at, and the plan going forward, 
with regards to having:

1) Hardware to run the CI on.
2) Tests that actively exercise the functionality (if not already in existence).
3) Point person for each setup to maintain it and report into the third-party 
meeting [2].
4) Getting the jobs operational and reporting [3][4][5][6].

In the Nova session we discussed a goal of having the hardware by K-1 (Dec 18) 
and having it reporting at least periodically by K-2 (Feb 5). I'm not sure if 
similar discussions occurred on the Neutron side of the design summit.

SR-IOV
==

Adrian and Irena mentioned they were already in the process of getting up to 
speed with third party CI for their respective SR-IOV configurations. Robert 
are you attempting similar with regards to Cisco devices? What is the status of 
each of these efforts versus the four items I lifted above and what do you need 
assistance with?

NUMA


We still need to identify some hardware to run third party CI for the 
NUMA-related work, and no doubt other things that will come up. It's expected 
that this will be an interim solution until OPNFV resources can be used (note 
cdub jokingly replied 1-2 years when asked for a rough estimate - I mention 
this because based on a later discussion some people took this as a serious 
estimate).

Ian did you have any luck kicking this off? Russell and I are also endeavouring 
to see what we can do on our side w.r.t. this short term approach - in 
particular if you find hardware we still need to find an owner to actually 
setup and manage it as discussed.

In theory to get started we need a physical multi-socket box and a virtual 
machine somewhere on the same network to handle job control etc. I believe the 
tests themselves can be run in VMs (just not those exposed by existing public 
clouds) assuming a recent Libvirt and an appropriately crafted Libvirt XML that 
ensures the VM gets a multi-socket topology etc. (we can assist with this).

Thanks,

Steve

[1] https://etherpad.openstack.org/p/kilo-nova-nfv
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] http://ci.openstack.org/third_party.html
[4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
[5] 
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
[6] 
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] A mascot for Ironic

2014-11-16 Thread Chris K
How cute.

maybe we could call him bear-thoven.

Chris


On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes lucasago...@gmail.com
wrote:

 Hi Ironickers,

 I was thinking this weekend: All the cool projects does have a mascot
 so I thought that we could have one for Ironic too.

 The idea about what the mascot would be was easy because the RAX guys
 put bear metal their presentation[1] and that totally rocks! So I
 drew a bear. It also needed an instrument, at first I thought about a
 guitar, but drums is actually my favorite instrument so I drew a pair
 of drumsticks instead.

 The drawing thing wasn't that hard, the problem was to digitalize it.
 So I scanned the thing and went to youtube to watch some tutorials
 about gimp and inkspace to learn how to vectorize it. Magic, it
 worked!

 Attached in the email there's the original draw, the vectorized
 version without colors and the final version of it (with colors).

 Of course, I know some people does have better skills than I do, so I
 also attached the inkspace file of the final version in case people
 want to tweak it :)

 So, what you guys think about making this little drummer bear the
 mascot of the Ironic project?

 Ahh he also needs a name. So please send some suggestions and we can
 vote on the best name for him.

 [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90

 Lucas

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


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


Re: [openstack-dev] Solving the client libs stable support dilemma

2014-11-16 Thread Doug Hellmann

On Nov 15, 2014, at 5:50 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 During the Kilo design summit session on Oslo versioning changes, we
 mostly resolved to switch to semver without alphas and pin stable
 branch libs to less than the next nontrivial version number
 (allowing for backports to fix bugs with subsequent point releases
 on a stable branch when needed). This however raises a question for
 other library dependencies, including dependencies on client
 libraries.
 
 Specifically, if we're going to limit the Oslo libraries consumed by
 stable branches of integrated release servers (bear in mind we
 already do this in one way by declaring they can't suddenly start
 requiring new dependencies), then how does that play out when we
 allow client libraries which are also dependencies of our stable
 release servers to depend on later versions of (or for that matter
 additional) Oslo libs?
 
 It seems likely we need to apply a similar versioning and branching
 model across our client libraries to address this, but this raises
 the end-user/app-dev interoperability concern we discuss from time
 to time: with a recent enough client library, you should be able to
 interact with multiple OpenStack deployments made from different
 integrated releases (or non-releases, continuous deployment, et al).
 
 The challenge, then, is to test interactions using our client
 libraries under development against older stable servers while
 installing those stable servers using different, older versions of
 the same client libraries. Perhaps something similar to how
 devstack+tempest jobs install devstack/server requirements globally
 on the system but then tempest requirements are installed separately
 into a virtualenv?

So we would pin the client libraries used by the servers and installed 
globally, but then install the more recent client libraries in a virtualenv and 
test using those versions? I like that.

Doug

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


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


Re: [openstack-dev] [Ironic] A mascot for Ironic

2014-11-16 Thread Assaf Muller


- Original Message -
 Hi Ironickers,
 
 I was thinking this weekend: All the cool projects does have a mascot
 so I thought that we could have one for Ironic too.
 
 The idea about what the mascot would be was easy because the RAX guys
 put bear metal their presentation[1] and that totally rocks! So I
 drew a bear. It also needed an instrument, at first I thought about a
 guitar, but drums is actually my favorite instrument so I drew a pair
 of drumsticks instead.
 
 The drawing thing wasn't that hard, the problem was to digitalize it.
 So I scanned the thing and went to youtube to watch some tutorials
 about gimp and inkspace to learn how to vectorize it. Magic, it
 worked!
 
 Attached in the email there's the original draw, the vectorized
 version without colors and the final version of it (with colors).
 
 Of course, I know some people does have better skills than I do, so I
 also attached the inkspace file of the final version in case people
 want to tweak it :)
 
 So, what you guys think about making this little drummer bear the
 mascot of the Ironic project?
 

Totally awesome.

 Ahh he also needs a name. So please send some suggestions and we can
 vote on the best name for him.
 

Metal is kind of obvious.

What would it take for you to give Neutron a mascot as well? We need all
the PR we can get :)

 [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
 
 Lucas
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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


Re: [openstack-dev] Solving the client libs stable support dilemma

2014-11-16 Thread Jeremy Stanley
On 2014-11-16 09:06:02 -0500 (-0500), Doug Hellmann wrote:
 So we would pin the client libraries used by the servers and
 installed globally, but then install the more recent client
 libraries in a virtualenv and test using those versions?

That's what I was thinking anyway, yes.

 I like that.

Honestly I don't, but it sucks less than the other solutions which
sprang to mind. Hopefully someone will come along with a more
elegant suggestion... in the meantime I don't see any obvious
reasons why it wouldn't work.
-- 
Jeremy Stanley

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


Re: [openstack-dev] Solving the client libs stable support dilemma

2014-11-16 Thread Doug Hellmann

On Nov 16, 2014, at 9:54 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2014-11-16 09:06:02 -0500 (-0500), Doug Hellmann wrote:
 So we would pin the client libraries used by the servers and
 installed globally, but then install the more recent client
 libraries in a virtualenv and test using those versions?
 
 That's what I was thinking anyway, yes.
 
 I like that.
 
 Honestly I don't, but it sucks less than the other solutions which
 sprang to mind. Hopefully someone will come along with a more
 elegant suggestion... in the meantime I don't see any obvious
 reasons why it wouldn't work.

Really, it’s a much more accurate test of what we want. We have, as an artifact 
of our test configuration, to install everything on a single box. But what 
we’re trying to test is that a user can install the new clients and talk to an 
old cloud. We don’t expect deployers of old clouds to install new clients — at 
least we shouldn’t, and by pinning the requirements we can make that clear. 
Using the virtualenv for the new clients gives us separation between the “user” 
and “cloud” parts of the test configuration that we don’t have now.

Anyway, if we’re prepared to go along with this I think it’s safe for us to 
stop using alpha version numbers for Oslo libraries as a matter of course. We 
may still opt to do it in cases where we aren’t sure of a new API or feature, 
but we won’t have to do it for every release.

Doug

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


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


Re: [openstack-dev] [Ironic] A mascot for Ironic

2014-11-16 Thread Peeyush Gupta
It's awesome. How about IRONicBEAR?
On 11/16/2014 06:44 PM, Lucas Alvares Gomes wrote:
 Hi Ironickers,

 I was thinking this weekend: All the cool projects does have a mascot
 so I thought that we could have one for Ironic too.

 The idea about what the mascot would be was easy because the RAX guys
 put bear metal their presentation[1] and that totally rocks! So I
 drew a bear. It also needed an instrument, at first I thought about a
 guitar, but drums is actually my favorite instrument so I drew a pair
 of drumsticks instead.

 The drawing thing wasn't that hard, the problem was to digitalize it.
 So I scanned the thing and went to youtube to watch some tutorials
 about gimp and inkspace to learn how to vectorize it. Magic, it
 worked!

 Attached in the email there's the original draw, the vectorized
 version without colors and the final version of it (with colors).

 Of course, I know some people does have better skills than I do, so I
 also attached the inkspace file of the final version in case people
 want to tweak it :)

 So, what you guys think about making this little drummer bear the
 mascot of the Ironic project?

 Ahh he also needs a name. So please send some suggestions and we can
 vote on the best name for him.

 [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90

 Lucas


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

-- 
Peeyush Gupta
gpeey...@linux.vnet.ibm.com

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


Re: [openstack-dev] [Ironic] A mascot for Ironic

2014-11-16 Thread David Shrewsbury

 On Nov 16, 2014, at 8:57 AM, Chris K nobody...@gmail.com wrote:
 
 How cute.
 
 maybe we could call him bear-thoven.
 
 Chris
 

I like Blaze Bearly, lead singer for Ironic Maiden.  :)

https://en.wikipedia.org/wiki/Blaze_Bayley 
https://en.wikipedia.org/wiki/Blaze_Bayley


 
 On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes lucasago...@gmail.com 
 mailto:lucasago...@gmail.com wrote:
 Hi Ironickers,
 
 I was thinking this weekend: All the cool projects does have a mascot
 so I thought that we could have one for Ironic too.
 
 The idea about what the mascot would be was easy because the RAX guys
 put bear metal their presentation[1] and that totally rocks! So I
 drew a bear. It also needed an instrument, at first I thought about a
 guitar, but drums is actually my favorite instrument so I drew a pair
 of drumsticks instead.
 
 The drawing thing wasn't that hard, the problem was to digitalize it.
 So I scanned the thing and went to youtube to watch some tutorials
 about gimp and inkspace to learn how to vectorize it. Magic, it
 worked!
 
 Attached in the email there's the original draw, the vectorized
 version without colors and the final version of it (with colors).
 
 Of course, I know some people does have better skills than I do, so I
 also attached the inkspace file of the final version in case people
 want to tweak it :)
 
 So, what you guys think about making this little drummer bear the
 mascot of the Ironic project?
 
 Ahh he also needs a name. So please send some suggestions and we can
 vote on the best name for him.
 
 [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90 
 http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
 
 Lucas
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Thomas Goirand
On 11/15/2014 06:27 AM, Gabriel Hurley wrote:
 So, I propose that a group gets together and defines criteria:
 we need to accept that the Horizon team (and those knowledgeable
 about web-app development) know best what tools they need, and
 they need to produce such a list as a starting point. We then
 need packagers and maintainers to examine that list and evaluate
 it for problems (non-free software, irresolvable dependencies,
 etc.). They're looking strictly for things which are un-packageable,
 not commenting on the necessity of said software. And we need people
 (thanks, Monty) willing to build new tools to find a way to turn
 that list into something the package maintainers can consume
 without burdening either side.
 
 Make sense?
 
  - Gabriel

I'd be happy to be in this group.

Let me sum-up again my opinion.

Selenium

As I wrote previously, the biggest issue currently for me, is selenium.
It is very frustrating that I can't run these unit tests when building
package, and potentially loose the opportunity to discover problems. I
really would like this to be solved. There's 2 ways of solving it:

1/ Someone works so that the .xpi can be built together with the rest of
selenium, and therefore, selenium can leave the non-free repository of
Debian and go in main (and also be uploaded in other distros).

2/ We move away from Selenium and decide to use something else like
PhantomJS.

Tooling for JS dependencies
===
As for the tooling, we're currently talking about 7 new dependencies,
which isn't much. I believe it's preferable to continue to use XStatic,
because it has been very convenient in many aspects (I wont list here
why again...), and that doing 7 new xstatic packages will not be so much
work. But I wouldn't mind if there was some kind of environment used by
developers to experience new things faster, if that doesn't affect
packaging.

Can someone sum-up the other opinions for the other options?

Cheers,

Thomas Goirand (zigo)


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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Thomas Goirand
On 11/15/2014 05:34 PM, Martin Geisler wrote:
 I'm sorry if I came across as being hostile towards packagers and
 distros. I've been running Debian for 15 years and that is because of
 the work the Debian developers put into making the system work well
 together at a whole.
 
 When it comes to installing software, I only use apt to touch paths
 outside my home directory. That is to ensure that the integrity of the
 system isn't compromised. That means that software not yet packaged for
 Debian has a low change of being installed by me.
 
 However, the chances of me installing it improve significantly if I can
 install it with pip or npm. Simply because this allows me to do a local
 installation in a home directory -- I know then that I can easily remove
 the sofware later.

Sorry to say it this way, and it's not about you in particular, but this
debate about apt vs others is largely not interesting for the
maintenance of Horizon itself, neither upstream or in distributions.

Let me try to sum-up what has been written, so we can move forward.

What we care is to find a system that will satisfy both worlds:
distributions  upstream fast moving development. It is looking like NPM
has the best feature and that it would be a winner against Bower and Grunt.

At the same time, it's obvious that stuff like NPM cannot be used for
deploying Horizon inside a distribution (please, this is *not* open for
a debate...). Though it seems convenient for development, just like pip
is, because it is very easy to just add a new dependency, and try it out.

Using NPM, Horizon contributors wouldn't have to do the work of building
and maintaining XStatic packages. However, it has the issue that, unlike
with XStatic, these dependencies will *not* land into our
global-requirements.txt, and isn't either integrated (yet) with
something like devstack. We'd have to find a way to clearly define these
dependencies somewhere (like in a global-requirements-js.txt?), and have
a way to agree on them and their versions.

Did I forget anything?

Cheers,

Thomas Goirand (zigo)


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


Re: [openstack-dev] [Ironic] A mascot for Ironic

2014-11-16 Thread Jeremy Stanley
On 2014-11-16 13:51:07 -0500 (-0500), David Shrewsbury wrote:
 I like Blaze Bearly, lead singer for Ironic Maiden.  :)
[...]

Ironically, it works on too many levels.
-- 
Jeremy Stanley

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


Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

2014-11-16 Thread MENDELSOHN, ITAI (ITAI)
I guess we can assist with this one.
We have the HW needed and a ci environment.
We will be happy to do so.

I need some help to understand the needed in order integrate into os ci.

Who can assist with that?

Itai



Sent from my iPhone

 On Nov 16, 2014, at 3:31 PM, Irena Berezovsky ire...@mellanox.com wrote:
 
 Hi Steve,
 Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal 
 node with Mellanox SR-IOV NIC.  This job is reporting on neutron patches. 
 Currently API tests are executed. 
 The contact person for SRIOV CI job is listed at driverlog:
 https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1439
 
 The following items are in progress:
 - SR-IOV functional testing 
 - Reporting CI job on nova patches
 - Multi-node setup
 It worth to mention that we   want to start the collaboration on SR-IOV 
 testing effort as part of the pci pass-through subteam activity.
 Please join the weekly meeting if you want to collaborate or have some 
 inputs: https://wiki.openstack.org/wiki/Meetings/Passthrough
 
 BR,
 Irena
 
 -Original Message-
 From: Steve Gordon [mailto:sgor...@redhat.com] 
 Sent: Wednesday, November 12, 2014 9:11 PM
 To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells); Irena 
 Berezovsky; ba...@cisco.com
 Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List (not 
 for usage questions)
 Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other 
 features that can't be tested on current infra.
 
 Hi all,
 
 We had some discussions last week - particularly in the Nova NFV design 
 session [1] - on the subject of ensuring that telecommunications and 
 NFV-related functionality has adequate continuous integration testing. In 
 particular the focus here is on functionality that can't easily be tested on 
 the public clouds that back the gate, including:
 
 - NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device 
 locality)
 - SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)
 
 In each case we need to confirm where we are at, and the plan going forward, 
 with regards to having:
 
 1) Hardware to run the CI on.
 2) Tests that actively exercise the functionality (if not already in 
 existence).
 3) Point person for each setup to maintain it and report into the third-party 
 meeting [2].
 4) Getting the jobs operational and reporting [3][4][5][6].
 
 In the Nova session we discussed a goal of having the hardware by K-1 (Dec 
 18) and having it reporting at least periodically by K-2 (Feb 5). I'm not 
 sure if similar discussions occurred on the Neutron side of the design summit.
 
 SR-IOV
 ==
 
 Adrian and Irena mentioned they were already in the process of getting up to 
 speed with third party CI for their respective SR-IOV configurations. Robert 
 are you attempting similar with regards to Cisco devices? What is the status 
 of each of these efforts versus the four items I lifted above and what do you 
 need assistance with?
 
 NUMA
 
 
 We still need to identify some hardware to run third party CI for the 
 NUMA-related work, and no doubt other things that will come up. It's expected 
 that this will be an interim solution until OPNFV resources can be used (note 
 cdub jokingly replied 1-2 years when asked for a rough estimate - I mention 
 this because based on a later discussion some people took this as a serious 
 estimate).
 
 Ian did you have any luck kicking this off? Russell and I are also 
 endeavouring to see what we can do on our side w.r.t. this short term 
 approach - in particular if you find hardware we still need to find an owner 
 to actually setup and manage it as discussed.
 
 In theory to get started we need a physical multi-socket box and a virtual 
 machine somewhere on the same network to handle job control etc. I believe 
 the tests themselves can be run in VMs (just not those exposed by existing 
 public clouds) assuming a recent Libvirt and an appropriately crafted Libvirt 
 XML that ensures the VM gets a multi-socket topology etc. (we can assist with 
 this).
 
 Thanks,
 
 Steve
 
 [1] https://etherpad.openstack.org/p/kilo-nova-nfv
 [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
 [3] http://ci.openstack.org/third_party.html
 [4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
 [5] 
 http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
 [6] 
 http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

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


Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-16 Thread Alan Pevec
2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net:
 We did find a further issue, which was due to the use of setUpClass in
 tempest (a thing that testtools has never supported per se - its
 always been a happy accident that it worked). I've hopefully fixed
 that in 1.3.0 and we're babysitting tempest now to see.

Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0

http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz
...
 File 
/home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py,
line 60, in setUpClass
super(MockMgmtInstanceTest, cls).setUpClass()
AttributeError: 'super' object has no attribute 'setUpClass'

pip freeze diff since last good report is:
-testtools==1.1.0
+testtools==1.3.0
+unittest2==0.8.0

Any ideas?

Cheers,
Alan

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


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-16 Thread Christopher Yeoh
On Thu, Nov 13, 2014 at 12:14 AM, Pasquale Porreca 
pasquale.porr...@dektech.com.au wrote:

 Hello

 I am working on an api for a new feature in nova, but I am wondering what
 is the correct way to add a new extension: should it be supported by v2, v3
 or both?


You need now to have at least a v2.1 (formerly known as v3) extension. V2
support if you want but I think once v2.1 is fully merged and tested (which
may not be that far away at all) we should freeze v2 and rely just on v2.1
for new features. Otherwise the interaction between v2.1 being exactly
equivalent to v2 plus having microversion support for v2.1 will get a bit
confusing.

As the other Chris mentioned, the first step however is to get a nova-spec
submitted which needs to fully describe the API additions that you want to
make.

Regards,

Chris

BR

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


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

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


Re: [openstack-dev] [api] Cross-Project Liaison for the API Working Group

2014-11-16 Thread Christopher Yeoh
On Sat, Nov 15, 2014 at 7:26 AM, Everett Toews everett.to...@rackspace.com
wrote:

 On Nov 14, 2014, at 1:43 PM, Jay Pipes jaypi...@gmail.com wrote:

  On 11/14/2014 05:13 PM, Everett Toews wrote:
  The liaison should be a core reviewer for the project, but does not
  need to be the PTL. By default, the liaison will be the PTL.
 
  ]Anyway, the outcome of the email exchange with Eoghan was that I
 recommended he submit a core for the API liaison to start, and that I would
 raise the issue on the ML to see if those conditions may be loosened to
 include non-cores. And... here is that issue being raised :)

 I’m totally fine with that. Ideally it’s the person who is the most
 passionate about the API from the team, regardless of core status.

 The current wording on the Cross-Project Liaisons page is

 The liaison should be a core reviewer for the project, but does not need
 to be the PTL.”

 I think the key word there is _should_. Naturally, it’s preferable to want
 a core reviewer in this role because they have more say about what gets
 into the code base but it’s not an absolute must.

 We can loosen the wording further but I think it’s okay to proceed with a
 non-core reviewer, especially if that person is passionate about APIs.


My 2c is we should say The liason should be the PTL or whomever they
delegate to be their representative  and not mention anything about the
person needing to be a core developer. It removes any ambiguity about who
ultimately decides who the liason is (the PTL) without saying that they
have to do the work themselves.

Regards,

Chris



 Everett


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

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Richard Jones
On 17 November 2014 06:42, Thomas Goirand z...@debian.org wrote:

 On 11/15/2014 06:27 AM, Gabriel Hurley wrote:
  So, I propose that a group gets together and defines criteria:
  we need to accept that the Horizon team (and those knowledgeable
  about web-app development) know best what tools they need, and
  they need to produce such a list as a starting point. We then
  need packagers and maintainers to examine that list and evaluate
  it for problems (non-free software, irresolvable dependencies,
  etc.). They're looking strictly for things which are un-packageable,
  not commenting on the necessity of said software. And we need people
  (thanks, Monty) willing to build new tools to find a way to turn
  that list into something the package maintainers can consume
  without burdening either side.
 
  Make sense?
 
   - Gabriel

 I'd be happy to be in this group.

As would I, hence I started the conversation in the first place :)


 Selenium
 
 As I wrote previously, the biggest issue currently for me, is selenium.
 It is very frustrating that I can't run these unit tests when building
 package, and potentially loose the opportunity to discover problems. I
 really would like this to be solved. There's 2 ways of solving it:

 1/ Someone works so that the .xpi can be built together with the rest of
 selenium, and therefore, selenium can leave the non-free repository of
 Debian and go in main (and also be uploaded in other distros).

 2/ We move away from Selenium and decide to use something else like
 PhantomJS.

I think you're confusing a couple of things here. Selenium is a system for
Javascript running tests in a browser environment. To do that, it needs a
browser. PhantomJS provides a headless browser to do that. The tests end up
being faster, less intrusive on a desktop and much simpler to run on
servers (no virtual X11 shenanigans).

I advocate for using PhantomJS, but also for using a reduced Selenium suite
where possible - with an emphasis on unit testing of the angular code
directly. Selenium is just so flaky, especially with an interface that's
even slightly dynamic.


 What we care is to find a system that will satisfy both worlds:
 distributions  upstream fast moving development. It is looking like NPM
 has the best feature and that it would be a winner against Bower and
Grunt.

Again, just to be clear: npm and bower are *both* packaging systems and
have completely separate domains of use. npm is used to package
command-line tools and libraries written in the node.js programming
language whereas bower is used to package browser application components.
It's not npm-or-bower.

bower is most likely going to be replaced by xstatic in our environment,
assuming we have some simple mechanism for creating xstatic packages from
bower components.

The distributions are going to have to package up the npm-packaged tools
that we need, though that set of packages is looking smaller and smaller,
and will probably just include the testing tools (karma, protractor,
jasmin, phantomjs). Some of those are already packaged \o/


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


Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-16 Thread Robert Collins
On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote:
 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net:
 We did find a further issue, which was due to the use of setUpClass in
 tempest (a thing that testtools has never supported per se - its
 always been a happy accident that it worked). I've hopefully fixed
 that in 1.3.0 and we're babysitting tempest now to see.

 Trove stable/juno py26 (py27 works) unit tests are failing with testtools 
 1.3.0

 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz
 ...
  File 
 /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py,
 line 60, in setUpClass
 super(MockMgmtInstanceTest, cls).setUpClass()
 AttributeError: 'super' object has no attribute 'setUpClass'

 pip freeze diff since last good report is:
 -testtools==1.1.0
 +testtools==1.3.0
 +unittest2==0.8.0

 Any ideas?

The use of unittest2 in the plumbing means we're now calling
setUpClass on 2.6 which we were not doing before.

However there is no implementation of setUpClass in the testtools base
class, which leads to the error you are seeing.

We can fix that by subclassing unittest2.TestCase in testtools'
TestCase. I'll put a patch together today.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] [oslo] oslo.messaging outcome from the summit

2014-11-16 Thread Joshua Harlow
I started the following issue on kombu's github page (to see if there is 
any interest on there side to such an effort):


https://github.com/celery/kombu/issues/430

It's about seeing if the kombu folks would be ok with a 'rpc' subfolder 
in there repository that can start to contain 'rpc' like functionality 
that now exists in oslo.messaging (I don't see why they would be against 
this kind of idea, since it seems to make sense IMHO).


Let's see what happens,

-Josh

Doug Hellmann wrote:


On Nov 13, 2014, at 7:02 PM, Joshua Harlow harlo...@yahoo-inc.com
mailto:harlo...@yahoo-inc.com wrote:


Don't forget my executor which isn't dependent on a larger set of
changes for asyncio/trollious...

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

The above will/should just 'work', although I'm unsure what thread
count should be by default (the number of green threads that is set at
like 200 shouldn't be the same number used in that executor which uses
real python/system threads). The neat thing about that executor is
that it can also replace the eventlet one, since when eventlet is
monkey patching the threading module (which it should be) then it
should behave just as the existing eventlet one; which IMHO is pretty
cool (and could be one way to completely remove the eventlet usage in
oslo.messaging).


Good point, thanks for reminding me.



As for the kombu discussions, maybe its time to jump on the #celery
channel (where the kombu folks hang out) and start talking to them
about how we can work better together to move some of our features
into kombu (and also depreciate/remove some of the oslo.messaging
features that now are in kombu). I believe
https://launchpad.net/~asksol is the main guy there (and also the main
maintainer of celery/kombu?). It'd be nice to have these
cross-community talks and at least come up with some kind of game
plan; hopefully one that benefits both communities…


I would like that, but won’t have time to do it myself this cycle. Maybe
we can find another volunteer from the team?

Doug



-Josh

https://launchpad.net/~asksol

*From:* Doug Hellmann d...@doughellmann.com
mailto:d...@doughellmann.com
*To:* OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
*Sent:* Wednesday, November 12, 2014 12:22 PM
*Subject:* [openstack-dev] [oslo] oslo.messaging outcome from the summit

The oslo.messaging session at the summit [1] resulted in some plans to
evolve how oslo.messaging works, but probably not during this cycle.

First, we talked about what to do about the various drivers like
ZeroMQ and the new AMQP 1.0 driver. We decided that rather than moving
those out of the main tree and packaging them separately, we would
keep them all in the main repository to encourage the driver authors
to help out with the core library (oslo.messaging is a critical
component of OpenStack, and we’ve lost several of our core reviewers
for the library to other priorities recently).

There is a new set of contributors interested in maintaining the
ZeroMQ driver, and they are going to work together to review each
other’s patches. We will re-evaluate keeping ZeroMQ at the end of
Kilo, based on how things go this cycle.

We also talked about the fact that the new version of Kombu includes
some of the features we have implemented in our own driver, like
heartbeats and connection management. Kombu does not include the
calling patterns (cast/call/notifications) that we have in
oslo.messaging, but we may be able to remove some code from our driver
and consolidate the qpid and rabbit driver code to let Kombu do more
of the work for us.

Python 3 support is coming slowly. There are a couple of patches up
for review to provide a different sort of executor based on greenio
and trollius. Adopting that would require some application-level
changes to use co-routines, so it may not be an optimal solution even
though it would get us off of eventlet. (During the Python 3 session
later in the week we talked about the possibility of fixing eventlet’s
monkey-patching to allow us to use the new eventlet under python 3.)

We also talked about the way the oslo.messaging API uses URLs to get
some settings and configuration options for others. I thought I
remembered this being a conscious decision to pass connection-specific
parameters in the URL, and “global” parameters via configuration
settings. It sounds like that split may not have been implemented as
cleanly as originally intended, though. We identified documenting URL
parameters as an issue for removing the configuration object, as well
as backwards-compatibility. I don’t think we agreed on any specific
changes to the API based on this part of the discussion, but please
correct me if your recollection is different.

We also learned that there is a critical bug [2] related to heartbeats
for RabbitMQ, and we have a few patches up to 

Re: [openstack-dev] [cinder] Adding support for iSCSI helper

2014-11-16 Thread Mike Perez
On 01:35 Wed 05 Nov , Anish Bhatt wrote:
 This is very helpful, thank you !  Is this planned for kilo ?

Yes.

-- 
Mike Perez

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Thomas Goirand
On 11/15/2014 05:03 AM, Matthias Runge wrote:
 On 14/11/14 16:21, Adam Young wrote:
 
 Example:  I don't need Grunt to run a web server.  I need Apache for
 that.  Grunt does not need to be in the distro, mod_wsgi does.
 
 I will need every tool required to run e.g. unit tests or selenium tests
 to be packaged. Why? Because our builders don't have access to the
 internet and I want to be sure, the packaged version of horizon still
 passes tests.
 
 Matthias

Except that selenium is non-free: it's in the non-free repository of
Debian, because it contains a pre-built .xpi plugin for firefox, which
itself contains pre-built .so and .dll files.

So, we're on the same page, but selenium is a bad tool... :)

Chatting with Maxime Vidori on IRC, there's a bunch of alternative
solutions that we could use instead of Selenium. PhantomJS for example
is already in Debian main. I would very much welcome switching to that
instead of Selenium.

Cheers,

Thomas Goirand (zigo)


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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Richard Jones
On 17 November 2014 11:11, Thomas Goirand z...@debian.org wrote:

 On 11/15/2014 05:03 AM, Matthias Runge wrote:
  On 14/11/14 16:21, Adam Young wrote:
 
  Example:  I don't need Grunt to run a web server.  I need Apache for
  that.  Grunt does not need to be in the distro, mod_wsgi does.
 
  I will need every tool required to run e.g. unit tests or selenium tests
  to be packaged. Why? Because our builders don't have access to the
  internet and I want to be sure, the packaged version of horizon still
  passes tests.
 
  Matthias

 Except that selenium is non-free: it's in the non-free repository of
 Debian, because it contains a pre-built .xpi plugin for firefox, which
 itself contains pre-built .so and .dll files.


Hasn't this issue already been addressed? Horizon currently uses
Selenium-based integration tests.



 So, we're on the same page, but selenium is a bad tool... :)

 Chatting with Maxime Vidori on IRC, there's a bunch of alternative
 solutions that we could use instead of Selenium. PhantomJS for example
 is already in Debian main. I would very much welcome switching to that
 instead of Selenium.


PhantomJS isn't a testing framework - it's just a headless browser that's
scriptable from Javascript. It has a webdriver for Selenium, which is a
testing framework. If you ditch Selenium then you need to replace it with a
testing framework on top of PhantomJS.

There's also CasperJS which is an entirely separate testing framework built
over PhantomJS (and SlimerJS, which looks to be similar to PhantomJS except
built on Gecko - but not headless). It's very JUnit. Some people like that
;)

While Selenium has issues, I'm concerned that there's very few people out
there in the wilds doing interface testing without it. Indeed there's
people advocating for Selenium over PhantomJS directly. Using PhantomJS
directly means we won't have a suite of tests we can then target at IE,
Safari, etc to ensure that the interface works there in an automated
fashion. PhantomJS might be built on WebKit, but it's different enough from
Chrome that you still want to run your tests on Chrome to ensure the
interface actually works. SlimerJS does allow the testing to be slightly
broader, but we'd still miss automated IE and Safari tests.


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


Re: [openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found

2014-11-16 Thread Wan, Sam
Hi Gord,

  Seems this not work for me.  I've pip uninstalled all python-*client .
# pip list|grep -P 'python-.*client'
python-barbicanclient (3.0.1)
python-ceilometerclient (1.0.12)
python-cinderclient (1.1.1)
python-glanceclient (0.14.2)
python-heatclient (0.2.12)
python-keystoneclient (0.11.2)
python-neutronclient (2.3.9)
python-novaclient (2.20.0)
python-openstackclient (0.4.1)
python-saharaclient (0.7.5)
python-swiftclient (2.3.1)
python-troveclient (1.0.7)
# pip list|grep -P 'python-.*client'|awk '{print $1}'|while read pn; do pip 
uninstall -y $pn; done
Uninstalling python-barbicanclient:
  Successfully uninstalled python-barbicanclient
Uninstalling python-ceilometerclient:
  Successfully uninstalled python-ceilometerclient
Uninstalling python-cinderclient:
  Successfully uninstalled python-cinderclient
Uninstalling python-glanceclient:
  Successfully uninstalled python-glanceclient
Uninstalling python-heatclient:
  Successfully uninstalled python-heatclient
Uninstalling python-keystoneclient:
  Successfully uninstalled python-keystoneclient
Uninstalling python-neutronclient:
  Successfully uninstalled python-neutronclient
Uninstalling python-novaclient:
  Successfully uninstalled python-novaclient
Uninstalling python-openstackclient:
  Successfully uninstalled python-openstackclient
Uninstalling python-saharaclient:
  Successfully uninstalled python-saharaclient
Uninstalling python-swiftclient:
  Successfully uninstalled python-swiftclient
Uninstalling python-troveclient:
  Successfully uninstalled python-troveclient
root@vnxslave2:~# pip list|grep -P 'python-.*client'
root@vnxslave2:~#


But devstack still failed with same errors.


Thanks and regards
Sam

From: gordon chung [mailto:g...@live.ca]
Sent: Saturday, November 15, 2014 12:12 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra][devstack] CI failed The plugin 
token_endpoint could not be found

just an fyi, i had same issue. i 'pip uninstall'ed all the python-*clients and 
it worked fine... i assume it's something to do with master (as i had it 
configured previously) since devstack seems to pull in pypi version.

cheers,
gord
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found

2014-11-16 Thread Wan, Sam
Hi Sean,

  Seems once I unset ' 
DEVSTACK_PROJECT_FROM_GIT=python-keystoneclient,python-openstackclient',  
devstack will fail with ' ERROR: openstack The plugin token_endpoint could not 
be found'.
  How should I overcome this issue then?

Thanks and regards
Sam

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Saturday, November 15, 2014 12:28 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra][devstack] CI failed The plugin 
token_endpoint could not be found

On 11/14/2014 09:09 AM, Jeremy Stanley wrote:
 On 2014-11-14 00:34:14 -0500 (-0500), Wan, Sam wrote:
 Seems we need to use python-keystoneclient and python-openstackclient 
 from git.openstack.org  because those on pip don’t work.
 
 That's a bug we're (collectively) trying to prevent in the future.
 Services, even under development, should not depend on features only 
 available in unreleased versions of libraries.
 
 But in latest update of stack.sh, it’s to use pip by default
 [...]
 
 And this is intentional, implemented specifically so that we can keep 
 it from happening again.
 

Patrick actually got to the bottom of a bug we had in devstack around this, we 
merged the fixes this morning.

As Jeremy said, installing from pypi released versions is intentional.
If something wants to use features in a library, the library needs to cut a 
release.

-Sean

--
Sean Dague
http://dague.net

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


Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-16 Thread Robert Collins
On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote:
 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net:
 We did find a further issue, which was due to the use of setUpClass in
 tempest (a thing that testtools has never supported per se - its
 always been a happy accident that it worked). I've hopefully fixed
 that in 1.3.0 and we're babysitting tempest now to see.

 Trove stable/juno py26 (py27 works) unit tests are failing with testtools 
 1.3.0

 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz
 ...
  File 
 /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py,
 line 60, in setUpClass
 super(MockMgmtInstanceTest, cls).setUpClass()
 AttributeError: 'super' object has no attribute 'setUpClass'

 pip freeze diff since last good report is:
 -testtools==1.1.0
 +testtools==1.3.0
 +unittest2==0.8.0

 Any ideas?

https://github.com/testing-cabal/testtools/pull/125

Will fix that, and I'll cut 1.4.0 with that in it once I get a peer review.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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


[openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?

2014-11-16 Thread Mike Perez
The Open Solaris ZFS driver [1] is currently missing a lot of the minimum
features [2] that the Cinder team requires with all drivers. As a result, it's
really broken.

I wanted to gauge who is using it, and if anyone was interested in fixing the
driver. If there is not any activity with this driver, I would like to propose
it to be deprecated for removal.

[1] - 
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py
[2] - 
http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features

-- 
Mike Perez

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


[openstack-dev] Query regarding vRouters Openstack

2014-11-16 Thread Vikram Choudhary
Hi All,

Can someone please help in clarifying below doubts regarding vRouter (say 
vyyata/quagga for example).

How we can use openstack framework for communicating to vRouters?
To be more precise:

* How we can make the communication between neutron and vRouter 
possible?

* How we can push vRouter related configuration using neutron?

It will be great if you can help us with above queries.

Thanks
Vikram

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


Re: [openstack-dev] Query regarding vRouters Openstack

2014-11-16 Thread Li Ma

Here are several hints:

1. Brocade has implemented a service plugin [1] for vRouter using its 
own vyatta image(seems not free and open sourced), but you can read the 
plugin source code as reference.


2. Here's a new method [2] for L3 fabric. It's totally open source and 
can use any routing stack, like quagga or bird.


I've tested the second method. It works pretty well.
[1] 
https://github.com/openstack/neutron/tree/master/neutron/services/l3_router/brocade
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2014-October/049150.html


cheers,
Li Ma

On 2014/11/17 11:53, Vikram Choudhary wrote:


Hi All,

Can someone please help in clarifying below doubts regarding vRouter 
(say vyyata/quagga for example).


How we can use openstack framework for communicating to vRouters?

To be more precise:

·How we can make the communication between neutron and vRouter possible?

·How we can push vRouter related configuration using neutron?

It will be great if you can help us with above queries.

Thanks

Vikram



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


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


Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?

2014-11-16 Thread Drew Fisher
We (here at Oracle) have a replacement for this driver which includes
local ZFS, iSCSI and FC drivers all with ZFS as the underlying driver.
We're in the process of getting CI set up so we can contribute the
driver upstream along with our ZFSSA driver (which is already in the tree).

If anybody has more questions about this, please let me know.  The
driver is in the open for folks to look at and if anybody wants us to
start upstream integration for it, we'll be happy to do so.

-Drew


On 11/16/14, 8:45 PM, Mike Perez wrote:
 The Open Solaris ZFS driver [1] is currently missing a lot of the minimum
 features [2] that the Cinder team requires with all drivers. As a result, it's
 really broken.
 
 I wanted to gauge who is using it, and if anyone was interested in fixing the
 driver. If there is not any activity with this driver, I would like to propose
 it to be deprecated for removal.
 
 [1] - 
 https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py
 [2] - 
 http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features
 

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


Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-16 Thread Nikhil Manchanda
Thanks Robert!

Looks like it failed the Travis CI job due to an intermittent connectivity
issue
and I don't have the rights to kick-off the job again. I would appreciate it
if you could kick it off again when you get a chance.

Cheers,
Nikhil

On Sun, Nov 16, 2014 at 6:44 PM, Robert Collins robe...@robertcollins.net
wrote:

 On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote:
  2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net:
  We did find a further issue, which was due to the use of setUpClass in
  tempest (a thing that testtools has never supported per se - its
  always been a happy accident that it worked). I've hopefully fixed
  that in 1.3.0 and we're babysitting tempest now to see.
 
  Trove stable/juno py26 (py27 works) unit tests are failing with
 testtools 1.3.0
 
 
 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz
  ...
   File
 /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py,
  line 60, in setUpClass
  super(MockMgmtInstanceTest, cls).setUpClass()
  AttributeError: 'super' object has no attribute 'setUpClass'
 
  pip freeze diff since last good report is:
  -testtools==1.1.0
  +testtools==1.3.0
  +unittest2==0.8.0
 
  Any ideas?

 https://github.com/testing-cabal/testtools/pull/125

 Will fix that, and I'll cut 1.4.0 with that in it once I get a peer review.

 -Rob


 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Matthias Runge
On 17/11/14 02:07, Richard Jones wrote:
 Except that selenium is non-free: it's in the non-free repository of
 Debian, because it contains a pre-built .xpi plugin for firefox, which
 itself contains pre-built .so and .dll files.
 
 
 Hasn't this issue already been addressed? Horizon currently uses
 Selenium-based integration tests.

For Fedora, we found, that simply removing bundled .dll and .xpi files
still leaves selenium intact. But I agree, I would like not to have that
stuff bundled at all.

Tests in Horizon are: unit tests and selenium tests, both executed at
the gate; selenium tests are just mocked, vs. integration tests require
a cloud environment set up. This is not executed at the gate right now.

Matthias

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-16 Thread Radomir Dopieralski
On 15/11/14 03:21, Richard Jones wrote:
 On 15 November 2014 00:58, Radomir Dopieralski openst...@sheep.art.pl wrote:

[...]

 4. additions and upgrades of libraries moderated by the packagers,
 
 Is there already some mechanism for handling the creation and management
 of xstatic packages and how they interact with linux packagers? Sorry if
 this is a noob question.

Anybody can at any time create any Xstatic package and put it on PyPi.
To put it in StackForge, it has to be approved by the infra team, but
they usually don't make problems (also, you don't technically need to
keep the source code on StackForge). To put it in the global
requirements.txt file, it has to be approved by the people who review
that repository, and that includes the packagers. To put it in the
Horizon's requirements.txt, it has to be approved by the Horizon core
reviewers.

I imagine we can have a similar setup for JavaScript dependencies,
possibly a bower configuration file, that would be handled in a similar way.

[...]
-- 
Radomir Dopieralski

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