date:20140331


On 03/31/2014 03:56 PM, Vishvananda Ishaya wrote:


On Mar 27, 2014, at 4:38 PM, Chris Friesen  wrote:


On 03/27/2014 04:47 PM, Chris Friesen wrote:


Interestingly, unit test
nova.tests.api.openstack.compute.contrib.test_server_groups.ServerGroupTest.test_display_members
passes just fine, and it seems to be running the same sqlalchemy code.

Is this a case where sqlite behaves differently from mysql?


Sorry to keep replying to myself, but this might actually hit us other places.

Down in db/sqlalchemy/api.py we end up calling


query = query.filter(column_attr.op(db_regexp_op)('None’))


Sqlalchemy handles mapping None to NULL in many cases, so it appears that the 
problem is that we are passing
None as a string here?


I think fundamentally it makes no sense to try and regex match a NULL 
database field.  So in instance_get_all_by_filters() if we want to test 
for None it should be done separate from the regex filter.


Chris

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

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

2014-03-31 Thread Alessandro Pilotti


On 31 Mar 2014, at 18:13, Solly Ross  wrote:

> Building on what John said, I'm a bit wary of introducing semantics into the 
> Conductor's live migration code
> that are VMWare-specific.  The conductor's live-migration code is supposed to 
> be driver-agnostic.  IMHO, it
> would be much better if we could handle this at a level where the code was 
> already VMWare-specific.
> 

In terms of driver specific features, we’re evaluating cluster support for 
Hyper-V in the next cycle which would encounter the same issue for live 
migration.
Hyper-V does not require clustering for supporting live migration (it’s already 
available since Grizzly), but various users are requesting Windows clustering 
support
for supporting specific scenarios, which requires a separate Nova Hyper-V 
failover clustering driver with resemblances to the VCenter driver in terms of 
cells / hosts management. Note: this is not related to Microsoft System Center.

Evaluating such a feature solely in base of blueprints barely under drafting 
for other drivers and never discussed for approval isn’t obviously requested, 
but it might be 
useful to consider the possibility that VMWare’s might not be the only Nova 
driver with this requirement in the relatively short term future.

Thanks,

Alessandro


> Best Regards,
> Solly Ross
> 
> - Original Message -
> From: "Jay Lau" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, March 31, 2014 10:36:17 AM
> Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live 
> migration with one nova compute
> 
> Thanks John. Yes, I also think that this should be a bp as it is going to 
> make some changes to enable live migration with only one nova compute, will 
> file a blueprint later. 
> 
> For your proposal "specify the same host as the instance", this can resolve 
> the issue of live migration with target host, but what about the case of live 
> migration without target host? If we still allow "specify the same host as 
> the instance", the the live migration will goes to dead loop. 
> 
> So it seems we definitely need to find a way to specify the node for live 
> migration, hope someone else can show some light here. 
> 
> Of course, I will file bp and go through the new bp review process for this 
> feature. 
> 
> Thanks! 
> 
> 
> 2014-03-31 21:02 GMT+08:00 John Garbutt < j...@johngarbutt.com > : 
> 
> 
> 
> On 31 March 2014 10:11, Jay Lau < jay.lau@gmail.com > wrote: 
>> Hi, 
>> 
>> Currently with VMWare VCDriver, one nova compute can manage multiple 
>> clusters/RPs, this caused cluster admin cannot do live migration between 
>> clusters/PRs if those clusters/PRs managed by one nova compute as the 
>> current live migration logic request at least two nova computes. 
>> 
>> A bug [1] was also filed to trace VMWare live migration issue. 
>> 
>> I'm now trying the following solution to see if it is acceptable for a fix, 
>> the fix wants enable live migration with one nova compute: 
>> 1) When live migration check if host are same, check both host and node for 
>> the VM instance. 
>> 2) When nova scheduler select destination for live migration, the live 
>> migration task should put (host, node) to attempted hosts. 
>> 3) Nova scheduler needs to be enhanced to support ignored_nodes. 
>> 4) nova compute need to be enhanced to check host and node when doing live 
>> migration. 
>> 
>> I also uploaded a WIP patch [2] for you to review the idea of the fix and 
>> hope can get some comments from you. 
>> 
>> [1] https://bugs.launchpad.net/nova/+bug/1192192 
>> [2] https://review.openstack.org/#/c/84085 
> 
> Long term, finding a way to unify how cells and the VMware driver 
> manages multiple hosts, seems like the best way forward. It would be a 
> shame for this API to be different between cells and VMware, although 
> right now, that might not work too well :( 
> 
> A better short term fix, might be to allow you to specify the same 
> host as the instance, and the scheduling of the node could be 
> delegated to the VMware driver, which might just delegate that to 
> vCenter. I assume we still need some way to specify the node, and I 
> can't immediately think of a good way forward. 
> 
> I feel this should really be treated as a blueprint, and go through 
> the new blueprint review process. That should help decide the right 
> approach to take. 
> 
> John 
> 
> ___ 
> OpenStack-dev mailing list 
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> -- 
> Thanks, 
> 
> Jay 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova] avahi-autoipd vs. nova networking (cloud-init)

2014-03-31 Thread Mike Spreitzer

Lars Kellogg-Stedman  wrote on 03/31/2014 01:31:57 PM:

> ... you could add an explicit route to the metadata
> address via your default gateway

Yes, and there are other work-arounds possible too.  I posted here because 
I was concerned there may be a bug that needs fixing.

> Why are you installing avahi-autoipd in your cloud instance?  ...

I did not explicitly ask for avahi-autoipd; it came as a consequence of 
installing xubuntu-desktop.

BTW, I mis-identified some things in my original post.  The cloud was not 
a recent DevStack install of the latest code; it was a non-DevStack 
install of Havana done a few months ago.

I tested again with a cloud that *is* a recent DevStack install of the 
latest code, and used that to make an instance of 
http://cloud-images.ubuntu.com/precise/20140331/precise-server-cloudimg-amd64-disk1.img
 
--- and in this case the extra route added by avahi-autoipd does *not* 
break routing to 169.254.169.254 !___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [third-party-testing] Enabling voting for 3rd party testing

On 03/31/2014 06:02 PM, Kyle Mestery wrote:
> What is the criteria for this? The OpenDaylight Jenkins has been
> reliably voting for a few weeks now, I'm wondering how and when we can
> get it's voting rights approved.
> 
> Thanks!
> Kyle
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
The criteria -infra is expecting is that the account in question would
create an agenda item for the program weekly meeting. During the
meeting, the account in question would present their data - test logs,
commit history on sandbox repo, comment history on other repos and
answer questions from the attendees about system fitness. There would
then be some logged indication of the decision of the group/ptl (the
meeting channels log votes, if a vote is called). The logged decision is
then communicated to -infra (an -infra ml post is good for a link to the
logs and follow up with a ping in -infra channel) to get your system
moved to the voting group.

Thanks for asking the question,
Anita.

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

[openstack-dev] [neutron] [third-party-testing] Enabling voting for 3rd party testing

2014-03-31 Thread Kyle Mestery

What is the criteria for this? The OpenDaylight Jenkins has been
reliably voting for a few weeks now, I'm wondering how and when we can
get it's voting rights approved.

Thanks!
Kyle

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

Re: [openstack-dev] [nova] [bug] "nova server-group-list" doesn't show any members

2014-03-31 Thread Vishvananda Ishaya


On Mar 27, 2014, at 4:38 PM, Chris Friesen  wrote:

> On 03/27/2014 04:47 PM, Chris Friesen wrote:
> 
>> Interestingly, unit test
>> nova.tests.api.openstack.compute.contrib.test_server_groups.ServerGroupTest.test_display_members
>> passes just fine, and it seems to be running the same sqlalchemy code.
>> 
>> Is this a case where sqlite behaves differently from mysql?
> 
> Sorry to keep replying to myself, but this might actually hit us other places.
> 
> Down in db/sqlalchemy/api.py we end up calling
> 
> 
> query = query.filter(column_attr.op(db_regexp_op)('None’))

Sqlalchemy handles mapping None to NULL in many cases, so it appears that the 
problem is that we are passing
None as a string here?

Vish

> 
> 
> When using mysql, it looks like a regexp comparison of the string 'None' 
> against a NULL field fails to match.
> 
> Since sqlite doesn't have its own regexp function we provide one in 
> openstack/common/db/sqlalchemy/session.py.  In the buggy case we end up 
> calling it as regexp('None', None), where the types are "unicode" and 
> "NoneType".  However, we end up converting the second arg to text type before 
> calling reg.search() on it, so it matches.
> 
> Chris
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-03-31 Thread Clint Byrum

Excerpts from Jeremy Stanley's message of 2014-03-31 13:03:28 -0700:
> On 2014-03-31 10:55:06 +0200 (+0200), Thierry Carrez wrote:
> > No miracle here... All slots are pretty full as expected. I think our
> > best bet is still the 30-min morning break on Wednesday or Thursday at
> > 10:30am.
> 
> Would finding an available room for an hour sometime on Monday make
> sense instead? Since we don't have design sessions that day, it
> might make it easier to collect some majority of interested ATCs for
> longer than we can cram into a 30-minute break. On the other hand it
> will potentially conflict with some other operations and general
> conference stuff, so we end up leaving out people who might be doing
> those things instead...

Would it be entirely out of line to take a portion of an infra-team
session to do this? A lot of keys can be signed in 30 minutes.

* You will have the most important people in the WoT for OpenStack in
  that room. This will ensure that the signing is extremely relevant.
* The projection method will be available.
* This seems relevant to OpenStack development infrastructure.

If not, then taking over a session room directly after any day of the
event has been the most successful strategy I've seen at open source
conferences. It needs to be relatively soon after everything ends so that
people can still get to their respective plans.

If we can't commandeer a session, I'll go down the path of contacting
the conference/summit organizers to see if that is possible.

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

Re: [openstack-dev] [Nova] Juno open for development

2014-03-31 Thread Clark Boylan

The infrastructure team can update the OSes used by the gate when new
versions of the distros we use release, and our cloud providers make
those images available to us (or provide us with glance upload access,
whichever comes first). That means we can't upgrade Ubuntu to Trusty
until Trusty releases, same story with Centos7.

Also, there is typically a period of making things work after we get
access to VMs running these new images. So you can probably count on
an additional delay before things are tested on Trusy and Centos7.

Clark

On Mon, Mar 31, 2014 at 2:25 PM, Solly Ross  wrote:
> I should specify that I meant updating the OS version used by the CI.
>
> - Original Message -
> From: "Solly Ross" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, March 31, 2014 5:24:12 PM
> Subject: Re: [openstack-dev] [Nova] Juno open for development
>
> There was some talk about updating the CI for Juno.
> Has this been done/when will this be done?
>
> Best Regards,
> Solly Ross
>
> - Original Message -
> From: "Russell Bryant" 
> To: "OpenStack Development Mailing List" 
> Sent: Monday, March 31, 2014 2:23:32 PM
> Subject: [openstack-dev] [Nova] Juno open for development
>
> We just merged the change that opens the master branch for Juno development:
>
> https://review.openstack.org/#/c/83752/
>
> We will be releasing icehouse-rc1 from the commit that precedes the
> above patch.  If anything comes up that warrants another release
> candidates, please get in contact with me directly.
>
> On the Juno front, we are now ready to start accepting and reviewing
> Juno blueprints.  The process is documented here:
>
> https://wiki.openstack.org/wiki/Blueprints#Creation
>
> If you have any questions not answered by that page, please bring them
> up so that we can ensure the process is adequately documented.
>
> Thanks,
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova] Juno open for development

There was some talk about updating the CI for Juno.
Has this been done/when will this be done?

Best Regards,
Solly Ross

- Original Message -
From: "Russell Bryant" 
To: "OpenStack Development Mailing List" 
Sent: Monday, March 31, 2014 2:23:32 PM
Subject: [openstack-dev] [Nova] Juno open for development

We just merged the change that opens the master branch for Juno development:

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

We will be releasing icehouse-rc1 from the commit that precedes the
above patch.  If anything comes up that warrants another release
candidates, please get in contact with me directly.

On the Juno front, we are now ready to start accepting and reviewing
Juno blueprints.  The process is documented here:

https://wiki.openstack.org/wiki/Blueprints#Creation

If you have any questions not answered by that page, please bring them
up so that we can ensure the process is adequately documented.

Thanks,

-- 
Russell Bryant

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

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

Re: [openstack-dev] [Nova] Juno open for development

I should specify that I meant updating the OS version used by the CI.

- Original Message -
From: "Solly Ross" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, March 31, 2014 5:24:12 PM
Subject: Re: [openstack-dev] [Nova] Juno open for development

There was some talk about updating the CI for Juno.
Has this been done/when will this be done?

Best Regards,
Solly Ross

- Original Message -
From: "Russell Bryant" 
To: "OpenStack Development Mailing List" 
Sent: Monday, March 31, 2014 2:23:32 PM
Subject: [openstack-dev] [Nova] Juno open for development

We just merged the change that opens the master branch for Juno development:

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

We will be releasing icehouse-rc1 from the commit that precedes the
above patch.  If anything comes up that warrants another release
candidates, please get in contact with me directly.

On the Juno front, we are now ready to start accepting and reviewing
Juno blueprints.  The process is documented here:

https://wiki.openstack.org/wiki/Blueprints#Creation

If you have any questions not answered by that page, please bring them
up so that we can ensure the process is adequately documented.

Thanks,

-- 
Russell Bryant

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

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

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

Re: [openstack-dev] Domains prototype in Nova

2014-03-31 Thread Vishvananda Ishaya

Note that there has been a lot of discussion and a potential path forward for 
hierarchical project support in openstack. I personally think this makes a lot 
more sense than having a bunch of domain specific calls. Please take a look at 
the information in the wiki here:

https://wiki.openstack.org/wiki/HierarchicalMultitenancy

We are going to be discussing this in detail at the summit.

Vish

On Mar 28, 2014, at 7:06 AM, Henrique Truta  
wrote:

> Hi all!
> 
> I've been working on a prototype of Domains in Nova. In that prototype the 
> user is now able to do the following API calls with a domain scoped token:
> 
> GET v2/domains/{domain_id}/servers: Lists servers which projects belong to 
> the given domain
> GET v2/domains/{domain_id}/servers/{server_id}: Gets details from the given 
> server
> DELETE v2/domains/{domain_id}/servers/{server_id}: Deletes the given server
> POST v2/domains/{domain_id}/servers/{server_id}/action: Reboots the given 
> server
> 
> Could you help me test these functionalities and review the code?
> 
> The code can be found in my github repo 
> (https://github.com/henriquetruta/nova) on the domains-prototype branch.
> 
> Thanks!
> 
> -- 
> --
> Ítalo Henrique Costa Truta
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] Icehouse RC1 available

2014-03-31 Thread Thierry Carrez

Hello everyone,

Last one for today, Heat just published its first Icehouse release
candidate. 63 bugs were fixed since feature freeze earlier this month.

The RC1 is available for download at:
https://launchpad.net/heat/icehouse/icehouse-rc1

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

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/heat/tree/milestone-proposed

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

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

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

Note that the "master" branch of Heat is now open for Juno
development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

2014-03-31 Thread David Kranz


On 03/31/2014 02:42 PM, Chris K wrote:

Hi David,

We are in feature freeze right now, waiting for the Juno cycle to open 
up, so there are several reviews that are holding. If you are able 
please join the #opensack-ironic IRC channel, there is almost always a 
core member in channel who should be able to answer any questions you 
have about specific reviews.


Chris Krelle
Thanks, but this is not quite the issue. It is that many tempest 
reviewers do not know all the ins and outs of every api, particularly 
new ones. So it is helpful to have a +1 from some one who does. This has 
been very valuable in neutron and I'm sure it would be here as well. I 
will certainly ping in #openstack-ironic if there are any specific issues.


 -David




On Mon, Mar 31, 2014 at 8:47 AM, David Kranz > wrote:


I was reviewing some ironic changes that are more than a week old
and do not have any reviews from the ironic team. Having at least
one review from the ironic team would be very helpful.

 -David

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

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




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


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

Re: [openstack-dev] [Neutron] PTL Candidacy

confirmed

On 03/31/2014 04:15 PM, Mark McClain wrote:
> All-
> 
> I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.
> 
> I am the current Neutron PTL and would like to continue leading our team 
> during the Juno cycle.  As PTL, I have worked to promote a vibrant open 
> ecosystem of deployers, integrators and vendors within Neutron.  Our openness 
> is exemplified by the new drivers/plugins, new contributors, and diversity of 
> sub team leadership in Icehouse.
> 
> Qualifications
> ---
> I have been a contributor to Neutron since Essex and a core team member since 
> Folsom.  I have been developing software with Python professionally for 14 
> years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
> Neutron code base, I have worked extensively on DHCP, IP library, network 
> namespaces, metadata services, database migrations, and LBaaS reference 
> implementation.  I frequently present Neutron at local and regional OpenStack 
> events to build community by engaging new developers, deployers, and 
> integrators.
> 
> I am the top reviewer during the Icehouse cycle:
> http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt
> 
> I am the top reviewer since the inception of Neutron:
> http://russellbryant.net/openstack-stats/neutron-reviewers-1095.txt
> 
> Icehouse
> 
> As the technical lead during Icehouse, I kicked off the initiative to improve 
> testing within Neutron.  This initiative included the creation of the 
> mid-cycle sprint that brought the QA and Neutron teams together.  The 
> successful sprint  produced a more stable Neutron core, more API test 
> coverage, the soon-to-be enabled full Tempest and Grenade jobs and a more 
> connected community.  Additionally, I promoted the policy of improve 3rd 
> party testing of plugin/driver code from vendors [1].  This initiative has 
> resulted in a more thoroughly tested and stable driver/plugin codebase for 
> operators to deploy.
> 
> Juno
> ---
> My vision for Juno is that our team continue to build upon the open 
> environment that enables all vendors, deployers and integrators the 
> opportunity to contribute to the development of Neutron.  During the cycle, I 
> believe our team should focus on a few core initiatives:
> 
> * Nova Parity
> We committed to delivering Nova Parity when Neutron was accepted as an 
> Integrated project.  By delivering Distributed Virtual Routing, Nova-Network 
> to Neutron migration, testing and documentation we will be following through 
> on our commitment to the greater OpenStack community.
> 
> * Advanced Services
> The team should implement a multi-vendor ‘flavor' API that provides tenants 
> an easy to use API, deployers a choice and vendors an opportunity to 
> innovate.  This API should complement the existing APIs our teams have 
> created over the last two cycles.  Additionally, we should add secure APIs 
> and agent code to support SSL termination for LBaaS and SSL VPNs.
> 
> * Process Improvements
> Our team has grown, but our processes for submitting and reviewing blueprints 
> has largely stayed the same which has made the review process uneven. As the 
> Icehouse cycle has wound down, I have been working to put new infrastructure 
> in place to improve the blueprint process for Juno[2].  The new process 
> should ensure a more consistent experience for all contributors in Juno.  In 
> addition to refining the blueprint process, our sub team structure should be 
> revised to improve communication, remove blockers, and facilitate more 
> efficient reviews.
> 
> * Internal API and REST API Improvements
> We have several exciting new features in development for Neutron, but at 
> times our internal APIs have inhibited efficient implementation of these 
> features.  During the Juno cycle, we should begin the process of revising our 
> internal interfaces to enable easier IPv6, migration to Python 3 and 
> development of plugins/drivers and services,
> 
> * Group Policy
> There is significant community interest in adding policy support to Neutron.  
> During Juno, we should work on implementing the first iteration of the policy 
> API extension.  This extensions will be aided by the work to improve the 
> internal API.
> 
> * Testing
> The team made significant testing gains during Icehouse.  We should build on 
> that work during Juno and collaborate with the QA team to further refine and 
> improve our testing through additional scenarios, varied migration 
> configurations and functional tests.
> 
> * Documentation
> Good documentation is a requirement for both deployers and developers we have 
> made improvements to both Icehouse.  For Juno, I’d like to continue this work 
> as it is essential for parity.
> 
> * Growing our plugin and driver community
> 
> See something missing from this list?  As PTL, I’m excited to work with our 
> community to refine this list for Juno.
> 
> 
> Other OpenStack Contributions
> --

[openstack-dev] [Neutron] PTL Candidacy

2014-03-31 Thread Mark McClain

All-

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL and would like to continue leading our team during 
the Juno cycle.  As PTL, I have worked to promote a vibrant open ecosystem of 
deployers, integrators and vendors within Neutron.  Our openness is exemplified 
by the new drivers/plugins, new contributors, and diversity of sub team 
leadership in Icehouse.

Qualifications
---
I have been a contributor to Neutron since Essex and a core team member since 
Folsom.  I have been developing software with Python professionally for 14 
years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
Neutron code base, I have worked extensively on DHCP, IP library, network 
namespaces, metadata services, database migrations, and LBaaS reference 
implementation.  I frequently present Neutron at local and regional OpenStack 
events to build community by engaging new developers, deployers, and 
integrators.

I am the top reviewer during the Icehouse cycle:
http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt

I am the top reviewer since the inception of Neutron:
http://russellbryant.net/openstack-stats/neutron-reviewers-1095.txt

Icehouse

As the technical lead during Icehouse, I kicked off the initiative to improve 
testing within Neutron.  This initiative included the creation of the mid-cycle 
sprint that brought the QA and Neutron teams together.  The successful sprint  
produced a more stable Neutron core, more API test coverage, the soon-to-be 
enabled full Tempest and Grenade jobs and a more connected community.  
Additionally, I promoted the policy of improve 3rd party testing of 
plugin/driver code from vendors [1].  This initiative has resulted in a more 
thoroughly tested and stable driver/plugin codebase for operators to deploy.

Juno
---
My vision for Juno is that our team continue to build upon the open environment 
that enables all vendors, deployers and integrators the opportunity to 
contribute to the development of Neutron.  During the cycle, I believe our team 
should focus on a few core initiatives:

* Nova Parity
We committed to delivering Nova Parity when Neutron was accepted as an 
Integrated project.  By delivering Distributed Virtual Routing, Nova-Network to 
Neutron migration, testing and documentation we will be following through on 
our commitment to the greater OpenStack community.

* Advanced Services
The team should implement a multi-vendor ‘flavor' API that provides tenants an 
easy to use API, deployers a choice and vendors an opportunity to innovate.  
This API should complement the existing APIs our teams have created over the 
last two cycles.  Additionally, we should add secure APIs and agent code to 
support SSL termination for LBaaS and SSL VPNs.

* Process Improvements
Our team has grown, but our processes for submitting and reviewing blueprints 
has largely stayed the same which has made the review process uneven. As the 
Icehouse cycle has wound down, I have been working to put new infrastructure in 
place to improve the blueprint process for Juno[2].  The new process should 
ensure a more consistent experience for all contributors in Juno.  In addition 
to refining the blueprint process, our sub team structure should be revised to 
improve communication, remove blockers, and facilitate more efficient reviews.

* Internal API and REST API Improvements
We have several exciting new features in development for Neutron, but at times 
our internal APIs have inhibited efficient implementation of these features.  
During the Juno cycle, we should begin the process of revising our internal 
interfaces to enable easier IPv6, migration to Python 3 and development of 
plugins/drivers and services,

* Group Policy
There is significant community interest in adding policy support to Neutron.  
During Juno, we should work on implementing the first iteration of the policy 
API extension.  This extensions will be aided by the work to improve the 
internal API.

* Testing
The team made significant testing gains during Icehouse.  We should build on 
that work during Juno and collaborate with the QA team to further refine and 
improve our testing through additional scenarios, varied migration 
configurations and functional tests.

* Documentation
Good documentation is a requirement for both deployers and developers we have 
made improvements to both Icehouse.  For Juno, I’d like to continue this work 
as it is essential for parity.

* Growing our plugin and driver community

See something missing from this list?  As PTL, I’m excited to work with our 
community to refine this list for Juno.


Other OpenStack Contributions
--
* Co-organizer of the Atlanta OpenStack Meetup
* Member of the Technical Committee since the Havana cycle
* Stable Core Team Member
* Requirements Core Team Member

Thanks,
mark

[1] http://lists.openstack.org/pipermai

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-03-31 Thread Jeremy Stanley

On 2014-03-31 10:55:06 +0200 (+0200), Thierry Carrez wrote:
> No miracle here... All slots are pretty full as expected. I think our
> best bet is still the 30-min morning break on Wednesday or Thursday at
> 10:30am.

Would finding an available room for an hour sometime on Monday make
sense instead? Since we don't have design sessions that day, it
might make it easier to collect some majority of interested ATCs for
longer than we can cram into a 30-minute break. On the other hand it
will potentially conflict with some other operations and general
conference stuff, so we end up leaving out people who might be doing
those things instead...
-- 
Jeremy Stanley

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

[openstack-dev] [Nova] Icehouse RC1 available

2014-03-31 Thread Thierry Carrez

Hello everyone,

Nova just published its first Icehouse release candidate. Congrats to
all Nova developers for reaching this key milestone: 131 bugs were
fixed in Nova since feature freeze earlier this month !

The RC1 is available for download at:
https://launchpad.net/nova/icehouse/icehouse-rc1

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

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/nova/tree/milestone-proposed

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

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

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

Note that the "master" branch of Nova is now open for Juno
development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] ML2 Type driver for supporting network overlays, with more than 4K seg

2014-03-31 Thread Padmanabhan Krishnan

Hi Mathieu,
Thanks for the link. Some similarities for sure. I see Nova libvirt being used.
I had looked at libvirt earlier.

Firstly, the libvirt support that Nova uses to communicate with LLDPAD doesn't
have support for the latest 2.2 standard. The support is also only for the VEPA
mode and not for VEB mode. It's also quite not clear as how the VLAN provided
by VDP is used by libvirt to communicate it back to Openstack.
There's already an existing blueprint where i can add more details
(https://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support)

Even for a single physical network, you need more parameters in the ini file. I
was thinking of Host or Network Overlay with or w/o VDP for Tunnel mode. I will
add more to the blueprint.

Thanks,
Paddu

On Friday, March 28, 2014 8:42 AM, Mathieu Rohon
wrote:

Hi,

the more I think about your use case, the more I think you should
create a BP to have tenant network based on interfaces created with
VDP protocol.
I'm not a VDP specialist, but if it creates some vlan back interfaces,
you might match those physical interfaces with the
physical_interface_mappings parameter in your ml2_conf.ini. Then you
could create flat networks backed on those interfaces.
SR-IOv use cases also talk about using vif_type 802.1qbg :
https://wiki.openstack.org/wiki/Nova-neutron-sriov

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

Re: [openstack-dev] [Mistral] Engine overview and proposal

2014-03-31 Thread Dmitri Zimine

I am in the full agreement with the proposed approach (risked to copy below, 
let's see if email handles your diagrams): 

* Single Engine handles multiple executions asynchronously, in non-blocking way.
* Persistence access only from API and/or Engine, Engine writes, API reads. 
* Action runes don't talk to DB - it's very simple protocol and queue is 
perfectly fine. 
* This is scalable and as fault tolerant as underlying DB and Queue. Engine 
restart is no loss of info with right persistense; ActionRunner restart  is a 
lost of Action, which can fail for 100 other reasons thus expected, and with 
the right retry policy potentially recoverable. 

I'll inline minor points in the etherpad. 



 API EngineQueueDatabaseWorkers
  |   |   | | | ||   |
---> +-+  |   | | | ||   |
 |S|  |   | | | ||   |
 |t| --> +-+  | | | ||   |
 |a| | | < - - - - - - - -> ||   |
 |r| | | - - - -> t - - - - - - - - - > +-+  |
 |t| <-- +-+  | | | |   | |  |
<--- +-+  |   | | | |   | |  |
  |   |  +-+ <- r <- - - - - - - - - -  +-+  |
---> +-+  |  | | <- - - - - - > R|   |
 |I|  |  | | - -> t - - - - - - - - - > +-+  |
 |n|  |  | | - -> t - - - - - - - - - - - > +-+
 |f|  |  +-+| | |   | | | |
 |o| <- - - - - - - - - - - - > |   | | | |
<--- +-+  |  +-+ <- r <- - - - - - - - - - -+-+ | |
  |   |  | | <- - - - - - > R|  | |
---> +-+  |  +-+| | ||  | |
 |S| --> +-+  | | | ||  | |
 |t| | | <- - - - - - - - > ||  | |
 |o| <-- +-+  | | | ||  | |
 |p|  |  +-+ <- r < - - - - - - - - - - - - +-+
<--- +-+  |  | | <- - - - - - > R|   |
  |   |  |%|| | ||   |
  |   |  +-+| | ||   |
  |   |   | | | ||   |


On Mar 31, 2014, at 4:09 AM, Kirill Izotov  wrote:

> I have an idea regarding engine design i want to share with you. But first, 
> it seems like we need a small overview of the current implementations.
> 
> I'm not sure how ML will react on a bunch of ASCII graphs, so here is an 
> etherpad: 
> https://etherpad.openstack.org/p/mistral-engine-overview-and-proposal
> 
> What do you think, guys, is this the way to go?
> 
> -- 
> Kirill Izotov
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] bug/129135

2014-03-31 Thread Nathanael Burton

Also, how does this work for RHEL-based distros where they tend to backport
new kernel features?  For instance vxlan support was added in the kernel
for RHEL6.5 which is 2.6.32-based...  That changeset looks like it breaks
Neutron for ovs + vxlan on RHEL distros.

Nate


On Mon, Mar 31, 2014 at 1:07 PM,  wrote:

>
> openstack-dev,
>
> A question about the fix from https://review.openstack.org/#/c/82931
>
> After this fix, the neutron code now explicitly checks for kernel
> version 3.13- was this deliberate? (I was using an older 3.11 version
> before, and did not seem to have any issues before this change).
>
> Is there a specific kernel patch that ovs-vxlan is dependant on?
>
> Thanks
> Sowmini
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] PTL Candidacy

confirmed

On 03/31/2014 02:52 PM, Lyle, David wrote:
> I would like to announce my candidacy for Horizon PTL.
> 
> I've been working on and contributing to Horizon for the last three releases 
> and had the pleasure to serve as the PTL for the Icehouse cycle.
> 
> In the Icehouse cycle, we started a number of changes that I would like to 
> see completed in the Juno cycle:
> 
> 1) Adding Role Based Access Control support in the user interface for all 
> services across OpenStack.  This is an ongoing process as we have support for 
> several services, and many more in progress.  Once the changes are completed, 
> Horizon will be able to support users with various cloud operator defined 
> roles beyond just member and admin.  This will also allow for a dramatic 
> reduction in duplicate code.
> 
> 2) Supporting richer client experiences and less custom JavaScript, by 
> adopting AngularJS. In Juno, I would like to see further progress on this 
> transition with effective use of Angular to improve end user experience with 
> items like better client side validation and more responsive workflows.
> 
> 3) An increased focus on usability. In Icehouse, Horizon added a wizard UI 
> and with the help of the OpenStack-UX team conducted usability testing on 
> Horizon.  Horizon needs to work toward not only supporting as much of the 
> OpenStack service APIs as possible, but making sure we do so in a well 
> thought out and user enabling way. In Juno, I would like to see a focus on 
> implementing more intuitive workflows.
> 
> 4) Breaking horizon into logical pieces.  We formulated a plan to split the 
> existing Horizon repo into several repos to separate concerns and improve 
> extensibility and maintainability.  In Juno, we need to achieve this split.
> 
> 5) Support infrastructure management.  In Icehouse, tuskar-ui (rename to 
> follow) joined the Horizon Program, I am excited by the future inclusion of 
> greater infrastructure and deployment management into the Horizon framework.  
> We need to help this functionality progress and fill out the Horizon 
> ecosystem. 
> 
> 
> In the Icehouse release, we saw continued growth of the Horizon community.  I 
> am very proud of the accomplishments we've made in Icehouse and I'm excited 
> by the opportunities ahead in Juno.
> 
> 
> Thanks,
> David Lyle
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

[openstack-dev] [Horizon] PTL Candidacy

2014-03-31 Thread Lyle, David

I would like to announce my candidacy for Horizon PTL.

I've been working on and contributing to Horizon for the last three releases 
and had the pleasure to serve as the PTL for the Icehouse cycle.

In the Icehouse cycle, we started a number of changes that I would like to see 
completed in the Juno cycle:

1) Adding Role Based Access Control support in the user interface for all 
services across OpenStack.  This is an ongoing process as we have support for 
several services, and many more in progress.  Once the changes are completed, 
Horizon will be able to support users with various cloud operator defined roles 
beyond just member and admin.  This will also allow for a dramatic reduction in 
duplicate code.

2) Supporting richer client experiences and less custom JavaScript, by adopting 
AngularJS. In Juno, I would like to see further progress on this transition 
with effective use of Angular to improve end user experience with items like 
better client side validation and more responsive workflows.

3) An increased focus on usability. In Icehouse, Horizon added a wizard UI and 
with the help of the OpenStack-UX team conducted usability testing on Horizon.  
Horizon needs to work toward not only supporting as much of the OpenStack 
service APIs as possible, but making sure we do so in a well thought out and 
user enabling way. In Juno, I would like to see a focus on implementing more 
intuitive workflows.

4) Breaking horizon into logical pieces.  We formulated a plan to split the 
existing Horizon repo into several repos to separate concerns and improve 
extensibility and maintainability.  In Juno, we need to achieve this split.

5) Support infrastructure management.  In Icehouse, tuskar-ui (rename to 
follow) joined the Horizon Program, I am excited by the future inclusion of 
greater infrastructure and deployment management into the Horizon framework.  
We need to help this functionality progress and fill out the Horizon ecosystem. 


In the Icehouse release, we saw continued growth of the Horizon community.  I 
am very proud of the accomplishments we've made in Icehouse and I'm excited by 
the opportunities ahead in Juno.


Thanks,
David Lyle

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

Re: [openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

2014-03-31 Thread Chris K

Hi David,

We are in feature freeze right now, waiting for the Juno cycle to open up,
so there are several reviews that are holding. If you are able please join
the #opensack-ironic IRC channel, there is almost always a core member in
channel who should be able to answer any questions you have about specific
reviews.

Chris Krelle

On Mon, Mar 31, 2014 at 8:47 AM, David Kranz  wrote:

> I was reviewing some ironic changes that are more than a week old and do
> not have any reviews from the ironic team. Having at least one review from
> the ironic team would be very helpful.
>
>  -David
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] PTL Candidacy

2014-03-31 Thread John Garbutt

On 31 March 2014 18:53, John Garbutt  wrote:
> Hi,
>
> I would like to run for the OpenStack Compute (Nova) PTL position.
>
> I find it really rewarding to help resolve conflict. Gallup says I am
> a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
> all sides of the story, learn about everyones point of view, help
> frame the argument, and help come up with a resolution that works for
> everyone. That is why the idea of being a PTL excites me.
>
> Nova excites me because I love projects that integrate lots of
> different components into a single cohesive user experience. (I see it
> as one of the upsides of my Dyslexia.)
>
> Should I get elected, Rackspace has promised that Nova PTL will be my
> full time job.
>
>
> My (OpenStack) life story...
> 
>
> My first involvement with Nova was in late 2010, working on what
> became Citrix's "Project Olympus" private cloud packaging of OpenStack
> and XenServer. We got Nova, Glance, Swift and XenServer all installed
> and configured from a CD (or optional PXE) install.
>
> After some changes in direction at Citrix, I started focusing on
> XenServer and OpenStack integration, with a particular focus on Nova.
> This lead me to form the XenAPI sub team, and help Russell with his
> formalisation of the "Nova Sub-Team" concept.
>
> In early 2013, I moved to Rackspace. That allowed me to focus more
> attention on the rest of Nova. I am part of the dev team working on
> (probably) the largest Nova installation in the world, Rackspace Cloud
> Servers. I quickly joined nova-core, and then nova-drivers. Most
> recently taking up the role of blueprint czar.
>
> I feel I am in a better position than most to understand the breadth
> of the Nova community, given my varied experience:
> * moved from packaging OpenStack, then contributing code to Nova, now
> helping more with the leadership of Nova
> * worked on packaging OpenStack for private clouds (at Citrix)
> * currently helping run (probably) the largest Nova deployment on the
> planet, at Rackspace
> * worked at a company whose strategy is more focused on its own
> product, than the success of OpenStack (at Citrix). Note: I consider
> this a perfectly valid situation. Without people concentrating on
> non-OpenStack projects and products, Nova would have nothing to
> orchestrate.
>
>
> How I see the PTL role
> --
>
> The basics of the Project Team Lead (or Project Technical Lead) role
> are covered here:
> https://wiki.openstack.org/wiki/PTLguide
>
> I feel that the role is really about fostering a vibrant community,
> and ensuring decisions get made, not making the decisions. This
> challenge really excites me, as in the past, I have had much fun, and
> many successes, resolving conflicts between conflicting/competing
> teams, helping them find a good resolution.
>
> What I have found works is...
> * Agree on a common set of user problems that need to be solved now
> * ... and at the same time, gain a better understanding of where
> people need/want to go in the future
>
> That way, everyone starts to focus their efforts in the same direction.
>
>
> What I would keep
> -
>
> In summary, I would keep most things. The Nova project is thriving.
>
> The focus on "cloud" and not "server virt" should continue. That
> doesn't mean we shouldn't work well at the small scale, we should work
> well at both the large scale and the small scale. We should not stop
> the work evolving the architecture of Nova and working out how to
> evolve the API. Indeed, we also need to continue to improve how we
> interface with Neutron, Glance, etc, etc.
>
> We should also continue to avoid Nova scope creep, and continue to
> reduce the scope of Nova where possible:
> * split out nova-scheduler, to help cross project scheduling
> * deprecate nova-network, or/and split it out of nova
> * keep on the look out for other ideas
>
> There are several people I would trust to be a good PTL for the next
> cycle, which shows how much Russell has managed to scale out the
> leadership in recent cycles. This drive to scale out the leadership of
> Nova should continue.
>
>
> But there are growing pains that need urgent attention...
>
>
> What I would change
> ---
>
> This is not about what we should build in Juno, it's how I'm thinking
> the Nova community and Nova leadership should evolve during Juno:
>
>
> 1) Connecting developers with those "using" Nova
>
> We are a very developer driven community. I would like to work with
> deployers, packagers, and all users, to get their voices heard by the
> Nova developer community.
>
> The improved blueprint reviews and improved triaging of bugs are a
> good start, but we need to continue to innovate here. Glance have
> included a Product Manager, Brian Rosmaita, on their drivers team. I
> am sure Nova would benefit from getting Product Managers, Operators,
> and others, more involved in setting project priorities.

Just

[openstack-dev] [Nova] Juno open for development

2014-03-31 Thread Russell Bryant

We just merged the change that opens the master branch for Juno development:

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

We will be releasing icehouse-rc1 from the commit that precedes the
above patch.  If anything comes up that warrants another release
candidates, please get in contact with me directly.

On the Juno front, we are now ready to start accepting and reviewing
Juno blueprints.  The process is documented here:

https://wiki.openstack.org/wiki/Blueprints#Creation

If you have any questions not answered by that page, please bring them
up so that we can ensure the process is adequately documented.

Thanks,

-- 
Russell Bryant

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

[openstack-dev] [Neutron][L3] Dynamic Routing Use Cases

2014-03-31 Thread Carl Baldwin

Hi All,

The neutron L3 subteam [1] has been discussing dynamic routing use
cases for a couple of weeks in our meeting.  I attempted to capture
the use cases at a high level here [2].  It is far from complete, I'd
like some feedback from the community on the use cases.

Carl Baldwin

[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
[2] https://wiki.openstack.org/wiki/Neutron/DynamicRoutingUseCases

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

Re: [openstack-dev] [Nova] PTL Candidacy

confirmed

On 03/31/2014 07:53 PM, John Garbutt wrote:
> Hi,
> 
> I would like to run for the OpenStack Compute (Nova) PTL position.
> 
> I find it really rewarding to help resolve conflict. Gallup says I am
> a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
> all sides of the story, learn about everyones point of view, help
> frame the argument, and help come up with a resolution that works for
> everyone. That is why the idea of being a PTL excites me.
> 
> Nova excites me because I love projects that integrate lots of
> different components into a single cohesive user experience. (I see it
> as one of the upsides of my Dyslexia.)
> 
> Should I get elected, Rackspace has promised that Nova PTL will be my
> full time job.
> 
> 
> My (OpenStack) life story...
> 
> 
> My first involvement with Nova was in late 2010, working on what
> became Citrix's "Project Olympus" private cloud packaging of OpenStack
> and XenServer. We got Nova, Glance, Swift and XenServer all installed
> and configured from a CD (or optional PXE) install.
> 
> After some changes in direction at Citrix, I started focusing on
> XenServer and OpenStack integration, with a particular focus on Nova.
> This lead me to form the XenAPI sub team, and help Russell with his
> formalisation of the "Nova Sub-Team" concept.
> 
> In early 2013, I moved to Rackspace. That allowed me to focus more
> attention on the rest of Nova. I am part of the dev team working on
> (probably) the largest Nova installation in the world, Rackspace Cloud
> Servers. I quickly joined nova-core, and then nova-drivers. Most
> recently taking up the role of blueprint czar.
> 
> I feel I am in a better position than most to understand the breadth
> of the Nova community, given my varied experience:
> * moved from packaging OpenStack, then contributing code to Nova, now
> helping more with the leadership of Nova
> * worked on packaging OpenStack for private clouds (at Citrix)
> * currently helping run (probably) the largest Nova deployment on the
> planet, at Rackspace
> * worked at a company whose strategy is more focused on its own
> product, than the success of OpenStack (at Citrix). Note: I consider
> this a perfectly valid situation. Without people concentrating on
> non-OpenStack projects and products, Nova would have nothing to
> orchestrate.
> 
> 
> How I see the PTL role
> --
> 
> The basics of the Project Team Lead (or Project Technical Lead) role
> are covered here:
> https://wiki.openstack.org/wiki/PTLguide
> 
> I feel that the role is really about fostering a vibrant community,
> and ensuring decisions get made, not making the decisions. This
> challenge really excites me, as in the past, I have had much fun, and
> many successes, resolving conflicts between conflicting/competing
> teams, helping them find a good resolution.
> 
> What I have found works is...
> * Agree on a common set of user problems that need to be solved now
> * ... and at the same time, gain a better understanding of where
> people need/want to go in the future
> 
> That way, everyone starts to focus their efforts in the same direction.
> 
> 
> What I would keep
> -
> 
> In summary, I would keep most things. The Nova project is thriving.
> 
> The focus on "cloud" and not "server virt" should continue. That
> doesn't mean we shouldn't work well at the small scale, we should work
> well at both the large scale and the small scale. We should not stop
> the work evolving the architecture of Nova and working out how to
> evolve the API. Indeed, we also need to continue to improve how we
> interface with Neutron, Glance, etc, etc.
> 
> We should also continue to avoid Nova scope creep, and continue to
> reduce the scope of Nova where possible:
> * split out nova-scheduler, to help cross project scheduling
> * deprecate nova-network, or/and split it out of nova
> * keep on the look out for other ideas
> 
> There are several people I would trust to be a good PTL for the next
> cycle, which shows how much Russell has managed to scale out the
> leadership in recent cycles. This drive to scale out the leadership of
> Nova should continue.
> 
> 
> But there are growing pains that need urgent attention...
> 
> 
> What I would change
> ---
> 
> This is not about what we should build in Juno, it's how I'm thinking
> the Nova community and Nova leadership should evolve during Juno:
> 
> 
> 1) Connecting developers with those "using" Nova
> 
> We are a very developer driven community. I would like to work with
> deployers, packagers, and all users, to get their voices heard by the
> Nova developer community.
> 
> The improved blueprint reviews and improved triaging of bugs are a
> good start, but we need to continue to innovate here. Glance have
> included a Product Manager, Brian Rosmaita, on their drivers team. I
> am sure Nova would benefit from getting Product Managers, Operators,
> and others, more invol

Re: [openstack-dev] [Swift] PTL candidacy

confirmed

On 03/31/2014 08:01 PM, John Dickinson wrote:
> I'm announcing my candidacy for Swift PTL. I've been involved with Swift 
> specifically and OpenStack in general since the beginning. I'd like to 
> continue to serve in the role as Swift PTL.
> 
> Swift has grown quite a bit over the last 4 years. In this past year, we've 
> added major new features refactored significant areas of the code to improve 
> efficiency and extensibility. We've added support for global clusters. We've 
> significantly refactored replication to be more efficient. We've cleaned up 
> the volume interface to make it much simpler to extend. Swift is a great 
> storage engine, powering some of the world's largest storage clouds. Let's 
> keep making it better.
> 
> Going forward, I'd like to address four things in Swift in the next year:
> 
> 1) Finish storage policies, including erasure code support. In my opinion, 
> this is the biggest feature in Swift since it was open-sourced, and I'm 
> really excited by the opportunities it enables. I sent an email earlier this 
> month about our current plan on getting storage policies finished up: 
> http://lists.openstack.org/pipermail/openstack-dev/2014-March/030937.html
> 
> 2) Focus on performance and efficiency rather than on a "feature train". 
> We've started on several things here, including the "ssync" replication 
> improvements and some profiling middleware. I'd also like to see improvement 
> in replication bandwidth efficiency (especially with global clusters), 
> time-to-first-byte latency improvement, better support of very dense storage, 
> and support higher concurrency with less resources.
> 
> 3) Better QA. Swift has always been a very stable system. We need to ensure 
> that it remains stable, especially as new feature go in and other parts of 
> the codebase change. Examples here include better functional test coverage, 
> testing against real clusters, more end-to-end testing of workflows, running 
> probetests automatically against submitted changes, and tracking performance 
> metrics against patches. 
> 
> 4) Better community efficiency. As the community has grown, we need to get 
> better at offering feedback channels from production deployments, especially 
> from non-developers. We need to get better at reducing the patch review time 
> and encouraging newer developers to jump in and offer patches.
> 
> These are the things that I want to focus on as PTL in the next 6 to 12 
> months. My vision for Swift is that everyone will use it every day, even if 
> they don't realize it. Together we can make it happen.
> 
> --John
> 
> 
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Swift] PTL candidacy

2014-03-31 Thread John Dickinson

I'm announcing my candidacy for Swift PTL. I've been involved with Swift 
specifically and OpenStack in general since the beginning. I'd like to continue 
to serve in the role as Swift PTL.

Swift has grown quite a bit over the last 4 years. In this past year, we've 
added major new features refactored significant areas of the code to improve 
efficiency and extensibility. We've added support for global clusters. We've 
significantly refactored replication to be more efficient. We've cleaned up the 
volume interface to make it much simpler to extend. Swift is a great storage 
engine, powering some of the world's largest storage clouds. Let's keep making 
it better.

Going forward, I'd like to address four things in Swift in the next year:

1) Finish storage policies, including erasure code support. In my opinion, this 
is the biggest feature in Swift since it was open-sourced, and I'm really 
excited by the opportunities it enables. I sent an email earlier this month 
about our current plan on getting storage policies finished up: 
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030937.html

2) Focus on performance and efficiency rather than on a "feature train". We've 
started on several things here, including the "ssync" replication improvements 
and some profiling middleware. I'd also like to see improvement in replication 
bandwidth efficiency (especially with global clusters), time-to-first-byte 
latency improvement, better support of very dense storage, and support higher 
concurrency with less resources.

3) Better QA. Swift has always been a very stable system. We need to ensure 
that it remains stable, especially as new feature go in and other parts of the 
codebase change. Examples here include better functional test coverage, testing 
against real clusters, more end-to-end testing of workflows, running probetests 
automatically against submitted changes, and tracking performance metrics 
against patches. 

4) Better community efficiency. As the community has grown, we need to get 
better at offering feedback channels from production deployments, especially 
from non-developers. We need to get better at reducing the patch review time 
and encouraging newer developers to jump in and offer patches.

These are the things that I want to focus on as PTL in the next 6 to 12 months. 
My vision for Swift is that everyone will use it every day, even if they don't 
realize it. Together we can make it happen.

--John






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Morgan Fainberg

I’ve been working on (albeit slowly) getting the keystone implementation of 
dogpile.cache into oslo.cache. It’s been slow due to other demands, but I’m 
hoping to get back to it in the near future here so we can make moves like this 
more easily.
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com


On March 31, 2014 at 10:11:21, Dolph Mathews (dolph.math...@gmail.com) wrote:

dogpile.cache would be substantially lighter on the client-side as it only has 
a hard dependency on dogpile.core. It supports plenty of backends beyond 
memcached and we already use it in keystone quite heavily.

  http://dogpilecache.readthedocs.org/en/latest/


On Mon, Mar 31, 2014 at 11:35 AM, Doug Hellmann  
wrote:



On Mon, Mar 31, 2014 at 12:18 PM, Kurt Griffiths  
wrote:
Hi folks, has there been any discussion on using oslo.cache within the 
auth_token middleware to allow for using other cache backends besides 
memcached? I didn’t find a Keystone blueprint for it, and was considering 
registering one for Juno if the team thinks this feature makes sense. I’d be 
happy to put some time into the implementation.

That does make sense. We need to look at the dependency graph between the 
keystoneclient and oslo.cache, though. It appears the current version of 
oslo.cache is going to bring in quite a few oslo libraries that we would not 
want keystoneclient to depend on [1]. Moving the middleware to a separate 
library would solve that.

[1] https://wiki.openstack.org/wiki/Oslo/Dependencies

Doug


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


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

[openstack-dev] [Nova] PTL Candidacy

2014-03-31 Thread John Garbutt

Hi,

I would like to run for the OpenStack Compute (Nova) PTL position.

I find it really rewarding to help resolve conflict. Gallup says I am
a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
all sides of the story, learn about everyones point of view, help
frame the argument, and help come up with a resolution that works for
everyone. That is why the idea of being a PTL excites me.

Nova excites me because I love projects that integrate lots of
different components into a single cohesive user experience. (I see it
as one of the upsides of my Dyslexia.)

Should I get elected, Rackspace has promised that Nova PTL will be my
full time job.


My (OpenStack) life story...


My first involvement with Nova was in late 2010, working on what
became Citrix's "Project Olympus" private cloud packaging of OpenStack
and XenServer. We got Nova, Glance, Swift and XenServer all installed
and configured from a CD (or optional PXE) install.

After some changes in direction at Citrix, I started focusing on
XenServer and OpenStack integration, with a particular focus on Nova.
This lead me to form the XenAPI sub team, and help Russell with his
formalisation of the "Nova Sub-Team" concept.

In early 2013, I moved to Rackspace. That allowed me to focus more
attention on the rest of Nova. I am part of the dev team working on
(probably) the largest Nova installation in the world, Rackspace Cloud
Servers. I quickly joined nova-core, and then nova-drivers. Most
recently taking up the role of blueprint czar.

I feel I am in a better position than most to understand the breadth
of the Nova community, given my varied experience:
* moved from packaging OpenStack, then contributing code to Nova, now
helping more with the leadership of Nova
* worked on packaging OpenStack for private clouds (at Citrix)
* currently helping run (probably) the largest Nova deployment on the
planet, at Rackspace
* worked at a company whose strategy is more focused on its own
product, than the success of OpenStack (at Citrix). Note: I consider
this a perfectly valid situation. Without people concentrating on
non-OpenStack projects and products, Nova would have nothing to
orchestrate.


How I see the PTL role
--

The basics of the Project Team Lead (or Project Technical Lead) role
are covered here:
https://wiki.openstack.org/wiki/PTLguide

I feel that the role is really about fostering a vibrant community,
and ensuring decisions get made, not making the decisions. This
challenge really excites me, as in the past, I have had much fun, and
many successes, resolving conflicts between conflicting/competing
teams, helping them find a good resolution.

What I have found works is...
* Agree on a common set of user problems that need to be solved now
* ... and at the same time, gain a better understanding of where
people need/want to go in the future

That way, everyone starts to focus their efforts in the same direction.


What I would keep
-

In summary, I would keep most things. The Nova project is thriving.

The focus on "cloud" and not "server virt" should continue. That
doesn't mean we shouldn't work well at the small scale, we should work
well at both the large scale and the small scale. We should not stop
the work evolving the architecture of Nova and working out how to
evolve the API. Indeed, we also need to continue to improve how we
interface with Neutron, Glance, etc, etc.

We should also continue to avoid Nova scope creep, and continue to
reduce the scope of Nova where possible:
* split out nova-scheduler, to help cross project scheduling
* deprecate nova-network, or/and split it out of nova
* keep on the look out for other ideas

There are several people I would trust to be a good PTL for the next
cycle, which shows how much Russell has managed to scale out the
leadership in recent cycles. This drive to scale out the leadership of
Nova should continue.


But there are growing pains that need urgent attention...


What I would change
---

This is not about what we should build in Juno, it's how I'm thinking
the Nova community and Nova leadership should evolve during Juno:


1) Connecting developers with those "using" Nova

We are a very developer driven community. I would like to work with
deployers, packagers, and all users, to get their voices heard by the
Nova developer community.

The improved blueprint reviews and improved triaging of bugs are a
good start, but we need to continue to innovate here. Glance have
included a Product Manager, Brian Rosmaita, on their drivers team. I
am sure Nova would benefit from getting Product Managers, Operators,
and others, more involved in setting project priorities.

One idea: Agree on rough focus areas for each release. Focus areas are
a level of detail where everyone can engage, but with enough detail to
be useful in setting priorities of blueprints and bugs. Efforts that
match the focus areas can be given a highe

[openstack-dev] [Neutron] Dynamic Routing Blueprint Updated

2014-03-31 Thread Artem Dmytrenko

Hi team.

The dynamic routing blueprint has been updated to reflect the feedback 
received during L3 subteam meetings over the last few weeks. The 
blueprint is registered here: 
https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing, and the 
full specification is available here: 
https://docs.google.com/a/midokura.com/document/d/1wUcgL6ZTqB14DsiNvGaA1Ao2Try5i5E7_VAzcavzTbY/edit.

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

Re: [openstack-dev] [Neutron] PTL Candidacy

2014-03-31 Thread CôngTT

Thanks anh. Lúc chiều e cũng bookmark bài này rồi. E phải xem kỹ phần kiến
trúc trong neutron, phần network này vẫn chưa thông lắm anh ạ.

P/s: Anh gửi tài liệu OVS cho e và Long nhé.
On 1 Apr 2014 00:04, "Kyle Mestery"  wrote:

> Hi everyone,
>
> I have decided to run for the OpenStack Networking (Neutron) PTL position.
>
> Why I Want To Be Neutron PTL
> -
> I want to be Neutron PTL because I wish to continue pushing Neutron forward
> and help it evolve, and have the skills necessary to do it. I've worked in
> Open
> Source for many years, having contributed to projects such as Open vSwitch,
> libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a
> great
> team of developers, both core and non-core contributors. Being able to help
> them all work productively together and push Neutron forward is something I
> not only want to do, but something I think I can be very effective at.
>
> Qualifications
> -
> I have been a core developer since the beginning of the Havana cycle. My
> main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
> which I've co-lead for the last year. I wrote the OpenDaylight ML2
> driver, as well
> as the devstack integration and Jenkins setup for OpenDaylight. I have also
> been leading a sub-team focused on Group Based Policy since the Icehouse
> Summit. As on Open vSwitch developer, my focus has been on improving
> Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
> Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
> from the OpenStack community to an audience in the upper Midwest. I've
> presented at the last few OpenStack Summits on Open Source SDN topics, as
> well as giving presentations on OpenStack at other Open Source
> conferences. I
> recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
> developers to interact with not only each other but also developers from
> OpenStack Neutron and OpenDaylight.
>
> Icehouse Accomplishments
> -
> This past cycle, my main focus was continuing to expand the ML2 sub-team
> and
> assist plugin developers who were porting their existing core plugins
> into ML2 or
> writing brand new ML2 drivers. I also formed and lead the Group Based
> Policy
> sub-team, which is now marching towards a Proof of Concept for the Juno
> Summit
>  In addition, I've spent time with the OpenDaylight project to ensure that
> OpenDaylight integrates with OpenStack Neutron as an ML2 driver.
>
> Looking forward to Juno
> -
> If I am elected PTL, I'd like to focus on a few areas for Neutron. One
> immediate
> area of improvement I'd like to do is around the blueprint process. I've
> been
> watching what Russell and the Nova team have been doing with setting up the
> Nova BP process to use gerrit, and I'd like to move Neutron in this
> direction as well.
> Formalizing this process a bit more will lead to less surprises for BP
> drafters, and
> will also ensure core reviewers know what they are signing up for as
> people propose
> features. I'd also like to work to expand our core reviewer team in
> the Juno cycle. As
> the project has grown, the existing core reviewers could use some
> assistance by
> working to expand the team and spread the review load. Along these
> lines, I'd also
> like to empower the sub-teams in Neutron. The project has grown to a point
> where
> empowering the various sub-teams to allow more effective decision
> making would be
> a good thing. I'd like to continue the focus on ensuring Neutron is a
> good citizen in
> the community by ensuring we squash bugs related to the gate. And
> finally, I want to
> work to ensure we have a scalable, production quality Open Source
> Neutron reference
> implementation in the Juno timeframe.
>
> In closing
> -
> OpenStack Neutron has taken a big step forward in the Icehouse cycle
> with regards to
> stability and testing. Ensuring we continue to enhance the development
> process will
> allow us to continue making strides in this area and allow Neutron to
> continue evolving
> in a positive direction.
>
> Thank you,
> Kyle
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Feature about QEMU Assisted online-extend volume

2014-03-31 Thread Duncan Thomas

On 29 March 2014 02:49, Zhangleiqiang (Trump)  wrote:
> Hi, Duncan:
> Thanks for your advice.
>
> About the "summit session" you mentioned, what things can I do for it 
> ?

If you (or a colleague who can speak on your behalf) is going to the
summit, then go to 'http://summit.openstack.org/' and click 'suggest
session'. Note that you will need somebody to present / discuss /
defend the proposal at the summit, it rarely goes well if the proposer
isn't present.

Having a detailed blueprint available before the summit also helps, in
this case it looks like that is covered.

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

Re: [openstack-dev] [Neutron] PTL Candidacy

confirmed

On 03/31/2014 01:04 PM, Kyle Mestery wrote:
> Hi everyone,
> 
> I have decided to run for the OpenStack Networking (Neutron) PTL position.
> 
> Why I Want To Be Neutron PTL
> -
> I want to be Neutron PTL because I wish to continue pushing Neutron forward
> and help it evolve, and have the skills necessary to do it. I've worked in 
> Open
> Source for many years, having contributed to projects such as Open vSwitch,
> libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a great
> team of developers, both core and non-core contributors. Being able to help
> them all work productively together and push Neutron forward is something I
> not only want to do, but something I think I can be very effective at.
> 
> Qualifications
> -
> I have been a core developer since the beginning of the Havana cycle. My
> main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
> which I've co-lead for the last year. I wrote the OpenDaylight ML2
> driver, as well
> as the devstack integration and Jenkins setup for OpenDaylight. I have also
> been leading a sub-team focused on Group Based Policy since the Icehouse
> Summit. As on Open vSwitch developer, my focus has been on improving
> Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
> Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
> from the OpenStack community to an audience in the upper Midwest. I've
> presented at the last few OpenStack Summits on Open Source SDN topics, as
> well as giving presentations on OpenStack at other Open Source conferences. I
> recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
> developers to interact with not only each other but also developers from
> OpenStack Neutron and OpenDaylight.
> 
> Icehouse Accomplishments
> -
> This past cycle, my main focus was continuing to expand the ML2 sub-team and
> assist plugin developers who were porting their existing core plugins
> into ML2 or
> writing brand new ML2 drivers. I also formed and lead the Group Based Policy
> sub-team, which is now marching towards a Proof of Concept for the Juno Summit
>  In addition, I've spent time with the OpenDaylight project to ensure that
> OpenDaylight integrates with OpenStack Neutron as an ML2 driver.
> 
> Looking forward to Juno
> -
> If I am elected PTL, I'd like to focus on a few areas for Neutron. One 
> immediate
> area of improvement I'd like to do is around the blueprint process. I've been
> watching what Russell and the Nova team have been doing with setting up the
> Nova BP process to use gerrit, and I'd like to move Neutron in this
> direction as well.
> Formalizing this process a bit more will lead to less surprises for BP
> drafters, and
> will also ensure core reviewers know what they are signing up for as
> people propose
> features. I'd also like to work to expand our core reviewer team in
> the Juno cycle. As
> the project has grown, the existing core reviewers could use some assistance 
> by
> working to expand the team and spread the review load. Along these
> lines, I'd also
> like to empower the sub-teams in Neutron. The project has grown to a point 
> where
> empowering the various sub-teams to allow more effective decision
> making would be
> a good thing. I'd like to continue the focus on ensuring Neutron is a
> good citizen in
> the community by ensuring we squash bugs related to the gate. And
> finally, I want to
> work to ensure we have a scalable, production quality Open Source
> Neutron reference
> implementation in the Juno timeframe.
> 
> In closing
> -
> OpenStack Neutron has taken a big step forward in the Icehouse cycle
> with regards to
> stability and testing. Ensuring we continue to enhance the development
> process will
> allow us to continue making strides in this area and allow Neutron to
> continue evolving
> in a positive direction.
> 
> Thank you,
> Kyle
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] Decorator behavior

2014-03-31 Thread Dan Smith

> At run time there are decorators that behave in an unexpected manner.
> For instance, in nova/compute/manager.py when ComputeManager's
> resize_instance method is called, the "migration" positional argument
> is somehow added to kwargs (paired with the "migration" key) and is
> stripped out of the args parameters when the decorators are called.
> However, when this same method is called in
> nova/tests/compute/test_compute_mgr.py, the "migration" positional
> argument remains in args when the decorators are called.  In other
> words at run time the decorators see these arguments:
> 
> (self, context, [], {'migration': migration, 'image': image,
> 'instance': instance, 'reservations': reservations})
> 
> while when running a test case, they see these arguments:
> 
> (self, context, [instance, image, reservations, migration,
> instance_type], {})

All RPC-called methods get called with all of their arguments as keyword
arguments. I think this explains the runtime behavior you're seeing.
Tests tend to differ in this regard because test writers are human and
call the methods in the way they normally expect, passing positional
arguments when appropriate.

--Dan


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

Re: [openstack-dev] [nova] avahi-autoipd vs. nova networking (cloud-init)

2014-03-31 Thread Lars Kellogg-Stedman

On Sat, Mar 29, 2014 at 11:53:13AM -0400, Mike Spreitzer wrote:
> I run into trouble in Ubuntu VMs when avahi-autoipd is installed. 
> After avahi-autoipd is installed, there is an extra route (number 2 in the 
> [...]
> Of course, avahi-autoipd thinks it is doing me a favor.  Nova thinks it is 
> doing me harm.  Which is right, and how do we achieve harmony?

Why are you installing avahi-autoipd in your cloud instance?  The
autoipd tool is used for configuring network interfaces in the absence
of either a static configuration or a functioning dhcp
environment...and because you're running in a cloud environment,
you're pretty much guaranteed the latter.

If you really want zeroconf networking to be functional inside your
instances while at the same time maintaining access to the OpenStack
metadata service, you could add an explicit route to the metadata
address via your default gateway.  For example, given:

# ip route
default via 10.0.0.1 dev eth0  metric 100 
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.4 
169.254.0.0/16 dev eth0  scope link  metric 1000 

I would add:

  ip route add 169.254.169.254 via 10.0.0.1

And this restores access to the metadata service.  This forces the
kernel to pass traffic to 169.254.169.254 to the gateway, rather than
assuming it's accessible via a local network.

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack  | "   "  @ twitter

pgpjmNHTFPbOK.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican PTL Candidacy

On 03/31/2014 12:18 PM, Jarret Raim wrote:
> I'd like to throw my name in for PTL for the Key Management Program which
> includes the Barbican, python-barbicanclient and Kite projects.
Also please note for the purposes of elections the only repositories
eligible for consideration are the repositories listed in:
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml

> 
> I've been working on Barbican since the first line of code was committed
> and was responsible for building the team and desire at Rackspace to start
> the project. It is a confluence of ideas from my time as a security
> consultant, internal security architect and OpenStack contributor. I
> believe that Barbican is key to allowing other projects in OpenStack to
> expose desired features in the encryption space while meeting requirements
> from security or compliance conscious customers. Additionally, the team
> that we build for Barbican (both inside and outside of Rackspace) tends to
> draw security minded folks that contribute their time and expertise to the
> community.
> 
> My goal for the Juno cycle is to move Barbican through the incubation
> process while incorporating the Kite work done in Keystone and filling out
> the next set of planned features. With the requirements for integration
> being clarified now, I'm not sure we'll be ready for integration in the
> Juno cycle, but we will certainly be tackling as many of those as possible.
> 
> In addition to the integration work, Barbican has several community and
> feature goals:
> 
> Community:
> * Continue to drive wider community adoption. We've had a great start with
> folks from HP, Nebula, Red Hat and others, but we want to continue to
> diversify the team.
> * Adopt a new blueprint system using Gerrit similar to Nova
> * Discuss the future of the oslo.crypto libraries with the Oslo team
> * Continue to evangelize Barbican and OpenStack in various venues through
> speaking and training engagements
> 
> 
> Features:
> * Asymmetric key generation and escrow support include support for
> external CAs
> * Land the Dogtag support patches from Red Hat
> * Auditing and logging compliance requirements
> * Land the preliminary work done for the Kite project
> 
> 
> 
> 
> 
> Thanks,
> Jarret
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

[openstack-dev] Decorator behavior

2014-03-31 Thread John S Warren

At run time there are decorators that behave in an unexpected manner.
For instance, in nova/compute/manager.py when ComputeManager's
resize_instance method is called, the "migration" positional argument
is somehow added to kwargs (paired with the "migration" key) and is
stripped out of the args parameters when the decorators are called.
However, when this same method is called in
nova/tests/compute/test_compute_mgr.py, the "migration" positional
argument remains in args when the decorators are called.  In other
words at run time the decorators see these arguments:

(self, context, [], {'migration': migration, 'image': image,
'instance': instance, 'reservations': reservations})

while when running a test case, they see these arguments:

(self, context, [instance, image, reservations, migration,
instance_type], {})


What is happening at run time to cause this behavior?  How can this
behavior be duplicated when executing test cases, so that the test
cases correctly mimic run-time behavior?___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican PTL Candidacy

confirmed

On 03/31/2014 12:18 PM, Jarret Raim wrote:
> I'd like to throw my name in for PTL for the Key Management Program which
> includes the Barbican, python-barbicanclient and Kite projects.
> 
> I've been working on Barbican since the first line of code was committed
> and was responsible for building the team and desire at Rackspace to start
> the project. It is a confluence of ideas from my time as a security
> consultant, internal security architect and OpenStack contributor. I
> believe that Barbican is key to allowing other projects in OpenStack to
> expose desired features in the encryption space while meeting requirements
> from security or compliance conscious customers. Additionally, the team
> that we build for Barbican (both inside and outside of Rackspace) tends to
> draw security minded folks that contribute their time and expertise to the
> community.
> 
> My goal for the Juno cycle is to move Barbican through the incubation
> process while incorporating the Kite work done in Keystone and filling out
> the next set of planned features. With the requirements for integration
> being clarified now, I'm not sure we'll be ready for integration in the
> Juno cycle, but we will certainly be tackling as many of those as possible.
> 
> In addition to the integration work, Barbican has several community and
> feature goals:
> 
> Community:
> * Continue to drive wider community adoption. We've had a great start with
> folks from HP, Nebula, Red Hat and others, but we want to continue to
> diversify the team.
> * Adopt a new blueprint system using Gerrit similar to Nova
> * Discuss the future of the oslo.crypto libraries with the Oslo team
> * Continue to evangelize Barbican and OpenStack in various venues through
> speaking and training engagements
> 
> 
> Features:
> * Asymmetric key generation and escrow support include support for
> external CAs
> * Land the Dogtag support patches from Red Hat
> * Auditing and logging compliance requirements
> * Land the preliminary work done for the Kite project
> 
> 
> 
> 
> 
> Thanks,
> Jarret
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Roman Bogorodskiy

  Michał Dubiel wrote:

> Hi All,
> 
> I have prepared commits I would like to have it reviewed and eventually
> merged that add initial, limited support for FreeBSD as a host to nova. It
> includes basic networking via freebsd_net driver (similar to the linux_net)
> and few addons to libvirt compute driver in order to support the bhyve
> hypervisor. Intent for those commits is let other play with openstack on
> FreeBSD and to provide a code base for further development, as the current
> version comes with many limitations like:
> 
> - Only FreeBSD guest OSes can be used
> - No support for the config drive
> - Only one disk and one Ethernet interface
> - No pause/resume functionality
> - No VM migration support
> - No files injection to VMs filesystem
> - Only works with bridged networking using nova-network with Flat/FlatDHCP
> multi-host mode
> 
> Unit test are included, however, for all that to work on a real system you
> have to use a slightly patched version of libvirt as not all features has
> been merged to the official repository yet. My question is if that is
> applicable to be merged at all, or should I wait for all necessary stuff to
> be in libvirt official repository at first? I want also mention that there
> is an active work underway in libvirt community to have all them
> implemented and included in the libvirt code.

Hi Michal,

I'd say it would be good to revive the old blueprint about bhyve
support and push the patches. Also, probably freebsd_net itself
deserve a blueprint on its own. And I guess it could be tested
independently of bhyve driver because as you might now qemu driver is
also supported on FreeBSD.

As for the bhyve, I think it's ok to push it now and mark it WIP for
example. I'd think it's not a small piece of code and will take some
time to review anyway.

But I think it cannot be merged until libvirt supports all the required
features (otherwise it'd be troublesome to setup gate jobs for bhyve for
I think).

As for the modifications to libvirt, unfortunately, they'll not get it
into the upcoming 1.2.3 as the freeze started already.

Roman Bogorodskiy

pgptY0LlVscTq.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Russell Bryant

On 03/31/2014 01:01 PM, Michał Dubiel wrote:
> Hi All,
> 
> I have prepared commits I would like to have it reviewed and eventually
> merged that add initial, limited support for FreeBSD as a host to nova.
> It includes basic networking via freebsd_net driver (similar to the
> linux_net) and few addons to libvirt compute driver in order to support
> the bhyve hypervisor. Intent for those commits is let other play with
> openstack on FreeBSD and to provide a code base for further development,
> as the current version comes with many limitations like:
> 
> - Only FreeBSD guest OSes can be used
> - No support for the config drive
> - Only one disk and one Ethernet interface
> - No pause/resume functionality
> - No VM migration support
> - No files injection to VMs filesystem
> - Only works with bridged networking using nova-network with
> Flat/FlatDHCP multi-host mode
> 
> Unit test are included, however, for all that to work on a real system
> you have to use a slightly patched version of libvirt as not all
> features has been merged to the official repository yet. My question is
> if that is applicable to be merged at all, or should I wait for all
> necessary stuff to be in libvirt official repository at first? I want
> also mention that there is an active work underway in libvirt community
> to have all them implemented and included in the libvirt code.

The limitations you mention are pretty severe, so I'm not sure this
sounds like something we would want to include in that state.

If the gaps were closed, the biggest blocker to considering it for
merging would be a CI platform that's running Nova in this setup against
every patch.  We require that for all hypervisor drivers now.

https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan

-- 
Russell Bryant

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

Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Aryeh Friedman

How do you handle the fact that as it stands bhyve can only run *nix like
OS's (specifically FreeBSD and Linux only)?   The long term answer seems to
be a working kqemu or use something like PetiteCloud (
http://www.petitecloud.org) as a bridge (run OS nested on bhyve under PC)


On Mon, Mar 31, 2014 at 1:01 PM, Michał Dubiel  wrote:

> Hi All,
>
> I have prepared commits I would like to have it reviewed and eventually
> merged that add initial, limited support for FreeBSD as a host to nova. It
> includes basic networking via freebsd_net driver (similar to the linux_net)
> and few addons to libvirt compute driver in order to support the bhyve
> hypervisor. Intent for those commits is let other play with openstack on
> FreeBSD and to provide a code base for further development, as the current
> version comes with many limitations like:
>
> - Only FreeBSD guest OSes can be used
> - No support for the config drive
> - Only one disk and one Ethernet interface
> - No pause/resume functionality
> - No VM migration support
> - No files injection to VMs filesystem
> - Only works with bridged networking using nova-network with Flat/FlatDHCP
> multi-host mode
>
> Unit test are included, however, for all that to work on a real system you
> have to use a slightly patched version of libvirt as not all features has
> been merged to the official repository yet. My question is if that is
> applicable to be merged at all, or should I wait for all necessary stuff to
> be in libvirt official repository at first? I want also mention that there
> is an active work underway in libvirt community to have all them
> implemented and included in the libvirt code.
>
> Regards,
> Michal
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Dolph Mathews

dogpile.cache would be substantially lighter on the client-side as it only
has a hard dependency on dogpile.core. It supports plenty of backends
beyond memcached and we already use it in keystone quite heavily.

  http://dogpilecache.readthedocs.org/en/latest/


On Mon, Mar 31, 2014 at 11:35 AM, Doug Hellmann  wrote:

>
>
>
> On Mon, Mar 31, 2014 at 12:18 PM, Kurt Griffiths <
> kurt.griffi...@rackspace.com> wrote:
>
>>  Hi folks, has there been any discussion on using oslo.cache within the
>> auth_token middleware to allow for using other cache backends besides
>> memcached? I didn’t find a Keystone blueprint for it, and was considering
>> registering one for Juno if the team thinks this feature makes sense. I’d
>> be happy to put some time into the implementation.
>>
>
> That does make sense. We need to look at the dependency graph between the
> keystoneclient and oslo.cache, though. It appears the current version of
> oslo.cache is going to bring in quite a few oslo libraries that we would
> not want keystoneclient to depend on [1]. Moving the middleware to a
> separate library would solve that.
>
> [1] https://wiki.openstack.org/wiki/Oslo/Dependencies
>
> Doug
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Mistral] Community meeting minutes - 03/31/2014

2014-03-31 Thread Renat Akhmerov

Thanks for joining IRC meeting today at #openstack-meeting channel.

As usually,

Minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-31-16.00.html
Full log: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-31-16.00.log.html

Looking forward to see you again in one week.

Renat Akhmerov
@ Mirantis Inc.



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

[openstack-dev] bug/129135

2014-03-31 Thread sowmini . varadhan


openstack-dev,

A question about the fix from https://review.openstack.org/#/c/82931

After this fix, the neutron code now explicitly checks for kernel
version 3.13- was this deliberate? (I was using an older 3.11 version
before, and did not seem to have any issues before this change).

Is there a specific kernel patch that ovs-vxlan is dependant on?

Thanks
Sowmini

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

[openstack-dev] [Neutron] PTL Candidacy

2014-03-31 Thread Kyle Mestery

Hi everyone,

I have decided to run for the OpenStack Networking (Neutron) PTL position.

Why I Want To Be Neutron PTL
-
I want to be Neutron PTL because I wish to continue pushing Neutron forward
and help it evolve, and have the skills necessary to do it. I've worked in Open
Source for many years, having contributed to projects such as Open vSwitch,
libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a great
team of developers, both core and non-core contributors. Being able to help
them all work productively together and push Neutron forward is something I
not only want to do, but something I think I can be very effective at.

Qualifications
-
I have been a core developer since the beginning of the Havana cycle. My
main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
which I've co-lead for the last year. I wrote the OpenDaylight ML2
driver, as well
as the devstack integration and Jenkins setup for OpenDaylight. I have also
been leading a sub-team focused on Group Based Policy since the Icehouse
Summit. As on Open vSwitch developer, my focus has been on improving
Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
from the OpenStack community to an audience in the upper Midwest. I've
presented at the last few OpenStack Summits on Open Source SDN topics, as
well as giving presentations on OpenStack at other Open Source conferences. I
recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
developers to interact with not only each other but also developers from
OpenStack Neutron and OpenDaylight.

Icehouse Accomplishments
-
This past cycle, my main focus was continuing to expand the ML2 sub-team and
assist plugin developers who were porting their existing core plugins
into ML2 or
writing brand new ML2 drivers. I also formed and lead the Group Based Policy
sub-team, which is now marching towards a Proof of Concept for the Juno Summit
 In addition, I've spent time with the OpenDaylight project to ensure that
OpenDaylight integrates with OpenStack Neutron as an ML2 driver.

Looking forward to Juno
-
If I am elected PTL, I'd like to focus on a few areas for Neutron. One immediate
area of improvement I'd like to do is around the blueprint process. I've been
watching what Russell and the Nova team have been doing with setting up the
Nova BP process to use gerrit, and I'd like to move Neutron in this
direction as well.
Formalizing this process a bit more will lead to less surprises for BP
drafters, and
will also ensure core reviewers know what they are signing up for as
people propose
features. I'd also like to work to expand our core reviewer team in
the Juno cycle. As
the project has grown, the existing core reviewers could use some assistance by
working to expand the team and spread the review load. Along these
lines, I'd also
like to empower the sub-teams in Neutron. The project has grown to a point where
empowering the various sub-teams to allow more effective decision
making would be
a good thing. I'd like to continue the focus on ensuring Neutron is a
good citizen in
the community by ensuring we squash bugs related to the gate. And
finally, I want to
work to ensure we have a scalable, production quality Open Source
Neutron reference
implementation in the Juno timeframe.

In closing
-
OpenStack Neutron has taken a big step forward in the Icehouse cycle
with regards to
stability and testing. Ensuring we continue to enhance the development
process will
allow us to continue making strides in this area and allow Neutron to
continue evolving
in a positive direction.

Thank you,
Kyle

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

[openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Michał Dubiel

Hi All,

I have prepared commits I would like to have it reviewed and eventually
merged that add initial, limited support for FreeBSD as a host to nova. It
includes basic networking via freebsd_net driver (similar to the linux_net)
and few addons to libvirt compute driver in order to support the bhyve
hypervisor. Intent for those commits is let other play with openstack on
FreeBSD and to provide a code base for further development, as the current
version comes with many limitations like:

- Only FreeBSD guest OSes can be used
- No support for the config drive
- Only one disk and one Ethernet interface
- No pause/resume functionality
- No VM migration support
- No files injection to VMs filesystem
- Only works with bridged networking using nova-network with Flat/FlatDHCP
multi-host mode

Unit test are included, however, for all that to work on a real system you
have to use a slightly patched version of libvirt as not all features has
been merged to the official repository yet. My question is if that is
applicable to be merged at all, or should I wait for all necessary stuff to
be in libvirt official repository at first? I want also mention that there
is an active work underway in libvirt community to have all them
implemented and included in the libvirt code.

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

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Paul Michali (pcm)

On Mar 31, 2014, at 12:25 PM, Darragh O'Reilly  
wrote:

> 
> 
> ok, good to hear you are making progress. From the variable names in the 
> script - ifname=$IFNAME_ETH2,vlan=2 - it sounds like this is a Neutron 
> provider network. If so, then it should be possible to bridge the VM to the 
> link with with a simple Linux bridge, without the need for a Neutron port and 
> OVS/br-int.
> 

I’d be interested in hearing more about that, Darragh, as this stuff is pretty 
new for me.  For this interface, it’s not a provider network.

eth0 is the management network, which is local to the host. I create a port on 
the host (192.168.200.3) and in the I/F up script a Neutron port is created and 
bound  (mgmt_p) and added to br-int using ova-vsctl.

eth1 is connected to the devstack public network as public_p, using br-ex 
(again all Neutron calls). I guess this would be a provider net.

eth2, the one in question, is connected to the devstack private network, as 
private_p.  I’m currently using Neutron, for the port create, and then Nova 
(with VIF object instead of dict), and it looks like it hooked up OK (even 
though the “details” are not being set as selected). Discussing with others, it 
sounds like I want to have the ova_hybrid_plug set anyway, so I’m commenting 
out the line I had and trying this:

port_id = port['port']['id']

instance = {'uuid': vm_uuid}
network = {'bridge': 'br-int'}

class VeryDangerousHack(network_model.VIF):
def __init__(self, port_id, mac_addr, network):
super(VeryDangerousHack, self).__init__(
id=port_id, address=mac_addr, network=network,
type=network_model.VIF_TYPE_OVS,
# details={'ovs_hybrid_plug': False, 'port_filter': False},
active=True)

vif = VeryDangerousHack(port_id, mac_addr, network)

# For ML2 plugin
driver = vif_driver.LibvirtGenericVIFDriver({})
driver.plug(instance, vif)

I’m re-stacking and will see if everything is OK (fingers crossed). There was 
some issue on my last try (without the line commented out), but the issue was 
with a the VM’s eht1 (public), which uses a different script (neutron only), so 
I’m trying from scratch just in case I’ve messed things up.

Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

2014-03-31 Thread Timur Sufiev

Thank you,

that was the actual cause of the error. I got the wrong year, my fault.

On Mon, Mar 31, 2014 at 3:55 PM, Akihiro Motoki  wrote:
> According to the failure log, you seem to try to install 2012.2.4 (== Folsom).
> I don't think this is the intended version you want to use. Please check it.
>
> http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_917
> 2014-03-24 11:08:50.917 |   Running setup.py install for horizon-2012.2.4
>
> Thanks,
> Akihiro
>
> On Mon, Mar 31, 2014 at 6:05 PM, Timur Sufiev  wrote:
>> Hello, Akihiro
>>
>> Thanks for the advice (and sorry for not very timely response)! I've
>> added last stable/havana release to the test-requirements, and
>> received some new error from the Jenknins' side: [1]. At first I
>> thought that the problem is caused by the reverse order of settings
>> modules inclusion (and almost renounced the idea of change [2]), but
>> today read the code and traceback again and realized that this error
>> happens even before muranodashboard settings come into play! So now it
>> seems to me that there are some inherent problems with horizon package
>> installation with pip even if the source different from the PyPi is
>> used. Is that a known issue or am I doing something wrong?
>>
>> [1] 
>> http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_923
>> [2] https://review.openstack.org/#/c/68125/
>>
>> On Thu, Mar 20, 2014 at 9:50 PM, Akihiro Motoki  wrote:
>>> As a workaround you can use tarball in requirements.txt (or
>>> test-requirements.txt).
>>> Each versions of Horizon/openstack_dashboard is available at
>>> http://tarballs.openstack.org/horizon/.
>>> Each tarball is generated every time corresponding branch or tag is updated.
>>> If you would like to use horizon I-3 as a requirement, please add the
>>> following line to your requirements.txt:
>>>
>>> http://tarballs.openstack.org/horizon/horizon-2014.1.b3.tar.gz
>>>
>>> Thanks,
>>> Akihiro
>>>
>>> On Fri, Mar 21, 2014 at 2:22 AM, Paul Belanger
>>>  wrote:
 On Mon, Mar 17, 2014 at 5:22 AM, Timur Sufiev  wrote:
> It depends on openstack_dashboard, namely on
> openstack_dashboard.settings. So it is fine from Murano's point of
> view to have openstack_dashboard published on PyPi. Many thanks for
> considering my request :).
>
 We are having this issue too, for now we have worked around it with
 pip switches allowing to download from an external source, but
 hopefully we'll get horizon and openstack_dashboard split out in the
 near future.

 Like you, we've built a dashboard atop of horizon, mostly because of
 the existing keystone integration.  Everything else we do is external
 to OpenStack.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter: 
 https://twitter.com/pabelanger

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



-- 
Timur Sufiev

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

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

On Mon, Mar 31, 2014 at 12:18 PM, Kurt Griffiths <
kurt.griffi...@rackspace.com> wrote:

>  Hi folks, has there been any discussion on using oslo.cache within the
> auth_token middleware to allow for using other cache backends besides
> memcached? I didn't find a Keystone blueprint for it, and was considering
> registering one for Juno if the team thinks this feature makes sense. I'd
> be happy to put some time into the implementation.
>

That does make sense. We need to look at the dependency graph between the
keystoneclient and oslo.cache, though. It appears the current version of
oslo.cache is going to bring in quite a few oslo libraries that we would
not want keystoneclient to depend on [1]. Moving the middleware to a
separate library would solve that.

[1] https://wiki.openstack.org/wiki/Oslo/Dependencies

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

Re: [openstack-dev] [Designate] Atlanta Summit Design Session

2014-03-31 Thread Betsy Luzader

Graham,

I'm definitely interested in a design session. Thanks for offering to put
in the application.

FYI, most of us from Rackspace get in late morning on Monday and are
leaving early afternoon on Friday.

Thanks again,

Betsy

On 3/31/14 9:46 AM, "Hayes, Graham"  wrote:

>Hi All,
>
>The design summit this year has allowed 'Other Projects' (ie non
>incubated projects) to book design sessions.
>
>Is there any interest in trying to get a session in Atlanta?
>
>If people are interested I can do an application for Designate.
>
>Cheers,
>
>Graham
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [dev-env] Error setting up dev environment on Mac OS X (10.9.2)

2014-03-31 Thread Andrew Lazarev

Hi Bob,

The error is because of https://bugs.launchpad.net/sahara/+bug/1283133. Fix
is ready, but not merged to master because of FF (
https://review.openstack.org/#/c/75456/). As a workaround I could suggest
temporarily removing DROP queries in migration script #3. Or use other sql
db (e.g. mysql).

Thanks,
Andrew


On Mon, Mar 31, 2014 at 9:18 AM, Robert Nettleton <
rnettle...@hortonworks.com> wrote:

> Hi All,
>
> I'm trying to setup my dev environment on Mac OS X (10.9.2) with the
> latest Sahara code, using the following instructions:
>
>
> http://docs.openstack.org/developer/sahara/devref/development.environment.html
>
> When I run the "Create database Schema" step, I see the following error:
>
> "
> sqlalchemy.exc.OperationalError: (OperationalError) near "DROP": syntax
> error u'ALTER TABLE job_executions DROP COLUMN java_opts' ()
> "
>
> Has anyone seen this problem?  If so, is there a workaround or setup step
> that I'm missing?
>
> In a separate thread, Sergey mentioned that "gnu-getups" was required on
> Mac OS X for the dev env.  I've installed this package, but it does not
> resolve my problem.
>
> thanks,
> Bob
>
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [marconi] Performance numbers

2014-03-31 Thread Malini Kamalambal

Hello Tomasz,

We have been pulled into some other priorities the past week & haven't got a 
chance yet to run a new benchmark.
I hope to get to it later this week.

Meanwhile if you are interested in deploying Marconi/running the benchmarks 
yourself, please let me know.
We can point you to the benchmark scripts etc.

Thanks!
 Malini

From: Tomasz Janczuk mailto:tom...@janczuk.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, March 25, 2014 4:06 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [marconi] Performance numbers


Hello,


I wonder if any performance measurements have been done with Marconi? Are there 
results available somewhere?


I am generally trying to set my expectations in terms of latency and throughput 
as a function of the size of the deployment, number of queues, number of 
producers/consumers, type of backend, size of backend cluster, guarantees, 
message size etc. Trying to understand how Marconi would do in a large 
multi-tenant deployment.


Any and all data points would be helpful.


Thanks,

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

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Darragh O'Reilly



ok, good to hear you are making progress. From the variable names in the script 
- ifname=$IFNAME_ETH2,vlan=2 - it sounds like this is a Neutron provider 
network. If so, then it should be possible to bridge the VM to the link with 
with a simple Linux bridge, without the need for a Neutron port and OVS/br-int.


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

[openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Kurt Griffiths

Hi folks, has there been any discussion on using oslo.cache within the 
auth_token middleware to allow for using other cache backends besides 
memcached? I didn’t find a Keystone blueprint for it, and was considering 
registering one for Juno if the team thinks this feature makes sense. I’d be 
happy to put some time into the implementation.

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

[openstack-dev] PTL Candidacy

2014-03-31 Thread Michael Basnight

Howdy Trovesters and co,

I would like to announce that i will _not_ be running for the Trove PTL
this cycle. We have some smart peoples who can step up and keep the
momentum going.

Its been a wild ride going into integration, and I feel like its someone
else's turn to have the fun that I have had over the last 6mo (and before
when Trove was a wee little RedDwarf). Thanks to the other PTLs for helping
me shape my PTL role into something tangible. And of course a special shout
out to ttx for helping to keep me focused :) I will be still be working on
Trove full time.

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

[openstack-dev] Barbican PTL Candidacy

2014-03-31 Thread Jarret Raim

I'd like to throw my name in for PTL for the Key Management Program which
includes the Barbican, python-barbicanclient and Kite projects.

I've been working on Barbican since the first line of code was committed
and was responsible for building the team and desire at Rackspace to start
the project. It is a confluence of ideas from my time as a security
consultant, internal security architect and OpenStack contributor. I
believe that Barbican is key to allowing other projects in OpenStack to
expose desired features in the encryption space while meeting requirements
from security or compliance conscious customers. Additionally, the team
that we build for Barbican (both inside and outside of Rackspace) tends to
draw security minded folks that contribute their time and expertise to the
community.

My goal for the Juno cycle is to move Barbican through the incubation
process while incorporating the Kite work done in Keystone and filling out
the next set of planned features. With the requirements for integration
being clarified now, I'm not sure we'll be ready for integration in the
Juno cycle, but we will certainly be tackling as many of those as possible.

In addition to the integration work, Barbican has several community and
feature goals:

Community:
* Continue to drive wider community adoption. We've had a great start with
folks from HP, Nebula, Red Hat and others, but we want to continue to
diversify the team.
* Adopt a new blueprint system using Gerrit similar to Nova
* Discuss the future of the oslo.crypto libraries with the Oslo team
* Continue to evangelize Barbican and OpenStack in various venues through
speaking and training engagements


Features:
* Asymmetric key generation and escrow support include support for
external CAs
* Land the Dogtag support patches from Red Hat
* Auditing and logging compliance requirements
* Land the preliminary work done for the Kite project





Thanks,
Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [dev-env] Error setting up dev environment on Mac OS X (10.9.2)

2014-03-31 Thread Robert Nettleton

Hi All,

I’m trying to setup my dev environment on Mac OS X (10.9.2) with the latest 
Sahara code, using the following instructions:

http://docs.openstack.org/developer/sahara/devref/development.environment.html

When I run the “Create database Schema” step, I see the following error:

"
sqlalchemy.exc.OperationalError: (OperationalError) near "DROP": syntax error 
u'ALTER TABLE job_executions DROP COLUMN java_opts' ()
“

Has anyone seen this problem?  If so, is there a workaround or setup step that 
I’m missing?  

In a separate thread, Sergey mentioned that “gnu-getups” was required on Mac OS 
X for the dev env.  I’ve installed this package, but it does not resolve my 
problem. 

thanks,
Bob
-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API


On 03/31/2014 04:11 PM, Doug Hellmann wrote:




On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim mailto:g...@redhat.com>> wrote:

I have recently been trying to get some API level functional tests
for the olso.messaging library. The idea is that these tests could
be run with any driver and configured 'backend' and would test the
basic functional guarantees that the API makes.


This sounds like a good idea, thanks for tackling it!


Initial changeset for review available here: 
https://review.openstack.org/#/c/84164/


I put these tests in their own module just to highlight that they are 
somewhat different in nature than the unit tests, requiring explicit 
selection of a transport url to use.


Any comments or feedback welcome!

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

[openstack-dev] [Ceilometer] [Horizon] Icehouse RC1 available

2014-03-31 Thread Thierry Carrez

Hello everyone,

Ceilometer and Horizon just published their first Icehouse release
candidate. 38 bugs and bugs, respectively, were fixed in those projects
since feature freeze.

The RC1s are available for download at:
https://launchpad.net/ceilometer/icehouse/icehouse-rc1
https://launchpad.net/horizon/icehouse/icehouse-rc1

Unless release-critical issues are found that warrant a release
candidate respin, these RC1s will be formally released as the 2014.1
final version on April 17. You are therefore strongly encouraged to test
and validate these tarballs !

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/ceilometer/tree/milestone-proposed
https://github.com/openstack/horizon/tree/milestone-proposed

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

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

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

Note that the "master" branches of Ceilometer and Horizon are now open
for Juno development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [infra] Meeting Tuesday April 1st at 19:00 UTC

2014-03-31 Thread Elizabeth Krumbach Joseph

Hi everyone,

No joke, the OpenStack Infrastructure (Infra) team is hosting our
weekly meeting tomorrow, Tuesday April 1st, at 19:00 UTC in
#openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

Re: [openstack-dev] [horizon] Cannot login to dashboard

2014-03-31 Thread Ben Nemec

Please ask usage questions on the non-development list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Thanks.

-Ben

On 03/30/2014 11:34 AM, Andrew Chul wrote:

Hello, guys, I'm new in Horizon. Can anybody tell me how can I login
to my local OpenStack dashboard?




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

Re: [openstack-dev] Oslo PTL Candidacy

confirmed

On 03/31/2014 05:37 PM, Doug Hellmann wrote:
> I am running for a second term as PTL for the OpenStack Common Libraries
> (Oslo) project.
> 
> I have been programming in Python professionally for over 15 years, in a
> variety of application areas. I am currently a Senior Developer at
> DreamHost, on our DreamCompute OpenStack-based public cloud project.
> 
> I started working on OpenStack just before the Folsom summit. I am a core
> reviewer and one of the founding members of the Ceilometer project, and a
> core reviewer for the requirements and unified command line interface
> projects. I am also on the stable release maintenance team and am part of
> the team working on the Python 3 transition. I have contributed to many of
> the OpenStack projects through code and reviews.
> 
> I joined the Oslo team at the Folsom summit, and served as PTL during the
> Icehouse release cycle.
> 
> Although overall I think Icehouse went well for Oslo when checked against
> our internal goals, we have heard from developers in other projects who are
> frustrated. Syncing fixes has become increasingly difficult, and some
> breaking changes were merged in the existing libraries and not caught until
> those libraries were released. The sync issue is a symptom of two
> underlying problems. Our rapid growth as a community has made it difficult
> to keep up with the number of new projects pulling changes from the
> incubator, making it harder for us to keep everyone up to date. Oslo's goal
> of providing a "collaboration space" has also been lost somewhat, and
> instead the program has started to be treated more as a team producing
> tools to be consumed by other projects. We have been working hard to adapt
> Oslo to the changing needs of the community, but to truly fix these issues
> we need to bring back the original collaborative intent of the program.
> 
> During Icehouse we have worked with the infra team to develop the processes
> to release more of the incubated code as standalone libraries [1], and to
> set up the additional testing that will be needed to prevent the issues we
> had with libraries during Icehouse. I anticipate having a few final changes
> land soon after the Icehouse feature freeze lifts to clear the way for our
> Juno plans [2]. As we move more stable code out of the incubator and into
> libraries, it will mean fewer sync merges and better testing of Oslo code
> in devstack and unit test gate jobs. After these initial low level
> libraries are released, we will be able to release more incubated modules
> in future cycles.
> 
> To return Oslo to being a collaborative project, I plan to adopt and
> formalize Joe Gordon's suggestion of having designated liaisons to
> coordinate changes from Oslo code with each project [3]. There are just too
> many other projects for the small Oslo team to be intimately familiar with,
> and contribute to, all of them directly. The liaisons will be responsible
> for helping merge changes into their project to move to the libraries being
> released. We will also need the liaisons to help us identify API
> incompatibilities between what is in the proposed library and the way
> projects are using the incubated modules now.
> 
> In the days leading up to RC1, we have had several different items brought
> to our attention as critical blocking issues that had been going on for
> many weeks. None of these took what I would call a lot of time or effort to
> fix or work around, but because we were not aware of the issues or their
> impact, frustration built up in the teams affected by the issues. I hope
> that having designated liaisons will help us establish communication
> channels to identify, prioritize, and resolve these sorts of issues earlier.
> 
> My commit history:
> https://review.openstack.org/#/q/owner:doug.hellmann%2540dreamhost.com,n,z
> 
> My review history:
> https://review.openstack.org/#/q/reviewer:doug.hellmann%2540dreamhost.com,n,z
> 
> I'm looking forward to continuing to work with everyone,
> Doug
> 
> 
> [1] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
> [2] https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans
> [3] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql


On 03/31/2014 09:24 AM, Solly Ross wrote:

IMHO,Stringifying None and then expecting the *string* to match NULL is wrong.
Could we check to see if `filters[filter_name]` is None and deal with that case 
separately
(i.e `if filters[filter_name] is None:
   filter = column_is_null_check
   else:
   filter = column_attr.op(db_regexp_op)(
   str(filters[filter_name]))`)?


I think we actually should do two separate things.

1) As you suggest, we should special-case testing for "None".  I'm not 
sure that it should be in regex_filter(), it might make more sense to do 
it in instance_get_all_by_filters() and add a comment to regex_filter() 
that it doesn't match "None".


2) The sqlite regexp() function should be modified to behave like mysql 
regexp() so that we don't trigger other mismatches in the future.


Chris

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

[openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

2014-03-31 Thread David Kranz

I was reviewing some ironic changes that are more than a week old and do 
not have any reviews from the ironic team. Having at least one review 
from the ironic team would be very helpful.


 -David

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

Re: [openstack-dev] [Heat] PTL Candidacy

confirmed

On 03/31/2014 05:11 PM, Zane Bitter wrote:
> Greetings, fellow Heatists. My name is not Steve and I would like to
> announce my candidacy for the position of Orchestration PTL.
> 
> Most of you, I hope, already know me. I've been working on Heat
> full-time essentially since the project started, and I've been a member
> of the core team since before that was a thing. I'm pretty familiar with
> both the Heat code and the strategic direction of the program. I've also
> regularly filled in for past PTLs in various capacities (e.g. on the
> Technical Committee, in project meetings, and chairing Heat team
> meetings), so I feel as prepared as one could for being an OpenStack PTL
> without actually having been one.
> 
> Heat has always been a project where the core team members make
> decisions by consensus, the PTL does *not* have the last word on any
> decision, and the role is rotated through the core team. I'd like to
> keep it that way. The term "Program Technical Lead" is a misnomer to me,
> because we expect leadership from everyone in the team, and especially
> the core team. (And, not incidentally, because the responsibilities of
> the PTL are not primarily technical.)
> 
> With the move to a directly-elected Technical Committee, I think it's
> time to revisit the role of the PTLs in OpenStack, and understanding
> that role from the inside will help me to give better input into that
> process. So the main change I want to make to the project is to make
> sure that the _next_ PTL has less work to do.
> 
> PTLs exist primarily to ensure that the program remains accountable to
> the wider OpenStack community, and I am happy to take on that
> accountability because I have complete faith in the core team.
> 
> If elected, it would be my intention to serve for only a single
> development cycle, as previous Heat PTLs have done. I think that has
> proven to be a successful model for building leadership depth,
> maintaining team culture, avoiding burnout and maintaining long-term
> productivity. I'd also like to encourage anyone thinking of running next
> time to consider bringing forward their plans and stepping up now,
> because choice is healthy :)
> 
> Finally, I'd like to take this opportunity to thank the Steves - Dake,
> Hardy and Baker - for all their hard work in this role over the past
> three release cycles. Great work guys!
> 
> cheers,
> Zane.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API


On 03/31/2014 04:41 PM, Doug Hellmann wrote:




On Mon, Mar 31, 2014 at 11:36 AM, Gordon Sim mailto:g...@redhat.com>> wrote:

On 03/31/2014 04:11 PM, Doug Hellmann wrote:

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim mailto:g...@redhat.com>
>> wrote:
 Another slight annoyance from the testing pov is that the API
 provides no way of determining when a server is 'ready'
i.e. when
 its subscriptions are in place. I had to work around this
for qpid
 and rabbit with a short sleep, which is always a bit nasty.


Are you saying that creating the subscription doesn't block
until it is
ready?


With the blocking executor, if I call start() on the server returned
by get_rpc_server(), then the start call blocks (until it detects
stop has been called). It does look like this is just an issue for
that executor though, since the eventlet executor will return after
the listen has been issued.


That's how I would expect them to work. Is the eventlet executor not
"ready" then?


Yes, as I said (in a rather clumsy way), it is just an issue for the 
blocking executor.



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

Re: [openstack-dev] [oslo] ordering of notification 'events' in oslo.messaging


On 03/31/2014 03:36 PM, Sandy Walsh wrote:

If they're on different queues, the order they appear depends on the
consumer(s). It's not really an oslo.messaging issue.


Well, they are on two queues because that's how the oslo.messaging 
notification listener is implemented. However...


[...]

I think we have to assume that ordering cannot be guaranteed and it's
the consumers responsibility to handle it.


... that is indeed a perfectly reasonable position.

I was certainly arguing against that, I was merely pointing out one 
aspect that I found (a little) unexpected. Since it appears to be well 
understood, I apologise for the noise!



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

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API

On Mon, Mar 31, 2014 at 11:36 AM, Gordon Sim  wrote:

> On 03/31/2014 04:11 PM, Doug Hellmann wrote:
>
>> On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim > > wrote:
>> Another slight annoyance from the testing pov is that the API
>> provides no way of determining when a server is 'ready' i.e. when
>> its subscriptions are in place. I had to work around this for qpid
>> and rabbit with a short sleep, which is always a bit nasty.
>>
>>
>> Are you saying that creating the subscription doesn't block until it is
>> ready?
>>
>
> With the blocking executor, if I call start() on the server returned by
> get_rpc_server(), then the start call blocks (until it detects stop has
> been called). It does look like this is just an issue for that executor
> though, since the eventlet executor will return after the listen has been
> issued.


That's how I would expect them to work. Is the eventlet executor not
"ready" then?

Doug



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

[openstack-dev] Oslo PTL Candidacy

I am running for a second term as PTL for the OpenStack Common Libraries
(Oslo) project.

I have been programming in Python professionally for over 15 years, in a
variety of application areas. I am currently a Senior Developer at
DreamHost, on our DreamCompute OpenStack-based public cloud project.

I started working on OpenStack just before the Folsom summit. I am a core
reviewer and one of the founding members of the Ceilometer project, and a
core reviewer for the requirements and unified command line interface
projects. I am also on the stable release maintenance team and am part of
the team working on the Python 3 transition. I have contributed to many of
the OpenStack projects through code and reviews.

I joined the Oslo team at the Folsom summit, and served as PTL during the
Icehouse release cycle.

Although overall I think Icehouse went well for Oslo when checked against
our internal goals, we have heard from developers in other projects who are
frustrated. Syncing fixes has become increasingly difficult, and some
breaking changes were merged in the existing libraries and not caught until
those libraries were released. The sync issue is a symptom of two
underlying problems. Our rapid growth as a community has made it difficult
to keep up with the number of new projects pulling changes from the
incubator, making it harder for us to keep everyone up to date. Oslo's goal
of providing a "collaboration space" has also been lost somewhat, and
instead the program has started to be treated more as a team producing
tools to be consumed by other projects. We have been working hard to adapt
Oslo to the changing needs of the community, but to truly fix these issues
we need to bring back the original collaborative intent of the program.

During Icehouse we have worked with the infra team to develop the processes
to release more of the incubated code as standalone libraries [1], and to
set up the additional testing that will be needed to prevent the issues we
had with libraries during Icehouse. I anticipate having a few final changes
land soon after the Icehouse feature freeze lifts to clear the way for our
Juno plans [2]. As we move more stable code out of the incubator and into
libraries, it will mean fewer sync merges and better testing of Oslo code
in devstack and unit test gate jobs. After these initial low level
libraries are released, we will be able to release more incubated modules
in future cycles.

To return Oslo to being a collaborative project, I plan to adopt and
formalize Joe Gordon's suggestion of having designated liaisons to
coordinate changes from Oslo code with each project [3]. There are just too
many other projects for the small Oslo team to be intimately familiar with,
and contribute to, all of them directly. The liaisons will be responsible
for helping merge changes into their project to move to the libraries being
released. We will also need the liaisons to help us identify API
incompatibilities between what is in the proposed library and the way
projects are using the incubated modules now.

In the days leading up to RC1, we have had several different items brought
to our attention as critical blocking issues that had been going on for
many weeks. None of these took what I would call a lot of time or effort to
fix or work around, but because we were not aware of the issues or their
impact, frustration built up in the teams affected by the issues. I hope
that having designated liaisons will help us establish communication
channels to identify, prioritize, and resolve these sorts of issues earlier.

My commit history:
https://review.openstack.org/#/q/owner:doug.hellmann%2540dreamhost.com,n,z

My review history:
https://review.openstack.org/#/q/reviewer:doug.hellmann%2540dreamhost.com,n,z

I'm looking forward to continuing to work with everyone,
Doug


[1] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
[2] https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans
[3] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API


On 03/31/2014 04:11 PM, Doug Hellmann wrote:

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim mailto:g...@redhat.com>> wrote:
Another slight annoyance from the testing pov is that the API
provides no way of determining when a server is 'ready' i.e. when
its subscriptions are in place. I had to work around this for qpid
and rabbit with a short sleep, which is always a bit nasty.


Are you saying that creating the subscription doesn't block until it is
ready?


With the blocking executor, if I call start() on the server returned by 
get_rpc_server(), then the start call blocks (until it detects stop has 
been called). It does look like this is just an issue for that executor 
though, since the eventlet executor will return after the listen has 
been issued.




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

[openstack-dev] [barbican] Meeting Monday March 31st at 20:00 UTC

2014-03-31 Thread Douglas Mendizabal

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday March 24, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_31_Mar_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizabal




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql

IMHO,Stringifying None and then expecting the *string* to match NULL is wrong.
Could we check to see if `filters[filter_name]` is None and deal with that case 
separately
(i.e `if filters[filter_name] is None:
  filter = column_is_null_check
  else:
  filter = column_attr.op(db_regexp_op)(
  str(filters[filter_name]))`)?

Best Regards,
Solly Ross

- Original Message -
From: "Chris Friesen" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, March 31, 2014 10:57:04 AM
Subject: Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function 
doesn't behave like mysql

On 03/31/2014 08:54 AM, Chris Friesen wrote:
>
> I mentioned this last week in another thread but I suspect it got lost.

I forgot to mention...I've opened this as a bug 
(https://bugs.launchpad.net/nova/+bug/1298690) but I wanted to get some 
wider suggestions as to the proper way to deal with it.

Chris

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

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

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

Building on what John said, I'm a bit wary of introducing semantics into the 
Conductor's live migration code
that are VMWare-specific.  The conductor's live-migration code is supposed to 
be driver-agnostic.  IMHO, it
would be much better if we could handle this at a level where the code was 
already VMWare-specific.

Best Regards,
Solly Ross

- Original Message -
From: "Jay Lau" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, March 31, 2014 10:36:17 AM
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live 
migration with one nova compute

Thanks John. Yes, I also think that this should be a bp as it is going to make 
some changes to enable live migration with only one nova compute, will file a 
blueprint later. 

For your proposal "specify the same host as the instance", this can resolve the 
issue of live migration with target host, but what about the case of live 
migration without target host? If we still allow "specify the same host as the 
instance", the the live migration will goes to dead loop. 

So it seems we definitely need to find a way to specify the node for live 
migration, hope someone else can show some light here. 

Of course, I will file bp and go through the new bp review process for this 
feature. 

Thanks! 

2014-03-31 21:02 GMT+08:00 John Garbutt < j...@johngarbutt.com > : 

On 31 March 2014 10:11, Jay Lau < jay.lau@gmail.com > wrote: 
> Hi, 
> 
> Currently with VMWare VCDriver, one nova compute can manage multiple 
> clusters/RPs, this caused cluster admin cannot do live migration between 
> clusters/PRs if those clusters/PRs managed by one nova compute as the 
> current live migration logic request at least two nova computes. 
> 
> A bug [1] was also filed to trace VMWare live migration issue. 
> 
> I'm now trying the following solution to see if it is acceptable for a fix, 
> the fix wants enable live migration with one nova compute: 
> 1) When live migration check if host are same, check both host and node for 
> the VM instance. 
> 2) When nova scheduler select destination for live migration, the live 
> migration task should put (host, node) to attempted hosts. 
> 3) Nova scheduler needs to be enhanced to support ignored_nodes. 
> 4) nova compute need to be enhanced to check host and node when doing live 
> migration. 
> 
> I also uploaded a WIP patch [2] for you to review the idea of the fix and 
> hope can get some comments from you. 
> 
> [1] https://bugs.launchpad.net/nova/+bug/1192192 
> [2] https://review.openstack.org/#/c/84085 

Long term, finding a way to unify how cells and the VMware driver 
manages multiple hosts, seems like the best way forward. It would be a 
shame for this API to be different between cells and VMware, although 
right now, that might not work too well :( 

A better short term fix, might be to allow you to specify the same 
host as the instance, and the scheduling of the node could be 
delegated to the VMware driver, which might just delegate that to 
vCenter. I assume we still need some way to specify the node, and I 
can't immediately think of a good way forward. 

I feel this should really be treated as a blueprint, and go through 
the new blueprint review process. That should help decide the right 
approach to take. 

John 

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

-- 
Thanks, 

Jay 

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

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

[openstack-dev] [Heat] PTL Candidacy

2014-03-31 Thread Zane Bitter

Greetings, fellow Heatists. My name is not Steve and I would like to 
announce my candidacy for the position of Orchestration PTL.


Most of you, I hope, already know me. I've been working on Heat 
full-time essentially since the project started, and I've been a member 
of the core team since before that was a thing. I'm pretty familiar with 
both the Heat code and the strategic direction of the program. I've also 
regularly filled in for past PTLs in various capacities (e.g. on the 
Technical Committee, in project meetings, and chairing Heat team 
meetings), so I feel as prepared as one could for being an OpenStack PTL 
without actually having been one.


Heat has always been a project where the core team members make 
decisions by consensus, the PTL does *not* have the last word on any 
decision, and the role is rotated through the core team. I'd like to 
keep it that way. The term "Program Technical Lead" is a misnomer to me, 
because we expect leadership from everyone in the team, and especially 
the core team. (And, not incidentally, because the responsibilities of 
the PTL are not primarily technical.)


With the move to a directly-elected Technical Committee, I think it's 
time to revisit the role of the PTLs in OpenStack, and understanding 
that role from the inside will help me to give better input into that 
process. So the main change I want to make to the project is to make 
sure that the _next_ PTL has less work to do.


PTLs exist primarily to ensure that the program remains accountable to 
the wider OpenStack community, and I am happy to take on that 
accountability because I have complete faith in the core team.


If elected, it would be my intention to serve for only a single 
development cycle, as previous Heat PTLs have done. I think that has 
proven to be a successful model for building leadership depth, 
maintaining team culture, avoiding burnout and maintaining long-term 
productivity. I'd also like to encourage anyone thinking of running next 
time to consider bringing forward their plans and stepping up now, 
because choice is healthy :)


Finally, I'd like to take this opportunity to thank the Steves - Dake, 
Hardy and Baker - for all their hard work in this role over the past 
three release cycles. Great work guys!


cheers,
Zane.

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

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim  wrote:

> I have recently been trying to get some API level functional tests for the
> olso.messaging library. The idea is that these tests could be run with any
> driver and configured 'backend' and would test the basic functional
> guarantees that the API makes.
>

This sounds like a good idea, thanks for tackling it!



>
> I have an initial set of such tests now. The url use is set via an
> environment variable, so e.g.
>
> TRANSPORT_URL=rabbit://127.0.0.1 python -m testtools.run
> functional_tests.test_functional.NotifyTests
>
> would run the notify tests against a local rabbit broker on the standard
> port. If attached the tests here, but if there is interest in including
> these in the repo, I'll create a proper changeset for review and comments.
>
> I've run these tests against the qpid and rabbit drivers as well as the
> new AMQP 1.0 based driver available for initial review[1]. For rabbit and
> qpid there is one failure, where the exchange specified in the target is
> ignored. I'll be running them against the 0mq driver also.
>
> At present, against rabbit and qpid, the tests work only if each test is
> run in isolation. This is because there appears to be no way through the
> API to have subscriptions created by the driver to be dropped, short of
> killing the process[2].


> There may be some step my tests aren't doing that would trigger proper
> cleanup. This may also not be that important to real world uses of the
> library(?) and is only a minor irritation from the testing pov. However if
> there is interest, and assuming it is indeed an issue and not just a
> misunderstanding on my part,I can try and get a patch up for review to
> address it.
>

I can see where that would be useful in some apps, so let's see if we can
make the API support it.

Another slight annoyance from the testing pov is that the API provides no
> way of determining when a server is 'ready' i.e. when its subscriptions are
> in place. I had to work around this for qpid and rabbit with a short sleep,
> which is always a bit nasty.
>

Are you saying that creating the subscription doesn't block until it is
ready?



>
> The last issue to mention here is that stop() implementation doesn't
> signal the driver in any way. So to actually get it to stop, at least for
> the blocking executor, you have to send a dummy message after calling
> stop() in order to have the poll() on the listener return and allow the
> detection of the stop flag. This is easy enough to work around in the tests
> and is a lot less nasty than the sleep.
>

That sounds like it would be useful, too, so apps can cleanly disconnect
from the broker.

Doug



>
> --Gordon.
>
> [1] https://review.openstack.org/#/c/75815/
>
> [2] The cleanup() impl for both drivers simply closes any free connections
> in the pool
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Trove] Instance Metadata

2014-03-31 Thread Daniel Salinas

I have completed the blueprint and specification for the proposed
instance metadata code that is up for review.  We can discuss the
blueprint either here or on the IRC channel.

Related links:
Blueprint: https://blueprints.launchpad.net/trove/+spec/trove-metadata
Specification: https://wiki.openstack.org/wiki/Trove-Instance-Metadata

Metadata Code Reviews:
Trove: https://review.openstack.org/#/c/82123/
TroveClient: https://review.openstack.org/#/c/82124/

Enjoy!

-DSal

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

Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql


On 03/31/2014 08:54 AM, Chris Friesen wrote:


I mentioned this last week in another thread but I suspect it got lost.


I forgot to mention...I've opened this as a bug 
(https://bugs.launchpad.net/nova/+bug/1298690) but I wanted to get some 
wider suggestions as to the proper way to deal with it.


Chris


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

[openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql