date:20150326

On 03/26/2015 09:47 PM, Alan Pevec wrote:
> blast from the past...
> 
> 2013-12-04 19:17 GMT+01:00 Chuck Short :
>> On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov  wrote:
> ...
>>> 1) Figure out what is the deal with mox3 and decide if owning it will
>>> really be less trouble than porting nova. To be hones - I was unable to
>>> even find the code repo for it, only [3]. If anyone has more info -
>>> please weigh in. We'll also need volunteers
>>>
>>
>> Monty and I did this last cycle, its apart of the openstack project,
>> although its not available in gerrit. Which should be fixed so we can start
>> getting bug fixes in for it.
> 
> Looks like this was not done, last pypi upload was mox3-0.7.0.tar.gz
> on 2013-08-15 by owner "openstackci" but I don't see it in
> https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml
> ?
> 
> There was a bug reported about py34 incompatibility which was worked
> around in one specific project, but oslotest has a dependency on mox3
> so I moved it to oslotest
> https://bugs.launchpad.net/oslotest/+bug/1403214
> 
> What's the status of migration to mock, can mox and mox3 be dropped
> from global-requirements ?

No.

kosh:~/code/openstack/nova(master)> git grep mox | wc -l
4061

This has been treated as a thing that should be done slowly over time.
At that line count, I expect it would require a few dedicated people to
work through the issues in Liberty to convert the rest of the tests.

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] [Fuel] Version bump in the beginning of a release cycle

2015-03-26 Thread Sergii Golovatiuk

Hi Roman,

We are doing the same in a bit different way.

Firstly, we are removing package build out of ISO build. These packages
will flow the same way we do for MOS components. The will use the same
build procedures as all other packages.
Secondly, all packages will be put in repository in our mirror.
Thirdly, when we start working on new version of MOS, meta information of
our mirror will be updated with new release. What does it mean? We'll fork
current release to a new one. When package needs an update the developer
will be able to produce a new package with updated information. It will
pass testing and will be added to mirror though targeted to new release
only. If we need to backport it current release it will be back ported
using standard procedures. The developer will decide where he needs to bump
version to next one and use beta or alpha prefixes in version.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Thu, Mar 26, 2015 at 2:45 AM, Roman Prykhodchenko  wrote:

> Hi folks,
>
> This end of the release cycle I realized that due to different reasons
> bumping a version of Fuel’s components takes much more than just updating a
> set of text files. In fact it causes different kinds of cross-component
> problems which of course must be fixed.
>
> This email is not about fixing them but about the way of detecting them
> earlier and not delaying any component in the end of release cycles. The
> idea is not mine, I borrowed it from one of our folks asked that in a
> private channel. I decided to tell that in a public place like this mailing
> list is.
>
> The idea is to bump version in Fuel’s components not in the end of a
> release cycle, but in it’s early beginning, i.e., when a stable branch has
> been made. What are your thoughts on that?
>
>
> - romcheg
>
> __
> 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] [Heat] Decoupling Heat integration tests from Heat tree

2015-03-26 Thread Angus Salkeld

On Fri, Mar 27, 2015 at 6:26 AM, Zane Bitter  wrote:

> On 26/03/15 10:38, Pavlo Shchelokovskyy wrote:
>
>> Hi all,
>>
>> following IRC discussion here is a summary of what I propose can be done
>> in this regard, in the order of increased decoupling:
>>
>> 1) make a separate requirements.txt for integration tests and modify the
>> tox job to use it. The code of these tests is pretty much decoupled
>> already, not using any modules from the main heat tree. The actual
>> dependencies are mostly api clients and test framework. Making this
>> happen should decrease the time needed to setup the tox env and thus
>> speed up the test run somewhat.
>>
>
> +1
>
>  2) provide separate distutils' setup.py/setup.cfg
>>  to ease packaging and installing this test
>> suit to run it against an already deployed cloud (especially scenario
>> tests seem to be valuable in this regard).
>>
>
> +1
>
>  3) move the integration tests to a separate repo and use it as git
>> submodule in the main tree. The main reasons not to do it as far as I've
>> collected are not being able to provide code change and test in the same
>> (or dependent) commits, and lesser reviewers' attention to a separate
>> repo.
>>
>
> -0
>
> I'm not sure what the advantage is here, and there are a bunch of
> downsides (basically, I agree with Ryan). Unfortunately I missed the IRC
> discussion, can you elaborate on how decoupling to this degree might help
> us?
>

I think the overall goal is to make it easier for an operator to run tests
against their cloud to make sure
everything is working. We should really have a common approach to this so
they don't have to do something
different for each project. Any opinions from the QA team?

Maybe have it as it's own package, then you can install it and run
something like:
os-functional-tests-run  

-A



>
> cheers,
> Zane.
>
>  What do you think about it? Please share your comments.
>>
>> Best regards,
>>
>> Pavlo Shchelokovskyy
>> Software Engineer
>> Mirantis Inc
>> www.mirantis.com 
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2015-03-26 Thread Alan Pevec

blast from the past...

2013-12-04 19:17 GMT+01:00 Chuck Short :
> On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov  wrote:
...
>> 1) Figure out what is the deal with mox3 and decide if owning it will
>> really be less trouble than porting nova. To be hones - I was unable to
>> even find the code repo for it, only [3]. If anyone has more info -
>> please weigh in. We'll also need volunteers
>>
>
> Monty and I did this last cycle, its apart of the openstack project,
> although its not available in gerrit. Which should be fixed so we can start
> getting bug fixes in for it.

Looks like this was not done, last pypi upload was mox3-0.7.0.tar.gz
on 2013-08-15 by owner "openstackci" but I don't see it in
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml
?

There was a bug reported about py34 incompatibility which was worked
around in one specific project, but oslotest has a dependency on mox3
so I moved it to oslotest
https://bugs.launchpad.net/oslotest/+bug/1403214

What's the status of migration to mock, can mox and mox3 be dropped
from global-requirements ?


Cheers,
Alan

__
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] The risk of hanging when shutdown instance.

2015-03-26 Thread Rui Chen

Yes, you are right, but we found our instance hang at first dom.shutdown()
call, if the dom.shutdown() don't return, there is no chance to execute
dom.destroy(), right?

2015-03-26 23:20 GMT+08:00 Chris Friesen :

> On 03/25/2015 10:15 PM, Rui Chen wrote:
>
>> Hi all:
>>
>>  I found a discuss about the libvirt shutdown API maybe hang when
>> shutdown
>> instance in libvirt community,
>> https://www.redhat.com/archives/libvir-list/2015-March/msg01121.html
>>
>>  I'm not sure that whether there are some risks when we shutdown
>> instance in
>> nova.
>>
>>  Three questions:
>>  1. Whether acpi is the default shutdown mode in QEMU/KVM hypervisor
>> when we
>> shutdown instance using libvirt?
>>  2. Whether acpi is asynchronous mode, and qemu-agent is synchronous
>> mode
>> when we shutdown instance?
>>  3. If the hypervisor use qemu-agent as default shutdown mode, how we
>> can
>> deal the hanging issue?
>>
>
>
> When shutting down an instance if there is a timeout (controlled by config
> file or system metadata) the code will first attempt a clean shutdown via
> dom.shutdown().  If that doesn't terminate the instance by the time the
> timeout expires, then we'll call virt_dom.destroy().
>
> Chris
>
> __
> 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][Neutron] Status of the nova-network to Neutron migration work

2015-03-26 Thread Kyle Mestery

On Thu, Mar 26, 2015 at 7:58 PM, Russell Bryant  wrote:

> On 03/26/2015 06:31 PM, Michael Still wrote:
> > Hi,
> >
> > I thought it would be a good idea to send out a status update for the
> > migration from nova-network to Neutron, as there hasn't been as much
> > progress as we'd hoped for in Kilo. There are a few issues which have
> > been slowing progress down.
>
> Thanks for writing up the status!
>
> > First off, creating an all encompassing turn key upgrade is probably
> > not possible. This was also never a goal of this effort -- to quote
> > the spec for this work, "Consequently, the process described here is
> > not a “one size fits all” automated push-button tool but a series of
> > steps that should be obvious to automate and customise to meet local
> > needs" [1]. The variety of deployment and configuration options
> > available makes a turn key migration very hard to write, and possibly
> > impossible to test. We therefore have opted for writing "migration
> > tools", which allow operators to plug components together in the way
> > that makes sense for their deployment and then migrate using those.
>
> Yes, I'm quite convinced that it will end up being a fairly custom
> effort for virtually all deployments complex enough where just starting
> over or cold migration isn't an option.
>
> > However, talking to operators at the Ops Summit, is has become clear
> > that some operators simply aren't interested in moving to Neutron --
> > largely because they either aren't interested in tenant networks, or
> > have corporate network environments that make deploying Neutron very
> > hard.
>
> I totally get point #1: "nova-network has less features, but I don't
> need the rest, and nova-network is rock solid for me."
>
> I'm curious about the second point about Neutron being more difficult to
> deploy than nova-network.  That's interesting because it actually seems
> like Neutron is more flexible when it comes to integration with existing
> networks.  Do you know any more details?  If not, perhaps those with
> that concern could fill in with some detail here?
>
> > So, even if we provide migration tools, it is still likely that
> > we will end up with loyal nova-network users who aren't interested in
> > moving. From the Nova perspective, the end goal of all of this effort
> > is to delete the nova-network code, and if we can't do that because
> > some people simply don't want to move, then what is gained by putting
> > a lot of effort into migration tooling?
>
> To me it comes down to the reasons people don't want to move.  I'd like
> to dig into exactly why people don't want to use Neutron.  If there are
> legitimate reasons why nova-network will work better, then Neutron has
> not met parity and we're certainly not ready to deprecate nova-network.
>
> I still think getting down to a single networking project should be the
> end goal.  The confusion around networking choices has been detrimental
> to OpenStack.
>
> > Therefore, there is some talk about spinning nova-network out into its
> > own project where it could continue to live on and be better
> > maintained than the current Nova team is able to do. However, this is
> > a relatively new idea and we haven't had a chance to determine how
> > feasible it is given where we are in the release cycle. I assume that
> > if we did this, we would need to find a core team passionate about
> > maintaining nova-network, and we would still need to provide some
> > migration tooling for operators who are keen to move to Neutron.
> > However, that migration tooling would be less critical than it is now.
>
> From a purely technical perspective, it seems like quite a bit of work.
>  It reminds me of "we'll just split the scheduler out", and we see how
> long that's taking in practice.  I really think all of that effort is
> better spent just improving Neutron.
>
> From a community perspective, I'm not thrilled about long term
> fragmentation for such a fundamental piece of our stack.  So, I'd really
> like to dig into the current state of gaps between Neutron and
> nova-network.  If there were no real gaps, there would be no sensible
> argument to keep the 2nd option.
>
> I agree with Russell here. After talking to a few folks, my sense is there
is still a misunderstanding between people running nova-network and those
developing Neutron. I realize not everyone wants tenant networks, and I
think we can look at the use case for that and see how to map it to what
Neutron has, and fill in any missing gaps. There are some discussions
started already to see how we can fill those gaps.


> > Unfortunately, this has all come to a head at a time when the Nova
> > team is heads down getting the Kilo release out the door. We simply
> > don't have the time at the moment to properly consider these issues.
> > So, I'd like to ask for us to put a pause on this current work until
> > we have Kilo done. These issues are complicated and important, so I
> > feel we shouldn't rus

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-26 Thread Jay Bryant

Mike,

This effort has taken quite some time and was going to require hard
decisions to be made at some point.   You have been more than patient in
this process and I commend you for that as well as all the communication.

Thank you for continuing to drive this!

Jay
On Mar 24, 2015 10:55 PM, "Monty Taylor"  wrote:

> On 03/24/2015 06:05 PM, Kyle Mestery wrote:
> > On Tue, Mar 24, 2015 at 9:56 AM, Doug Hellmann 
> > wrote:
> >
> >> Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400:
> >>>
> >>> Echoing both Thierry and John.  I support Mike’s decision to enforce
> the
> >> requirement. Maintaining drivers in the tree comes with
> responsibilities to
> >> the community and 3rd party CI is one of the them.  Mike enforcing this
> >> requirement was the right action even if a hard one to take.
> >>>
> >>> mark
> >>
> >> Indeed. The deadlines were communicated clearly, and frequently.
> >> Making phone calls to reach out to contributors for issues like
> >> this is exceptional.
> >>
> >> +1000. Enabling contributors is great, but CI systems are an important
> > part of that enablement. I appreciate what Mike has done to drive Cinder
> > towards a quality level for all contributors here. It's a hard stance to
> > take, but saying "No" can sometimes be the right decision.
>
> I'm just going to pile on.
>
> People keep asking us to focus on quality over landing features. It was
> the #1 request from EVERY operator at the recent Ops summit. This is one
> of that facets of doing that. It's hard, and it doesn't always feel good
> to all the parties involved - but it's important.
>
> Thank you, Mike, for sticking to your deadline. OpenStack will be better
> for it.
>
> "If it's not tested, it's broken"
>
> __
> 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] initial OVN testing

2015-03-26 Thread Russell Bryant

On 03/26/2015 08:22 PM, Salvatore Orlando wrote:
> To set this up outside of ovs-sandbox, you need to first create the OVN
> northbound database:
> 
>   $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema
> 
> Then you need to tell ovsdb-server to use it.  By default ovsdb-server
> will only serve up conf.db.  It can take a list of dbs as positional
> arguments, though.  You can see that's what the ovs-sandbox script
> is doing.
> 
> Do you reckon this steps should be performed by devstack (or to be more
> precise the neutron-ovn devstack plugin that we should develop) or shall
> we assume OVN is already configured? For me both ways work. However some
> developers (like Russell I guess) will be working both on OVN and the
> neutron plugin, so maybe I'm not sure having devstack doing the OVN
> setup might be helpful for them; on the other hand this might come
> somewhat handy for setting up CI jobs. 

I think automating in devstack makes sense.  Right now I would want it
to feel like the OpenStack components in devstack.  I want an ovs git
tree that I can hack on along side my OpenStack git trees and have
everything started up using the current state of the code.  Automating
that should serve both the dev and test cases.  I'm sure the automation
will evolve over time when it's eventually packaged and so forth.  For
now it's going to be a fast moving target straight from git.

>  
> 
> So, you can either change the command used to start ovsdb-server on your
> system, or start up another instance of it with its own unix socket and
> tcp port.
> 
> There was also a question on IRC about the format of the database option
> for the ML2 driver.  The value is passed directly to ovn-nbctl.  The
> format is the same as is used for ovs-vsctl (and probably others).
> 
> 
> In the ovs-dev mailing list you said (correctly imo) that openstack
> should not use nbctl but rather talk directly through ovsdb with the OVN
> controller.
> It seems here you're stating the ML2 driver will pass down the database
> connection info to nbctl.
> I don't know if that's your intention, but I would rather avoid having
> another plugin that uses command line for everything.This would save us
> the pain of having to scrape through command output, and more
> importantly will avoid the overhead associated with rootwrap (daemonized
> or not).

I absolutely agree.  The current use of the utility is just a "make it
work ASAP" approach for POC purposes.  The real goal is to use ovsdb
directly.  I've been talking to Terry about using his work in Neutron
here, as well.  However, I don't want to block on that part for getting
things up and running in a first iteration.

-- 
Russell Bryant

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

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

2015-03-26 Thread Russell Bryant

On 03/26/2015 06:31 PM, Michael Still wrote:
> Hi,
> 
> I thought it would be a good idea to send out a status update for the
> migration from nova-network to Neutron, as there hasn't been as much
> progress as we'd hoped for in Kilo. There are a few issues which have
> been slowing progress down.

Thanks for writing up the status!

> First off, creating an all encompassing turn key upgrade is probably
> not possible. This was also never a goal of this effort -- to quote
> the spec for this work, "Consequently, the process described here is
> not a “one size fits all” automated push-button tool but a series of
> steps that should be obvious to automate and customise to meet local
> needs" [1]. The variety of deployment and configuration options
> available makes a turn key migration very hard to write, and possibly
> impossible to test. We therefore have opted for writing "migration
> tools", which allow operators to plug components together in the way
> that makes sense for their deployment and then migrate using those.

Yes, I'm quite convinced that it will end up being a fairly custom
effort for virtually all deployments complex enough where just starting
over or cold migration isn't an option.

> However, talking to operators at the Ops Summit, is has become clear
> that some operators simply aren't interested in moving to Neutron --
> largely because they either aren't interested in tenant networks, or
> have corporate network environments that make deploying Neutron very
> hard. 

I totally get point #1: "nova-network has less features, but I don't
need the rest, and nova-network is rock solid for me."

I'm curious about the second point about Neutron being more difficult to
deploy than nova-network.  That's interesting because it actually seems
like Neutron is more flexible when it comes to integration with existing
networks.  Do you know any more details?  If not, perhaps those with
that concern could fill in with some detail here?

> So, even if we provide migration tools, it is still likely that
> we will end up with loyal nova-network users who aren't interested in
> moving. From the Nova perspective, the end goal of all of this effort
> is to delete the nova-network code, and if we can't do that because
> some people simply don't want to move, then what is gained by putting
> a lot of effort into migration tooling?

To me it comes down to the reasons people don't want to move.  I'd like
to dig into exactly why people don't want to use Neutron.  If there are
legitimate reasons why nova-network will work better, then Neutron has
not met parity and we're certainly not ready to deprecate nova-network.

I still think getting down to a single networking project should be the
end goal.  The confusion around networking choices has been detrimental
to OpenStack.

> Therefore, there is some talk about spinning nova-network out into its
> own project where it could continue to live on and be better
> maintained than the current Nova team is able to do. However, this is
> a relatively new idea and we haven't had a chance to determine how
> feasible it is given where we are in the release cycle. I assume that
> if we did this, we would need to find a core team passionate about
> maintaining nova-network, and we would still need to provide some
> migration tooling for operators who are keen to move to Neutron.
> However, that migration tooling would be less critical than it is now.

From a purely technical perspective, it seems like quite a bit of work.
 It reminds me of "we'll just split the scheduler out", and we see how
long that's taking in practice.  I really think all of that effort is
better spent just improving Neutron.

From a community perspective, I'm not thrilled about long term
fragmentation for such a fundamental piece of our stack.  So, I'd really
like to dig into the current state of gaps between Neutron and
nova-network.  If there were no real gaps, there would be no sensible
argument to keep the 2nd option.

> Unfortunately, this has all come to a head at a time when the Nova
> team is heads down getting the Kilo release out the door. We simply
> don't have the time at the moment to properly consider these issues.
> So, I'd like to ask for us to put a pause on this current work until
> we have Kilo done. These issues are complicated and important, so I
> feel we shouldn't rush them at a time we are distracted.

Makes sense.  It seems clear this has now pushed back another release
(at least).

> Finally, I want to reinforce that the position we currently find
> ourselves in isn't because of a lack of effort. Oleg, Angus and Anita
> have all worked very hard on this problem during Kilo, and it is
> frustrating that we haven't managed to find a magic bullet to solve
> all of these problems. I want to personally thank each of them for
> their efforts this cycle on this relatively thankless task.

++

-- 
Russell Bryant

__

[openstack-dev] [Devstack] What is neutron-legacy?

2015-03-26 Thread Hirofumi Ichihara

Hi Devstack folks,

I found lib/neutron-legacy in master branch today. 
I didn’t know this important change because I couldn’t watch for the last few 
days.
Could someone tell me what is neutron-legacy?
How do we manage and develop it?

I would also like to know where is the change decided, IRC or ML? I probably 
missed it.

thanks,
Hirofumi
__
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] Fwd: PCI passthrough of 40G ethernet interface

2015-03-26 Thread yongli he


在 2015年03月11日 22:15, jacob jacob 写道:
Hi, jacob

  we now find   przemyslaw.czesnowicz have same NIC, hope will help a 
little bit.


Yongli He


-- Forwarded message --
From: *jacob jacob* mailto:opstk...@gmail.com>>
Date: Tue, Mar 10, 2015 at 6:00 PM
Subject: PCI passthrough of 40G ethernet interface
To: openst...@lists.openstack.org 



Hi,
I'm interested in finding out if anyone has successfully tested PCI 
passthrough functionality for 40G interfaces in Openstack(KVM hypervisor).


I am trying this out on a Fedora 21 host  with Fedora 21 VM 
image.(3.18.7-200.fc21.x86_64)


Was able to successfully test PCI passthrough of 10 G interfaces:
  Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ 
Network Connection (rev 01)


With 40G interface testing, the PCI device is passed through to the VM 
but data transfer is failing.
0a:00.1 Ethernet controller: Intel Corporation Ethernet Controller 
XL710 for 40GbE QSFP+ (rev 01)


Tried this with both the i40e driver and latest dpdk driver but no 
luck so far.


With the i40e driver, the data transfer fails.
 Relevant dmesg output:
 [   11.544088] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None
[   11.689178] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None

[   16.704071] [ cut here ]
[   16.705053] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 
dev_watchdog+0x23e/0x250()

[   16.705053] NETDEV WATCHDOG: eth1 (i40e): transmit queue 1 timed out
[   16.705053] Modules linked in: cirrus ttm drm_kms_helper i40e drm 
ppdev serio_raw i2c_piix4 virtio_net parport_pc ptp virtio_balloon 
crct10dif_pclmul pps_core parport pvpanic crc32_pclmul 
ghash_clmulni_intel virtio_blk crc32c_intel virtio_pci virtio_ring 
virtio ata_generic pata_acpi
[   16.705053] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.18.7-200.fc21.x86_64 #1
[   16.705053] Hardware name: Fedora Project OpenStack Nova, BIOS 
1.7.5-20140709_153950- 04/01/2014
[   16.705053]   2e5932b294d0c473 88043fc83d48 
8175e686
[   16.705053]   88043fc83da0 88043fc83d88 
810991d1
[   16.705053]  88042958f5c0 0001 88042865f000 
0001

[   16.705053] Call Trace:
[   16.705053][] dump_stack+0x46/0x58
[   16.705053]  [] warn_slowpath_common+0x81/0xa0
[   16.705053]  [] warn_slowpath_fmt+0x55/0x70
[   16.705053]  [] dev_watchdog+0x23e/0x250
[   16.705053]  [] ? dev_graft_qdisc+0x80/0x80
[   16.705053]  [] call_timer_fn+0x3a/0x120
[   16.705053]  [] ? dev_graft_qdisc+0x80/0x80
[   16.705053]  [] run_timer_softirq+0x212/0x2f0
[   16.705053]  [] __do_softirq+0x124/0x2d0
[   16.705053]  [] irq_exit+0x125/0x130
[   16.705053]  [] smp_apic_timer_interrupt+0x48/0x60
[   16.705053]  [] apic_timer_interrupt+0x6d/0x80
[   16.705053][] ? hrtimer_start+0x18/0x20
[   16.705053]  [] ? native_safe_halt+0x6/0x10
[   16.705053]  [] ? rcu_eqs_enter+0xa3/0xb0
[   16.705053]  [] default_idle+0x1f/0xc0
[   16.705053]  [] arch_cpu_idle+0xf/0x20
[   16.705053]  [] cpu_startup_entry+0x3c5/0x410
[   16.705053]  [] start_secondary+0x1af/0x1f0
[   16.705053] ---[ end trace 7bda53aeda558267 ]---
[   16.705053] i40e :00:05.0 eth1: tx_timeout recovery level 1
[   16.705053] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 519 Tx 
ring 0 disable timeout
[   16.744198] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 520 Tx 
ring 64 disable timeout

[   16.779322] i40e :00:05.0: i40e_ptp_init: added PHC on eth1
[   16.791819] i40e :00:05.0: PF 40 attempted to control timestamp 
mode on port 1, which is owned by PF 1
[   16.933869] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None
[   18.853624] SELinux: initialized (dev tmpfs, type tmpfs), uses 
transition SIDs

[   22.720083] i40e :00:05.0 eth1: tx_timeout recovery level 2
[   22.826993] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 519 Tx 
ring 0 disable timeout
[   22.935288] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 520 Tx 
ring 64 disable timeout

[   23.669555] i40e :00:05.0: i40e_ptp_init: added PHC on eth1
[   23.682067] i40e :00:05.0: PF 40 attempted to control timestamp 
mode on port 1, which is owned by PF 1
[   23.722423] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None

[   23.800206] i40e :00:06.0: i40e_ptp_init: added PHC on eth2
[   23.813804] i40e :00:06.0: PF 48 attempted to control timestamp 
mode on port 0, which is owned by PF 0
[   23.855275] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None

[   38.720091] i40e :00:05.0 eth1: tx_timeout recovery level 3
[   38.725844] random: nonblocking pool is initialized
[   38.729874] i40e :00:06.0: HMC error interrupt
[   38.733425] i40e :00:06.0: i40e_vsi_control_tx: VSI seid 518 Tx 
ring 0 disable timeout
[   38.738886] i40e :00:06.0: i4

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

Thanks for clarifying!

Ryan

On Mar 26, 2015, at 5:29 PM, Mike Perez  wrote:

> On 00:24 Fri 27 Mar , Ryan Hsu wrote:
>> Rightfully so, but it doesn't hurt to offer suggestions that might improve
>> the community. It would just be nice to have exclusions reconsidered if there
>> are legitimate bugs behind them. You see them all the time in the tempest
>> tests ala "SKIPPED: Skipped until Bug: 1373513 is resolved" so  it's hard to
>> understand why we can't just apply the same principles to third-party CI.
> 
> Your usage of exclusions is fine for fixing bugs in my opinion. My meaning of
> exclusion was not allowing these additional tests to be discovered.
> 
> -- 
> Mike Perez
> 
> __
> 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] [cinder] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Jay Bryant

Mike,

I am communicating this problem with my teams and will get it resolved asap.

Jay
On Mar 26, 2015 1:23 PM, "Mike Perez"  wrote:

> On 09:39 Thu 26 Mar , Mike Perez wrote:
> > As discussed in the last Cinder meeting [1], in order to have your volume
> > driver readded into the Kilo release, you must have a CI reporting and
> stable
> > for five days prior to 4/6.
> >
> > This includes:
> >
> > 1) Providing logs to screen sessions, etc configs, tempest output [2].
> > 2) You should be running around 304 tests if you're following
> instructions from
> >the Cinder third party wiki [3]. If you're running less than that,
> your CI
> >will be *NOT* be considered satisfactory for skipping tests.
> >
> > I will also be emailing individuals who have already asked for
> exceptions, just
> > to make sure communication was clear.
> >
> >
> > [1] -
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
> > [2] - http://ci.openstack.org/third_party.html#requirements
> > [3] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
>
> The current CI's not meeting the second requirement:
>
> * Cloudbyte
> * Dell EQL
> * Dell SC FC
> * Dell SC ISCSI
> * EMC VMAX FC
> * EMC VMX ISCSI
> * EMC VNX FC
> * EMC VNX ISCSI
> * EMC XIO FC
> * EMC XIO ISCSI
> * HDS NFS
> * HDS NAS
> * Hitachi HBSD FC
> * Hitach HBSD ISCSI
> * IBM Flash Systems FC
> * IBM Flash Systems ISCSI
> * IBM NAS
> * IBM XIV (couldn't find tempest results to verify)
> * IBM Storwize FC
> * IBM Storwize ISCSI
> * Nimble
> * OpenVStorage
> * Quobyte
> * XIO FC
> * XIO ISCSI
> * Vmware
>
> Pretty sure this is because the previous instructions in the wiki were
> incorrect and are now corrected [1]. This is not the fault of the CI
> maintainers. As mentioned, individual emails are being sent out to get
> this all
> sorted.
>
>
> [1] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
>
> --
> Mike Perez
>
> __
> 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] What's Up Doc? March 26, 2015 [all]

2015-03-26 Thread Anne Gentle

Here's the latest news installment from docsland.

Install Guides updates
-
We've got a spec ready for the changes to the Install Guides now published
at:
http://specs.openstack.org/openstack/docs-specs/specs/kilo/installguide-kilo.html
I'm sure the keystone team will rejoice to see changes to support the
Identity v3 API by default. Also the openstack CLI will substitute for
keystone CLI commands.

Doc core team
---
Removed some people from openstack-doc-core team so we now have 12 (yes
that's a dozen) doc core members who can +2 and publish a doc patch. I’m
consulting with the group to see who we can add next based on the 30 and 90
day stats for both reviews and commits.

Speciality teams
--
Specialty teams are working well for docs, install guides, user guides,
security guide, ha guide, and networking guide -- specialists are working
independently in teams and planning and writing. Currently many of those
specialized review teams maintain their own core list, and can publish
their guide without needing a doc-core member.

RST Migration Updates
---
Fixed two bugs in the OpenStack Sphinx theme that were showstoppers. Three
remain, and all of those need to be landed this week or next for us to
publish RST by April 9th (trying to beat
https://wiki.openstack.org/wiki/Kilo_Release_Schedule dates). Calling web
devs especially to take a look at these:
Bug links https://review.openstack.org/#/c/160151/
TOC links https://review.openstack.org/#/c/160354/
Search fix https://review.openstack.org/#/c/167028/

Once the End User Guide and Admin User Guide content is migrated, we will
shift focus to determine what criteria to use to migrate and publish the
next guide with RST/Sphinx. Git 'er done.

Doc Team meeting
-
The Doc team met this week and the minutes and logs are available:

Minutes:
http://eavesdrop.openstack.org/meetings/docteam/2015/docteam.2015-03-25-14.00.html

Log:
http://eavesdrop.openstack.org/meetings/docteam/2015/docteam.2015-03-25-14.00.log.html

Licensing code and content
-
I completed an audit of our current displayed licensing for our docs:
https://wiki.openstack.org/wiki/Documentation/ContentSpecs#Licenses

Working through the desired state which we believe to be to indicate that
code is Apache 2.0 and content is CC-by 3.0 I'm picking up tasks to make
that happen.

Thanks everyone for the hard work -- with just a dozen doc core we are
getting a lot done, with the support of the hundreds of doc contributors
this release (over 200!). Let's keep it up to get Kilo out into the world.

Anne


-- 
Anne Gentle
annegen...@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] [cinder] Deadline For Volume Drivers to Be Readded

On 00:24 Fri 27 Mar , Ryan Hsu wrote:
> Rightfully so, but it doesn't hurt to offer suggestions that might improve
> the community. It would just be nice to have exclusions reconsidered if there
> are legitimate bugs behind them. You see them all the time in the tempest
> tests ala "SKIPPED: Skipped until Bug: 1373513 is resolved" so  it's hard to
> understand why we can't just apply the same principles to third-party CI.

Your usage of exclusions is fine for fixing bugs in my opinion. My meaning of
exclusion was not allowing these additional tests to be discovered.

-- 
Mike Perez

__
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] Deadline For Volume Drivers to Be Readded

Rightfully so, but it doesn't hurt to offer suggestions that might improve the 
community. It would just be nice to have exclusions reconsidered if there are 
legitimate bugs behind them. You see them all the time in the tempest tests ala 
"SKIPPED: Skipped until Bug: 1373513 is resolved" so  it's hard to understand 
why we can't just apply the same principles to third-party CI.

Thanks,
Ryan

On Mar 26, 2015, at 4:42 PM, Anita Kuno  wrote:

> On 03/26/2015 06:48 PM, Ryan Hsu wrote:
>> Exclusions are legitimate and will always be necessary at some point. In the 
>> case of the linked bug, this was once a known issue for the VMware driver 
>> and we had excluded affected tests so that CI could continue to run. This is 
>> the same way we do it in Nova CI and oslo.vmware CI. 
> 
> This is Cinder, Ryan, and Mike is the PTL. It is his decision.
> 
> Thank you,
> Anita.
> 
>> Thanks,
>> Ryan
>> 
>> On Mar 26, 2015, at 3:30 PM, Mike Perez  wrote:
>> 
>>> On 20:49 Thu 26 Mar , Ryan Hsu wrote:
 Hi Mike,

 We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and 
 this
 runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests 
 are
 not being run due to skips and disabled features. For example, here is
 a sampling of tests that are skipped in a recent run (note that this is 
 using
 tempest.conf with no explicit disabling of Cinder services):

 tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
  ... SKIPPED: Block Live migration not available
 setUpClass 
 (tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
 SKIPPED: Heat support is required
 setUpClass 
 (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
 SKIPPED: Cinder multi-backend feature disabled
 tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
  ... SKIPPED: SSH required for this test
 setUpClass 
 (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
 SKIPPED: Cinder backup feature disabled
 setUpClass 
 (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
 SKIPPED: Cinder backup feature disabled
 setUpClass 
 (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
 SKIPPED: Cinder multi-backend feature disabled
 tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
 tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern 
 ... SKIPPED: Skipped until Bug: 1205344 is resolved.
 setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) 
 ... SKIPPED: The EC2 API is not available
 setUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... 
 SKIPPED: The EC2 API is not available
 tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
  ... SKIPPED: Skipped until Bug: 1373513 is resolved.

 As we are actually running the volume suite according to the FAQ and the
 above skipped tests are documented by our CI, would it be possible to add 
 an
 exception to the rule?  I'm sure these numbers will be different for all 
 CIs
 and as long as people are not abusing and hiding skipped tests, I don't see
 this as a problem.
>>> 
>>> There will be no exceptions. Everyone must pass the same tests or you're 
>>> not an
>>> approved volume driver for OpenStack Cinder.
>>> 
>>> You should also take this bug [1] Vmware hit as a lesson of doing any
>>> excluding in your CI. The driver would've been seriously broken in Kilo if 
>>> this
>>> wasn't caught.
>>> 
>>> [1] - https://bugs.launchpad.net/cinder/+bug/1436603
>>> 
>>> -- 
>>> Mike Perez
>>> 
>>> __
>>> 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.ope

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

On 00:11 Fri 27 Mar , Ryan Hsu wrote:
> Thanks Mike. The wiki still showing the old edit when I had sent out my
> earlier email but I see it's been updated now. I've tested running with "tox
> -e all -- volume" and that gets us to 291 tests now.

Ah gotcha. That's great to hear, thank you!

-- 
Mike Perez

__
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] initial OVN testing

2015-03-26 Thread Salvatore Orlando

Thanks for starting this Russell.

Some answers inline.

Salvatore

On 27 March 2015 at 00:54, Russell Bryant  wrote:

> Gary and Kyle, I saw in my IRC backlog that you guys were briefly
> talking about testing the Neutron ovn ml2 driver.  I suppose it's time
> to add some more code to the devstack integration to install the current
> ovn branch and set up ovsdb-server to serve up the right database for
> this.  I'll try to work on that tomorrow.  Of course, note that all we
> can set up right now is the northbound database.  None of the code that
> reacts to updates to that database is merged yet.  We can still go ahead
> and test our code and make sure the expected data makes it there, though.
>

In theory this should be enough!

>
> Here's some more detail about the pieces ...
>
> When I was writing ovn-nbctl [1], I was testing using ovs-sandbox.  It's
> a script that sets up a handy development environment for ovs.  It has
> ovn support if you pass the "-o" option [2].  To run it, it would be
> something like ...
>
>   $ git clone https://github.com/openvswitch/ovs.git
>   $ cd ovs
>   $ git checkout ovn
>
  $ ./boot.sh
>   $ ./configure
>   $ make
>   $ make SANDBOXFLAGS="-o" sandbox
>




>
> From there you can run ovn-nbctl.  Here's a script to demonstrate the
> various commands:
>
>   https://gist.github.com/russellb/946953e8675063c0c756
>
> To set this up outside of ovs-sandbox, you need to first create the OVN
> northbound database:
>
>   $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema
>
> Then you need to tell ovsdb-server to use it.  By default ovsdb-server
> will only serve up conf.db.  It can take a list of dbs as positional
> arguments, though.  You can see that's what the ovs-sandbox script is
> doing.
>
> Do you reckon this steps should be performed by devstack (or to be more
precise the neutron-ovn devstack plugin that we should develop) or shall we
assume OVN is already configured? For me both ways work. However some
developers (like Russell I guess) will be working both on OVN and the
neutron plugin, so maybe I'm not sure having devstack doing the OVN setup
might be helpful for them; on the other hand this might come somewhat handy
for setting up CI jobs.


> So, you can either change the command used to start ovsdb-server on your
> system, or start up another instance of it with its own unix socket and
> tcp port.
>
> There was also a question on IRC about the format of the database option
> for the ML2 driver.  The value is passed directly to ovn-nbctl.  The
> format is the same as is used for ovs-vsctl (and probably others).
>

In the ovs-dev mailing list you said (correctly imo) that openstack should
not use nbctl but rather talk directly through ovsdb with the OVN
controller.
It seems here you're stating the ML2 driver will pass down the database
connection info to nbctl.
I don't know if that's your intention, but I would rather avoid having
another plugin that uses command line for everything.This would save us the
pain of having to scrape through command output, and more importantly will
avoid the overhead associated with rootwrap (daemonized or not).


>
> When running in ovs-sandbox, ovn-nbctl's help output shows:
>
>   --db=DATABASE connect to DATABASE
> (default:
> unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock)
>
> and further down, it provides some more detail:
>
>   Active database connection methods:
> tcp:IP:PORT PORT at remote IP
> ssl:IP:PORT SSL PORT at remote IP
> unix:FILE   Unix domain socket named FILE
>   Passive database connection methods:
> ptcp:PORT[:IP]  listen to TCP PORT on IP
> pssl:PORT[:IP]  listen for SSL on PORT on IP
> punix:FILE  listen on Unix domain socket FILE
>
>
> [1] http://openvswitch.org/pipermail/dev/2015-March/052757.html
> [2] http://openvswitch.org/pipermail/dev/2015-March/052353.html
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] Deadline For Volume Drivers to Be Readded

Thanks Mike. The wiki still showing the old edit when I had sent out my earlier 
email but I see it's been updated now. I've tested running with "tox -e all -- 
volume" and that gets us to 291 tests now.

-Ryan

On Mar 26, 2015, at 4:28 PM, Mike Perez  wrote:

> On 21:45 Thu 26 Mar , Ryan Hsu wrote:
>> Hmm, that's what I thought at first but when I looked at the "What tests do
>> I use" FAQ, the tests that it says to use links to:
>> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/volume,
>> which is exactly what we're running. Even so, I ran the "tox -e all --
>> volume" command and that just runs 4 more tests.
> 
> As the email that went out, it was mentioned the wiki has been corrected. It
> should not just be api.volume.
> 
> There have been a number of drivers today in the #openstack-cinder that have
> reported to me that they made the adjustments from the wiki and are now
> reporting 294 tests. If this is not making a difference for you, I recommend
> you reach out to the liasons mentioned in the wiki and get help:
> 
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions
> 
> -- 
> Mike Perez
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Neutron] initial OVN testing

2015-03-26 Thread Russell Bryant

Gary and Kyle, I saw in my IRC backlog that you guys were briefly
talking about testing the Neutron ovn ml2 driver.  I suppose it's time
to add some more code to the devstack integration to install the current
ovn branch and set up ovsdb-server to serve up the right database for
this.  I'll try to work on that tomorrow.  Of course, note that all we
can set up right now is the northbound database.  None of the code that
reacts to updates to that database is merged yet.  We can still go ahead
and test our code and make sure the expected data makes it there, though.

Here's some more detail about the pieces ...

When I was writing ovn-nbctl [1], I was testing using ovs-sandbox.  It's
a script that sets up a handy development environment for ovs.  It has
ovn support if you pass the "-o" option [2].  To run it, it would be
something like ...

  $ git clone https://github.com/openvswitch/ovs.git
  $ cd ovs
  $ git checkout ovn
  $ ./boot.sh
  $ ./configure
  $ make
  $ make SANDBOXFLAGS="-o" sandbox

>From there you can run ovn-nbctl.  Here's a script to demonstrate the
various commands:

  https://gist.github.com/russellb/946953e8675063c0c756

To set this up outside of ovs-sandbox, you need to first create the OVN
northbound database:

  $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema

Then you need to tell ovsdb-server to use it.  By default ovsdb-server
will only serve up conf.db.  It can take a list of dbs as positional
arguments, though.  You can see that's what the ovs-sandbox script is doing.

So, you can either change the command used to start ovsdb-server on your
system, or start up another instance of it with its own unix socket and
tcp port.

There was also a question on IRC about the format of the database option
for the ML2 driver.  The value is passed directly to ovn-nbctl.  The
format is the same as is used for ovs-vsctl (and probably others).

When running in ovs-sandbox, ovn-nbctl's help output shows:

  --db=DATABASE connect to DATABASE
(default:
unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock)

and further down, it provides some more detail:

  Active database connection methods:
tcp:IP:PORT PORT at remote IP
ssl:IP:PORT SSL PORT at remote IP
unix:FILE   Unix domain socket named FILE
  Passive database connection methods:
ptcp:PORT[:IP]  listen to TCP PORT on IP
pssl:PORT[:IP]  listen for SSL on PORT on IP
punix:FILE  listen on Unix domain socket FILE


[1] http://openvswitch.org/pipermail/dev/2015-March/052757.html
[2] http://openvswitch.org/pipermail/dev/2015-March/052353.html

-- 
Russell Bryant

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

Re: [openstack-dev] How to do once off/infrequent meetings?

2015-03-26 Thread Tony Breeds

On Wed, Mar 25, 2015 at 03:23:29PM +, Bailey, Darragh wrote:
> 
> 
> I was looking at using the meetings service
> (https://wiki.openstack.org/wiki/Meetings) to run and log a meeting on a
> stackforge project (git-upstream -
> http://git.openstack.org/cgit/stackforge/git-upstream), which seems to
> focus on reoccurring meetings.
> 
> So I'm wondering how best to register an adhoc meeting, I'm sure there
> may be others in the future, but the project isn't at the point where it
> would be useful to run a regular meeting.
> 
> I'm happy enough to just run this through the standard IRC channel in
> this case, but I figured it might be better if I found out if it was
> possible to use the meetings service?
> 
> 
> btw, if anyone is interested in the project git-upstream the
> discussion/meeting is happening tomorrow in the #git-upstream IRC
> channel @5pm UTC.

There are a few of reasons to 'register' the meeting.

1) so people know where to be when

 * As this is an adhoc meeting I don't think 1 applies as you'll have some
   other way of ensuring that the people you need are on IRC.

2) To ensure that there is a conflict free venue available.

 * If you want the logging and such I think you can use a free meetiung room.
   You can use[1] to check if a room is free.  Note if 2 or more groups use
   this method then it fails and you shoudl fallback to booking a room.

3) For logging and archiving of the discussions and outcomes.

 * If you're in one of the std. openstack meeting rooms then you can just use
   the std. MeetBot commands to log your meeting.

Of course if this is a becomes a regular meeting you should certainly create a
meeting.

Yours Tony.

[1] 
https://www.google.com/calendar/embed?src=bj05mroquq28jhud58esggqmh4%40group.calendar.google.com&ctz=Iceland/Reykjavik
[2] https://wiki.openstack.org/wiki/Meetings/CreateaMeeting

pgpcKAgYvnTPK.pgp
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] [cinder] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Anita Kuno

On 03/26/2015 06:48 PM, Ryan Hsu wrote:
> Exclusions are legitimate and will always be necessary at some point. In the 
> case of the linked bug, this was once a known issue for the VMware driver and 
> we had excluded affected tests so that CI could continue to run. This is the 
> same way we do it in Nova CI and oslo.vmware CI. 

This is Cinder, Ryan, and Mike is the PTL. It is his decision.

Thank you,
Anita.

> Thanks,
> Ryan
> 
> On Mar 26, 2015, at 3:30 PM, Mike Perez  wrote:
> 
>> On 20:49 Thu 26 Mar , Ryan Hsu wrote:
>>> Hi Mike,
>>>
>>> We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this
>>> runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests 
>>> are
>>> not being run due to skips and disabled features. For example, here is
>>> a sampling of tests that are skipped in a recent run (note that this is 
>>> using
>>> tempest.conf with no explicit disabling of Cinder services):
>>>
>>> tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
>>>  ... SKIPPED: Block Live migration not available
>>> setUpClass 
>>> (tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
>>> SKIPPED: Heat support is required
>>> setUpClass 
>>> (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
>>> SKIPPED: Cinder multi-backend feature disabled
>>> tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
>>>  ... SKIPPED: SSH required for this test
>>> setUpClass 
>>> (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
>>> SKIPPED: Cinder backup feature disabled
>>> setUpClass 
>>> (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
>>> SKIPPED: Cinder backup feature disabled
>>> setUpClass 
>>> (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
>>> SKIPPED: Cinder multi-backend feature disabled
>>> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
>>>  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
>>> tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
>>> SKIPPED: Skipped until Bug: 1205344 is resolved.
>>> setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) 
>>> ... SKIPPED: The EC2 API is not available
>>> setUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... 
>>> SKIPPED: The EC2 API is not available
>>> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
>>>  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
>>>
>>> As we are actually running the volume suite according to the FAQ and the
>>> above skipped tests are documented by our CI, would it be possible to add an
>>> exception to the rule?  I'm sure these numbers will be different for all CIs
>>> and as long as people are not abusing and hiding skipped tests, I don't see
>>> this as a problem.
>>
>> There will be no exceptions. Everyone must pass the same tests or you're not 
>> an
>> approved volume driver for OpenStack Cinder.
>>
>> You should also take this bug [1] Vmware hit as a lesson of doing any
>> excluding in your CI. The driver would've been seriously broken in Kilo if 
>> this
>> wasn't caught.
>>
>> [1] - https://bugs.launchpad.net/cinder/+bug/1436603
>>
>> -- 
>> Mike Perez
>>
>> __
>> 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] [cinder] Deadline For Volume Drivers to Be Readded

On 21:45 Thu 26 Mar , Ryan Hsu wrote:
> Hmm, that's what I thought at first but when I looked at the "What tests do
> I use" FAQ, the tests that it says to use links to:
> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/volume,
> which is exactly what we're running. Even so, I ran the "tox -e all --
> volume" command and that just runs 4 more tests.

As the email that went out, it was mentioned the wiki has been corrected. It
should not just be api.volume.

There have been a number of drivers today in the #openstack-cinder that have
reported to me that they made the adjustments from the wiki and are now
reporting 294 tests. If this is not making a difference for you, I recommend
you reach out to the liasons mentioned in the wiki and get help:

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

-- 
Mike Perez

__
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] Deadline For Volume Drivers to Be Readded

On 22:42 Thu 26 Mar , Ryan Hsu wrote:
> Like I mentioned earlier, these numbers are going to be different for
> everyone depending on their testbed set up or driver capabilities. Just by
> disabling Heat in devstack you're going to miss some tests. As long as people
> are transparent about this, I don't see the harm here. 

This has nothing to do with what services you're running (e.g. heat, sahara).
If you're just running volume.api tests, you're verifying a limited number of
tests due to your discovery settings. For your convenience, here's a diff
between testing just volume.api versus tox -e all -- volume:

http://paste.openstack.org/raw/196962/

As you'll notice there is a lot of snapshot/image tests missed that should be
covered by all CI's. However Vmware is kicking off the tests, this can be
corrected without enabling any additional OpenStack services by:

tox -e all -- volume

or if you're using devstack-gate, export this before running the tests:

export DEVSTACK_GATE_TEMPEST_REGEX="volume"

All of this is explained in the Cinder wiki:

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

-- 
Mike Perez

__
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] Deadline For Volume Drivers to Be Readded

Exclusions are legitimate and will always be necessary at some point. In the 
case of the linked bug, this was once a known issue for the VMware driver and 
we had excluded affected tests so that CI could continue to run. This is the 
same way we do it in Nova CI and oslo.vmware CI. 

Thanks,
Ryan

On Mar 26, 2015, at 3:30 PM, Mike Perez  wrote:

> On 20:49 Thu 26 Mar , Ryan Hsu wrote:
>> Hi Mike,
>> 
>> We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this
>> runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests are
>> not being run due to skips and disabled features. For example, here is
>> a sampling of tests that are skipped in a recent run (note that this is using
>> tempest.conf with no explicit disabling of Cinder services):
>> 
>> tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
>>  ... SKIPPED: Block Live migration not available
>> setUpClass 
>> (tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
>> SKIPPED: Heat support is required
>> setUpClass 
>> (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
>> SKIPPED: Cinder multi-backend feature disabled
>> tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
>>  ... SKIPPED: SSH required for this test
>> setUpClass 
>> (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
>> SKIPPED: Cinder backup feature disabled
>> setUpClass 
>> (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
>> SKIPPED: Cinder backup feature disabled
>> setUpClass 
>> (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
>> SKIPPED: Cinder multi-backend feature disabled
>> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
>>  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
>> tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
>> SKIPPED: Skipped until Bug: 1205344 is resolved.
>> setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) 
>> ... SKIPPED: The EC2 API is not available
>> setUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... 
>> SKIPPED: The EC2 API is not available
>> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
>>  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
>> 
>> As we are actually running the volume suite according to the FAQ and the
>> above skipped tests are documented by our CI, would it be possible to add an
>> exception to the rule?  I'm sure these numbers will be different for all CIs
>> and as long as people are not abusing and hiding skipped tests, I don't see
>> this as a problem.
> 
> There will be no exceptions. Everyone must pass the same tests or you're not 
> an
> approved volume driver for OpenStack Cinder.
> 
> You should also take this bug [1] Vmware hit as a lesson of doing any
> excluding in your CI. The driver would've been seriously broken in Kilo if 
> this
> wasn't caught.
> 
> [1] - https://bugs.launchpad.net/cinder/+bug/1436603
> 
> -- 
> Mike Perez
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread Robert Collins

On 27 March 2015 at 09:14, Ryan Brown  wrote:

> Ooof, that's huge. If we can configure it to be less aggressive I love
> the *idea* of having everything formatted semantically, but that's a
> pretty major burden for everyone involved.

It's huge today. It wouldn't be if we did it :).

I suggest that given the other aspects of our code review system, we
might treat this like translations as a long term thing - that is
setup a job somewhere to run the autoformatter against trunk and
submit the result as a patchset.

To get over the initial hump, I'd have a human break the patch up into
per-file changes or some such.

A variation would be to have a config file saying which files are
covered, and slowly dial that up, one file at a time.

Once everything is covered, and we're dealing with commits that change
things async (via the job above), then we can talk about how to help
developers submit code using it in the first place.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] Deadline For Volume Drivers to Be Readded

Like I mentioned earlier, these numbers are going to be different for everyone 
depending on their testbed set up or driver capabilities. Just by disabling 
Heat in devstack you're going to miss some tests. As long as people are 
transparent about this, I don't see the harm here. 

-Ryan

On Mar 26, 2015, at 3:31 PM, Mike Perez  wrote:

> On 22:28 Thu 26 Mar , Tom Swanson wrote:
>> I just ran it and got ...
>> 
>> Ran: 304 tests in 412. sec.
>> - Passed: 293
>> - Skipped: 11
> 
> That looks good to me then and might've been a mistake in looking at 
> everyone's
> logs. Thanks Tom.
> 
> -- 
> Mike Perez
> 
> __
> 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][Neutron] Status of the nova-network to Neutron migration work

2015-03-26 Thread Michael Still

Hi,

I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped for in Kilo. There are a few issues which have
been slowing progress down.

First off, creating an all encompassing turn key upgrade is probably
not possible. This was also never a goal of this effort -- to quote
the spec for this work, "Consequently, the process described here is
not a “one size fits all” automated push-button tool but a series of
steps that should be obvious to automate and customise to meet local
needs" [1]. The variety of deployment and configuration options
available makes a turn key migration very hard to write, and possibly
impossible to test. We therefore have opted for writing "migration
tools", which allow operators to plug components together in the way
that makes sense for their deployment and then migrate using those.

However, talking to operators at the Ops Summit, is has become clear
that some operators simply aren't interested in moving to Neutron --
largely because they either aren't interested in tenant networks, or
have corporate network environments that make deploying Neutron very
hard. So, even if we provide migration tools, it is still likely that
we will end up with loyal nova-network users who aren't interested in
moving. From the Nova perspective, the end goal of all of this effort
is to delete the nova-network code, and if we can't do that because
some people simply don't want to move, then what is gained by putting
a lot of effort into migration tooling?

Therefore, there is some talk about spinning nova-network out into its
own project where it could continue to live on and be better
maintained than the current Nova team is able to do. However, this is
a relatively new idea and we haven't had a chance to determine how
feasible it is given where we are in the release cycle. I assume that
if we did this, we would need to find a core team passionate about
maintaining nova-network, and we would still need to provide some
migration tooling for operators who are keen to move to Neutron.
However, that migration tooling would be less critical than it is now.

Unfortunately, this has all come to a head at a time when the Nova
team is heads down getting the Kilo release out the door. We simply
don't have the time at the moment to properly consider these issues.
So, I'd like to ask for us to put a pause on this current work until
we have Kilo done. These issues are complicated and important, so I
feel we shouldn't rush them at a time we are distracted.

Finally, I want to reinforce that the position we currently find
ourselves in isn't because of a lack of effort. Oleg, Angus and Anita
have all worked very hard on this problem during Kilo, and it is
frustrating that we haven't managed to find a magic bullet to solve
all of these problems. I want to personally thank each of them for
their efforts this cycle on this relatively thankless task.

I'd appreciate other's thoughts on these issues.

Michael

1:
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/migration-from-nova-net.html#impact-limitations

--
Rackspace Australia

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

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

On 22:28 Thu 26 Mar , Tom Swanson wrote:
> I just ran it and got ...
> 
> Ran: 304 tests in 412. sec.
> - Passed: 293
> - Skipped: 11

That looks good to me then and might've been a mistake in looking at everyone's
logs. Thanks Tom.

-- 
Mike Perez

__
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] Deadline For Volume Drivers to Be Readded

On 20:49 Thu 26 Mar , Ryan Hsu wrote:
> Hi Mike,
> 
> We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this
> runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests are
> not being run due to skips and disabled features. For example, here is
> a sampling of tests that are skipped in a recent run (note that this is using
> tempest.conf with no explicit disabling of Cinder services):
> 
> tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
>  ... SKIPPED: Block Live migration not available
> setUpClass 
> (tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
> SKIPPED: Heat support is required
> setUpClass 
> (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
> SKIPPED: Cinder multi-backend feature disabled
> tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
>  ... SKIPPED: SSH required for this test
> setUpClass 
> (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
> SKIPPED: Cinder backup feature disabled
> setUpClass 
> (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
> SKIPPED: Cinder backup feature disabled
> setUpClass 
> (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
> SKIPPED: Cinder multi-backend feature disabled
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
>  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
> tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
> SKIPPED: Skipped until Bug: 1205344 is resolved.
> setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) 
> ... SKIPPED: The EC2 API is not available
> setUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... 
> SKIPPED: The EC2 API is not available
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
>  ... SKIPPED: Skipped until Bug: 1373513 is resolved.
> 
> As we are actually running the volume suite according to the FAQ and the
> above skipped tests are documented by our CI, would it be possible to add an
> exception to the rule?  I'm sure these numbers will be different for all CIs
> and as long as people are not abusing and hiding skipped tests, I don't see
> this as a problem.

There will be no exceptions. Everyone must pass the same tests or you're not an
approved volume driver for OpenStack Cinder.

You should also take this bug [1] Vmware hit as a lesson of doing any
excluding in your CI. The driver would've been seriously broken in Kilo if this
wasn't caught.

[1] - https://bugs.launchpad.net/cinder/+bug/1436603

-- 
Mike Perez

__
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] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Tom Swanson

I just ran it and got ...

Ran: 304 tests in 412. sec.
- Passed: 293
- Skipped: 11

From: Ryan Hsu [mailto:r...@vmware.com]
Sent: Thursday, March 26, 2015 4:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

Hmm, that's what I thought at first but when I looked at the "What tests do I 
use" FAQ, the tests that it says to use links to: 
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/volume, which 
is exactly what we're running. Even so, I ran the "tox -e all -- volume" 
command and that just runs 4 more tests.

-Ryan

[1] 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

On Mar 26, 2015, at 1:56 PM, Tom Swanson 
mailto:tom_swan...@dell.com>> wrote:

You want to run the "volume" tests and not "tempest.api.volume" tests.

-Original Message-
From: Ryan Hsu [mailto:r...@vmware.com]
Sent: Thursday, March 26, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

Hi Mike,

We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this 
runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests are 
not being run due to skips and disabled features. For example, here is a 
sampling of tests that are skipped in a recent run (note that this is using 
tempest.conf with no explicit disabling of Cinder services):

tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
 ... SKIPPED: Block Live migration not available setUpClass 
(tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
SKIPPED: Heat support is required setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
SKIPPED: Cinder multi-backend feature disabled 
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
 ... SKIPPED: SSH required for this test setUpClass 
(tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
SKIPPED: Cinder backup feature disabled setUpClass 
(tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
SKIPPED: Cinder backup feature disabled setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
SKIPPED: Cinder multi-backend feature disabled 
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.
tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
SKIPPED: Skipped until Bug: 1205344 is resolved.
setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) ... 
SKIPPED: The EC2 API is not available setUpClass 
(tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... SKIPPED: The EC2 
API is not available 
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.

As we are actually running the volume suite according to the FAQ and the above 
skipped tests are documented by our CI, would it be possible to add an 
exception to the rule?  I'm sure these numbers will be different for all CIs 
and as long as people are not abusing and hiding skipped tests, I don't see 
this as a problem.

Thanks,
Ryan

On Mar 26, 2015, at 9:39 AM, Mike Perez 
mailto:thin...@gmail.com>> wrote:

As discussed in the last Cinder meeting [1], in order to have your
volume driver readded into the Kilo release, you must have a CI
reporting and stable for five days prior to 4/6.

This includes:

1) Providing logs to screen sessions, etc configs, tempest output [2].
2) You should be running around 304 tests if you're following instructions from
 the Cinder third party wiki [3]. If you're running less than that, your CI
 will be *NOT* be considered satisfactory for skipping tests.

I will also be emailing individuals who have already asked for
exceptions, just to make sure communication was clear.

[1] -
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-
16.00.log.html#l-173 [2] -
http://ci.openstack.org/third_party.html#requirements
[3] -
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_te
sts_do_I_use.3F

--
Mike Perez

__
 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://li

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

Hmm, that's what I thought at first but when I looked at the "What tests do I 
use" FAQ, the tests that it says to use links to: 
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/volume, which 
is exactly what we're running. Even so, I ran the "tox -e all -- volume" 
command and that just runs 4 more tests.

-Ryan

[1] 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

On Mar 26, 2015, at 1:56 PM, Tom Swanson 
mailto:tom_swan...@dell.com>> wrote:

You want to run the "volume" tests and not "tempest.api.volume" tests.

-Original Message-
From: Ryan Hsu [mailto:r...@vmware.com]
Sent: Thursday, March 26, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

Hi Mike,

We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this 
runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests are 
not being run due to skips and disabled features. For example, here is a 
sampling of tests that are skipped in a recent run (note that this is using 
tempest.conf with no explicit disabling of Cinder services):

tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
 ... SKIPPED: Block Live migration not available setUpClass 
(tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
SKIPPED: Heat support is required setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
SKIPPED: Cinder multi-backend feature disabled 
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
 ... SKIPPED: SSH required for this test setUpClass 
(tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
SKIPPED: Cinder backup feature disabled setUpClass 
(tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
SKIPPED: Cinder backup feature disabled setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
SKIPPED: Cinder multi-backend feature disabled 
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.
tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
SKIPPED: Skipped until Bug: 1205344 is resolved.
setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) ... 
SKIPPED: The EC2 API is not available setUpClass 
(tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... SKIPPED: The EC2 
API is not available 
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.

As we are actually running the volume suite according to the FAQ and the above 
skipped tests are documented by our CI, would it be possible to add an 
exception to the rule?  I'm sure these numbers will be different for all CIs 
and as long as people are not abusing and hiding skipped tests, I don't see 
this as a problem.

Thanks,
Ryan

On Mar 26, 2015, at 9:39 AM, Mike Perez 
mailto:thin...@gmail.com>> wrote:

As discussed in the last Cinder meeting [1], in order to have your
volume driver readded into the Kilo release, you must have a CI
reporting and stable for five days prior to 4/6.

This includes:

1) Providing logs to screen sessions, etc configs, tempest output [2].
2) You should be running around 304 tests if you're following instructions from
 the Cinder third party wiki [3]. If you're running less than that, your CI
 will be *NOT* be considered satisfactory for skipping tests.

I will also be emailing individuals who have already asked for
exceptions, just to make sure communication was clear.


[1] -
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-
16.00.log.html#l-173 [2] -
http://ci.openstack.org/third_party.html#requirements
[3] -
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_te
sts_do_I_use.3F

--
Mike Perez

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


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

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

_

[openstack-dev] Volunteers Needed for OpenStack Booth at PyCon

2015-03-26 Thread Stefano Maffulli

Volunteers Needed for OpenStack Booth

We are looking for 3 more knowledgeable volunteers who can staff the
OpenStack booth in shifts (see the booth schedule below).  If you are
available and have at least one year of experience contributing to or
using OpenStack, please email ridolfoden...@gmail.com. We have free
sponsor passes available.  

Details of the show, schedule and peak times on the show floor are on
https://etherpad.openstack.org/p/pycon-2015-booth

If you are interested in helping, please add your name to the etherpad
in the time slot you'd be available.

Thanks,
Stef

PyCon Event details:
Location: Palais des Congres Montreal Convention Center in Montreal,
Canada 
Show Dates: April 8-16, 2015
Exhibit Hall Dates: April 9-11, 2015




__
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] Tracking ideas for summit sessions

2015-03-26 Thread Michael Still

Hi,

let's start tracking ideas for summit sessions in this etherpad:

https://etherpad.openstack.org/p/liberty-nova-summit-ideas

Have at it!

Cheers,
Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Tom Swanson

You want to run the "volume" tests and not "tempest.api.volume" tests.

-Original Message-
From: Ryan Hsu [mailto:r...@vmware.com] 
Sent: Thursday, March 26, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

Hi Mike,

We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this 
runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests are 
not being run due to skips and disabled features. For example, here is a 
sampling of tests that are skipped in a recent run (note that this is using 
tempest.conf with no explicit disabling of Cinder services):

tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
 ... SKIPPED: Block Live migration not available setUpClass 
(tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) ... 
SKIPPED: Heat support is required setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
SKIPPED: Cinder multi-backend feature disabled 
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
 ... SKIPPED: SSH required for this test setUpClass 
(tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) ... 
SKIPPED: Cinder backup feature disabled setUpClass 
(tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) ... 
SKIPPED: Cinder backup feature disabled setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
SKIPPED: Cinder multi-backend feature disabled 
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
 ... SKI
 PPED: Skipped until Bug: 1373513 is resolved.
tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
SKIPPED: Skipped until Bug: 1205344 is resolved.
setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) ... 
SKIPPED: The EC2 API is not available setUpClass 
(tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... SKIPPED: The EC2 
API is not available 
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.

As we are actually running the volume suite according to the FAQ and the above 
skipped tests are documented by our CI, would it be possible to add an 
exception to the rule?  I'm sure these numbers will be different for all CIs 
and as long as people are not abusing and hiding skipped tests, I don't see 
this as a problem.

Thanks,
Ryan

On Mar 26, 2015, at 9:39 AM, Mike Perez  wrote:

> As discussed in the last Cinder meeting [1], in order to have your 
> volume driver readded into the Kilo release, you must have a CI 
> reporting and stable for five days prior to 4/6.
> 
> This includes:
> 
> 1) Providing logs to screen sessions, etc configs, tempest output [2].
> 2) You should be running around 304 tests if you're following instructions 
> from
>   the Cinder third party wiki [3]. If you're running less than that, your CI
>   will be *NOT* be considered satisfactory for skipping tests.
> 
> I will also be emailing individuals who have already asked for 
> exceptions, just to make sure communication was clear.
> 
> 
> [1] - 
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-
> 16.00.log.html#l-173 [2] - 
> http://ci.openstack.org/third_party.html#requirements
> [3] - 
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_te
> sts_do_I_use.3F
> 
> --
> Mike Perez
> 
> __
>  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] [cinder] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Marcus Vinícius Ramires do Nascimento

Hi Mike,

We (VMware CI) run "testr run tempest.api.volume" for our Cinder CI and this 
runs about ~240 tests for us. I'm guessing that the rest of the ~60 tests are 
not being run due to skips and disabled features. For example, here is a 
sampling of tests that are skipped in a recent run (note that this is using 
tempest.conf with no explicit disabling of Cinder services):

tempest.api.compute.test_live_block_migration.LiveBlockMigrationTestJSON.test_iscsi_volume
 ... SKIPPED: Block Live migration not available
setUpClass (tempest.api.orchestration.stacks.test_volumes.CinderResourcesTest) 
... SKIPPED: Heat support is required
setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV2Test) ... 
SKIPPED: Cinder multi-backend feature disabled
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume
 ... SKIPPED: SSH required for this test
setUpClass (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV1Test) 
... SKIPPED: Cinder backup feature disabled
setUpClass (tempest.api.volume.admin.test_volumes_backup.VolumesBackupsV2Test) 
... SKIPPED: Cinder backup feature disabled
setUpClass 
(tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendV1Test) ... 
SKIPPED: Cinder multi-backend feature disabled
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.
tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern ... 
SKIPPED: Skipped until Bug: 1205344 is resolved.
setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) ... 
SKIPPED: The EC2 API is not available
setUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest) ... 
SKIPPED: The EC2 API is not available
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
 ... SKIPPED: Skipped until Bug: 1373513 is resolved.

As we are actually running the volume suite according to the FAQ and the above 
skipped tests are documented by our CI, would it be possible to add an 
exception to the rule?  I'm sure these numbers will be different for all CIs 
and as long as people are not abusing and hiding skipped tests, I don't see 
this as a problem.

Thanks,
Ryan

On Mar 26, 2015, at 9:39 AM, Mike Perez  wrote:

> As discussed in the last Cinder meeting [1], in order to have your volume
> driver readded into the Kilo release, you must have a CI reporting and stable
> for five days prior to 4/6.
> 
> This includes:
> 
> 1) Providing logs to screen sessions, etc configs, tempest output [2].
> 2) You should be running around 304 tests if you're following instructions 
> from
>   the Cinder third party wiki [3]. If you're running less than that, your CI
>   will be *NOT* be considered satisfactory for skipping tests.
> 
> I will also be emailing individuals who have already asked for exceptions, 
> just
> to make sure communication was clear.
> 
> 
> [1] - 
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
> [2] - http://ci.openstack.org/third_party.html#requirements
> [3] - 
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
> 
> -- 
> Mike Perez
> 
> __
> 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] [heat] heat delete woes in Juno

2015-03-26 Thread Zane Bitter


On 26/03/15 15:56, Matt Fischer wrote:

We don't have heat stack-abandon enabled. It's marked as a "preview
feature", have you had any issues?


It's fairly safe for this use case. If it's important for you that you 
don't lose track of your resources and you want to adopt them again 
later, it's a bit more dicey:


https://bugs.launchpad.net/heat/+bugs?field.tag=abandon-adopt


Once you abandon the stack I assume
you remove the resources outside of heat using nova/neutron etc?


Correct.

- ZB


On Thu, Mar 26, 2015 at 1:15 PM, Ala Rezmerita
mailto:ala.rezmer...@cloudwatt.com>> wrote:

Hi Matt

I had similar problems with heat, and the work-around that i used is
to abandon the stack (heat stack-abandon),
and then I delete stack resources created  one by one.

Hope this helps.

Ala Rezmerita
Software Engineer || Cloudwatt
M: (+33) 06 77 43 23 91 
Immeuble Etik
892 rue Yves Kermen
92100 Boulogne-Billancourt – France


*De: *"Matt Fischer" mailto:m...@mattfischer.com>>
*À: *openstack-dev@lists.openstack.org

*Envoyé: *Jeudi 26 Mars 2015 19:17:08
*Objet: *[openstack-dev] [heat] heat delete woes in Juno


Nobody on the operators list had any ideas on this, so re-posting here.

We've been having some issues with heatdelete-stack in Juno. The
issues generally fall into three categories:

1) it takes multiple calls to heat to delete a stack. Presumably due
to heat being unable to figure out the ordering on deletion and
resources being in use.

2) undeleteable stacks. Stacks that refuse to delete, get stuck in
DELETE_FAILED state. In this case, they show up in stack-list and
stack-show, yet resource-list and stack-delete deny their existence.
This means I can't be sure whether they have any real resources very
easily.

3) As a corollary to item 1, stacks for which heat can never unwind
the dependencies and stay in DELETE_IN_PROGRESS forever.

Does anyone have any work-arounds for these or recommendations on
cleanup? My main worry is removing a stack from the database that is
still consuming the customer's resources. I also don't just want to
remove stacks from the database and leave orphaned records in the DB.

__
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] [API] Do we need to specify "follow the HTTP RFCs"?

2015-03-26 Thread Everett Toews

Top posting the relevant review https://review.openstack.org/#/c/161946/

Everett


On Feb 13, 2015, at 8:44 AM, michael mccune 
mailto:m...@redhat.com>> wrote:

On 02/12/2015 02:20 PM, Ryan Brown wrote:
+1 I think the way to go would be:

"We suggest (pretty please) that you comply with RFCs 7230-5 and if you
have any questions ask us. Also here are some examples of usage that
is/isn't RFC compliant for clarity"


+1, i like the idea of pointing readers towards the RFCs but also providing 
examples.

mike

__
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] [Heat] Decoupling Heat integration tests from Heat tree

2015-03-26 Thread Zane Bitter


On 26/03/15 10:38, Pavlo Shchelokovskyy wrote:

Hi all,

following IRC discussion here is a summary of what I propose can be done
in this regard, in the order of increased decoupling:

1) make a separate requirements.txt for integration tests and modify the
tox job to use it. The code of these tests is pretty much decoupled
already, not using any modules from the main heat tree. The actual
dependencies are mostly api clients and test framework. Making this
happen should decrease the time needed to setup the tox env and thus
speed up the test run somewhat.


+1


2) provide separate distutils' setup.py/setup.cfg
 to ease packaging and installing this test
suit to run it against an already deployed cloud (especially scenario
tests seem to be valuable in this regard).


+1


3) move the integration tests to a separate repo and use it as git
submodule in the main tree. The main reasons not to do it as far as I've
collected are not being able to provide code change and test in the same
(or dependent) commits, and lesser reviewers' attention to a separate repo.


-0

I'm not sure what the advantage is here, and there are a bunch of 
downsides (basically, I agree with Ryan). Unfortunately I missed the IRC 
discussion, can you elaborate on how decoupling to this degree might 
help us?


cheers,
Zane.


What do you think about it? Please share your comments.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com 


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




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

Re: [openstack-dev] [Heat][qa][tempest] Decoupling Heat integration tests from Heat tree

2015-03-26 Thread Steve Baker


On 27/03/15 03:38, Pavlo Shchelokovskyy wrote:

Hi all,

following IRC discussion here is a summary of what I propose can be 
done in this regard, in the order of increased decoupling:


1) make a separate requirements.txt for integration tests and modify 
the tox job to use it. The code of these tests is pretty much 
decoupled already, not using any modules from the main heat tree. The 
actual dependencies are mostly api clients and test framework. Making 
this happen should decrease the time needed to setup the tox env and 
thus speed up the test run somewhat.



Lets at least do this
2) provide separate distutils' setup.py/setup.cfg 
 to ease packaging and installing this test 
suit to run it against an already deployed cloud (especially scenario 
tests seem to be valuable in this regard).


3) move the integration tests to a separate repo and use it as git 
submodule in the main tree. The main reasons not to do it as far as 
I've collected are not being able to provide code change and test in 
the same (or dependent) commits, and lesser reviewers' attention to a 
separate repo.


What do you think about it? Please share your comments.


Before we choose an approach here I'd like to wait for some common 
(tempest-lib based?) solution to emerge. Since tests are dis-aggregating 
out of tempest into project trees then ideally users will need a 
convenient way of pulling in all the tests they want to run on their cloud.
__
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][stable][OSSA 2015-005] Nova console Cross-Site WebSocket hijacking (CVE-2015-0259)

2015-03-26 Thread Jeremy Stanley

On 2015-03-26 14:29:03 -0400 (-0400), Lars Kellogg-Stedman wrote:
[...]
> The solution, of course, is to make sure that the value of
> novncproxy_base_url is set explicitly where the nova-novncproxy
> service is running. This is a bit of a hack, since the service
> *really* only cares about the protocol portion of the URL,
> suggesting that maybe a new configuration option would have been a
> less intrusive solution.
[...]

Thanks for the heads up. The developers working to backport security
fixes to stable branches try to come up with ways to have them
automatically applicable without configuration changes on the part
of the deployers consuming them. Sometimes it's possible, sometimes
it's not, and sometimes they think it is but turn out in retrospect
to have introduced an unintended behavior change. Unfortunately I
think that last possibility is what happened for this bug[1].

It's worth bringing this to the attention of the Nova developers who
implemented the original fix to see if there's a better stable
solution which achieves the goal of protecting deployments where
operators aren't likely to update their configuration while still
maintaining consistent behavior. To that end, I'm Cc'ing the
openstack-dev list, setting MFT and tagging the subject accordingly.

[1] https://launchpad.net/bugs/1409142
-- 
Jeremy Stanley

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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread Ryan Brown

On 03/26/2015 02:15 PM, Kiall Mac Innes wrote:
> I have no clue how I managed to send that last email encrypted -
> Apologies :)
> 
> Re YAPF, or autofomatting, I've very little opinion..
> 
> But - I gave YAPF a go against the Designate codebase with the stock config:
> 
>   258 files changed, 5242 insertions(+), 5691 deletions(-)
> 
> Getting changes like that into the various projects won't be easy, even
> if the core team is happy to just +A without reviewing for potential
> issues, a massive percentage of in-progress reviews will fail to merge
> and need manual rebasing.
> 
> For companies with internal forks/patches - those will likely all have
> to be redone too..

Ooof, that's huge. If we can configure it to be less aggressive I love
the *idea* of having everything formatted semantically, but that's a
pretty major burden for everyone involved.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

2015-03-26 Thread Ryan Brown

On 03/26/2015 10:38 AM, Pavlo Shchelokovskyy wrote:
> Hi all,
> 
> following IRC discussion here is a summary of what I propose can be
> done in this regard, in the order of increased decoupling:
> 
> 1) make a separate requirements.txt for integration tests and modify
> the tox job to use it. The code of these tests is pretty much
> decoupled already, not using any modules from the main heat tree. The
> actual dependencies are mostly api clients and test framework. Making
> this happen should decrease the time needed to setup the tox env and
> thus speed up the test run somewhat.

+1 for this

> 2) provide separate distutils' setup.py/setup.cfg to ease packaging
> and installing this test suit to run it against an already deployed
> cloud (especially scenario tests seem to be valuable in this
> regard).

I quite like this idea, the value here is pretty apparent & in the
spirit of the separate requirements.txt.

> 3) move the integration tests to a separate repo and use it as git 
> submodule in the main tree. The main reasons not to do it as far as
> I've collected are not being able to provide code change and test in
> the same (or dependent) commits, and lesser reviewers' attention to a
> separate repo.

It's also important for local development workflow to have an up-to-date
version of the project's tests and having them shuffled out to a
submodule would make it exceptionally easy to forget "submodule pull"
and end up missing tests. This is, of course, in addition to your (all
valid) reasons for avoiding submodules.

> 
> What do you think about it? Please share your comments.
> 
> Best regards,
> 
> Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com
> 

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [heat] heat delete woes in Juno

2015-03-26 Thread pcrews


Regarding item #3:
I have mainly seen this issue on stacks that have been snapshotted:
https://bugs.launchpad.net/heat/+bug/1412965

In such cases, the only way to avoid (afaik) is for the owner to 
manually delete the snapshots prior to deleting the stack.  Heat tries 
to auto-delete snapshots and hangs otherwise.


On 03/26/2015 11:17 AM, Matt Fischer wrote:

Nobody on the operators list had any ideas on this, so re-posting here.

We've been having some issues with heatdelete-stack in Juno. The issues
generally fall into three categories:

1) it takes multiple calls to heat to delete a stack. Presumably due
to heat being unable to figure out the ordering on deletion and
resources being in use.

2) undeleteable stacks. Stacks that refuse to delete, get stuck in
DELETE_FAILED state. In this case, they show up in stack-list and
stack-show, yet resource-list and stack-delete deny their existence.
This means I can't be sure whether they have any real resources very easily.

3) As a corollary to item 1, stacks for which heat can never unwind the
dependencies and stay in DELETE_IN_PROGRESS forever.

Does anyone have any work-arounds for these or recommendations on
cleanup? My main worry is removing a stack from the database that is
still consuming the customer's resources. I also don't just want to
remove stacks from the database and leave orphaned records in the DB.


__
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] [heat] heat delete woes in Juno

2015-03-26 Thread Matt Fischer

We don't have heat stack-abandon enabled. It's marked as a "preview
feature", have you had any issues? Once you abandon the stack I assume you
remove the resources outside of heat using nova/neutron etc?

On Thu, Mar 26, 2015 at 1:15 PM, Ala Rezmerita 
wrote:

> Hi Matt
>
> I had similar problems with heat, and the work-around that i used is to
> abandon the stack (heat stack-abandon),
> and then I delete stack resources created  one by one.
>
> Hope this helps.
>
> Ala Rezmerita
> Software Engineer || Cloudwatt
> M: (+33) 06 77 43 23 91
> Immeuble Etik
> 892 rue Yves Kermen
> 92100 Boulogne-Billancourt – France
>
> --
> *De: *"Matt Fischer" 
> *À: *openstack-dev@lists.openstack.org
> *Envoyé: *Jeudi 26 Mars 2015 19:17:08
> *Objet: *[openstack-dev] [heat] heat delete woes in Juno
>
>
> Nobody on the operators list had any ideas on this, so re-posting here.
>
> We've been having some issues with heat delete-stack in Juno. The issues
> generally fall into three categories:
>
> 1) it takes multiple calls to heat to delete a stack. Presumably due
> to heat being unable to figure out the ordering on deletion and resources
> being in use.
>
> 2) undeleteable stacks. Stacks that refuse to delete, get stuck in
> DELETE_FAILED state. In this case, they show up in stack-list and
> stack-show, yet resource-list and stack-delete deny their existence. This
> means I can't be sure whether they have any real resources very easily.
>
> 3) As a corollary to item 1, stacks for which heat can never unwind the
> dependencies and stay in DELETE_IN_PROGRESS forever.
>
> Does anyone have any work-arounds for these or recommendations on cleanup?
> My main worry is removing a stack from the database that is still consuming
> the customer's resources. I also don't just want to remove stacks from the
> database and leave orphaned records in the DB.
>
> __
> 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] [heat] heat delete woes in Juno

2015-03-26 Thread Matt Fischer

I will try to gather up these templates and post them somewhere once I
scrub any company specific stuff. Might be a day or so. Thanks!

On Thu, Mar 26, 2015 at 12:40 PM, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi Matt,
>
> if it would be feasible/appropriate, could you provide us with templates
> for stacks that show this behavior (try to get them with "heat
> template-show ")? This would help us to test and
> understand the problem better.
>
> And yes, just the day before I was contacted by one of my colleagues who
> seems to experience similar problems with Juno-based OpenStack deployment
> (though I did not had a chance to look through the issue yet).
>
> Best regards,
>
> Pavlo Shchelokovskyy
> Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Thu, Mar 26, 2015 at 8:17 PM, Matt Fischer 
> wrote:
>
>> Nobody on the operators list had any ideas on this, so re-posting here.
>>
>> We've been having some issues with heat delete-stack in Juno. The issues
>> generally fall into three categories:
>>
>> 1) it takes multiple calls to heat to delete a stack. Presumably due
>> to heat being unable to figure out the ordering on deletion and resources
>> being in use.
>>
>> 2) undeleteable stacks. Stacks that refuse to delete, get stuck in
>> DELETE_FAILED state. In this case, they show up in stack-list and
>> stack-show, yet resource-list and stack-delete deny their existence. This
>> means I can't be sure whether they have any real resources very easily.
>>
>> 3) As a corollary to item 1, stacks for which heat can never unwind the
>> dependencies and stay in DELETE_IN_PROGRESS forever.
>>
>> Does anyone have any work-arounds for these or recommendations on
>> cleanup? My main worry is removing a stack from the database that is still
>> consuming the customer's resources. I also don't just want to remove stacks
>> from the database and leave orphaned records in the DB.
>>
>> __
>> 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] [heat] heat delete woes in Juno

2015-03-26 Thread Georgy Okrokvertskhov

I attached an example of the template which is hanging right now in my Juno
environment. I believe it hangs because of floating ip stuff and the way
how it is attached to a VM.
It is autogenerated, so please don't be disturbed by strange resource names.

Thanks
Gosha

On Thu, Mar 26, 2015 at 12:15 PM, Ala Rezmerita  wrote:

> Hi Matt
>
> I had similar problems with heat, and the work-around that i used is to
> abandon the stack (heat stack-abandon),
> and then I delete stack resources created  one by one.
>
> Hope this helps.
>
> Ala Rezmerita
> Software Engineer || Cloudwatt
> M: (+33) 06 77 43 23 91
> Immeuble Etik
> 892 rue Yves Kermen
> 92100 Boulogne-Billancourt – France
>
> --
> *De: *"Matt Fischer" 
> *À: *openstack-dev@lists.openstack.org
> *Envoyé: *Jeudi 26 Mars 2015 19:17:08
> *Objet: *[openstack-dev] [heat] heat delete woes in Juno
>
>
> Nobody on the operators list had any ideas on this, so re-posting here.
>
> We've been having some issues with heat delete-stack in Juno. The issues
> generally fall into three categories:
>
> 1) it takes multiple calls to heat to delete a stack. Presumably due
> to heat being unable to figure out the ordering on deletion and resources
> being in use.
>
> 2) undeleteable stacks. Stacks that refuse to delete, get stuck in
> DELETE_FAILED state. In this case, they show up in stack-list and
> stack-show, yet resource-list and stack-delete deny their existence. This
> means I can't be sure whether they have any real resources very easily.
>
> 3) As a corollary to item 1, stacks for which heat can never unwind the
> dependencies and stay in DELETE_IN_PROGRESS forever.
>
> Does anyone have any work-arounds for these or recommendations on cleanup?
> My main worry is removing a stack from the database that is still consuming
> the customer's resources. I also don't just want to remove stacks from the
> database and leave orphaned records in the DB.
>
> __
> 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
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284


problematic-stack.hot
Description: Binary data
__
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][cells] Meeting time change

2015-03-26 Thread Sylvain Bauza

Le 26 mars 2015 17:20, "Andrew Laski"  a écrit :
>
> Daylight saving time has made it so that the 2200UTC meeting time is
fairly inconvenient for a few of us and the 2100UTC timeslot is open so
we're going to shift the meeting up by an hour.  I have already spoken with
many of the people in regular attendance at the meetings so this should
come as little surprise.  See you all next week at 2100!
>

Nice, thank you on behalf of EU people ;-)
> __
> 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] [heat] heat delete woes in Juno

2015-03-26 Thread Ala Rezmerita

Hi Matt 

I had similar problems with heat, and the work-around that i used is to abandon 
the stack (heat stack-abandon), 
and then I delete stack resources created one by one. 

Hope this helps. 

Ala Rezmerita 
Software Engineer || Cloudwatt 
M: (+33) 06 77 43 23 91 
Immeuble Etik 
892 rue Yves Kermen 
92100 Boulogne-Billancourt – France 

- Mail original -

De: "Matt Fischer"  
À: openstack-dev@lists.openstack.org 
Envoyé: Jeudi 26 Mars 2015 19:17:08 
Objet: [openstack-dev] [heat] heat delete woes in Juno 

Nobody on the operators list had any ideas on this, so re-posting here. 

We've been having some issues with heat delete -stack in Juno. The issues 
generally fall into three categories: 

1) it takes multiple calls to heat to delete a stack. Presumably due to heat 
being unable to figure out the ordering on deletion and resources being in use. 

2) undeleteable stacks. Stacks that refuse to delete, get stuck in 
DELETE_FAILED state. In this case, they show up in stack-list and stack-show, 
yet resource-list and stack-delete deny their existence. This means I can't be 
sure whether they have any real resources very easily. 

3) As a corollary to item 1, stacks for which heat can never unwind the 
dependencies and stay in DELETE_IN_PROGRESS forever. 

Does anyone have any work-arounds for these or recommendations on cleanup? My 
main worry is removing a stack from the database that is still consuming the 
customer's resources. I also don't just want to remove stacks from the database 
and leave orphaned records in the DB. 

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

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

[openstack-dev] [all] FYI:VPNaaS APIs moving from experimental to current

2015-03-26 Thread Paul Michali

The VPNaaS APIs have been unchanged for over a year and were last marked as
"experimental". Bug 1433561 is restoring the VPNaaS API reference
documentation (was lost in a site update). As part of the review [1], there
was some discussion about the experimental status, and so the status was
changed to CURRENT.

If there are any other actions that are needed to make this transition (or
that would prevent it), please comment in the review and reply to this
message. Otherwise, we can mark this API as current.

Regards,

Paul Michali

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

Re: [openstack-dev] [heat] heat delete woes in Juno

2015-03-26 Thread Pavlo Shchelokovskyy

Hi Matt,

if it would be feasible/appropriate, could you provide us with templates
for stacks that show this behavior (try to get them with "heat
template-show ")? This would help us to test and
understand the problem better.

And yes, just the day before I was contacted by one of my colleagues who
seems to experience similar problems with Juno-based OpenStack deployment
(though I did not had a chance to look through the issue yet).

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Mar 26, 2015 at 8:17 PM, Matt Fischer  wrote:

> Nobody on the operators list had any ideas on this, so re-posting here.
>
> We've been having some issues with heat delete-stack in Juno. The issues
> generally fall into three categories:
>
> 1) it takes multiple calls to heat to delete a stack. Presumably due
> to heat being unable to figure out the ordering on deletion and resources
> being in use.
>
> 2) undeleteable stacks. Stacks that refuse to delete, get stuck in
> DELETE_FAILED state. In this case, they show up in stack-list and
> stack-show, yet resource-list and stack-delete deny their existence. This
> means I can't be sure whether they have any real resources very easily.
>
> 3) As a corollary to item 1, stacks for which heat can never unwind the
> dependencies and stay in DELETE_IN_PROGRESS forever.
>
> Does anyone have any work-arounds for these or recommendations on cleanup?
> My main worry is removing a stack from the database that is still consuming
> the customer's resources. I also don't just want to remove stacks from the
> database and leave orphaned records in the DB.
>
> __
> 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] [heat] heat delete woes in Juno

2015-03-26 Thread Matt Fischer

Nobody on the operators list had any ideas on this, so re-posting here.

We've been having some issues with heat delete-stack in Juno. The issues
generally fall into three categories:

1) it takes multiple calls to heat to delete a stack. Presumably due
to heat being unable to figure out the ordering on deletion and resources
being in use.

2) undeleteable stacks. Stacks that refuse to delete, get stuck in
DELETE_FAILED state. In this case, they show up in stack-list and
stack-show, yet resource-list and stack-delete deny their existence. This
means I can't be sure whether they have any real resources very easily.

3) As a corollary to item 1, stacks for which heat can never unwind the
dependencies and stay in DELETE_IN_PROGRESS forever.

Does anyone have any work-arounds for these or recommendations on cleanup?
My main worry is removing a stack from the database that is still consuming
the customer's resources. I also don't just want to remove stacks from the
database and leave orphaned records in the DB.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread Kiall Mac Innes

I have no clue how I managed to send that last email encrypted -
Apologies :)

Re YAPF, or autofomatting, I've very little opinion..

But - I gave YAPF a go against the Designate codebase with the stock config:

  258 files changed, 5242 insertions(+), 5691 deletions(-)

Getting changes like that into the various projects won't be easy, even
if the core team is happy to just +A without reviewing for potential
issues, a massive percentage of in-progress reviews will fail to merge
and need manual rebasing.

For companies with internal forks/patches - those will likely all have
to be redone too..

I'm not sure there's really a good solution to this

Thanks,
Kiall

On 26/03/15 16:38, Kiall Mac Innes wrote:
> 
> 
> __
> 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] [cinder] Deadline For Volume Drivers to Be Readded

I'm not sure if I was clear... The driver is OK and snapshots are working
as expected. I'm working on get all CI tests back (304 tests).

On Thu, Mar 26, 2015 at 3:10 PM, Marcus Vinícius Ramires do Nascimento <
marcus...@gmail.com> wrote:

> Hi Mike,
>
> I'm working on it! The bug was fixed and now I'm working to get all
> tempest.api.volume tests back again on our CI, including also the tests
> that were missing.
>
> On Thu, Mar 26, 2015 at 3:00 PM, Mike Perez  wrote:
>
>> On 14:38 Thu 26 Mar , Erlon Cruz wrote:
>> 
>>
>> > Our HBSD drivers are only running 211 because we remove the snapshots
>> tests
>> > that were failing due a  patch that broken our driver.
>>
>> Whats being done about that in Kilo? That's a minimum feature required
>> for all
>> drivers in Cinder:
>>
>>
>> http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features
>>
>> --
>> Mike Perez
>>
>> __
>> 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
>>
>
>
>
> --
> *Marcus Vinícius Ramires do Nascimento*
> marcus...@gmail.com
>
> Cel: (11) 97396-4018
>



-- 
*Marcus Vinícius Ramires do Nascimento*
marcus...@gmail.com

Cel: (11) 97396-4018
__
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] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Marcus Vinícius Ramires do Nascimento

Hi Mike,

I'm working on it! The bug was fixed and now I'm working to get all
tempest.api.volume tests back again on our CI, including also the tests
that were missing.

On Thu, Mar 26, 2015 at 3:00 PM, Mike Perez  wrote:

> On 14:38 Thu 26 Mar , Erlon Cruz wrote:
> 
>
> > Our HBSD drivers are only running 211 because we remove the snapshots
> tests
> > that were failing due a  patch that broken our driver.
>
> Whats being done about that in Kilo? That's a minimum feature required for
> all
> drivers in Cinder:
>
>
> http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features
>
> --
> Mike Perez
>
> __
> 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
>



-- 
*Marcus Vinícius Ramires do Nascimento*
marcus...@gmail.com

Cel: (11) 97396-4018
__
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] Deadline For Volume Drivers to Be Readded

On 14:38 Thu 26 Mar , Erlon Cruz wrote:


> Our HBSD drivers are only running 211 because we remove the snapshots tests
> that were failing due a  patch that broken our driver.

Whats being done about that in Kilo? That's a minimum feature required for all
drivers in Cinder:

http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features

-- 
Mike Perez

__
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] [api][neutron] Best API for generating subnets from pool

2015-03-26 Thread Kevin Benton

Right now we force tenants choose a CIDR even if they don't care what
address they get. This allows them to skip that required input.

More importantly, if the network is fully routed, not only do tenants not
know which CIDR to configure, allowing them to choose arbitrary CIDRs can
disrupt the entire network.

This workflow isn't stopping the old one from working, it's just enabling
new deployments that basically weren't feasible before since we had an
implicit requirement that the tenants could configure whatever addresses
they wanted.
On Mar 26, 2015 10:23 AM, "Neil Jerram"  wrote:

> Salvatore Orlando  writes:
>
> > Neutron is adding a new concept of "subnet pool". [...]
>
> >
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html
>
> I apologize for asking this question so long after this spec has been
> proposed and discussed - but what is the problem that subnet allocation
> solves?  Or what is it possible to do with subnet allocation, that was
> not possible before?
>
> Of course the spec has text to address this, but for me it doesn't
> actually answer the above questions:
>
> Problem Description
>
> IPAM in Neutron cannot allocate subnets. Subnet details must be
> specified by the End User at the time of subnet creation.
>
> This seems to me to be restating the premise.
>
> End Users may want to offload the burden of keeping track of subnets
> and which addresses are in use. In this case, the End User should be
> able to set up a private address space from which these are
> automatically allocated.
>
> This sounds to me like what already happens.  When I launch a set of
> instances, I simply specify which subnet to use for each of their
> vNICs.  The Neutron DB keeps track of which addresses are in use, so I
> don't see any burden here.
>
> For IPv4, this will often be a portion of
> the RFC1918 address space but doesn’t need to be. It might be part
> of a corporate address space which has been delegated to the
> cloud. For IPv6, the End User may want Neutron to automatically
> calculate a useable ULA subnet using a pseudo-random algorithm in
> harmony with RFC4193 [1].
>
> This seems equivalent to configuring that usable subnet explicitly and
> then launching instances that are attached to its network.
>
> This implies that the algorithm for the selection of subnets within
> the space is pluggable in some way.
>
> [1] http://tools.ietf.org/html/rfc4193
>
> Deployers will set up external networks and may have a chunk of
> routable addresses that could be leased or delegated to tenants for
> use on their networks.
>
> And that could presumably be configured as subnets?
>
> Neutron needs an API for creating and managaging address spaces and
> making them available to tenants.
>
> I can certainly see the value in address spaces (or scopes) as a
> distinct concept from tenants - if that is what this is saying.  But I
> believe that's an independent concept from the idea of changing from
> explicit subnet configuration to subnet allocation, because it would be
> possible for an operator or tenant to configure a subnet within one of
> the address spaces that was available to them.
>
> Many thanks, and apologies again for asking this so late in the game.
>
> Regards,
> Neil
>
>
> __
> 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] [cinder] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread Erlon Cruz

Hi Mike,

The majority of the CIs don't run all 304 tests mostly because of these
tempest problems. I remember there was a list in the Thirdparty CI Wiki
with the common tests that used to fails to everyone, or at least most of
people.  IMO its better to have a more consistent CI than CIs with full
coverage giving lots of false negatives. Don't how much of the tests from
that list are fixed on tempest but we should bring that list up again and
reconsider to have the list of 'known to fail' tests.

Our HBSD drivers are only running 211 because we remove the snapshots tests
that were failing due a  patch that broken our driver.


>
On Thu, Mar 26, 2015 at 2:21 PM, Mike Perez  wrote:

> On 09:39 Thu 26 Mar , Mike Perez wrote:
> > As discussed in the last Cinder meeting [1], in order to have your volume
> > driver readded into the Kilo release, you must have a CI reporting and
> stable
> > for five days prior to 4/6.
> >
> > This includes:
> >
> > 1) Providing logs to screen sessions, etc configs, tempest output [2].
> > 2) You should be running around 304 tests if you're following
> instructions from
> >the Cinder third party wiki [3]. If you're running less than that,
> your CI
> >will be *NOT* be considered satisfactory for skipping tests.
> >
> > I will also be emailing individuals who have already asked for
> exceptions, just
> > to make sure communication was clear.
> >
> >
> > [1] -
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
> > [2] - http://ci.openstack.org/third_party.html#requirements
> > [3] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
>
> The current CI's not meeting the second requirement:
>
> * Cloudbyte
> * Dell EQL
> * Dell SC FC
> * Dell SC ISCSI
> * EMC VMAX FC
> * EMC VMX ISCSI
> * EMC VNX FC
> * EMC VNX ISCSI
> * EMC XIO FC
> * EMC XIO ISCSI
> * HDS NFS
> * HDS NAS
> * Hitachi HBSD FC
> * Hitach HBSD ISCSI
> * IBM Flash Systems FC
> * IBM Flash Systems ISCSI
> * IBM NAS
> * IBM XIV (couldn't find tempest results to verify)
> * IBM Storwize FC
> * IBM Storwize ISCSI
> * Nimble
> * OpenVStorage
> * Quobyte
> * XIO FC
> * XIO ISCSI
> * Vmware
>
> Pretty sure this is because the previous instructions in the wiki were
> incorrect and are now corrected [1]. This is not the fault of the CI
> maintainers. As mentioned, individual emails are being sent out to get
> this all
> sorted.
>
>
> [1] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
>
> --
> Mike Perez
>
> __
> 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] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

2015-03-26 Thread Diem Tran

Hi Mike, The CI has been adjusted to run 304 tests since 3/24/2015 
evening: 
https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z


Here are examples of recent success runs:
https://review.openstack.org/#/c/167080/
https://review.openstack.org/#/c/165763/
https://review.openstack.org/#/c/166823/
https://review.openstack.org/#/c/166689/
https://review.openstack.org/#/c/167366/
https://review.openstack.org/#/c/166164/

We delayed our response until now because we want to get proofs of 
success runs and make sure our CI complies with the requirements. We 
believe it does now.


Thank you for your contribution and effort in keeping us updated on this 
matter.


Diem.
On 03/24/2015 05:28 PM, Mike Perez wrote:

On 18:20 Mon 23 Mar , Diem Tran wrote:

Hello Cinder team,

Oracle ZFSSA CI has been reporting since March 20th. Below is a link
to the list of results the CI already posted:

https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z

Our CI system will be running and reporting results from now on,
hence I kindly request that you accept our CI results and consider
re-integrating our drivers back in Kilo RC.

If there is any concern, please let us know.

Diem,

I appreciate your team getting back to us on the CI. It appears your CI is
running 247 tests, when it should be running 304. Please verify you're running
tempest as followed in the instructions here:

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

Once this issue is resolved, I'll continue to monitor the stability, and based
on that make a decision for readding the driver.




__
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] Deadline For Volume Drivers to Be Readded

On 09:39 Thu 26 Mar , Mike Perez wrote:
> As discussed in the last Cinder meeting [1], in order to have your volume
> driver readded into the Kilo release, you must have a CI reporting and stable
> for five days prior to 4/6.
> 
> This includes:
> 
> 1) Providing logs to screen sessions, etc configs, tempest output [2].
> 2) You should be running around 304 tests if you're following instructions 
> from
>the Cinder third party wiki [3]. If you're running less than that, your CI
>will be *NOT* be considered satisfactory for skipping tests.
> 
> I will also be emailing individuals who have already asked for exceptions, 
> just
> to make sure communication was clear.
> 
> 
> [1] - 
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
> [2] - http://ci.openstack.org/third_party.html#requirements
> [3] - 
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

The current CI's not meeting the second requirement:

* Cloudbyte
* Dell EQL
* Dell SC FC
* Dell SC ISCSI
* EMC VMAX FC
* EMC VMX ISCSI
* EMC VNX FC
* EMC VNX ISCSI
* EMC XIO FC
* EMC XIO ISCSI
* HDS NFS
* HDS NAS
* Hitachi HBSD FC
* Hitach HBSD ISCSI
* IBM Flash Systems FC
* IBM Flash Systems ISCSI
* IBM NAS
* IBM XIV (couldn't find tempest results to verify)
* IBM Storwize FC
* IBM Storwize ISCSI
* Nimble
* OpenVStorage
* Quobyte
* XIO FC
* XIO ISCSI
* Vmware

Pretty sure this is because the previous instructions in the wiki were
incorrect and are now corrected [1]. This is not the fault of the CI
maintainers. As mentioned, individual emails are being sent out to get this all
sorted.


[1] - 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

-- 
Mike Perez

__
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] [api][neutron] Best API for generating subnets from pool

2015-03-26 Thread Neil Jerram

Salvatore Orlando  writes:

> Neutron is adding a new concept of "subnet pool". [...]

> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html

I apologize for asking this question so long after this spec has been
proposed and discussed - but what is the problem that subnet allocation
solves?  Or what is it possible to do with subnet allocation, that was
not possible before?

Of course the spec has text to address this, but for me it doesn't
actually answer the above questions:

Problem Description

IPAM in Neutron cannot allocate subnets. Subnet details must be
specified by the End User at the time of subnet creation.

This seems to me to be restating the premise.

End Users may want to offload the burden of keeping track of subnets
and which addresses are in use. In this case, the End User should be
able to set up a private address space from which these are
automatically allocated.

This sounds to me like what already happens.  When I launch a set of
instances, I simply specify which subnet to use for each of their
vNICs.  The Neutron DB keeps track of which addresses are in use, so I
don't see any burden here.

For IPv4, this will often be a portion of
the RFC1918 address space but doesn’t need to be. It might be part
of a corporate address space which has been delegated to the
cloud. For IPv6, the End User may want Neutron to automatically
calculate a useable ULA subnet using a pseudo-random algorithm in
harmony with RFC4193 [1].

This seems equivalent to configuring that usable subnet explicitly and
then launching instances that are attached to its network.

This implies that the algorithm for the selection of subnets within
the space is pluggable in some way.

[1] http://tools.ietf.org/html/rfc4193

Deployers will set up external networks and may have a chunk of
routable addresses that could be leased or delegated to tenants for
use on their networks.

And that could presumably be configured as subnets?

Neutron needs an API for creating and managaging address spaces and
making them available to tenants.

I can certainly see the value in address spaces (or scopes) as a
distinct concept from tenants - if that is what this is saying.  But I
believe that's an independent concept from the idea of changing from
explicit subnet configuration to subnet allocation, because it would be
possible for an operator or tenant to configure a subnet within one of
the address spaces that was available to them.

Many thanks, and apologies again for asking this so late in the game.

Regards,
Neil

__
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] [puppet] Coordinator(s)/PTL tasks description


Hi,

Following our Tuesday meeting, we decided to create a sort of PTL /
Coordinators tasks list with the essence of 
https://wiki.openstack.org/wiki/PTL_Guide

I list some point here, but feel free to add discuss about them, it's not (yet)
written in stone.

- Community (group) manager:
 The PTL keeps abreast of upcoming meetings ops/other where it would be 
interesting
 for our community to be represented. Maintain an ical?

- Meetings organisation
 We need a chair to ensure that the meeting is correctly orchestrated, the PTL
 publish also a meeting agenda a minimum 5days before the meeting (see this
 example in openstack-tc¹). The PTL also publish meeting notes on the ML +
 wiki (for archive / easy search purposes).

- Bug triage / management (bug squashing party ?)
 The subject was raised during the last meeting, maybe a good form was
 something like a BSP (like we made in Debian), or a PR triage like puppetlabs
 one's². (This task was not necessarily managed by PTL)

- Maintain a list of active subject and directions like a backlog :)
 This was already managed by our trello board, and have a clear vision of where
 we are going on.

By stepping back, maybe we must elect a PTL to fit with OpenStack « standards »
and act in intern with something like a « scrum master » (changing every week)
firstly to distribute tasks, and secondly to involve everyone in the process.

These points are just ideas, a kind of cornerstone to discuss.

Seb

¹http://lists.openstack.org/pipermail/openstack-tc/2015-March/000940.html
²https://github.com/puppet-community/community-triage/blob/master/core/notes/2015-03-25.md
--
Sebastien Badia


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

Re: [openstack-dev] [puppet] Moving under the "big tent"

On Mon, Mar 16, 2015 at 08:13:19AM (-0700), Colleen Murphy wrote:

This thread is to follow up on our IRC discussion today. In today's meeting
we started discussing whether we want to pursue applying to move under the
OpenStack namespace and what pros and cons are. One concern that was
brought up was that our contributor base, being largely made up of
operators with many responsibilities, may not remain as consistent as the
contributors in other major projects. The counter to that was that being a
"real" project may increase the number of contributors we get.

Hi,

Hum, I'm not sure that namespace change will solve this issue. We have mostly
ops/«devops» contributions because ops deploy OpenStack. And it's only a need.

At the beginning, puppet-modules living on github under puppetlabs namespace, we
decided to move on stackforge to fit with OpenStack development, despite a
greater barrier to contribute it was a good idea (we take profit of well
integrated review, gate, testing infra), but a point in the discussion at the
time was also the increase of contributors numbers. And it did not really take
place, companies that are already contributing, continued to contribute to.

So to summarize my thinkings (sorry if this is not clear…),

Ok for a move in the « big tent », we are not going to lose anything anyway, and
the step is relatively small now.

For the PTL history, I think you (Colleen) and Emilien already made the job,
(and
a big thanks for that!), formalize things will not change much.

About mailing list move, I had not realized before, but it's a bit impossible
now to follow a puppet-openstack subject on the web archive (we wait strongly
mailman 3.x :p).

Seb

Readings:
http://ttx.re/problem-space-in-the-big-tent.html
https://github.com/openstack/governance/blob/master/resolutions/20141202-project-structure-reform-spec.rst
--
Sebastien Badia

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

Re: [openstack-dev] [puppet] Release management and bug triage


On Tue, Mar 17, 2015 at 01:46:06PM (-0700), Colleen Murphy wrote:

Cons:
* I think some people don't go on Launchpad because there is so many
projects (one per module), so they did not subscribe emails or don't
visit the page very often.
* Each time we create a module (it's not every day, I would say each
time a new OpenStack project is started), we have to repeat the process
for a new launchpad project.


I don't think this is that big a hurdle, and it doesn't happen often.




"Having everything in a single project"
Pro:
* Release management could be simpler


What would be simpler? We'd still need to track releases of each module, as
not all of them always get released at the same time.


* A single view for all the bugs in Puppet modules


You can view all the bugs in the openstack-puppet-modules top-level project
https://bugs.launchpad.net/openstack-puppet-modules


* Maybe a bad idea, but we can use tags to track puppet modules issues
(ie: puppet-openstacklib whould be openstacklib)

Con:
* The solution does not scale much, it depends again at how we decide to
make bug triage and release management;

Also, feel free to add more concerns or feedback to this discussion.


I don't have strong feelings either way, but I'm not sure I see the current
way as broken enough to change. There is a top-level project for these
subprojects (https://launchpad.net/openstack-puppet-modules). You can
create a bug for one project and then add other projects to the bug, so
having one ticket that links to multiple modules is possible.


Completely agree, the actual layout is almost flexible to ensure that everyone
can find the way to subscribe about what he wants.

About lp script, a short search on github (bug mgmt, merged changes):

 - https://github.com/openstack-infra/release-tools
 - https://github.com/markmc/openstack-lp-scripts
 - https://github.com/dolph/launchpad

But we wait the publishing of Mathieu scripts :)

Seb

--
Sebastien Badia


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

Re: [openstack-dev] [puppet] Moving under the "big tent"


On Mon, Mar 16, 2015 at 05:06:14PM (+0100), Yanis Guenane wrote:

To match user expectations, I think we should -as much as possible-
act as a layer on top of the project themselves. So if the project the
module installs is an official Openstack project, the module should be
supported. Else 'incubated'. If modules for 'official' projects are
not as proof ready as other might be, we should focus more on this one
during a certain amount of time to bring it up to the other standard.


Completely agree with your point here Yanis!
Our puppet modules are only a way to deploy a piece of software, and we must
as much as possible follow upstream configurations and focus on our modules not
enough « mature ». Every OpenStack core project¹ must have a mature puppet
module.

Seb

¹http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
--
Sebastien Badia


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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread Maru Newby

> On Mar 25, 2015, at 4:22 PM, Monty Taylor  wrote:
> 
> On 03/25/2015 05:50 PM, Maru Newby wrote:
>> I am excited by the release of YAPF [1], a gofmt-like too for python.
>> I think it has the potential to simplify style enforcement, and as
>> much as I appreciate our current hacking checks, I’d be much happier
>> not requiring developers to manually conform to them.  Maybe we can
>> consider automation in a manner similar to that employed by the go
>> codereview tool [2]?
> 
> I played with it for a few minutes and although it's configurable, it's
> still pretty limited in terms of expressiveness.
> 
> That said - although I do appreciate the theory of auto-formatting
> (seriously, one less thing, right?) I think it would be problematic for
> us. You can't ship git hooks in a git repo, so we can't help our users
> know to run it before pushing. In a world where getting set up in
> openstack is already non-trivial, I think requiring 2500 developers to
> add a new git hook to every repo that they do something with would be a
> bit of a disaster. When you combine that with the people who won't know,
> will make a patch, send it up, and have it rejected --- oy. Chaos.
> 
> git review is used by a ton of people who write in non-python. I think
> adding openstack-specific style enforcement to it would make it way less
> generally useful.
> 
> In general, if you find it interesting, there's certainly nothing wrong
> with tracking it and poking at it from time to time. But I honestly
> think that the logistical issue is pretty large, and one that the payoff
> from solving would not be worth the effort.

I agree with points raised by you and jeblair regarding the
potential for problems in applying auto-formatting without
developer intervention.  I apologize if my use of the word
'automation' muddied the waters, as the go codereview tool's
support of the 'gofmt' command is limited to explicit invocation
rather than being triggered in a hook.  It doesn't appear
acceptable for git-review to be granted similar capability, but
really that is a nicety.  Individual projects can as easily
provide their own style definitions, include YAPF as a test
dependency, and document how to invoke it.

I think there is value in extending our current solution of
automated style enforcement to provide a component that can be
manually invoked to auto-format to the enforced style.  I don't
see virtue in applying manual effort to maintaining code style.
YAPF may not be ready for our use just yet, but I think it's
worth pursuing. 

Maru

__
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] FCoE support in openstack

2015-03-26 Thread Boring, Walter

Hi rujing,
  When we implemented FC in Cinder and Nova, we had tested FCoE against the 
nova and cinder code we implemented and it just worked.
As far as what nova sees in terms of volumes showing up in /dev/disk/by-path, 
and the HBA’s, there was no difference.   If you test it and find
issues, please file bugs and assign them to me.   I’m available on irc as the 
nickname ‘hemna’.   I typically hang out in the #openstack-cinder
channel.


Cheers,
Walt

On Mar 25, 2015, at 7:30 PM, Guo, Ruijing 
mailto:ruijing@intel.com>> wrote:

Hi,

I saw openstack cinder already supported iscsi & FC and didn’t support FCoE. 
Any plan to support it?

Is there any BP to cover it? If not, I may draft for it.

Thanks,
-Ruijing
__
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] [cinder] Deadline For Volume Drivers to Be Readded

As discussed in the last Cinder meeting [1], in order to have your volume
driver readded into the Kilo release, you must have a CI reporting and stable
for five days prior to 4/6.

This includes:

1) Providing logs to screen sessions, etc configs, tempest output [2].
2) You should be running around 304 tests if you're following instructions from
   the Cinder third party wiki [3]. If you're running less than that, your CI
   will be *NOT* be considered satisfactory for skipping tests.

I will also be emailing individuals who have already asked for exceptions, just
to make sure communication was clear.


[1] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
[2] - http://ci.openstack.org/third_party.html#requirements
[3] - 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

-- 
Mike Perez

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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread Kiall Mac Innes



binv2ijTsg9Fd.bin
Description: PGP/MIME version identification


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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread Chmouel Boudjnah

On Thu, Mar 26, 2015 at 5:02 PM, James E. Blair  wrote:

> This is purposefully done to ensure that developers do not inadvertently
> run code on their workstations from a source they may not trust.
>


Sure, but  is that really make a difference between having some scripts in
a tox.ini that are run with tox -e or a script launched by git-review as
pre submit to git ?

Chmouel
__
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] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

2015-03-26 Thread Fabrizio Soppelsa


+1 definitely


On 03/25/2015 10:10 PM, Dmitry Borodaenko wrote:

Fuelers,

I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
She has contributed thousands of lines of documentation to Fuel over
the past several months, and has been a diligent reviewer:

http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs

I believe it's time to grant her core reviewer rights in the fuel-docs
repository.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess




__
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][cells] Meeting time change

2015-03-26 Thread Andrew Laski

Daylight saving time has made it so that the 2200UTC meeting time is 
fairly inconvenient for a few of us and the 2100UTC timeslot is open so 
we're going to shift the meeting up by an hour.  I have already spoken 
with many of the people in regular attendance at the meetings so this 
should come as little surprise.  See you all next week at 2100!


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

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

2015-03-26 Thread James E. Blair

Chmouel Boudjnah  writes:

> On Thu, Mar 26, 2015 at 12:22 AM, Monty Taylor  wrote:
>
>> git review is used by a ton of people who write in non-python. I think
>> adding openstack-specific style enforcement to it would make it way less
>> generally useful.
>>
>
>
> I think if we wanted to do that we could just extend git-review run_scripts
> thing[1] to read tox.ini or other shipped with the project file to run the
> pre-review script from it.
>
> Chmouel
>
> PS: I haven't looked at yapf so i have not much opinion about it.
>
> [1]
> https://git.openstack.org/cgit/openstack-infra/git-review/tree/git_review/cmd.py?h=master#n229

An important thing to note about the git-review hooks is that they _very
deliberately_ do not automatically run anything in the repo.  You must
specifically add a git-review hook to your local checkout or to your
home directory in order for it to run.

This is purposefully done to ensure that developers do not inadvertently
run code on their workstations from a source they may not trust.

So yes, it would be very simple to configure git-review to run this on
patch upload.  But it still needs to be a choice each developer makes.

-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-dev] [QA] No Meeting this Week

2015-03-26 Thread Matthew Treinish

Hi Everyone,

There will be no QA meeting this week/today because a large contingent of 
people are
at the QA code sprint this week. We will have the meeting next Thurs. at 22:00 
UTC.

Thanks,

Matt Treinish


pgpwbqXGouzlB.pgp
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] [nova] [libvirt] The risk of hanging when shutdown instance.

2015-03-26 Thread Chris Friesen


On 03/25/2015 10:15 PM, Rui Chen wrote:

Hi all:

 I found a discuss about the libvirt shutdown API maybe hang when shutdown
instance in libvirt community,
https://www.redhat.com/archives/libvir-list/2015-March/msg01121.html

 I'm not sure that whether there are some risks when we shutdown instance in
nova.

 Three questions:
 1. Whether acpi is the default shutdown mode in QEMU/KVM hypervisor when we
shutdown instance using libvirt?
 2. Whether acpi is asynchronous mode, and qemu-agent is synchronous mode
when we shutdown instance?
 3. If the hypervisor use qemu-agent as default shutdown mode, how we can
deal the hanging issue?



When shutting down an instance if there is a timeout (controlled by config file 
or system metadata) the code will first attempt a clean shutdown via 
dom.shutdown().  If that doesn't terminate the instance by the time the timeout 
expires, then we'll call virt_dom.destroy().


Chris

__
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] [Heat] Decoupling Heat integration tests from Heat tree

2015-03-26 Thread Pavlo Shchelokovskyy

Hi all,

following IRC discussion here is a summary of what I propose can be done in
this regard, in the order of increased decoupling:

1) make a separate requirements.txt for integration tests and modify the
tox job to use it. The code of these tests is pretty much decoupled
already, not using any modules from the main heat tree. The actual
dependencies are mostly api clients and test framework. Making this happen
should decrease the time needed to setup the tox env and thus speed up the
test run somewhat.

2) provide separate distutils' setup.py/setup.cfg to ease packaging and
installing this test suit to run it against an already deployed cloud
(especially scenario tests seem to be valuable in this regard).

3) move the integration tests to a separate repo and use it as git
submodule in the main tree. The main reasons not to do it as far as I've
collected are not being able to provide code change and test in the same
(or dependent) commits, and lesser reviewers' attention to a separate repo.

What do you think about it? Please share your comments.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] FFE request

2015-03-26 Thread Nikita Konovalov

Hi.

I would like to request a FFE for the following change request 
https://review.openstack.org/#/c/158715/ 

The blueprint for it has been approved for kilo. This change has a dependency 
on a change in python-saharaclient which has been recently merged.
The code has passed a few review iterations. At the moment all the comments 
have been addressed.

Best Regards,
Nikita Konovalov
Mirantis, Inc

__
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] [depfreeze][horizon] Update to Django-1.7.x

2015-03-26 Thread Matthias Runge

On Thu, Mar 26, 2015 at 06:02:41AM -0400, Sean Dague wrote:
> 
> Yes, just approved.

Thank you, much appreciated!
-- 
Matthias Runge 

__
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] Mellanox request for permission for Nova CI

2015-03-26 Thread Joe Gordon

On Thu, Mar 19, 2015 at 5:52 AM, Nurit Vilosny  wrote:

>  Hi Joe,
>
> Sorry for the late response.
>
> Here are some latest logs for the Nova CI:
>
>
> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1650/
>
>
> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1506/
>
>
> http://144.76.193.39/ci-artifacts/37/165437/1/check-nova/Check-MLNX-Nova-ML2-Sriov-driver/e90a677/
>
>
> http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1851/
>
>
>

I couldn't find the equivalent of:
http://logs.openstack.org/68/135768/9/check/check-tempest-dsvm-full/f6c95de/logs/testr_results.html.gz

Also what tests are running and how do they actually check if sriov works?


>  I can provide more if needed.
>
>
>
> Thanks,
>
> Nurit.
>
>
>
> *From:* Joe Gordon [mailto:joe.gord...@gmail.com]
> *Sent:* Wednesday, March 11, 2015 7:50 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Mellanox request for permission for Nova CI
>
>
>
>
>
>
>
> On Wed, Mar 11, 2015 at 12:49 AM, Nurit Vilosny 
> wrote:
>
>  Hi ,
>
> I would like to ask for a CI permission to start commenting on Nova branch.
>
> Mellanox is engaged in pci pass-through features for quite some time now.
>
> We have an operating Neutron CI for  ~2 years, and since the pci
> pass-through features are part of Nova as well, we would like to start
> monitoring Nova’s patches.
>
> Our CI had been silently running locally over the past couple of weeks,
> and I would like to step ahead, and start commenting in a *non-voting
> mode*.
>
> During this period we will be closely monitor our systems and be ready to
> solve any problem that might occur.
>
>
>
> Do you have a link to the output of your testing system, so we can check
> what its testing etc.
>
>
>
>
>
> Thanks,
>
> Nurit Vilosny
>
> SW Cloud Solutions Manager
>
>
>
> Mellanox Technologies
>
> 13 Zarchin St. Raanana, Israel
>
> Office: 972-74-712-9410
>
> Cell: 972-54-4713000
>
> Fax: 972-74-712-9111
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Murano] Roadmap for Liberty (specs & blueprints)

2015-03-26 Thread Serg Melikyan

Hi everyone,

Kilo cycle is almost finished, and we are ready to accept specs &
blueprints for Liberty.

I would like to mention that our experiment with murano-specs is
considered fairly successful, therefore starting from Liberty every
blueprint for a new feature should be proposed with a spec submitted
to murano-specs [1].

In case when some feature that you've proposed to Kilo was not
implemented, but spec was approved, please move your spec to
'specs/liberty' directory and mention in commit message that spec was
already approved.

We are going to start reviewing new features from the next weekly
meeting (March 31, 2015, 17:00 UTC, #openstack-meeting-alt on
FreeNode).

P.S. I would like to encourage you to send e-mail to mailing list if
you would like to discuss some particular feature with community.

Reference:
[1] https://github.com/stackforge/murano-specs

-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] [barbican] Using KMIP with Barbican (Utkarsh Simha)

2015-03-26 Thread Kelsey, Timothy John

Hi Utkarsh,


I am also happy to help figure out whats going in here, as Kaitlin says,
the first step is get some more log info.

-- 
Tim Kelsey

Cloud Security Engineer
HP Helion




On 25/03/2015 15:24, "Farr, Kaitlin M."  wrote:

>Hi Utkarsh,
>
>Specifying "kmip_plugin" in the barbican-api.conf is the correct way to
>configure the plugin. In my previous debugging experience, I've found
>that I
>get CryptoPluginNotFound if an error occurred during the plugin's __init__
>method. For the KMIP plugin, this means the key file permissions were not
>set to 400 or the PyKMIP KMIPProxy object could not be created with the
>configuration options set. To debug this further, we'll need to log at the
>logs for more clues.
>
>Hope this helps!
>
>Kaitlin Farr
>Johns Hopkins University Applied Physics Laboratory
>
>
>--
>
>Date: Mon, 23 Mar 2015 16:56:43 +0530
>From: Utkarsh Simha 
>To: openstack-dev@lists.openstack.org
>Subject: [openstack-dev] [barbican] Using KMIP with Barbican
>Message-ID:
>
>
>Content-Type: text/plain; charset=UTF-8
>
>Hello!
>
>I was wondering how it is possible to use an external Key Management
>Server with Barbican? I have configured the barbican-api.conf file for
>the KMIP Plugin and also set "enabled_crypto_plugins" to
>"kmip_plugin", but it says "CryptoPluginNotFound"
>
>Any help is appreciated! Thank you :)
>
>--
>Regards
>
>
>
>--
>
>*
>
>__
>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] [devstack] Overriding settings file for devstack plugin

2015-03-26 Thread Deepak Shetty

On Thu, Mar 26, 2015 at 5:09 PM, Deepak Shetty  wrote:

>
>
> On Thu, Mar 26, 2015 at 4:40 PM, Sean Dague  wrote:
>
>> On 03/25/2015 09:26 AM, Dean Troyer wrote:
>> > On Wed, Mar 25, 2015 at 6:04 AM, Deepak Shetty > > > wrote:
>> >
>> > Had a question here, why is this source in the end ?
>> >
>> >
>> > More often than not, you will want the variables defined by the other
>> > plugins (including the built-ins), this is really the first case we've
>> > had to deviate from that.  The right solution is to add an
>> > 'override_plugins' phase that runs before the built-ins are sourced so
>> > you can override the built-in defaults.
>>
>> Ok, we did a quick discussion at the QA Sprint yesterday on this and the
>> result is - https://review.openstack.org/#/c/167933/
>>
>> Please see if that would work in the glusterfs case.
>>
>
> Thanks Sean.
>
> +Bharat
>

Adding Bharat now

thanx,
deepak



>
> Bharat,
>   Pls check the below scenarios with sean's patch:
>
> 1) enable_plugin glusterfs set & CINDER_ENABLED_BACKENDS unset - it should
> pick from plugin
> 2) enable_plugin glusterfs set & CINDER_ENABLED_BACKENDS set - it should
> pick from localrc
> 3) enable_plugin glusterfs set & set some backend-specific var not touched
> by lib/cinder (eg: GLUSTERFS_LOOPBACK_SIZE) and see if it picks up correctly
> 4) enable_plugin glusterfs unset - it should pick cinder default
>
> thanx,
> deepak
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

2015-03-26 Thread Deepak Shetty

On Thu, Mar 26, 2015 at 4:40 PM, Sean Dague  wrote:

> On 03/25/2015 09:26 AM, Dean Troyer wrote:
> > On Wed, Mar 25, 2015 at 6:04 AM, Deepak Shetty  > > wrote:
> >
> > Had a question here, why is this source in the end ?
> >
> >
> > More often than not, you will want the variables defined by the other
> > plugins (including the built-ins), this is really the first case we've
> > had to deviate from that.  The right solution is to add an
> > 'override_plugins' phase that runs before the built-ins are sourced so
> > you can override the built-in defaults.
>
> Ok, we did a quick discussion at the QA Sprint yesterday on this and the
> result is - https://review.openstack.org/#/c/167933/
>
> Please see if that would work in the glusterfs case.
>

Thanks Sean.

+Bharat

Bharat,
  Pls check the below scenarios with sean's patch:

1) enable_plugin glusterfs set & CINDER_ENABLED_BACKENDS unset - it should
pick from plugin
2) enable_plugin glusterfs set & CINDER_ENABLED_BACKENDS set - it should
pick from localrc
3) enable_plugin glusterfs set & set some backend-specific var not touched
by lib/cinder (eg: GLUSTERFS_LOOPBACK_SIZE) and see if it picks up correctly
4) enable_plugin glusterfs unset - it should pick cinder default

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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

On 03/25/2015 09:26 AM, Dean Troyer wrote:
> On Wed, Mar 25, 2015 at 6:04 AM, Deepak Shetty  > wrote:
> 
> Had a question here, why is this source in the end ?
> 
> 
> More often than not, you will want the variables defined by the other
> plugins (including the built-ins), this is really the first case we've
> had to deviate from that.  The right solution is to add an
> 'override_plugins' phase that runs before the built-ins are sourced so
> you can override the built-in defaults.

Ok, we did a quick discussion at the QA Sprint yesterday on this and the
result is - https://review.openstack.org/#/c/167933/

Please see if that would work in the glusterfs case.

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

2015-03-26 Thread Roman Prykhodchenko

So guys, I think it’s reasonable to find a consensus on this thread.

> I think this rule fits fine within the general frame of Roman's proposal:
> 
> - if the base distro already has a package that satisfies OpenStack
> global requirements (or Fuel requirements), the distro package is
> used;
> - else, OSCI mirror should contain the maximum version of a
> requirement that matches its version specification.

Yup, that also fits well. The only note I’d like to make here is that OS 
services are tested against the latest version of requirements. So perhaps we 
want to test them against the versions, supplied in distos, if those 
requirements are used.


- romcheg

> 19 бер. 2015 о 19:14 Dmitry Borodaenko  написав(ла):
> 
> Maciej,
> 
> Maintaining multiple versions of the same package concurrently and
> tracking their compatibility with the many different components of
> OpenStack and Fuel creates additional work on many different levels,
> from spec branch management to repo management to validation to
> container building and so on. Unified global requirements help avoid
> such work where it isn't necessary (and when you look close enough
> into each specific case you're likely to find that it's never really
> necessary).
> 
> -DmitryB
> 
> On Thu, Mar 19, 2015 at 4:04 AM, Maciej Kwiek  wrote:
>> I guess it would depend on how many docker containers are running on master
>> node and if we are able to pull off such stunt :).
>> 
>> I am not familiar with the amount of work needed to do sth like that, so the
>> proposition may be silly. Just let me know if it is.
>> 
>> On Thu, Mar 19, 2015 at 11:51 AM, Dmitry Burmistrov
>>  wrote:
>>> 
>>> Folks,
>>> 
>> Correct me if I am wrong, but isn't it what we have containers on
>> master node for?
>> On the master node itself conflicts won’t happen because the
>> components are run in their containers.
>>> 
>>> Do you propose to use _separate_ package repository for each docker
>>> container? (It means separate gerrit project for each package of each
>>> container, including openstack projects)
>>> 
>>> On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko 
>>> wrote:
 Folks,
 
> I assume you meant: "If a requirement that previously was only in Fuel
> Requirements is merged to Global Requirements, it should be removed
> from *Fuel* Requirements».
 
 Exactly.
 
> I'm not sure it's good idea.
> We should stay so close to upstream distro as we can. It should be
> very important reason to update package against it's upstream distro
 
 
 The issue is the following: OpenStack’s components are tested against
 those versions of dependencies, that are specified in their requirements.
 IIRC those requirements are set up by pip so CI nodes contain latest
 versions of python packages that match their specs.
 
 The question is whether it’s required to ship OpenStack services with
 packages from a distro or with packages, that are used for testing.
 
> Splitting of repositories doesn't help to solve python packages
> conflicts because master node uses a number of openstack components.
 
 On the master node itself conflicts won’t happen because the components
 are run in their containers.
 
 
 - romcheg
 
 
> 19 бер. 2015 о 10:47 Dmitry Burmistrov 
> написав(ла):
> 
> Roman, all
> 
   - OSCI mirror should contain the maximum version of a
 requirement that matches its version specification.
> I'm not sure it's good idea.
> We should stay so close to upstream distro as we can. It should be
> very important reason to update package against it's upstream distro
> version.
> If we update some package, we should maintain it too. Tracking bugs,
> CVEs and so on. The more packages, the more efforts to support it.
> 
 - Set up CI jobs to notify OSCI team if either Global Requirements
 or
 Fuel Requirements are changed.
 - Set up requirements proposal jobs that will automatically propose
 changes to all fuel projects once either of requirements lists was
 changed
> Need to be discussed and investigated.
> 
> Sebastian, Dmitry,
> 
> 
 There are some plans (unfortunately I do not know details, so maybe
 someone from OSCI could tell more) to split those repositories
> Splitting of repositories doesn't help to solve python packages
> conflicts because master node uses a number of openstack components.
> Anyway it should be done for 7.0 milestone in order to separatre
> master-node distro from environment one. (e.g. if we going to move
> master-node to debian)
> 
> 
> 
> On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko
>  wrote:
>> Roman,
>> 
>> I like this proposal very much, thanks for the idea and for putting
>> together a straightforward process.
>

Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x

On 03/26/2015 03:40 AM, Matthias Runge wrote:
> On Wed, Mar 25, 2015 at 12:00:11PM +0100, Matthias Runge wrote:
>> On 25/03/15 11:34, Sean Dague wrote:
>>
 Could you make this one "Depends on"
 https://review.openstack.org/#/c/167515/ so that we check that all
 Django 1.7 related issues are fixed ?
>>>
>>> I don't think it was ever sufficiently explained why horizon now needs
>>> django nose to compile it's message catalog (which is where it is
>>> failing) when moving to 1.7.
>>>
>>> http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098
>>>
>> We're getting nearer here, thank you!
>>
>> --compilemessages is called with test settings, which is wrong imo.
>>
> Now that this has been been fixed, can we proceed now?
> 
> Matthias
> 

Yes, just approved.

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )