Re: [Openstack] Security Groups Can't Apply in Kilo with Neutron & XenServer

[Bob Ball]

Hi Adhi,

Ccould you provide more details about how you’re installing Liberty, including 
your local.conf (if using devstack) and the nova / neutron configuration files?
Also details about how you’re booting the instance and what security groups 
you’re expecting to be applied.

Thanks,

Bob

From: Adhi Priharmanto [mailto:adhi@gmail.com]
Sent: 15 September 2016 08:48
To: Huan Xie 
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Security Groups Can't Apply in Kilo with Neutron & 
XenServer

Hi, I still no luck for this problem, even I using liberty release, Security 
groups still not applied on network. can you help me again ?

On Thu, Mar 17, 2016 at 10:55 AM, Adhi Priharmanto 
> wrote:
Ok, 'll try to patched my neutron

On Tue, Mar 15, 2016 at 8:52 AM, Huan Xie 
> wrote:
Hi,
For apply the patch, you need to download the changed file with this 
https://review.openstack.org/#/c/251271/ and its dependent changes, you can 
find its dependent changes in the right corner(Related Changes) in you open the 
link.
For files that you need edit, in the middle of the code review page, you can 
find a section called “Files”, this part shows you which files are changed.

Best Regards//Huan

From: Adhi Priharmanto [mailto:adhi@gmail.com]
Sent: Monday, March 14, 2016 6:21 PM
To: Huan Xie
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Security Groups Can't Apply in Kilo with Neutron & 
XenServer

Hi Xie,

I also commented on your post at blog.citrix :) , for step 1 - 3 was clear for 
me. I still confused about patched code in 
https://review.openstack.org/#/c/251271/ for some file, could you more explain 
how to, which file that I should edit ?

Thanks before

On Mon, Mar 14, 2016 at 3:34 PM, Huan Xie 
> wrote:
Hi Adhi,

Do you use devstack to deploy XenServer + Kilo or manually?
Current Kilo release does not support XenServer + Neutron security group, 
because security group is implemented via iptables on Linux bridge, however, 
there is no Linux bridge created when booting a new instance.
But we now have a new fix to support neutron security group, we have tested 
that it can work, this will be implemented as a blue print 
https://review.openstack.org/#/c/251271/
So, if you want to use neutron security group in Kilo, you should add some 
patch for your code and also please make the configurations as below:


1.   In nova.conf, two configurations should be set
[DEFAULT]
firewall_driver = nova.virt.firewall.NoopFirewallDriver

security_group_api=neutron


[xenserver]
ovs_integration_bridge =
vif_driver = nova.virt.xenapi.vif.XenAPIOpenVswitchDriver

If you don’t know how to configure ovs_integration_bridge, then 
you can refer this blog 
https://www.citrix.com/blogs/2015/11/30/integrating-xenserver-rdo-and-neutron/


2.   In neutron,  check configurations ml2_conf.ini in compute node which 
is used for neutron L2 agent

[agent]

minimize_polling = False

root_helper_daemon =

root_helper = /usr/local/bin/neutron-rootwrap-xen-dom0 
/etc/neutron/rootwrap.conf



[ovs]

integration_bridge =

bridge_mappings =

Also for ovs configuration items, if you don’t clear on how to 
configure them, refer the blog


3.   In neutron, check configurations /etc/neutron/rootwrap.conf in compute 
node

[xenapi]

# XenAPI configuration is only required by the L2 agent if it is to

# target a XenServer/XCP compute host's dom0.

xenapi_connection_url=

xenapi_connection_username=

xenapi_connection_password=


Best Regards//Huan


 Original Message 
Subject: [Openstack] Security Groups Can't Apply in Kilo with Neutron & 
XenServer
From: Adhi Priharmanto
To: openstack@lists.openstack.org
CC:
Hi all,

I had Openstack Kilo installed on my lab, for Compute Hypervisor I use 
XenServer 6.5, and networking Using Neutron OVS. For Controller, Network, and 
Compute node I'm using Ubuntu 14.04.

My problem was Security Groups rules doesn't applied to the instance that 
created. For example, there is no rule for SSH port 22 in security group i 
defined to the instance, but instance with floating IP able to login by ssh 
from external network.

I've already add this option on my nova.conf

firewall_driver=nova.virt.xenapi.firewall.Dom0IptablesFirewallDriver

and also defined firewall_driver on my ml2_conf.ini at Controller, Network, and 
Compute node

[ovs]
enable_security_group = True
enable_ipset = True
firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

can somebody help me with this problem ?


--
Cheers,


Adhi Priharmanto
about.me/a_dhi









___
Mailing list: 

Re: [Openstack] dashboard login screen with domain drop-down

[Nicolas Bock]

Hi Brad,

thanks!

Nick

On Thu, Sep 15, 2016 at 3:50 PM, Brad Pokorny  wrote:
> There's not a way to configure Horizon to do what you want, so you'd have
> to write custom code to do that.
>
> Also, there are security considerations to do it. Note that the default v3
> keystone policy[1] doesn't allow just any user to list all domains in the
> cloud. The list of domains is potentially information you wouldn't want an
> attacker to have, and if the list is on the Horizon login screen, anyone
> can see it.
>
> [1]
> https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.
> json#L32
>
> Brad
>
> On 9/15/16, 2:22 PM, "Nicolas Bock"  wrote:
>
>>Hi,
>>
>>when I deploy the dashboard with
>>`OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT` turned on, the login screen
>>gains a new text field for the domain. Is it possible to turn that
>>text field into a multiple choice drop down menu?
>>
>>Thanks,
>>
>>Nick
>>
>>___
>>Mailing list:
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>Post to : openstack@lists.openstack.org
>>Unsubscribe :
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] dashboard login screen with domain drop-down

[Brad Pokorny]

There's not a way to configure Horizon to do what you want, so you'd have
to write custom code to do that.

Also, there are security considerations to do it. Note that the default v3
keystone policy[1] doesn't allow just any user to list all domains in the
cloud. The list of domains is potentially information you wouldn't want an
attacker to have, and if the list is on the Horizon login screen, anyone
can see it.

[1] 
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.
json#L32

Brad

On 9/15/16, 2:22 PM, "Nicolas Bock"  wrote:

>Hi,
>
>when I deploy the dashboard with
>`OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT` turned on, the login screen
>gains a new text field for the domain. Is it possible to turn that
>text field into a multiple choice drop down menu?
>
>Thanks,
>
>Nick
>
>___
>Mailing list: 
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>Post to : openstack@lists.openstack.org
>Unsubscribe : 
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Security Groups Can't Apply in Kilo with Neutron & XenServer

[Adhi Priharmanto]

Hi, I still no luck for this problem, even I using liberty release,
Security groups still not applied on network. can you help me again ?

On Thu, Mar 17, 2016 at 10:55 AM, Adhi Priharmanto 
wrote:

> Ok, 'll try to patched my neutron
>
> On Tue, Mar 15, 2016 at 8:52 AM, Huan Xie  wrote:
>
>> Hi,
>>
>> For apply the patch, you need to download the changed file with this
>> https://review.openstack.org/#/c/251271/ and its dependent changes, you
>> can find its dependent changes in the right corner(Related Changes) in you
>> open the link.
>>
>> For files that you need edit, in the middle of the code review page, you
>> can find a section called “Files”, this part shows you which files are
>> changed.
>>
>>
>>
>> Best Regards//Huan
>>
>>
>>
>> *From:* Adhi Priharmanto [mailto:adhi@gmail.com]
>> *Sent:* Monday, March 14, 2016 6:21 PM
>> *To:* Huan Xie
>> *Cc:* openstack@lists.openstack.org
>> *Subject:* Re: [Openstack] Security Groups Can't Apply in Kilo with
>> Neutron & XenServer
>>
>>
>>
>> Hi Xie,
>>
>>
>>
>> I also commented on your post at blog.citrix :) , for step 1 - 3 was
>> clear for me. I still confused about patched code in
>> https://review.openstack.org/#/c/251271/ for some file, could you more
>> explain how to, which file that I should edit ?
>>
>>
>>
>> Thanks before
>>
>>
>>
>> On Mon, Mar 14, 2016 at 3:34 PM, Huan Xie  wrote:
>>
>> Hi Adhi,
>>
>>
>>
>> Do you use devstack to deploy XenServer + Kilo or manually?
>>
>> Current Kilo release does not support XenServer + Neutron security group,
>> because security group is implemented via iptables on Linux bridge,
>> however, there is no Linux bridge created when booting a new instance.
>>
>> But we now have a new fix to support neutron security group, we have
>> tested that it can work, this will be implemented as a blue print
>> https://review.openstack.org/#/c/251271/
>>
>> So, if you want to use neutron security group in Kilo, you should add
>> some patch for your code and also please make the configurations as below:
>>
>>
>>
>> 1.   In nova.conf, two configurations should be set
>>
>> [DEFAULT]
>>
>> firewall_driver = nova.virt.firewall.NoopFirewallDriver
>>
>> security_group_api=neutron
>>
>>
>>
>> [xenserver]
>>
>> ovs_integration_bridge =
>>
>> vif_driver = nova.virt.xenapi.vif.XenAPIOpenVswitchDriver
>>
>>
>>
>> If you don’t know how to configure
>> ovs_integration_bridge, then you can refer this blog
>> https://www.citrix.com/blogs/2015/11/30/integrating-
>> xenserver-rdo-and-neutron/
>>
>>
>>
>> 2.   In neutron,  check configurations ml2_conf.ini in compute node
>> which is used for neutron L2 agent
>>
>> [agent]
>>
>> minimize_polling = False
>>
>> root_helper_daemon =
>>
>> root_helper = /usr/local/bin/neutron-rootwrap-xen-dom0
>> /etc/neutron/rootwrap.conf
>>
>>
>>
>> [ovs]
>>
>> integration_bridge =
>>
>> bridge_mappings =
>>
>>
>>
>> Also for ovs configuration items, if you don’t clear on
>> how to configure them, refer the blog
>>
>>
>>
>> 3.   In neutron, check configurations /etc/neutron/rootwrap.conf in
>> compute node
>>
>> [xenapi]
>>
>> # XenAPI configuration is only required by the L2 agent if it is to
>>
>> # target a XenServer/XCP compute host's dom0.
>>
>> xenapi_connection_url=
>>
>> xenapi_connection_username=
>>
>> xenapi_connection_password=
>>
>>
>>
>> Best Regards//Huan
>>
>>
>>
>>  Original Message 
>> Subject: [Openstack] Security Groups Can't Apply in Kilo with Neutron &
>> XenServer
>> From: Adhi Priharmanto
>> To: openstack@lists.openstack.org
>> CC:
>>
>> Hi all,
>>
>> I had Openstack Kilo installed on my lab, for Compute Hypervisor I use
>> XenServer 6.5, and networking Using Neutron OVS. For Controller, Network,
>> and Compute node I'm using Ubuntu 14.04.
>>
>>
>>
>> My problem was Security Groups rules doesn't applied to the instance that
>> created. For example, there is no rule for SSH port 22 in security group i
>> defined to the instance, but instance with floating IP able to login by ssh
>> from external network.
>>
>>
>> I've already add this option on my nova.conf
>>
>>
>>
>> firewall_driver=nova.virt.xenapi.firewall.Dom0IptablesFirewallDriver
>>
>>
>>
>> and also defined firewall_driver on my ml2_conf.ini at Controller,
>> Network, and Compute node
>>
>>
>>
>> [ovs]
>>
>> enable_security_group = True
>>
>> enable_ipset = True
>>
>> firewall_driver = neutron.agent.linux.iptables_firewall.
>> OVSHybridIptablesFirewallDriver
>>
>>
>>
>> can somebody help me with this problem ?
>>
>>
>>
>>
>>
>> --
>>
>> Cheers,
>>
>>
>>
>> *Adhi Priharmanto*
>>
>> about.me/a_dhi
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>>
>>
>>
>>
>> --
>>
>> 

[Openstack] [Windows-Guest] Cloudbase init & sysprep Resets Administrator Password

[Vaidyanath Manogaran]

I am trying to install cloudbase init in win2012 and do sysprep.
Everytime i get the node its resetting my administrator password though i
had given a different user to be created.

what could be the reason for this to happen?

-- 
Regards,

Vaidyanath
+91-9483465528(M)
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0066] MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] dashboard login screen with domain drop-down

[Nicolas Bock]

Hi,

when I deploy the dashboard with
`OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT` turned on, the login screen
gains a new text field for the domain. Is it possible to turn that
text field into a multiple choice drop down menu?

Thanks,

Nick

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] public cloud runners

[s serge]

Hello,

I'm wondering is there anybody here who is participating to run a public cloud 
listed at https://www.openstack.org/marketplace/public-clouds/  
and would like to share the real experience related to the subject.

In particular, I interested to know about a billing solution a project is using 
...

In general, I'm considering an opportunity to join openstack public cloud 
business and appreciate any feedback based on real experience.

Thanks,
Regards,
Serge.



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [puppet] Core nominations

[Emilien Macchi]

While our group keeps moving, it's time to propose again new people
part of core team.

Dmitry Tantsur / puppet-ironic
Dmitry is the guardian of puppet-ironic. He's driving most of the
recent features in this module and he now fully deserves being core on
it.

Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
Prad is our Telemetry guru and he never stops to bring attention on
these modules! Keep going Prad, we appreciate your help here.

Iury Gregory / all modules
Iury is our padawan. Still learning, but learning fast, he has been a
continuous contributor over the last months. He's always here on IRC
and during meetings to help.
He always volunteer to help and not for the most fun tasks. (He drove
the authtoken work during Newton). I would like to reward his work and
show that we trust him to be a good core reviewer.
Iury, keep going in your efforts!


If your name is not here yet, please keep doing consistent work, help
in bug triage, maintain stable CI, doing good reviews, improve our
documentation, etc.

As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [cue][qa] Status of OpenStack CI jobs

[Hayes, Graham]

On 15/09/2016 00:12, Ken'ichi Ohmichi wrote:
> Hi Cue-team,
>
> As http://status.openstack.org/openstack-health/#/ , the cue gate jobs
> continues failing 100%.
> What is current status of the development?
> Hopefully the  job will become stable for smooth development.
>
> Thanks
> Ken Ohmichi

I am not sure what the status of development is, but it looks like they 
hit the same issue some of us did with olso.context 2.6.0 (when the
output of to_dict() changed).



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


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

Re: [openstack-dev] [TripleO] TripleO Core nominations

[Emilien Macchi]

On Thu, Sep 15, 2016 at 5:20 AM, Steven Hardy  wrote:
> Hi all,
>
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
>
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
>
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
>
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).

While I think this is good because our team is respectful about this
rule, I'm still thinking that's something we might want to revisit one
day.
In Puppet OpenStack, we created subgroups for specific modules because
some people were contributing to one modules and had one area of
expertise (ie: keystone for puppet-keystone), etc.

I guess we're fine now but having subgroups could help us to scale our
team by more proposing people working on a specific project more
quickly. Also, as long as we keep creating projects, it's not clear to
me who can really +2 a patch in this project.
Having subgroups would just clarify it. Anyway, this is not a critical
topic today but I might propose a change in the next months.

> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
>
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
>
> 1. Brent Eagles
>
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.

Big +1. And not because he's Canadian :-)
Seriously, Brent, you're doing a great job and I'm looking forward to
seeing your next contributions to make networking better in TripleO.

> 2. Pradeep Kilambi
>
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.

Same comment as Brent, Prad is always here to fix or improve Telemetry
things in TripleO. Keep going please :-)

> 3. Carlos Camacho
>
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.

Carlos was very helpful for composability work during the cycle, +1!

> 4. Ryan Brady
>
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.

Yes! Ryan has dramatically contributed to this topic, he deserves core
review on tripleo-common and tripleoclient.

> 5. Dan Sneddon
>
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network 

[openstack-dev] [vitrage] PTL candidacy

[Afek, Ifat (Nokia - IL)]

Hi All,

I would like to announce my candidacy to continue as Vitrage PTL for the Ocata
release.

I've been leading the Vitrage project development from the day it started, in
Mitaka. During this time our team has made tremendous progress, and now we have
a fully-functional RCA service. The project was accepted into the big tent
seven months after it started, in early June this year.

There are few areas I think we should focus on in the Ocata cycle. I believe
the main one is to enlarge our community. New contributors are welcome to join!
To achieve this, we should work on integrations with other OpenStack projects,
and continue our involvement in OPNFV.

Other goals are to increase the project stability, improve the UI, add new
datasources, and better support multi-tenancy use cases and templates CRUD.
The Ocata cycle is very short, but I believe we can achieve most of these
goals.

Looking forward to continue this exciting journey!

Thank you,
Ifat Afek

[1] https://review.openstack.org/370767



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

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

[Sean Dague]

On 09/15/2016 09:20 AM, Roman Podoliaka wrote:
> Sean,
> 
> So currently we have a default timeout of 160s in Nova. And
> specifically for migration tests we set a scaling factor of 2. Let's
> maybe give 2.5 or 3 a try ( https://review.openstack.org/#/c/370805/ )
> and make a couple of "rechecks" to see if it helps or not.

Given the fail rate, lets just go safe and double it to 4. If it's
really a timeout issue that should move the bell curve to mostly cover
it. Timeouts are really just supposed to be a backstop to ensure the
tests don't deadlock forever.

The incidence rate is at that odd race rate that we'll probably have to
merge and just see if it goes away.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [release][neutron] networking-ovn Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for networking-ovn for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/networking-ovn/networking-ovn-1.0.0.0rc1.tar.gz

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

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

http://git.openstack.org/cgit/openstack/networking-ovn/log/?h=stable/newton

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

https://bugs.launchpad.net/networking-ovn/+filebug

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

Note that the "master" branch of networking-ovn is now open for Newton
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] Spain Visa for Indian contributors

[Gorka Eguileor Gimeno]

Hi,

As a native Spanish speaker I offer my help with the translation if needed.
I assume the OpenStack visa team would be the one required to issue the
translated invitation letter for it to be valid.

Cheers,
Gorka.

On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy 
wrote:

> Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
> ==
> For business visas:
> □ Invitation letter from the Spanish company in Spanish language or both
> in English and Spanish.Letters issued only in English will not be
> accepted. This will be an obligatory requirement.
> ===
>
> On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy  > wrote:
>
>> That's good. Please share the appropriate link/url to openstack visa team.
>>
>> On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek <
>> abhishek.kek...@nttdata.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Yes it’s request from embassy than for Indian citizens invitation letter
>>> should be in Spanish as well English language.
>>>
>>> I have sent mail to openstack visa team.
>>>
>>>
>>>
>>> Thank you,
>>>
>>>
>>>
>>> Abhishek Kekane
>>>
>>>
>>>
>>> *From:* M Ranga Swami Reddy [mailto:swamire...@gmail.com]
>>> *Sent:* Thursday, September 15, 2016 1:06 PM
>>>
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] Spain Visa for Indian contributors
>>>
>>>
>>>
>>> Hi,
>>>
>>> Who asked the invitation letter in Spanish? Is it embassy, please share
>>> the same info openstack visa team.
>>>
>>>
>>>
>>> JYI - for Tokyo - invitation letter was in Japanese only.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Swami
>>>
>>>
>>>
>>> On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek <
>>> abhishek.kek...@nttdata.com> wrote:
>>>
>>> Hi Janki,
>>>
>>>
>>>
>>> I will keep you posted about this. Mean time sent mail to ‘
>>> eventv...@openstack.org’ to explain your issue and also give reference
>>> of this ML.
>>>
>>>
>>>
>>> Thank you,
>>>
>>>
>>>
>>> Abhishek Kekane
>>>
>>>
>>>
>>> *From:* Janki Chhatbar [mailto:jankih...@gmail.com]
>>> *Sent:* Thursday, September 15, 2016 11:51 AM
>>>
>>>
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] Spain Visa for Indian contributors
>>>
>>>
>>>
>>> Hi Abhishek
>>>
>>> I am Janki. I am applying for visa from India. I haven't applied yet but
>>> a friend of mine is facing the same issue of needing an invitation letter
>>> in Spanish.
>>>
>>> May be everyone applying from India can request to have the letter in
>>> Spanish too.
>>>
>>> Let me know how you proceed further. It would help me while applying.
>>>
>>> Thanks
>>>
>>> Janki
>>>
>>>
>>>
>>> On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek <
>>> abhishek.kek...@nttdata.com> wrote:
>>>
>>> Hi John,
>>>
>>> I have sent mail to 'eventv...@openstack.org', waiting for positive
>>> reply.
>>>
>>> One reply I got from Kendall is,
>>>
>>> We only send the letter in English. No one else applying for a visa has
>>> had a problem getting their visa with just the English letter so the letter
>>> you received should be sufficient.
>>>
>>> I will show this reply mail at VFS center and hopefully they will take
>>> no objection about this.
>>>
>>> Thank you for your time,
>>>
>>> Abhishek Kekane
>>>
>>> -Original Message-
>>> From: John Villalovos [mailto:openstack@sodarock.com]
>>>
>>> Sent: Thursday, September 15, 2016 11:17 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>>>
>>> On that page they seem to list a contact email:
>>>
>>> eventv...@openstack.org
>>>
>>> Hopefully they can help with the issue.
>>>
>>> John
>>>
>>> On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <
>>> abhishek.kek...@nttdata.com> wrote:
>>> > Hi John,
>>> >
>>> > I have read the information given at
>>> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
>>> > and got the invitation letter but it's in English language. Problem is
>>> that Visa centers in India are demanding this invitation letter in English
>>> as well as Spanish language.
>>> >
>>> > Thank you,
>>> >
>>> > Abhishek Kekane
>>> >
>>> > -Original Message-
>>> > From: John Villalovos [mailto:openstack@sodarock.com]
>>> > Sent: Thursday, September 15, 2016 9:45 AM
>>> > To: OpenStack Development Mailing List (not for usage questions)
>>> > Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>>> >
>>> > There is information on the Visa process at:
>>> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
>>> >
>>> > Not sure if you have already read that information.
>>> >
>>> > They talk about the steps needed to get an invitation letter.
>>> >
>>> > Good luck!
>>> >
>>> >
>>> > On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek <
>>> abhishek.kek...@nttdata.com> wrote:
>>> >> Hi Devs, Stackers,
>>> >>
>>> >>
>>> >>
>>> >> While applying visa from Pune (India), I came to know that 

Re: [openstack-dev] [nova] Question about fixing missing soft deleted rows

[Sean Dague]

On 09/14/2016 09:21 PM, Matt Riedemann wrote:
> I'm looking for other input on a question I have in this change:
> 
> https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py
> 
> We've had a few patches like this where we don't (soft) delete entries
> related to an instance when that instance record is (soft) deleted.
> These then cause the archive command to fail because of the referential
> constraint.
> 
> Then we go in and add a new entry in the instance_destroy method so we
> start (soft) deleting *new* things, but we don't cleanup anything old.
> 
> In the change above this is working around the fact we might have
> lingering consoles entries for an instance that's being archived.
> 
> One suggestion I made was adding a database migration that soft deletes
> any console entries where the related instance is deleted (deleted !=
> 0). Is that a bad idea? It's not a schema migration, it's data cleanup
> so archive works. We could do the same thing with a nova-manage command,
> but we don't know that someone has run it like they do with the DB
> migrations.
> 
> Another idea is doing it in the nova-manage db online_data_migrations
> command which should be run on upgrade. If we landed something like that
> in say Ocata, then we could remove the TODO in the archive code in Pike.
> 
> Other thoughts?

Is there a reason that archive doesn't go hunt for these references
first and delete them? I kind of assumed it would handle all the cleanup
logic itself, including this sort of integrity issue.

The data migration would still take time, and a table lock, even though
it's just deletes, so that feels like it should be avoided.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [trove] Newton RC1 tagged

[Amrith Kumar]

As I type this email, the release team is tagging Trove and Trove Dashboard 
Newton RC1. Once this process is complete, master will be heading for Ocata and 
if you want something into Newton, you will have to explicitly chkin to the 
Newton branch.

We will have an RC2 in a week or so to pick up any late bug fixes, and to pick 
up translations that may come in.

During this week, if you find a bug that you believe should be fixed in Newton 
RC2, please tag the bug "*newton-rc-potential*" in Launchpad.

If a fix includes a new message, I will likely reject it as we'll end up with 
an RC3. Unless it is crucial that the message change, that is.

Great job everyone, Newton features a bunch of exciting and new stuff, 
including the items below from the release notes that everyone provided.

features:
  - Add support for configuration group management for DB2 Express-C.
  - Add support for full online backup and restore for DB2
Express-C by enabling archive logging.
  - The reset-status command will set the task and status of
an instance to ERROR after which it can be deleted.
  - The force-delete command will allow the deletion of an
instance even if the instance is stuck in BUILD state.
  - The --incremental flag for backup-create will add the
ability to create incremental backup based on last full or
incremental backup. If no full or incremental backup
exists a new full backup will be created.
  - New instance upgrade API supports upgrading an instance of
a datastore to a new datastore version.  Includes
implementation for MySQL family of databases.
  - A locality flag was added to the trove ReST API to allow a
user to specify whether the instances of a cluster should
be on the same hypervisor (affinity) or on different
hypervisors (anti-affinity).
  - Support for standard WAL based streaming replication for
postgresql guests. Sets up read-only hot standby servers.
  - New quota management APIs for reviewing and changing the
quota for a particular tenant.  Requires admin privileges.
  - Add disk column in flavor-list (Bug 1617987).
  - Add vCPU column in flavor-list (Bug 1261876).
  - Add support for scheduled backups through Mistral.
  - Add log retreival capability for Cassandra datastores.
  - Add New Relic license driver.
  - Add PostgreSQL Incremental Backup and Restore.
fixes:
  - Applying a module again will now relect the update name,
type, datastore and datastore_version values. (Bug 1611525)
  - Updating a module with all_datastores and
all_datastore_versions now works correctly. (Bug 1612430)
  - Close the race condition window in user-list call. (Bug
1617464)
  - Fix bug regarding specification of volume-type on cluster
create (Bug 1623005)
  - Insulate TroveContext from oslo.context changes (Bug
1551468)
  - Improve logging of errors from the Guest (Bug 1618922)
  - Deprecate guest_log_long_query_time (Bug 1542485)
  - Insulate TroveContext from oslo.context changes
  - Separate database and user create in prepare
  - Deprecate 'guest_log_long_query_time'
  - Improve guest error reporting by calling GuestError with
proper options

On to Ocata!

-amrith

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

[openstack-dev] [release][trove] Trove Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for trove for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/trove/trove-6.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of trove is now open for Newton
development, and feature freeze restrictions no longer apply there!

Doug

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

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

[Roman Podoliaka]

Sean,

So currently we have a default timeout of 160s in Nova. And
specifically for migration tests we set a scaling factor of 2. Let's
maybe give 2.5 or 3 a try ( https://review.openstack.org/#/c/370805/ )
and make a couple of "rechecks" to see if it helps or not.

In Ocata we could revisit the migrations collapse again to reduce the
number of scripts.

On the testing side, we could probably "cheat" a bit to trade data
safety for performance. E.g. we could set "fsync = off" for PostgreSQL
(https://www.postgresql.org/docs/9.2/static/runtime-config-wal.html).
Similar settings must be available for MySQL as well.

Thanks,
Roman

On Thu, Sep 15, 2016 at 3:07 PM, Sean Dague  wrote:
> On 09/15/2016 05:52 AM, Roman Podoliaka wrote:
>> Mike,
>>
>> On Thu, Sep 15, 2016 at 5:48 AM, Mike Bayer  wrote:
>>
>>> * Prior to oslo.db 4.13.3, did we ever see this "timeout" condition occur?
>>> If so, was it also accompanied by the same "resource closed" condition or
>>> did this second part of the condition only appear at 4.13.3?
>>> * Did we see a similar "timeout" / "resource closed" combination prior to
>>> 4.13.3, just with less frequency?
>>
>> I believe we did -
>> https://bugs.launchpad.net/openstack-ci/+bug/1216851 , although we
>> used mysql-python back then, so the error was slightly different.
>>
>>> * What is the magnitude of the "timeout" this fixture is using, is it on the
>>> order of seconds, minutes, hours?
>>
>> It's set in seconds per project in .testr.conf, e.g.:
>>
>> https://github.com/openstack/nova/blob/master/.testr.conf
>> https://github.com/openstack/ironic/blob/master/.testr.conf
>>
>> In Nova we also have a 'timeout scaling factor' specifically set for
>> migration tests:
>>
>> https://github.com/openstack/nova/blob/master/nova/tests/unit/db/test_migrations.py#L67
>>
>>> * If many minutes or hours, can the test suite be observed to be stuck on
>>> this test?   Has someone tried to run a "SHOW PROCESSLIST" while this
>>> condition is occurring to see what SQL is pausing?
>>
>> We could try to do that in the gate, but I don't expect to see
>> anything interesting: IMO, we'd see regular queries that should have
>> been executed fast, but actually took much longer time (presumably due
>> to heavy disk IO caused by multiple workers running similar tests in
>> parallel).
>>
>>> * Is this failure only present within the Nova test suite or has it been
>>> observed in the test suites of other projects?
>>
>> According to
>>
>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22sqlalchemy.exc.ResourceClosedError%5C%22
>>
>> it's mostly Nova, but this has also been observed in Ironic, Manila
>> and Ceilometer. Ironic and Manila have OS_TEST_TIMEOUT value set to 60
>> seconds.
>>
>>> * Is this failure present only on the "database migration" test suite or is
>>> it present in other opportunistic tests, for Nova and others?
>>
>> Based on the console logs I've checked only migration tests failed,
>> but that's probably due to the fact that they are usually the slowest
>> ones (again, presumably due to heavy disk IO).
>>
>>> * Have there been new database migrations added to Nova which are being
>>> exercised here and may be involved?
>>
>> Looks like there were no changes recently:
>>
>> https://review.openstack.org/#/q/project:openstack/nova+status:merged+branch:master+(file:%22%255Enova/db/sqlalchemy/migrate_repo/.*%2524%22+OR+file:%22%255Enova/tests/unit/db/test_migrations.py%2524%22)
>>
>>> I'm not sure how much of an inconvenience it is to downgrade oslo.db. If
>>> downgrading it is feasible, that would at least be a way to eliminate it as
>>> a possibility if these same failures continue to occur, or a way to confirm
>>> its involvement if they disappear.   But if downgrading is disruptive then
>>> there are other things to look at in order to have a better chance at
>>> predicting its involvement.
>>
>> I don't think we need to block oslo.db 4.13.3, unless we clearly see
>> it's this version that causes these failures.
>>
>> I gave version 4.11 (before changes to provisioning) a try on my local
>> machine and see the very same errors when concurrency level is high (
>> http://paste.openstack.org/show/577350/ ), so I don't think the latest
>> oslo.db release has anything to do with the increase of the number of
>> failures on CI.
>>
>> My current understanding is that the load on gate nodes somehow
>> increased (either we run more testr workers in parallel now or
>> apply/test more migrations or just more run VMs per host or the gate
>> is simply busy at this point of the release cycle), so that we started
>> to see these timeouts more often.
>
> The migration count is definitely going to grow over time, as is the
> nature of the beast. Nova hasn't had a migration collapse in quite a
> while. The higher patch volume in Nova and larger number of db
> migrations could definitely account for Nova being higher here.
>
> Is there a better 

[openstack-dev] [release][trove] trove-dashboard Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for trove-dashboard for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/trove-dashboard/trove-dashboard-7.0.0.0rc1.tar.gz

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

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

http://git.openstack.org/cgit/openstack/trove-dashboard/log/?h=stable/newton

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

https://bugs.launchpad.net/trove-dashboard/+filebug

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

Note that the "master" branch of trove-dashboard is now open for Newton
development, and feature freeze restrictions no longer apply there!

Doug


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

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

[Roman Podoliaka]

Mike,

I think the exact error (InterfaceError vs TimeoutException) varies
depending on what code is being executed at the very moment when a
process receives SIGALRM.

I tried to run the tests against PostgreSQL passing very small timeout
values (OS_TEST_TIMEOUT=5 python -m testtools.run
nova.tests.unit.db.test_migrations.TestNovaMigrationsPostgreSQL.test_walk_versions)
and saw both InterfaceError and TimeoutException:

http://paste.openstack.org/show/577410/
http://paste.openstack.org/show/577411/

strace'ing shows that a connection to PostgreSQL is closed right after
SIGARLM is handled:

http://paste.openstack.org/show/577425/

I tried to reproduce that manually by the means of gdb and set a
breakpoint on close():

http://paste.openstack.org/show/577422/

^ looks like psycopg2 closes the connection automatically if a query
was interrupted by SIGALRM.

The corresponding Python level backtrace is:

http://paste.openstack.org/show/577423/

^ i.e. connection closing happens in the middle of cursor.execute() call.

In the end I see a similar InterfaceError:

http://paste.openstack.org/show/577424/

That being said, this does not explain the "DB is in use" part.

Thanks,
Roman

On Thu, Sep 15, 2016 at 6:05 AM, Mike Bayer  wrote:
> There's a different set of logs attached to the launchpad issue, that's not
> what I was looking at before.
>
> These logs are at
> http://logs.openstack.org/90/369490/1/check/gate-nova-tox-db-functional-ubuntu-xenial/085ac3e/console.html#_2016-09-13_14_54_18_098031
> .In these logs, I see something *very* different, not just the MySQL
> tests but the Postgresql tests are definitely hitting conflicts against the
> randomly generated database.
>
> This set of traces, e.g.:
>
> sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) database
> "dbzrtmgbxv" is being accessed by other users
> 2016-09-13 14:54:18.093723 | DETAIL:  There is 1 other session using the
> database.
> 2016-09-13 14:54:18.093736 |  [SQL: 'DROP DATABASE dbzrtmgbxv']
>
> and
>
> File
> "/home/jenkins/workspace/gate-nova-tox-db-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
> line 668, in _rollback_impl
> 2016-09-13 14:54:18.095470 |
> self.engine.dialect.do_rollback(self.connection)
> 2016-09-13 14:54:18.095513 |   File
> "/home/jenkins/workspace/gate-nova-tox-db-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
> line 420, in do_rollback
> 2016-09-13 14:54:18.095526 | dbapi_connection.rollback()
> 2016-09-13 14:54:18.095548 | sqlalchemy.exc.InterfaceError:
> (psycopg2.InterfaceError) connection already closed
>
> are a very different animal. For one thing, they're on Postgresql where the
> driver and DB acts extremely rationally.   For another, there's no timeout
> exception here, and not all the conflicts are within the teardown.
>
> Are *these* errors also new as of version 4.13.3 of oslo.db ?   Because here
> I have more suspicion of one particular oslo.db change here.
>
>
>
>
>
>
>
>  fits much more with your initial description
>
>
> On 09/14/2016 10:48 PM, Mike Bayer wrote:
>>
>>
>>
>> On 09/14/2016 07:04 PM, Alan Pevec wrote:

 Olso.db 4.13.3 did hit the scene about the time this showed up. So I
 think we need to strongly consider blocking it and revisiting these
 issues post newton.
>>>
>>>
>>> So that means reverting all stable/newton changes, previous 4.13.x
>>> have been already blocked https://review.openstack.org/365565
>>> How would we proceed, do we need to revert all backport on stable/newton?
>>
>>
>> In case my previous email wasn't clear, I don't *yet* see evidence that
>> the recent 4.13.3 release of oslo.db is the cause of this problem.
>> However, that is only based upon what I see in this stack trace, which
>> is that the test framework is acting predictably (though erroneously)
>> based on the timeout condition which is occurring.   I don't (yet) see a
>> reason that the same effect would not occur prior to 4.13.3 in the face
>> of a signal pre-empting the work of the pymysql driver mid-stream.
>> However, this assumes that the timeout condition itself is not a product
>> of the current oslo.db version and that is not known yet.
>>
>> There's a list of questions that should all be answerable which could
>> assist in giving some hints towards this.
>>
>> There's two parts to the error in the logs.  There's the "timeout"
>> condition, then there is the bad reaction of the PyMySQL driver and the
>> test framework as a result of the operation being interrupted within the
>> test.
>>
>> * Prior to oslo.db 4.13.3, did we ever see this "timeout" condition
>> occur?   If so, was it also accompanied by the same "resource closed"
>> condition or did this second part of the condition only appear at 4.13.3?
>>
>> * Did we see a similar "timeout" / "resource closed" combination prior
>> to 4.13.3, just with less frequency?

Re: [openstack-dev] [fuel-library] Nominate Stanislaw Bogatkin to fuel-library core

[Maksim Malchuk]

As there are no objections so, please welcome Stanislaw as he's just joined
fuel-library Core Team!

On Tue, Sep 13, 2016 at 3:07 PM, Aleksey Kasatkin 
wrote:

> +1
>
>
> Aleksey Kasatkin
>
>
> On Mon, Sep 12, 2016 at 5:01 PM, Alex Schultz  wrote:
>
>> +1
>>
>> On Wed, Sep 7, 2016 at 5:07 PM, Maksim Malchuk 
>> wrote:
>> > Hello,
>> >
>> > I would like to nominate Stanislaw Bogatkin to fuel-library core due to
>> his
>> > significant contribution to the project [1] and [2]. He is one of the
>> top
>> > reviewers and contributors in the project.
>> >
>> > [1]
>> > http://stackalytics.com/?user_id=sbogatkin_type=all;
>> release=all=marks=fuel-library
>> > [2] http://stackalytics.com/report/contribution/fuel-library/90
>> >
>> > --
>> > Best Regards,
>> > Maksim Malchuk,
>> > Senior DevOps Engineer,
>> > MOS: Product Engineering,
>> > Mirantis, Inc
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

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

Re: [openstack-dev] [fuel-virtualbox] Nominate Serhii Ovsianikov to fuel-virtualbox core

[Maksim Malchuk]

As there are no objections so, please welcome Serhii as he's just joined
fuel-virtualbox Core Team!

On Thu, Sep 8, 2016 at 12:01 PM, Sergey Kulanov 
wrote:

> +1
>
> 2016-09-08 11:12 GMT+03:00 Vladimir Kozhukalov :
>
>> +1
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 8, 2016 at 1:55 AM, Maksim Malchuk 
>> wrote:
>>
>>> Hello,
>>>
>>> I would like to nominate Serhii Ovsianikov to fuel-virtualbox core due
>>> to his significant contribution to the project [1] and [2]. He is the
>>> second reviewer and for the last half of the year [2] acts as an unoficial
>>> QA in the fuel-virtualbox project.
>>>
>>> [1] http://stackalytics.com/?user_id=sovsianikov_typ
>>> e=all=all=marks=fuel-virtualbox
>>> [2] http://stackalytics.com/report/contribution/fuel-virtualbox/180
>>>
>>> --
>>> Best Regards,
>>> Maksim Malchuk,
>>> Senior DevOps Engineer,
>>> MOS: Product Engineering,
>>> Mirantis, Inc
>>> 
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Sergey
> DevOps Engineer
> IRC: SergK
> Skype: Sergey_kul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
Mirantis, Inc

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

[openstack-dev] [release][manila] manila Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for manila for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/manila/manila-3.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of manila is now open for Newton
development, and feature freeze restrictions no longer apply there!

Doug

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

Re: [openstack-dev] [nova] Question about fixing missing soft deleted rows

[Sylvain Bauza]

Le 15/09/2016 14:21, Sean Dague a écrit :

On 09/14/2016 09:21 PM, Matt Riedemann wrote:

I'm looking for other input on a question I have in this change:

https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py

We've had a few patches like this where we don't (soft) delete entries
related to an instance when that instance record is (soft) deleted.
These then cause the archive command to fail because of the referential
constraint.

Then we go in and add a new entry in the instance_destroy method so we
start (soft) deleting *new* things, but we don't cleanup anything old.

In the change above this is working around the fact we might have
lingering consoles entries for an instance that's being archived.

One suggestion I made was adding a database migration that soft deletes
any console entries where the related instance is deleted (deleted !=
0). Is that a bad idea? It's not a schema migration, it's data cleanup
so archive works. We could do the same thing with a nova-manage command,
but we don't know that someone has run it like they do with the DB
migrations.

Another idea is doing it in the nova-manage db online_data_migrations
command which should be run on upgrade. If we landed something like that
in say Ocata, then we could remove the TODO in the archive code in Pike.

Other thoughts?

Is there a reason that archive doesn't go hunt for these references
first and delete them? I kind of assumed it would handle all the cleanup
logic itself, including this sort of integrity issue.


That's the alternative approach I was thinking in my email. Yeah, maybe 
reconciling the DB when archiving the rows seems the better approach 
instead of a periodic call for fixing that.




The data migration would still take time, and a table lock, even though
it's just deletes, so that feels like it should be avoided.


Well, that could be done thru cursors so that the lock is not really a 
problem, but by thinking about that, I tend to agree with you on the 
best approach which could be fixing the archive command.


-Sylvain



-Sean




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

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Michał Jastrzębski]

Option C will be best, but I guess we almost have enough votes for it?:)

I vote for C.

On 15 September 2016 at 06:45, Mauricio Lima  wrote:
> Option c.
>
> 2016-09-15 8:25 GMT-03:00 Eduardo Gonzalez :
>>
>> Option C
>>
>>
>> On Thu, Sep 15, 2016, 1:23 PM Dave Walker  wrote:
>>>
>>> Option C
>>>
>>> Thanks
>>>
>>> On 15 September 2016 at 12:10, Ryan Hallisey  wrote:

 Option c.

 - Ryan

 > On Sep 15, 2016, at 4:33 AM, Paul Bourke 
 > wrote:
 >
 > c)   Split the repository shortly after tagging 3.0.0 – creating a
 > kolla-ansible deliverable for Ocata.
 >
 >> On 15/09/16 07:12, Steven Dake (stdake) wrote:
 >> Core Reviewers:
 >>
 >>
 >>
 >> The facts:
 >>
 >> We have roughly 250 bugs in rc2.  Of those, I suspect over half can
 >> just
 >> be closed out as dupes, fixed, wontfix, or the like.
 >>
 >> The core reviewer team has had various discussions around splitting
 >> the
 >> repository at various times but has not come to a concrete conclusion
 >> via a vote.
 >>
 >> Once RC1 is tagged, the stable/newton branch will be created
 >> automatically.
 >>
 >> All rc2 bug fixes will require bug IDs and backports to stable/newton
 >> to
 >> enable the ability to manage the release of rc2 and 3.0.0.
 >>
 >> There is an expectation for core reviewers to do the work of
 >> backporting
 >> to stable/newton – only our backports team typically does this work –
 >> however during release we really need everyone’s participation.
 >>
 >>
 >>
 >> My understanding of general consensus beliefs:
 >>
 >> We believe splitting out the Ansible implementation into a separate
 >> repository will produce a better outcome for both Kolla-Ansible and
 >> Kolla-Kubernetes
 >>
 >> We have been unable to achieve consensus on the right timing for a
 >> repo
 >> split in the past but generally believe the timing is right at some
 >> point between rc1 and Summit or shortly thereafter, if we are to do
 >> the
 >> repo split during Newton or very early Ocata.)
 >>
 >>
 >>
 >> This vote is a multiple choice (one choice please) vote.  Feel free
 >> to
 >> discuss before making a decision.
 >>
 >>
 >>
 >> Please vote:
 >>
 >> a)   Do not split the repository between rc1 and Summit or
 >> shortly
 >> thereafter at all, keeping the Ansible implementation intact in Ocata
 >>
 >> b)   Split the repository shortly after tagging RC1 – creating of
 >> a
 >> kolla-ansible deliverable for Ocata.
 >>
 >> c)   Split the repository shortly after tagging 3.0.0 – creating
 >> a
 >> kolla-ansible deliverable for Ocata.
 >>
 >>
 >>
 >> Voting is open for 7 days until September 21^st , 2016. Please do not
 >> abstain on this critical vote.  Remember, no veto vote is available
 >> in
 >> roll-call votes.  If a majority can’t be reached on any one choice,
 >> but
 >> there is a majority around B & C, (which are the same idea, but
 >> different timing) a second vote will be triggered around when to
 >> split
 >> the repository.  The implication there is if you vote for b or c,
 >> your
 >> voting for a repository split.  If you vote for A you are voting for
 >> no
 >> repository split.  I hate to overload voting in this way.  It is only
 >> an
 >> optimization to speed things up as execution may need to happen now,
 >> or
 >> can be pushed out a month, or may not be needed at this time.
 >>
 >>
 >>
 >> Regards
 >>
 >> -steve
 >>
 >>
 >>
 >>
 >> __
 >> OpenStack Development Mailing List (not for usage questions)
 >> Unsubscribe:
 >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >
 >
 > __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] Ocata Design Summit - Proposed slot allocation

[Joshua Harlow]

Clint Byrum wrote:

Excerpts from Thierry Carrez's message of 2016-09-15 09:37:47 +0200:

Emilien Macchi wrote:

On Wed, Sep 14, 2016 at 1:51 PM,  wrote:

Also if you don't plan to use all of your

allocated slots, let us know so that we can propose them to other teams.


Just so that we are not forgotten (in case there is some space left), the
storlets dev team would greatly appreciate 2fb and 2-3wr.
Many thanks in advance!
Eran

In PuppetOpenStack we have:
1fb 2wr

And I'm really not sure we'll use them all:
https://etherpad.openstack.org/p/ocata-puppet

As you can see, we don't have much topics now, so I'm quite sure we
could give one wr to you.

I keep a list of non-official-yet-but-could-use-summit-space teams, and
will propose any leftover space to them soon. Let me know if you don't
plan to use all of your allocated slots and I'll put them in that pool.



I'm hoping the ArchWG lands on that list. We'll probably need some face
time just to hug it out by the time summit rolls around. :)




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

Re: [openstack-dev] [tripleo] CI is currently down: 2 blockers

[Emilien Macchi]

On Wed, Sep 14, 2016 at 10:13 PM, Emilien Macchi  wrote:
> Hi,
>
> Just a heads-up before end of day:
>
> 1) multinode job is failing 80% of time. James and myself did some
> attempts to revert or fix things but we have been unfortunate until
> now.
> Everything is documented here: https://bugs.launchpad.net/tripleo/+bug/1623606

We found out that https://review.openstack.org/#/c/368760/ is breaking
us, so we will revert it and work on it again later.

> 2) ovb jobs are timeing out during NetworkDeployment because
> 99-refresh-completed is not signaling to Heat due to instance-id being
> detected as null by os-apply-config.
> James proposed a revert: https://review.openstack.org/#/c/370250/
> But the patch can't be merged because of 1).

We are going to merge James's revert, we think it will bring back OVB jobs.

To merge the reverts, we need to disable voting on multinode jobs:
https://review.openstack.org/#/c/370922/

Please do not merge anything today (except the 2 reverts) until our
situation becomes more stable. Probably tonight or tomorrow.
Once situation is better, I or someone else in the team will give an
update here.

Thanks for your understanding,

> I'll continue to work on it tomorrow but if you're able to jump in and
> make progress on it, this downtime is very critical at this stage of
> the cycle.
>
> Any help is highly welcome.
>
> Thanks,
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[openstack-dev] [fuel] Meeting for today is canceled

[Andrew Woodward]

We have nothing slated on the agenda [1] for today, so I'm calling it for
the meeting.

As usual, if you have anything to discuss, please raise it on the ML or in
#fuel.

[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 
Andrew Woodward
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

[Sean Dague]

On 09/15/2016 05:52 AM, Roman Podoliaka wrote:
> Mike,
> 
> On Thu, Sep 15, 2016 at 5:48 AM, Mike Bayer  wrote:
> 
>> * Prior to oslo.db 4.13.3, did we ever see this "timeout" condition occur?
>> If so, was it also accompanied by the same "resource closed" condition or
>> did this second part of the condition only appear at 4.13.3?
>> * Did we see a similar "timeout" / "resource closed" combination prior to
>> 4.13.3, just with less frequency?
> 
> I believe we did -
> https://bugs.launchpad.net/openstack-ci/+bug/1216851 , although we
> used mysql-python back then, so the error was slightly different.
> 
>> * What is the magnitude of the "timeout" this fixture is using, is it on the
>> order of seconds, minutes, hours?
> 
> It's set in seconds per project in .testr.conf, e.g.:
> 
> https://github.com/openstack/nova/blob/master/.testr.conf
> https://github.com/openstack/ironic/blob/master/.testr.conf
> 
> In Nova we also have a 'timeout scaling factor' specifically set for
> migration tests:
> 
> https://github.com/openstack/nova/blob/master/nova/tests/unit/db/test_migrations.py#L67
> 
>> * If many minutes or hours, can the test suite be observed to be stuck on
>> this test?   Has someone tried to run a "SHOW PROCESSLIST" while this
>> condition is occurring to see what SQL is pausing?
> 
> We could try to do that in the gate, but I don't expect to see
> anything interesting: IMO, we'd see regular queries that should have
> been executed fast, but actually took much longer time (presumably due
> to heavy disk IO caused by multiple workers running similar tests in
> parallel).
> 
>> * Is this failure only present within the Nova test suite or has it been
>> observed in the test suites of other projects?
> 
> According to
> 
> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22sqlalchemy.exc.ResourceClosedError%5C%22
> 
> it's mostly Nova, but this has also been observed in Ironic, Manila
> and Ceilometer. Ironic and Manila have OS_TEST_TIMEOUT value set to 60
> seconds.
> 
>> * Is this failure present only on the "database migration" test suite or is
>> it present in other opportunistic tests, for Nova and others?
> 
> Based on the console logs I've checked only migration tests failed,
> but that's probably due to the fact that they are usually the slowest
> ones (again, presumably due to heavy disk IO).
> 
>> * Have there been new database migrations added to Nova which are being
>> exercised here and may be involved?
> 
> Looks like there were no changes recently:
> 
> https://review.openstack.org/#/q/project:openstack/nova+status:merged+branch:master+(file:%22%255Enova/db/sqlalchemy/migrate_repo/.*%2524%22+OR+file:%22%255Enova/tests/unit/db/test_migrations.py%2524%22)
> 
>> I'm not sure how much of an inconvenience it is to downgrade oslo.db. If
>> downgrading it is feasible, that would at least be a way to eliminate it as
>> a possibility if these same failures continue to occur, or a way to confirm
>> its involvement if they disappear.   But if downgrading is disruptive then
>> there are other things to look at in order to have a better chance at
>> predicting its involvement.
> 
> I don't think we need to block oslo.db 4.13.3, unless we clearly see
> it's this version that causes these failures.
> 
> I gave version 4.11 (before changes to provisioning) a try on my local
> machine and see the very same errors when concurrency level is high (
> http://paste.openstack.org/show/577350/ ), so I don't think the latest
> oslo.db release has anything to do with the increase of the number of
> failures on CI.
> 
> My current understanding is that the load on gate nodes somehow
> increased (either we run more testr workers in parallel now or
> apply/test more migrations or just more run VMs per host or the gate
> is simply busy at this point of the release cycle), so that we started
> to see these timeouts more often.

The migration count is definitely going to grow over time, as is the
nature of the beast. Nova hasn't had a migration collapse in quite a
while. The higher patch volume in Nova and larger number of db
migrations could definitely account for Nova being higher here.

Is there a better timeout value that you think will make these timeouts
happen less often?

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [requirements][release][FFE] Request for netaddr>=0.7.13 bump in g-r

[Matt Riedemann]

On 9/15/2016 9:30 AM, Matthew Thode wrote:

On 09/15/2016 09:09 AM, Matt Riedemann wrote:

There was a change introduced to nova in newton which requires a minimum
of netaddr 0.7.13. We've been testing with 0.7.18 from upper-constraints
so bumping the minimum from 0.7.12 to 0.7.13 shouldn't cause any issues.

The g-r change is here:

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

We're not going to revert the nova change since that would be riskier at
this point in the cycle since it landed before n-2.



This is a hard ask and I can't really support it, mainly because of all
the things it impacts this late in the cycle.  Is there ANY way we can
not merge this?

just some of the things that would need to be re-released


networking-ovn (just had their rc1)
os-net-config
os-vif
oslo.config
oslo.serialization
oslo.utils
oslo.versionedobjects
oslo.vmware
python-neutronclient
wsme



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



As I pointed out in the review, I don't think we'd need to re-release 
those things, however, I think this would cause a problem for 
stable/newton because the requirements repo doesn't have a stable/newton 
branch yet, so this min version bump would go into that, and since those 
libs/clients have cut stable/newton already, on their next reqs sync 
they'd get that min version bump, which we generally want to avoid on 
stable branches as some distros have frozen their packages - although to 
be fair they should have been shipping packages from the 
upper-constraints versions for newton, not the minimums since we only 
test the upper bound.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [requirements][release][FFE] Request for netaddr>=0.7.13 bump in g-r

[Sean Dague]

On 09/15/2016 10:30 AM, Matthew Thode wrote:
> On 09/15/2016 09:09 AM, Matt Riedemann wrote:
>> There was a change introduced to nova in newton which requires a minimum
>> of netaddr 0.7.13. We've been testing with 0.7.18 from upper-constraints
>> so bumping the minimum from 0.7.12 to 0.7.13 shouldn't cause any issues.
>>
>> The g-r change is here:
>>
>> https://review.openstack.org/#/c/370833/
>>
>> We're not going to revert the nova change since that would be riskier at
>> this point in the cycle since it landed before n-2.
>>
> 
> This is a hard ask and I can't really support it, mainly because of all
> the things it impacts this late in the cycle.  Is there ANY way we can
> not merge this?
> 
> just some of the things that would need to be re-released
> 
> 
> networking-ovn (just had their rc1)
> os-net-config
> os-vif
> oslo.config
> oslo.serialization
> oslo.utils
> oslo.versionedobjects
> oslo.vmware
> python-neutronclient
> wsme

Actually, there is very little this impacts. Basically no systems use
the g-r minimum except as a code comment. Yes, it will produce a patch
to be merged on those projects, however the only project that needs to
merge in is Nova, it's the only project that uses the function that will
actually explode at that level.

Given this is the lowest risk way to address this issue, far less risky
than a barely tested Nova workaround, this is really the way things
should move forward.

Nothing is harmed in the release if there is a mix of 0.7.12 / 0.7.13
minimums. Doug is even proposing that we explicitly allow situations
like that for the next cycle. Projects can merge and catch up in
stable/newton post release if we feel consistency is important.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [puppet] Core nominations

[Denis Egorenko]

+1, good job

2016-09-15 17:44 GMT+03:00 Matt Fischer :

> +1 to all. Thanks for your work guys!
>
> On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi 
> wrote:
>
>> While our group keeps moving, it's time to propose again new people
>> part of core team.
>>
>> Dmitry Tantsur / puppet-ironic
>> Dmitry is the guardian of puppet-ironic. He's driving most of the
>> recent features in this module and he now fully deserves being core on
>> it.
>>
>> Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
>> Prad is our Telemetry guru and he never stops to bring attention on
>> these modules! Keep going Prad, we appreciate your help here.
>>
>> Iury Gregory / all modules
>> Iury is our padawan. Still learning, but learning fast, he has been a
>> continuous contributor over the last months. He's always here on IRC
>> and during meetings to help.
>> He always volunteer to help and not for the most fun tasks. (He drove
>> the authtoken work during Newton). I would like to reward his work and
>> show that we trust him to be a good core reviewer.
>> Iury, keep going in your efforts!
>>
>>
>> If your name is not here yet, please keep doing consistent work, help
>> in bug triage, maintain stable CI, doing good reviews, improve our
>> documentation, etc.
>>
>> As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Ocata Design Summit - Proposed slot allocation

[Hongbin Lu]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: September-15-16 3:38 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] Ocata Design Summit - Proposed slot
> allocation
> 
> Emilien Macchi wrote:
> > On Wed, Sep 14, 2016 at 1:51 PM,   wrote:
> >> Also if you don't plan to use all of your
> >>>
> >>> allocated slots, let us know so that we can propose them to other
> teams.
> >>>
> >> Just so that we are not forgotten (in case there is some space left),
> >> the storlets dev team would greatly appreciate 2fb and 2-3wr.
> >> Many thanks in advance!
> >> Eran
> >
> > In PuppetOpenStack we have:
> > 1fb 2wr
> >
> > And I'm really not sure we'll use them all:
> > https://etherpad.openstack.org/p/ocata-puppet
> >
> > As you can see, we don't have much topics now, so I'm quite sure we
> > could give one wr to you.
> 
> I keep a list of non-official-yet-but-could-use-summit-space teams, and
> will propose any leftover space to them soon. Let me know if you don't
> plan to use all of your allocated slots and I'll put them in that pool.

Hope Zun [1] is in the non-official-yet-but-could-use-summit-space list.

[1] https://wiki.openstack.org/wiki/Zun

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

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

Re: [openstack-dev] [architecture] First meeting happened -- Regularly scheduled Thursdays at 1900

[Dean Troyer]

[To help remind folk of the meeting in a few hours, also I forgot
something...]

On Sun, Sep 11, 2016 at 5:27 PM, Clint Byrum  wrote:

> The agenda is available here:
>
> https://wiki.openstack.org/wiki/Meetings/Arch-WG
>
 [...]

> * Whether or not to abandon the cross-project spec and instead just
>   adopt what is available now as an internal charter.
>

I started working on one option for this last week and totally failed to
send it to the ML: https://etherpad.openstack.org/p/arch-wg-draft

It is a basic conversion of the spec document into a front-page document
for the group, suitable for a repo docs tree or a wiki page, depending on
how we choose to move forward.

dt

-- 

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

[openstack-dev] [release][Sahara] Sahara Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate(s) for Sahara for the end of the Newton cycle
are available!  You can find the RC1 source code tarballs at:

https://tarballs.openstack.org/sahara/sahara-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/sahara-dashboard/sahara-dashboard-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/sahara-extra/sahara-extra-5.0.0.0rc1.tar.gz
https://tarballs.openstack.org/sahara-image-elements/sahara-image-elements-5.0.0.0rc1.tar.gz

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

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

http://git.openstack.org/cgit/openstack/sahara/log/?h=stable/newton
http://git.openstack.org/cgit/openstack/sahara-dashboard/log/?h=stable/newton
http://git.openstack.org/cgit/openstack/sahara-extra/log/?h=stable/newton
http://git.openstack.org/cgit/openstack/sahara-image-elements/log/?h=stable/newton

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

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

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

Note that the "master" branch of Sahara is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [requirements][release][FFE] Request for netaddr>=0.7.13 bump in g-r

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2016-09-15 09:09:48 -0500:
> There was a change introduced to nova in newton which requires a minimum 
> of netaddr 0.7.13. We've been testing with 0.7.18 from upper-constraints 
> so bumping the minimum from 0.7.12 to 0.7.13 shouldn't cause any issues.
> 
> The g-r change is here:
> 
> https://review.openstack.org/#/c/370833/
> 
> We're not going to revert the nova change since that would be riskier at 
> this point in the cycle since it landed before n-2.
> 

After much discussion on IRC in both #openstack-release and
#openstack-requirements, the release team made the call to go ahead with
this requirements update.

We will merge the change to the global requirements, and update nova
before its RC1.

Other projects that believe they have an issue and have not already
tagged RC1 may also update their requirements list in their trees.

Projects that have already tagged RC1 and libraries that use netaddr *do
not* need to be updated right now.

When we branch the requirements repo, it will trigger updates to any
projects that have not already updated the min version for netaddr. We
will consider those changes as bugs in the requirements specifications
for newton, and tag point releases when there is another reason to
create a new release of the project or library.

Doug

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

Re: [openstack-dev] [murano] [all] Ocata Design Summit - Proposed slot allocation

[Kirill Zaitsev]

Your email says, that in Murano we have:
1 fb 3wr

This might be an error on my side, because I believe I’ve requested 1 fb 1wr in 
the questionnaire.

I’m not really sure we’ll be able to utilize that much time (In Austin our 2d 
wr was just a bit too much to be honest) I’m asking to downgrade our slots to 
1fb 1wr and suggest we spend the rest of our time on X-Project activities 
instead.

I'd also ask to not overlap Murano and Community App Catalog sessions if that 
is possible.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 13 septembre 2016 at 11:50:35, Thierry Carrez (thie...@openstack.org) wrote:

Murano: 1fb 3wr 


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

[openstack-dev] [Searchlight] PTL candidacy

[McLellan, Steven]

Hi,

I am announcing my candidacy for election as Searchlight PTL. I've been a
leading contributor and core reviewer since Searchlight's inception as a
standalone project in Vancouver.

Under Travis' very capable guidance Searchlight has reached a 1.0 Newton
release which supports nearly all of the widely-used Openstack services and
makes it easy to add support for others. We've made great improvements to
the way that we index data both in terms of use by clients and in reliability
and performance.

My goals for Ocata are thus based more around incremental improvement than
large numbers of features:

- Increasing ease of use and exploring opportunities afforded to user
  interfaces by Searchlight's querying and aggregation capabilities.
- Continuing to work on improved coordination with other projects around
  notifications to make indexing more reliable.
- Making it easier for developers from other services to write plugins for
  their services for Searchlight to make use of their greater domain knowledge
  and increase community involvement; we've made some steps in this direction
  already with Ironic.
- Integrating architectural improvements to allow pluggable publishers for data
  received via notifications. This was a feature originally planned for Newton
  but that didn't make it in, and allows Searchlight's indexing process to feed
  destinations other than Elasticsearch (for instance, Zaqar).

Unfortunately I will likely not be at the summit in Barcelona, but if elected
will work closely with Travis as part of the hand-off to ensure we take care
of any requests or issues that come up during the summit.

Thanks!

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

Re: [openstack-dev] [puppet] Core nominations

[Ivan Berezovskiy]

+1, great job, guys! Keep rocking!

2016-09-15 18:03 GMT+03:00 Denis Egorenko :

> +1, good job
>
> 2016-09-15 17:44 GMT+03:00 Matt Fischer :
>
>> +1 to all. Thanks for your work guys!
>>
>> On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi 
>> wrote:
>>
>>> While our group keeps moving, it's time to propose again new people
>>> part of core team.
>>>
>>> Dmitry Tantsur / puppet-ironic
>>> Dmitry is the guardian of puppet-ironic. He's driving most of the
>>> recent features in this module and he now fully deserves being core on
>>> it.
>>>
>>> Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
>>> Prad is our Telemetry guru and he never stops to bring attention on
>>> these modules! Keep going Prad, we appreciate your help here.
>>>
>>> Iury Gregory / all modules
>>> Iury is our padawan. Still learning, but learning fast, he has been a
>>> continuous contributor over the last months. He's always here on IRC
>>> and during meetings to help.
>>> He always volunteer to help and not for the most fun tasks. (He drove
>>> the authtoken work during Newton). I would like to reward his work and
>>> show that we trust him to be a good core reviewer.
>>> Iury, keep going in your efforts!
>>>
>>>
>>> If your name is not here yet, please keep doing consistent work, help
>>> in bug triage, maintain stable CI, doing good reviews, improve our
>>> documentation, etc.
>>>
>>> As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.
>>>
>>> Thanks,
>>> --
>>> Emilien Macchi
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][release][FFE] Request for netaddr>=0.7.13 bump in g-r

[Matt Riedemann]

There was a change introduced to nova in newton which requires a minimum 
of netaddr 0.7.13. We've been testing with 0.7.18 from upper-constraints 
so bumping the minimum from 0.7.12 to 0.7.13 shouldn't cause any issues.


The g-r change is here:

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

We're not going to revert the nova change since that would be riskier at 
this point in the cycle since it landed before n-2.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [puppet] Core nominations

[Matt Fischer]

+1 to all. Thanks for your work guys!

On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi  wrote:

> While our group keeps moving, it's time to propose again new people
> part of core team.
>
> Dmitry Tantsur / puppet-ironic
> Dmitry is the guardian of puppet-ironic. He's driving most of the
> recent features in this module and he now fully deserves being core on
> it.
>
> Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
> Prad is our Telemetry guru and he never stops to bring attention on
> these modules! Keep going Prad, we appreciate your help here.
>
> Iury Gregory / all modules
> Iury is our padawan. Still learning, but learning fast, he has been a
> continuous contributor over the last months. He's always here on IRC
> and during meetings to help.
> He always volunteer to help and not for the most fun tasks. (He drove
> the authtoken work during Newton). I would like to reward his work and
> show that we trust him to be a good core reviewer.
> Iury, keep going in your efforts!
>
>
> If your name is not here yet, please keep doing consistent work, help
> in bug triage, maintain stable CI, doing good reviews, improve our
> documentation, etc.
>
> As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Third party CI setup for OVS-DPDK and SRIOV

[Sanjay Upadhyay]

HI Folks,

I am reaching out to understand how best to setup a third party CI for
OVS-DPDK  and SRIOV
.

Since, we have put forth the patches for both sr-iov and ovs-dpdk, I think
its a requirement to test the functionality. Since, this requires specific
h/w, I guess this comes in the purview of third party CI. So, how best to
approach this.

If there is a vendor to back such an initiative, what kind of requirements
we need to post them. I can understand this is very specific question, but
do let me know from Openstack Infra side what are the requirements to
suffice this.

Any pointers on how to setup a third party CI, would be greatly
appreciated. As a part of my commitment, I can assure to document this for
others :)

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

Re: [openstack-dev] [requirements][release][FFE] Request for netaddr>=0.7.13 bump in g-r

[Matthew Thode]

On 09/15/2016 09:09 AM, Matt Riedemann wrote:
> There was a change introduced to nova in newton which requires a minimum
> of netaddr 0.7.13. We've been testing with 0.7.18 from upper-constraints
> so bumping the minimum from 0.7.12 to 0.7.13 shouldn't cause any issues.
> 
> The g-r change is here:
> 
> https://review.openstack.org/#/c/370833/
> 
> We're not going to revert the nova change since that would be riskier at
> this point in the cycle since it landed before n-2.
> 

This is a hard ask and I can't really support it, mainly because of all
the things it impacts this late in the cycle.  Is there ANY way we can
not merge this?

just some of the things that would need to be re-released


networking-ovn (just had their rc1)
os-net-config
os-vif
oslo.config
oslo.serialization
oslo.utils
oslo.versionedobjects
oslo.vmware
python-neutronclient
wsme

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [puppet] Core nominations

[Alex Schultz]

+1 to all

On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi  wrote:
> While our group keeps moving, it's time to propose again new people
> part of core team.
>
> Dmitry Tantsur / puppet-ironic
> Dmitry is the guardian of puppet-ironic. He's driving most of the
> recent features in this module and he now fully deserves being core on
> it.
>
> Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
> Prad is our Telemetry guru and he never stops to bring attention on
> these modules! Keep going Prad, we appreciate your help here.
>
> Iury Gregory / all modules
> Iury is our padawan. Still learning, but learning fast, he has been a
> continuous contributor over the last months. He's always here on IRC
> and during meetings to help.
> He always volunteer to help and not for the most fun tasks. (He drove
> the authtoken work during Newton). I would like to reward his work and
> show that we trust him to be a good core reviewer.
> Iury, keep going in your efforts!
>
>
> If your name is not here yet, please keep doing consistent work, help
> in bug triage, maintain stable CI, doing good reviews, improve our
> documentation, etc.
>
> As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] let's talk (development) environment deployment tooling and workflows

[Alex Schultz]

Hi all,

I've recently started looking at the various methods for deploying and
developing tripleo.  What I would like to bring up is the current
combination of the tooling for managing the VM instances and the
actual deployment method to launch the undercloud/overcloud
installation.  While running through the various methods and reading
up on the documentation, I'm concerned that they are not currently
flexible enough for a developer (or operator for that matter) to be
able to setup the various environment configurations for testing
deployments and doing development.  Additionally I ran into issues
just trying get them working at all so this probably doesn't help when
trying to attract new contributors as well.  The focus of this email
and of my experience seems to relate with workflow-simplification
spec[0].  I would like to share my experiences with the various
tooling available and raise some ideas.

Example Situation:

For example, I have a laptop with 16G of RAM and an SSD and I'd like
to get started with tripleo.  How can I deploy tripleo?

Tools:

instack:

I started with the tripleo docs[1] that reference using the instack
tools for virtual environment creation while deploying tripleo.   The
docs say you need at least 12G of RAM[2].  The docs lie (step 7[3]).
So after basically shutting everything down and letting it deploy with
all my RAM, the deployment fails because the undercloud runs out of
RAM and OOM killer kills off heat.  This was not because I had reduced
the amount of ram for the undercloud node or anything.  It was because
by default, 6GB of RAM with no swap is configured for the undercloud
(not sure if this is a bug?).  So I added a swap file to the
undercloud and continued. My next adventure was having the overcloud
deployment fail because lack of memory as puppet fails trying to spawn
a process and gets denied.  The instack method does not configure swap
for the VMs that are deployed and the deployment did not work with 5GB
RAM for each node.  So for a full 16GB I was unable to follow the
documentation and use instack to successfully deploy.  At this point I
switched over to trying to use tripleo-quickstart.  Eventually I was
able to figure out a configuration with instack to get it to deploy
when I figured out how to enable swap for the overcloud deployment.


tripleo-quickstart:

The next thing I attempted to use was the tripleo-quickstart[4].
Following the directions I attempted to deploy against my localhost.
I turns out that doesn't work as expected since ansible likes to do
magic when dealing with localhost[5].  Ultimately I was unable to get
it working against my laptop locally because I ran into some libvirt
issues.  But I was able to get it to work when I pointed it at a
separate machine.  It should be noted that tripleo-quickstart creates
an undercloud with swap which was nice because then it actually works,
but is an inconsistent experience depending on which tool you used for
your deployment.

Thoughts:

What these two methods showed me is that the deployment of tripleo is
not exactly a foolproof thing and that there are a lot of assumptions
that are being handled by the both of these tools.  My initial goal to
start this conversation around tooling and workflows was to bring the
idea of separation of the (virtual) environment configuration from the
actual deployment of tripleo as well as identifying places for
improvement as a way to speed up development and deployment testing.
I believe there are a few reasons why this can be beneficial.

The first reason is that as a developer, I would like to simplify the
development environment creation process and be able to draw the line
between environment and actual deployment tool.  By developing and
documenting a working development/deployment workflow, we can simplify
the onboarding experience as well as possibly accelerating the
existing development processes by reducing the time spent messing with
creating environments.  Does tripleo need to manage creation of VMs to
deploy on? The answer is probably no.  As the end user will want to
deploy tripleo on his or her gear, the focus for tripleo probably
should be on improving that process.  Now this doesn't mean that we
can't write stuff to do this, as it's important for development and
testing.  I'm not sure this is a core part of what should be
'tripleo'.

Another reason why I think this is important is as we talk about
creating different scenarios for CI[6] to improve testing, it would
also be useful for a developer or qa engineer to be able to test
different environmental configurations that would be more realistic of
actual deployment scenarios without having to hunt down multiple
machines or configure actual hardware networking.  For example,
creating environments using multiple networks, changing NICs,
providing different sized nodes based on roles, etc can all be done
virtually.  While tripleo-quickstart has some of these options, it is
mixed in with the tripleo 

[openstack-dev] [release][Heat] Heat Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for Heat for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/heat/heat-7.0.0.0rc1.tar.gz

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

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

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

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

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

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

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

Thanks,
Dims (On behalf of the Release Team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

[openstack-dev] [release][Keystone] Keystone Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for Keystone for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

(copy the link from https://releases.openstack.org/newton/index.html
and replace this text with it)

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

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

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

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

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

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

Note that the "master" branch of Keystone is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On Behalf of the Release Team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [requirements][release][FFE] Request for netaddr>=0.7.13 bump in g-r

[Matthew Thode]

On 09/15/2016 09:39 AM, Matt Riedemann wrote:
> 
> As I pointed out in the review, I don't think we'd need to re-release
> those things, however, I think this would cause a problem for
> stable/newton because the requirements repo doesn't have a stable/newton
> branch yet, so this min version bump would go into that, and since those
> libs/clients have cut stable/newton already, on their next reqs sync
> they'd get that min version bump, which we generally want to avoid on
> stable branches as some distros have frozen their packages - although to
> be fair they should have been shipping packages from the
> upper-constraints versions for newton, not the minimums since we only
> test the upper bound.
> 

I don't think this will hurt us like has happened in the past, I just
wanted to put the breaks on this so we can get all the interested
parties (releases and requirements teams) involved.  This would be
breaking our process at the last minute which has caused badness in the
past.  We (requirements) are working on divergent requirements which
would allow for this, but that was for the ocata cycle.

Distros I've checked so far won't have a problem with this anyway as
they are using newer netaddr anyway (0.7.18 for both debian and gentoo
at least).

In short, if the releases and requirements teams are both fine with
this, ok :D (and tonyb is on both...)

-- 
-- Matthew Thode (prometheanfire)



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

[openstack-dev] [Neutron] Preparing to cut RC1

[Armando M.]

Neutrinos,

In the next 24 hours we will be cutting RC1. Unfortunately we're battling
with a nasty bug, that's causing some instability and we're trying to find
the root cause. Please back off rechecking and merging until we figured out
what's happening.

In the meantime, do not be surprised if patches are given a -2 and their
relative LP entries are moved over to Ocata-1. If you think it's of
paramount importance for those changes to be part of Newton, and you are
actively working on them, please use the tag 'newton-rc-potential' [2], to
draw attention from the Neutron release team.

Thanks,
Armando

[1] https://bugs.launchpad.net/bugs/1623732
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=newton-rc-potential
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] [all] Ocata Design Summit - Proposed slot allocation

[Mikhail Fedosin]

Hey! If it's possible we could use one wr to discuss the integration of
Glare with Heat, Murano, Tacker and App-Catalog.

Best regards,
Mikhail Fedosin

On Thu, Sep 15, 2016 at 7:41 PM, Kirill Zaitsev 
wrote:

> Your email says, that in Murano we have:
> 1 fb 3wr
>
> This might be an error on my side, because I believe I’ve requested 1 fb
> 1wr in the questionnaire.
>
> I’m not really sure we’ll be able to utilize that much time (In Austin our
> 2d wr was just a bit too much to be honest) I’m asking to downgrade our
> slots to 1fb 1wr and suggest we spend the rest of our time on X-Project
> activities instead.
>
> I'd also ask to not overlap Murano and Community App Catalog sessions if
> that is possible.
>
> --
> Kirill Zaitsev
> Murano Project Tech Lead
> Software Engineer at
> Mirantis, Inc
>
> On 13 septembre 2016 at 11:50:35, Thierry Carrez (thie...@openstack.org)
> wrote:
>
> Murano: 1fb 3wr
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [OpenStack-Infra] Wednesday September 14th Infra Bug Day

[Elizabeth K. Joseph]

On Tue, Sep 6, 2016 at 2:59 PM, Elizabeth K. Joseph
 wrote:
> Following discussion at our past couple of meetings, I've gone ahead
> and reserved Wednesday, September 14th as an Infra Bug Day.

Huge thanks to everyone who participated in the sprint! bkero and
clarkb were particularly active in helping me go through our huge
(128) list of projects, triaging and closing as they went along, fungi
also answered a bunch of questions throughout the day. Zara drafted a
script now in the Etherpad to spit out only projects with stories and
it was pretty accurate, so we'll use that next time and SotK was also
standing by early in the sprint to help us out.

Now the fun part...

Starting story count: 496
Ending story count: 402

We did a pretty good job!

If you weren't able to participate, I encourage you to look at the
etherpad. We left notes for various people throughout so you may be
able to update a story or two:
https://etherpad.openstack.org/p/infra-bug-day-september-2016

There were also three projects that didn't have any owner for the day,
so those stories weren't looked at during the sprint:

openstack-infra/gear
openstack-infra/shade
openstack-infra/zuul

Of particular interest for our sprint next week, it would be nice to
make sure we're on top of our Zuul stories.

Also related to our sprint, there's a massive infra-cloud story that
hasn't been looked at in a few months. If someone (rcarrillocruz,
perhaps?) could look at this story so we're in good shape when we meet
next week, it may help us at the sprint:
https://storyboard.openstack.org/#!/story/2000175

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[openstack-dev] [barbican] PTL Candidacy

[Dave McCowan (dmccowan)]

Fellow Barbicaneers,


I'd like to nominate myself to serve as Barbican PTL for the Ocata cycle.


After talking it over with Doug (redrobot), I know I have a mentor in place.  
After talking it over with my employer, I know I will have the time and 
resources to dedicate to this position.


I first started working on Barbican in the Kilo release.  You were all 
welcoming and supportive to this stranger who wandered into your midcycle.  I 
was immediately impressed by your dedication to the project and your 
willingness to mentor me in all things OpenStack.


First and foremost, I want to maintain this culture in Barbican.


My goals for the Ocata cycle are:


1) Grow the Barbican team of contributors and core reviewers.

2) Collaborate with other OpenStack projects with joint blueprints, especially 
signing as a service (Designate) and container based install (Kolla).

3) Improve our project maturity index by addressing documentation and process 
items. [1]

4) Maintain our high standards for code reviews and unit and functional tests.

5) Be diligent with backporting bug fixes to stable releases.


Thank you in advance for this opportunity to serve.


Also, thanks to Doug Mendizábal for his leadership over the last four cycles 
and his offer to support me in this endeavor.


--Dave McCowan (dave-mccowan)


[1] https://www.openstack.org/software/releases/mitaka/components/barbican

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

[openstack-dev] [barbican] Deprecating Certificate Issuance

[Douglas Mendizábal]

Hello Openstack-dev,

The Barbican team will be deprecating the Ceritficate Issuance feature
in Barbican for the Newton release.  This is something that the
community has been discussing since before the Tokyo summit, and we feel
now is the right time to begin the deprecation process.  I'll try to
answer some common questions about this decision below:

* Why are we deprecating Certificate Issuance?

There are a few reasons that were considered for this decision.  First,
there does not seem to be a lot of interest in the community to fully
develop the Certificate Authority integration with Barbican.  We have a
few outstanding blueprints that are needed to make Certificate Issuance
fully functional, but so far no one has committed to getting the work
done.  Additionally, we've had very little buy-in from public
Certificate Authorities.  Both Symantec and Digicert were interested in
integration in the past, but that interest didn't materialize into
robust CA plugins like we hoped it would.

Secondly, there have been new developments in the space of Certificate
Authorities since we started Barbican.  The most significant of these
was the launch of the Let's Encrypt public CA along with the definition
of the ACME protocol for certificate issuance.  We believe that future
certificate authority services would do good to implement the ACME
standard, which is quite different than the API the Barbican team had
developed.

Lastly, deprecating Certificate Issuance within Barbican will simplify
both the architecture and deployment of Barbican.  This will allow us to
focus on the features that Barbican does well: the secure storage of
secret material.

* Will Barbican still be able to store Certificates?

Yes, absolutely!  The only thing we're deprecating is the the plugin
interface that talks to Certificate Authorites and associated APIs.
While you will not be able to use Barbican to issue a new certificate,
you will always be able to securely store any certificates in Barbican,
including those issued by public CAs or internal CAs.

* When will the APIs be removed?

The Barbican team will follow the standard deprecation policy for this
feature.  All APIs will still ship as part of the Newton release, and
we'll begin the deprecation work in the Ocata cycle.

Feel free to ask any other questions you may have.

Thanks,
Douglas Mendizábal
Barbican PTL



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

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi All,

I have got invitation letter in spanish.
Those who requires this letter in spanish, send mail to eventv...@openstack.org 
mentioning the same.

Thanks to OpenStack foundation.

Cheers,

Abhishek

From: Gorka Eguileor Gimeno [gegui...@redhat.com]
Sent: Thursday, September 15, 2016 9:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,

As a native Spanish speaker I offer my help with the translation if needed.
I assume the OpenStack visa team would be the one required to issue the 
translated invitation letter for it to be valid.

Cheers,
Gorka.

On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy 
> wrote:
Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
==
For business visas:
□ Invitation letter from the Spanish company in Spanish language or both in 
English and Spanish.Letters issued only in English will not be accepted. This 
will be an obligatory requirement.
===

On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy 
> wrote:
That's good. Please share the appropriate link/url to openstack visa team.

On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek 
> wrote:
Hi,

Yes it’s request from embassy than for Indian citizens invitation letter should 
be in Spanish as well English language.
I have sent mail to openstack visa team.

Thank you,

Abhishek Kekane

From: M Ranga Swami Reddy 
[mailto:swamire...@gmail.com]
Sent: Thursday, September 15, 2016 1:06 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the 
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek 
> wrote:
Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org’ to explain your issue 
and also give reference of this ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar [mailto:jankih...@gmail.com]
Sent: Thursday, September 15, 2016 11:51 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
> wrote:
Hi John,

I have sent mail to 'eventv...@openstack.org', 
waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 
[mailto:openstack@sodarock.com]
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek 
> wrote:
> Hi John,
>
> I have read the information given at
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos 
> [mailto:openstack@sodarock.com]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps 

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Vikram Hosakote (vhosakot)]

Yes, I vote Option C.

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, September 15, 2016 at 9:57 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a 
separate deliverable

Option C will be best, but I guess we almost have enough votes for it?:)

I vote for C.

On 15 September 2016 at 06:45, Mauricio Lima 
> wrote:
Option c.

2016-09-15 8:25 GMT-03:00 Eduardo Gonzalez 
>:

Option C


On Thu, Sep 15, 2016, 1:23 PM Dave Walker 
> wrote:

Option C

Thanks

On 15 September 2016 at 12:10, Ryan Hallisey 
> wrote:

Option c.

- Ryan

> On Sep 15, 2016, at 4:33 AM, Paul Bourke 
> >
> wrote:
>
> c)   Split the repository shortly after tagging 3.0.0 – creating a
> kolla-ansible deliverable for Ocata.
>
>> On 15/09/16 07:12, Steven Dake (stdake) wrote:
>> Core Reviewers:
>>
>>
>>
>> The facts:
>>
>> We have roughly 250 bugs in rc2.  Of those, I suspect over half can
>> just
>> be closed out as dupes, fixed, wontfix, or the like.
>>
>> The core reviewer team has had various discussions around splitting
>> the
>> repository at various times but has not come to a concrete conclusion
>> via a vote.
>>
>> Once RC1 is tagged, the stable/newton branch will be created
>> automatically.
>>
>> All rc2 bug fixes will require bug IDs and backports to stable/newton
>> to
>> enable the ability to manage the release of rc2 and 3.0.0.
>>
>> There is an expectation for core reviewers to do the work of
>> backporting
>> to stable/newton – only our backports team typically does this work –
>> however during release we really need everyone’s participation.
>>
>>
>>
>> My understanding of general consensus beliefs:
>>
>> We believe splitting out the Ansible implementation into a separate
>> repository will produce a better outcome for both Kolla-Ansible and
>> Kolla-Kubernetes
>>
>> We have been unable to achieve consensus on the right timing for a
>> repo
>> split in the past but generally believe the timing is right at some
>> point between rc1 and Summit or shortly thereafter, if we are to do
>> the
>> repo split during Newton or very early Ocata.)
>>
>>
>>
>> This vote is a multiple choice (one choice please) vote.  Feel free
>> to
>> discuss before making a decision.
>>
>>
>>
>> Please vote:
>>
>> a)   Do not split the repository between rc1 and Summit or
>> shortly
>> thereafter at all, keeping the Ansible implementation intact in Ocata
>>
>> b)   Split the repository shortly after tagging RC1 – creating of
>> a
>> kolla-ansible deliverable for Ocata.
>>
>> c)   Split the repository shortly after tagging 3.0.0 – creating
>> a
>> kolla-ansible deliverable for Ocata.
>>
>>
>>
>> Voting is open for 7 days until September 21^st , 2016. Please do not
>> abstain on this critical vote.  Remember, no veto vote is available
>> in
>> roll-call votes.  If a majority can’t be reached on any one choice,
>> but
>> there is a majority around B & C, (which are the same idea, but
>> different timing) a second vote will be triggered around when to
>> split
>> the repository.  The implication there is if you vote for b or c,
>> your
>> voting for a repository split.  If you vote for A you are voting for
>> no
>> repository split.  I hate to overload voting in this way.  It is only
>> an
>> optimization to speed things up as execution may need to happen now,
>> or
>> can be pushed out a month, or may not be needed at this time.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [openstack-ansible] cinder volume lxc and iscsi

[Sean McGinnis]

On Wed, Sep 14, 2016 at 05:08:51PM +0200, Fabrice Grelaud wrote:
> Hi,
> 
> i need recommendations to setup block storage with dell storage center
> iscsi drivers.
> 
> As seen in doc
> (http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure-cinder.html),
> no need for ISCSI block storage to have a separate host.
> So, i modify env.d/cinder.yml to remove "is_metal: true", and configure
> openstack_user_config.yml with:
> (http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/dell-storagecenter-driver.html)
> 
> storage_hosts:
>   p-osinfra01:
> ip: 172.29.236.11
> container_vars:
>   cinder_storage_availability_zone: Dell_SC
>   cinder_default_availability_zone: Dell_SC
>   cinder_default_volume_type: delliscsi
>   cinder_backends:
> limit_container_types: cinder_volume
> delliscsi:
>   volume_driver:
> cinder.volume.drivers.dell.dell_storagecenter_iscsi.DellStorageCenterISCSIDriver
>   volume_backend_name: dell_iscsi
>   san_ip: 172.x.y.z
>   san_login: admin
>   san_password: 
>   iscsi_ip_address: 10.a.b.c
>   dell_sc_ssn: 46247
>   dell_sc_api_port: 3033
>   dell_sc_server_folder: Openstack
>   dell_sc_volume_folder: Openstack
>   iscsi_port: 3260
> 
> Same for p-osinfra02 and p-osinfra03.
> 
> I launch playbook os-cinder-install.yml and i have 3 cinder-volume
> containers each on my infra hosts.
> Everything is ok.
> 
> In horizon, i can create a volume (seen on the storage center) and can
> attach this volume to an instance. Perfect !
> 
> But now, if i launch an instance with "Boot from image (create a new
> volume)", i got an error from nova "Block Device Mapping is Invalid".
> I checked my cinder-volume.log and i see:
> ERROR cinder.volume.flows.manager.create_volume
> FailedISCSITargetPortalLogin: Could not login to any iSCSI portal
> ERROR cinder.volume.manager ImageCopyFailure: Failed to copy image to
> volume: Could not login to any iSCSI portal.
> 
> I test in one container iscsi connection:
> root@p-osinfra03-cinder-volumes-container-2408e151:~# iscsiadm -m
> discovery -t sendtargets -p 10.a.b.c
> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a724
> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a728
> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a723
> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a727
> 
> But when login, i got:
> root@p-osinfra03-cinder-volumes-container-2408e151:~# iscsiadm -m node
> -T iqn.2002-03.com.compellent:5000d31000b4a724 --login
> Logging in to [iface: default, target:
> iqn.2002-03.com.compellent:5000d31000b4a724, portal: 10.a.b.c,3260]
> (multiple)
> iscsiadm: got read error (0/0), daemon died?
> iscsiadm: Could not login to [iface: default, target:
> iqn.2002-03.com.compellent:5000d31000b4a724, portal: 10.a.b.c,3260].
> iscsiadm: initiator reported error (18 - could not communicate to iscsid)
> iscsiadm: Could not log into all portals
> 
> I found in google a bug for use of open-iscsi inside lxc-container
> (https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855), a bug
> commented by Kevin Carter (openstack-ansible core team) as a "blocking
> issue" (in may 2015).
> 
> Is that bug still relevant ?
> Do i need to rather deploy my cinder-volume on compute host (metal) to
> solve my problem ?
> Or do you have others suggestions ?
> 
> Thanks.
> Regards,
> 
> -- 
> Fabrice Grelaud
> Université de Bordeaux

Everything else looks ok at first glance, so my guess would be that that
lxc bug is still an issue. You should be able to log in to the iSCSI
targets if you are able to connect and do the sendtargets to get the
info in the first place. That "could not communicate to iscsid" looks
very suspect.

Sean (smcginnis)

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

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

Re: [openstack-dev] [openstack-ansible] cinder volume lxc and iscsi

[Michał Jastrzębski]

So in Kolla we managed to put both iscsi and tgtd into containers. It
did require quite a few shares from host, not sure how feasible it is
with LXC

https://github.com/openstack/kolla/blob/master/ansible/roles/iscsi/tasks/start.yml

Look at volumes, this is what we share, you can try to mimic this behavior.

On 15 September 2016 at 13:58, Sean McGinnis  wrote:
> On Wed, Sep 14, 2016 at 05:08:51PM +0200, Fabrice Grelaud wrote:
>> Hi,
>>
>> i need recommendations to setup block storage with dell storage center
>> iscsi drivers.
>>
>> As seen in doc
>> (http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure-cinder.html),
>> no need for ISCSI block storage to have a separate host.
>> So, i modify env.d/cinder.yml to remove "is_metal: true", and configure
>> openstack_user_config.yml with:
>> (http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/dell-storagecenter-driver.html)
>>
>> storage_hosts:
>>   p-osinfra01:
>> ip: 172.29.236.11
>> container_vars:
>>   cinder_storage_availability_zone: Dell_SC
>>   cinder_default_availability_zone: Dell_SC
>>   cinder_default_volume_type: delliscsi
>>   cinder_backends:
>> limit_container_types: cinder_volume
>> delliscsi:
>>   volume_driver:
>> cinder.volume.drivers.dell.dell_storagecenter_iscsi.DellStorageCenterISCSIDriver
>>   volume_backend_name: dell_iscsi
>>   san_ip: 172.x.y.z
>>   san_login: admin
>>   san_password: 
>>   iscsi_ip_address: 10.a.b.c
>>   dell_sc_ssn: 46247
>>   dell_sc_api_port: 3033
>>   dell_sc_server_folder: Openstack
>>   dell_sc_volume_folder: Openstack
>>   iscsi_port: 3260
>>
>> Same for p-osinfra02 and p-osinfra03.
>>
>> I launch playbook os-cinder-install.yml and i have 3 cinder-volume
>> containers each on my infra hosts.
>> Everything is ok.
>>
>> In horizon, i can create a volume (seen on the storage center) and can
>> attach this volume to an instance. Perfect !
>>
>> But now, if i launch an instance with "Boot from image (create a new
>> volume)", i got an error from nova "Block Device Mapping is Invalid".
>> I checked my cinder-volume.log and i see:
>> ERROR cinder.volume.flows.manager.create_volume
>> FailedISCSITargetPortalLogin: Could not login to any iSCSI portal
>> ERROR cinder.volume.manager ImageCopyFailure: Failed to copy image to
>> volume: Could not login to any iSCSI portal.
>>
>> I test in one container iscsi connection:
>> root@p-osinfra03-cinder-volumes-container-2408e151:~# iscsiadm -m
>> discovery -t sendtargets -p 10.a.b.c
>> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a724
>> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a728
>> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a723
>> 10.a.b.c:3260,0 iqn.2002-03.com.compellent:5000d31000b4a727
>>
>> But when login, i got:
>> root@p-osinfra03-cinder-volumes-container-2408e151:~# iscsiadm -m node
>> -T iqn.2002-03.com.compellent:5000d31000b4a724 --login
>> Logging in to [iface: default, target:
>> iqn.2002-03.com.compellent:5000d31000b4a724, portal: 10.a.b.c,3260]
>> (multiple)
>> iscsiadm: got read error (0/0), daemon died?
>> iscsiadm: Could not login to [iface: default, target:
>> iqn.2002-03.com.compellent:5000d31000b4a724, portal: 10.a.b.c,3260].
>> iscsiadm: initiator reported error (18 - could not communicate to iscsid)
>> iscsiadm: Could not log into all portals
>>
>> I found in google a bug for use of open-iscsi inside lxc-container
>> (https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855), a bug
>> commented by Kevin Carter (openstack-ansible core team) as a "blocking
>> issue" (in may 2015).
>>
>> Is that bug still relevant ?
>> Do i need to rather deploy my cinder-volume on compute host (metal) to
>> solve my problem ?
>> Or do you have others suggestions ?
>>
>> Thanks.
>> Regards,
>>
>> --
>> Fabrice Grelaud
>> Université de Bordeaux
>
> Everything else looks ok at first glance, so my guess would be that that
> lxc bug is still an issue. You should be able to log in to the iSCSI
> targets if you are able to connect and do the sendtargets to get the
> info in the first place. That "could not communicate to iscsid" looks
> very suspect.
>
> Sean (smcginnis)
>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack 

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

[Sean Dague]

On 09/14/2016 11:57 PM, Mike Bayer wrote:
> 
> 
> On 09/14/2016 11:05 PM, Mike Bayer wrote:
>>
>> Are *these* errors also new as of version 4.13.3 of oslo.db ?   Because
>> here I have more suspicion of one particular oslo.db change here.
> 
> The version in question that has the changes to provisioning and
> anything really to do with this area is 4.12.0.   So if you didn't see
> any problem w/ 4.12 then almost definitely oslo.db is not the cause -
> the code changes subsequent to 4.12 have no relationship to any system
> used by the opportunistic test base.I would hope at least that 4.12
> is the version where we see things changing because there were small
> changes to the provisioning code.
> 
> But at the same time, I'm combing through the quite small adjustments to
> the provisioning code as of 4.12.0 and I'm not seeing what could
> introduce this issue.   That said, we really should never see the kind
> of error we see with the "DROP DATABASE" failing because it remains in
> use, however this can be a side effect of the test itself having
> problems with the state of a different connection, not being closed and
> locks remain held.
> 
> That is, there's poor failure modes for sure here, I just can't see
> anything in 4.13 or even 4.12 that would suddenly introduce them.
> 
> By all means if these failures disappear when we go to 4.11 vs. 4.12,
> that would be where we need to go and to look for next cycle. From
> my POV if the failures do disappear then that would be the best evidence
> that the oslo.db version is the factor.

In looking through the change history, I agree that nothing in the
4.13.x stream is plausibly related to this failure. The last time
something seems related is back in the 4.11/4.12 space. That would be a
much risker change than just rolling back to 4.13.0 at this point in the
release, so I would not recommend it.

So I think Roman's approach of trying to just adjust the timeout seems
like the lowest risk way to move forward. Hopefully that mitigates things.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [qa] Cancelled: IRC meeting 0900UTC Sep. 22 2016

[Ken'ichi Ohmichi]

Hi,

We have QA/Infra mid-cycle meetup next week, then it is hard to attend
the next meeting for most people.
So let's cancel the next week meeting.
The next irc meeting of QA will be Sep. 29th 2016 (1700 UTC).

Thanks
Ken Ohmichi

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

Re: [openstack-dev] [ironic] openstack/python-ironicclient

[Ruby Loo]

On Mon, Sep 12, 2016 at 12:38 PM, Dean Troyer  wrote:

> On Mon, Sep 12, 2016 at 10:51 AM, Ruby Loo  wrote:
>
>> My preference is:
>>
>> * openstack baremetal driver show --raid-logical-disk-properties
>>
>
> Agreed here.
>
> The process we encourage is always to first identify the resource you are
> operating on.  I would add that a 'property' is not a resource, it
> describes a resource, there may be many of them per resource, etc.  Here,
> the resource is 'baremetal driver'.
>
> because we already have 'openstack baremetal driver show' as a command,
>> and other than wanting to see a description of the logical disk properties,
>> the only other command related to the disk properties is 'openstack
>> baremetal node set --target-raid-config'.
>>
>
> Possible confusion on my part... the properties you want to display as
> part of 'baremetal driver show' are set with 'baremetal node set'?  That
> assymetry may be part of the reason this was ambiguous to start with.
>

A baremetal node has an associated driver; it is the driver that handles
the node (powering, booting, deploying, RAID configuration, ...). The RAID
logical disk properties describe the information that the driver needs, for
doing RAID configuration. e.g. [1]. Maybe it should be
--raid-logical-disk-property-descriptions?  But the actual configuration is
specific to a particular node, and that is set via the ..node set
--target-raid-config (which can specify one or more logical disks). e.g.
[2].

Maybe we could make it easier on ourselves by not providing an API to get
descriptions of things, but "just" document them. :)

--ruby

[1]
http://developer.openstack.org/api-ref/baremetal/index.html?expanded=show-driver-logical-disk-properties-detail
[2]
http://developer.openstack.org/api-ref/baremetal/index.html?expanded=set-raid-config-detail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][murano] murano Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for murano for the end of the Newton cycle
is available!  You can find the RC1 source code tarballs at:

https://tarballs.openstack.org/murano/murano-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/murano-agent/murano-agent-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/murano-dashboard/murano-dashboard-3.0.0.0rc1.tar.gz

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

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

http://git.openstack.org/cgit/openstack/murano/log/?h=stable/newton
http://git.openstack.org/cgit/openstack/murano-agent/log/?h=stable/newton
http://git.openstack.org/cgit/openstack/murano-dashboard/log/?h=stable/newton

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

https://bugs.launchpad.net/murano/+filebug
https://bugs.launchpad.net/murano-agent/+filebug
https://bugs.launchpad.net/murano-dashboard/+filebug

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

Note that the "master" branch of murano is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Doug

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

Re: [openstack-dev] [release][murano][Release-job-failures] Pre-release of openstack/murano-agent failed

[Doug Hellmann]

Excerpts from jenkins's message of 2016-09-15 18:31:50 +:
> Build failed.
> 
> - murano-agent-tarball 
> http://logs.openstack.org/42/4222da0a5911845dcaeef1e695915e010190245d/pre-release/murano-agent-tarball/f7ac5ed/
>  : SUCCESS in 2m 15s
> - murano-agent-tarball-signing 
> http://logs.openstack.org/42/4222da0a5911845dcaeef1e695915e010190245d/pre-release/murano-agent-tarball-signing/b4b4967/
>  : SUCCESS in 1m 05s
> - murano-agent-pypi-both-upload 
> http://logs.openstack.org/42/4222da0a5911845dcaeef1e695915e010190245d/pre-release/murano-agent-pypi-both-upload/6787944/
>  : FAILURE in 58s
> 

The murano-agent RC1 package has bad metadata and was rejected by PyPI.
The fix is in https://review.openstack.org/371050, which will need to be
merged in master and backported to stable/newton before your RC2 is
prepared.

Doug

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

[Openstack-operators] [Large Deployment Team] Meeting Reminder

[Matt Van Winkle]

Hello LDT folks,
This is a reminder that we will have a meeting at 03:00 UTC on September 16.  
See you all in #openstack-operators in a few hours!

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

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Steven Dake (stdake)]

We have far exceeded a majority for choice C (which is my preferred choice as 
well).  So once 3.0.0 tags, it is all hands on deck to make the repo split 
happen as well as get started on the osic documentation which we owe the OSIC 
team.  There were no other votes for other choices.  While not everyone has 
chimed in, I think we have a clear consensus.

Regards
-steve


From: Steven Dake 
Date: Wednesday, September 14, 2016 at 11:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [vote][kolla] Splitting out Ansible into a separate deliverable

Core Reviewers:

The facts:
We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be 
closed out as dupes, fixed, wontfix, or the like.
The core reviewer team has had various discussions around splitting the 
repository at various times but has not come to a concrete conclusion via a 
vote.
Once RC1 is tagged, the stable/newton branch will be created automatically.
All rc2 bug fixes will require bug IDs and backports to stable/newton to enable 
the ability to manage the release of rc2 and 3.0.0.
There is an expectation for core reviewers to do the work of backporting to 
stable/newton – only our backports team typically does this work – however 
during release we really need everyone’s participation.

My understanding of general consensus beliefs:
We believe splitting out the Ansible implementation into a separate repository 
will produce a better outcome for both Kolla-Ansible and Kolla-Kubernetes
We have been unable to achieve consensus on the right timing for a repo split 
in the past but generally believe the timing is right at some point between rc1 
and Summit or shortly thereafter, if we are to do the repo split during Newton 
or very early Ocata.)

This vote is a multiple choice (one choice please) vote.  Feel free to discuss 
before making a decision.

Please vote:

a)  Do not split the repository between rc1 and Summit or shortly 
thereafter at all, keeping the Ansible implementation intact in Ocata

b)  Split the repository shortly after tagging RC1 – creating of a 
kolla-ansible deliverable for Ocata.

c)  Split the repository shortly after tagging 3.0.0 – creating a 
kolla-ansible deliverable for Ocata.

Voting is open for 7 days until September 21st, 2016. Please do not abstain on 
this critical vote.  Remember, no veto vote is available in roll-call votes.  
If a majority can’t be reached on any one choice, but there is a majority 
around B & C, (which are the same idea, but different timing) a second vote 
will be triggered around when to split the repository.  The implication there 
is if you vote for b or c, your voting for a repository split.  If you vote for 
A you are voting for no repository split.  I hate to overload voting in this 
way.  It is only an optimization to speed things up as execution may need to 
happen now, or can be pushed out a month, or may not be needed at this time.

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

Re: [openstack-dev] [murano] [all] Ocata Design Summit - Proposed slot allocation

[Vitaly Gridnev]

Hello team,

As we discussed during the last meeting, we agreed that 6wr + cm is
absolutely enough for sahara. So, we can release one working room for other
projects. Thanks!

On Thu, Sep 15, 2016 at 8:58 PM, Mikhail Fedosin 
wrote:

> Hey! If it's possible we could use one wr to discuss the integration of
> Glare with Heat, Murano, Tacker and App-Catalog.
>
> Best regards,
> Mikhail Fedosin
>
> On Thu, Sep 15, 2016 at 7:41 PM, Kirill Zaitsev 
> wrote:
>
>> Your email says, that in Murano we have:
>> 1 fb 3wr
>>
>> This might be an error on my side, because I believe I’ve requested 1 fb
>> 1wr in the questionnaire.
>>
>> I’m not really sure we’ll be able to utilize that much time (In Austin
>> our 2d wr was just a bit too much to be honest) I’m asking to downgrade our
>> slots to 1fb 1wr and suggest we spend the rest of our time on X-Project
>> activities instead.
>>
>> I'd also ask to not overlap Murano and Community App Catalog sessions if
>> that is possible.
>>
>> --
>> Kirill Zaitsev
>> Murano Project Tech Lead
>> Software Engineer at
>> Mirantis, Inc
>>
>> On 13 septembre 2016 at 11:50:35, Thierry Carrez (thie...@openstack.org)
>> wrote:
>>
>> Murano: 1fb 3wr
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

[Sam Morrison]

Hi Julien,

Been working a bit on this and have a patch based on master that is working at:

https://github.com/NeCTAR-RC/gnocchi/tree/influxdb-driver

I could push it up to gerrit but I think something will need to change for it 
to run the influxdb tests?

It should act more like the carbonara drivers now as opposed to the old influx 
driver. It will do downsampling and retention based on the archive policies.

Currently it is failing one test [1] and that is to do with retention. 
This is because influxDB does retention based on the current time, e.g. a 1 day 
retention policy will be from the current time. 
The tests assume that the retention period is based on the data stored and so 
it will keep 1 day of data no matter how old that data is.

I also had to disable retention policies in influx while running the tests as 
when I backfill data influx is too smart and won’t backfill data that wouldn’t 
meet the retention policy.
One way to fix all this would be to change all the test times to be relative 
from now but then there could be other race conditions etc. I think.

I’m still not 100% happy with the code, particularly around how the continuous 
queries are created based on the archive policies.

We are using this code in preprod and so far all is going well. 

Should also note that you will need influxDB v1.0 to use this. To test all you 
should need is an influx server running locally.

Would love some feed back particularly from people who know how influx works as 
there are a few ways it could be architected.

Cheers,
Sam

[1] gnocchi.tests.test_rest.MetricTest.test_add_measures_back_window




> On 6 Sep 2016, at 11:24 AM, Sam Morrison  wrote:
> 
> Hi Julien,
> 
>> On 5 Sep 2016, at 5:36 PM, Julien Danjou  wrote:
>> 
>> On Mon, Sep 05 2016, Sam Morrison wrote:
>> 
>> Hi Sam,
>> 
>>> The issue I’m having are with the tests. Because the continuous queries are
>>> asynchronous and there is no current way in influxdb to force them to run I 
>>> get
>>> tests failing due to
>>> them not having run yet.
>>> 
>>> I’m not sure how to get around this issue, apart from the tests failing
>>> everything is working quite well. I’m going to start some load testing soon 
>>> to
>>> see what it’s like when pushing in a lot of metrics.
>> 
>> Does it break the REST API, or only some storage tests?
> 
> REST API is fine, in fact it fixes some tests that influx was failing on.
> 
>> If it's just some storage test, you can change the tests so they are
>> retrying until the operation are done. Either in the test, or via a
>> special flag in the driver – we used to have that in the first version
>> of the driver.
> 
> OK good idea, I’ll work on that.
> 
> 
>>> Wondering if there would be time to talk about this in Barcelona.
>> 
>> Sure.
> 
> Cheers,
> Sam
> 
> 
>> 
>> -- 
>> Julien Danjou
>> -- Free Software hacker
>> -- https://julien.danjou.info


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

[openstack-dev] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

There was no meeting of the working group this week as several of our 
members have scheduling conflicts.


The meeting logs are in the usual place [5]. If you find an issue with 
an existing guideline [3] or think of one that needs to exist, make a 
bug [4].


# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/322194
* A guideline for links
  https://review.openstack.org/354266
* Clear the case if the version string isn't parsable
  https://review.openstack.org/346846

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


Nothing new this week.

# Guidelines currently under review [6]

There are no new guidelines this week, there is one proposal open for 
comments though.


* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


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

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Jeffrey Zhang]

vote c

it will guarantee we have s stable N release.

On Fri, Sep 16, 2016 at 3:49 AM, Steven Dake (stdake)  wrote:
> We have far exceeded a majority for choice C (which is my preferred choice
> as well).  So once 3.0.0 tags, it is all hands on deck to make the repo
> split happen as well as get started on the osic documentation which we owe
> the OSIC team.  There were no other votes for other choices.  While not
> everyone has chimed in, I think we have a clear consensus.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> From: Steven Dake 
> Date: Wednesday, September 14, 2016 at 11:12 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [vote][kolla] Splitting out Ansible into a separate deliverable
>
>
>
> Core Reviewers:
>
>
>
> The facts:
>
> We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be
> closed out as dupes, fixed, wontfix, or the like.
>
> The core reviewer team has had various discussions around splitting the
> repository at various times but has not come to a concrete conclusion via a
> vote.
>
> Once RC1 is tagged, the stable/newton branch will be created automatically.
>
> All rc2 bug fixes will require bug IDs and backports to stable/newton to
> enable the ability to manage the release of rc2 and 3.0.0.
>
> There is an expectation for core reviewers to do the work of backporting to
> stable/newton – only our backports team typically does this work – however
> during release we really need everyone’s participation.
>
>
>
> My understanding of general consensus beliefs:
>
> We believe splitting out the Ansible implementation into a separate
> repository will produce a better outcome for both Kolla-Ansible and
> Kolla-Kubernetes
>
> We have been unable to achieve consensus on the right timing for a repo
> split in the past but generally believe the timing is right at some point
> between rc1 and Summit or shortly thereafter, if we are to do the repo split
> during Newton or very early Ocata.)
>
>
>
> This vote is a multiple choice (one choice please) vote.  Feel free to
> discuss before making a decision.
>
>
>
> Please vote:
>
> a)  Do not split the repository between rc1 and Summit or shortly
> thereafter at all, keeping the Ansible implementation intact in Ocata
>
> b)  Split the repository shortly after tagging RC1 – creating of a
> kolla-ansible deliverable for Ocata.
>
> c)  Split the repository shortly after tagging 3.0.0 – creating a
> kolla-ansible deliverable for Ocata.
>
>
>
> Voting is open for 7 days until September 21st, 2016. Please do not abstain
> on this critical vote.  Remember, no veto vote is available in roll-call
> votes.  If a majority can’t be reached on any one choice, but there is a
> majority around B & C, (which are the same idea, but different timing) a
> second vote will be triggered around when to split the repository.  The
> implication there is if you vote for b or c, your voting for a repository
> split.  If you vote for A you are voting for no repository split.  I hate to
> overload voting in this way.  It is only an optimization to speed things up
> as execution may need to happen now, or can be pushed out a month, or may
> not be needed at this time.
>
>
>
> Regards
>
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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

Re: [openstack-dev] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Steven Dake (stdake)]

Christian,

While the vote was not unanimous, a strong majority of core reviewers were in 
favor of our nomination with no veto in the voting period.  I know the two core 
reviewers that did not vote are travelling so perhaps they missed the vote.

Welcome to the core review team!  I attempted to make the necessary changes to 
gerrit, however, your id Berendt has some kind of problem with gerrit.  I’ll 
get that sorted out as soon as feasible.  I may need your help with it.  If you 
have any questions, please feel free to ask any of the core reviewers (me 
included).

Looking for good things from you!

Regards
-steve


From: Steven Dake 
Date: Wednesday, September 7, 2016 at 7:59 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

Kolla core reviewer team,

It is my pleasure to nominate Christian Berendt for the Kolla core team.

Christian’s output over the last cycle has been fantastic – cracking the top 10 
reviewer list for the full cycle.  His 30 day stats [1] place him in solid 7th 
position, and considering the size of the core review team we have, this is a 
great accomplishment.  Christian also has solid 60 day review stats [2] place 
him in solid 7th position.  But more importantly his reviews are of high 
quality.  He has great IRC participation as well as having implemented all 
kinds of bug fixes all over the code base.  He clearly understands Kolla by the 
quality of his reviews.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of Christian as a candidate, a 0 vote 
indicates an abstain, and a -1 is a veto.  Voting is open for 7 days until 
September 15th, or a unanimous response is reached or a veto vote occurs.  If a 
unanimous response is reached or a veto occurs, voting will close early.

Regards,
-steve

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60

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

[openstack-dev] [release][freezer] freezer Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for freezer for the end of the Newton cycle
is available!  You can find the RC1 source code tarballs at:

https://tarballs.openstack.org/freezer/freezer-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/freezer-api/freezer-api-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/freezer-dr/freezer-dr-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/freezer-web-ui/freezer-web-ui-3.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of freezer is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Doug

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

Re: [Openstack-operators] [Nova] Unable to login to instance

[Warad, Manjunath (Nokia - SG)]

Any workarounds to overcome this issue? I am basically stuck with this...

I cannot access via ssh as well, tried with private and public network to 
launch instance...

1. With private network:

- dhcp can assign an IP address successfully, but the subnet doesn't exist on 
host so I'm unable to access the instance.
Logs from instance launch...

no results found for mode=local. up 15.72. searched: nocloud configdrive ec2
Starting network...
udhcpc (v1.20.1) started
Sending discover...
Sending select for 10.0.0.3...
Lease of 10.0.0.3 obtained, lease time 86400
route: SIOCADDRT: File exists
WARN: failed: route add -net "0.0.0.0/0" gw "10.0.0.1"
cirros-ds 'net' up at 17.90
checking http://169.254.169.254/2009-04-04/instance-id
successful after 1/20 tries: up 18.65. iid=i-0003
failed to get http://169.254.169.254/2009-04-04/meta-data/public-keys
warning: no ec2 metadata for public-keys
failed to get http://169.254.169.254/2009-04-04/user-data
warning: no ec2 metadata for user-data


=== network info ===
if-info: lo,up,127.0.0.1,8,::1
if-info: eth0,up,10.0.0.3,24,fe80::f816:3eff:fe44:7613
ip-route:default via 10.0.0.1 dev eth0 
ip-route:10.0.0.0/24 dev eth0  src 10.0.0.3 
ip-route:169.254.169.254 via 10.0.0.1 dev eth0 
=== datasource: ec2 net ===
 -

IP addresses on the host machine (devstack)
Interface   IP Addr
br-ex   172.24.4.1 
enp0s3  172.16.1.71
virbr0  192.168.122.1

devstack@devstack:~/devstack$ route
Kernel IP routing table
Destination Gateway Genmask Flags   
Metric  Ref Use Iface
default home0.0.0.0 UG  
0   0   0   enp0s3
10.0.0.0172.24.4.4  255.255.255.0   UG  
0   0   0   br-ex
172.16.0.0  *   255.255.0.0 U   
0   0   0   enp0s3
172.24.4.0  *   255.255.255.0   U   
0   0   0   br-ex
192.168.122.0   *   255.255.255.0   U   
0   0   0   virbr0

2. With public network:

- failed to get dhcp IP address assigned..

Logs from instance launch...
--
udhcpc (v1.20.1) started
Sending discover...
Sending discover...
Sending discover...
Usage: /sbin/cirros-dhcpc 
No lease, failing
WARN: /etc/rc3.d/S40-network failed


=== network info ===
if-info: lo,up,127.0.0.1,8,::1
if-info: eth0,up,,8,fe80::f816:3eff:fe74:3c4b
=== datasource: None None ===
=== cirros: current=0.3.4 uptime=250.37 ===
route: fscanf
=== pinging gateway failed, debugging connection ===
 debug start ##
### /etc/init.d/sshd start
Starting dropbear sshd: OK
route: fscanf
### ifconfig -a
eth0  Link encap:Ethernet  HWaddr FA:16:3E:74:3C:4B  
  inet6 addr: fe80::f816:3eff:fe74:3c4b/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:6 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:608 (608.0 B)  TX bytes:1132 (1.1 KiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:12 errors:0 dropped:0 overruns:0 frame:0
  TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1020 (1020.0 B)  TX bytes:1020 (1020.0 B)

### route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
route: fscanf
### cat /etc/resolv.conf
cat: can't open '/etc/resolv.conf': No such file or directory
### gateway not found
/sbin/cirros-status: line 1: can't open /etc/resolv.conf: no such file
### pinging nameservers
### uname -a
Linux cirros 3.2.0-80-virtual #116-Ubuntu SMP Mon Mar 23 17:28:52 UTC 2015 
x86_64 GNU/Linux
### lsmod
Module  Size  Used byNot tainted
nls_iso8859_1  12713  0 
nls_cp437  16991  0 
vfat   17585  0 
fat61512  1 vfat
isofs  40259  0 
ip_tables  27473  0 
x_tables   29891  1 ip_tables
pcnet3242119  0 
8139cp 27360  0 
ne2k_pci   13691  0 
8390   18856  1 ne2k_pci
e1000 108589  0 
acpiphp24231  0 
### dmesg | tail
[4.426901] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[4.476572] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbog...@alpha.franken.de
[4.525105] ip_tables: (C) 2000-2006 Netfilter Core Team
[5.966370] 

[openstack-dev] [nova] Move api-ref-in-rst changes to api-ref-in-rst-ocata

[Matt Riedemann]

I've created an ocata blueprint for continuing the api-ref cleanup work:

https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst-ocata

Please move outstanding (or new) changes to the new blueprint.

https://review.openstack.org/#/q/topic:bp/api-ref-in-rst+status:open

--

Thanks,

Matt Riedemann


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

[openstack-dev] [release][mistral] mistral Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for mistral for the end of the Newton cycle
is available!  You can find the RC1 source code tarballs at:

https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/mistral-dashboard/mistral-dashboard-3.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of mistral is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Doug

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

[Openstack-operators] [ALL] Looking for participants in the Interop Challenge for Barcelona

[Rochelle Grober]

Hey folks!

Do you know about the Interop Challenge?  Well, here's a way to learn about it 
and and participate if you like...

"The interop challenge was started in July 2016 to create a set of common 
workloads/tests to be executed across multiple OpenStack distributions and/or 
cloud deployment models. The participants in this challenge will work together 
to prove once and for all that OpenStack-Powered clouds are interoperable."

The WG (and lots of other interested folks) would like to see how many of our 
Cloud deployers, vendors, distros, etc can successfully deploy and run some 
very common apps to their clouds.  And we want to let the world know about how 
easy it is in Barcelona.

The WG started with a number of vendors to create some OpenStack apps that 
demonstrate the kind of workloads users want to run.  The team identified four 
or so and started implementing the apps.  Those apps are:

* LAMP Stack

* Docker Swarm

* NFV
The  Ansible LAMP stack code can be found here:
http://git.openstack.org/cgit/openstack/osops-tools-contrib/tree/ansible/lampstack

And a Terraform version is here:
http://git.openstack.org/cgit/openstack/osops-tools-contrib/tree/terraform/lampstack

The Heat LAMP stack code is here:
http://git.openstack.org/cgit/openstack/osops-tools-contrib/tree/heat

The LAMP stack code is ready for Operators and other deployers and developers 
to take for a spin.  There are still some bugs and we are wringing out issues 
in the app as more clouds attempt to deoploy it.  But, you can file bugs on it, 
or file fixes, etc.

Mailing List discussions are happening on the defcore-committee mailing list.
IRC discussions are in openstack-defcore


Here is a bunch moreinfo on the challenge:
https://wiki.openstack.org/wiki/Interop_Challenge

And here is how to share your results:
https://wiki.openstack.org/wiki/Interop_Challenge#RefStack_Testing_and_Results_Upload

Come to the IRC meeting in #openstack-meeting-cp on Wednesday at UTC 14:-00 to 
ask questions.

Show the world that the OpenStack community not only has lots of clouds out 
there, but that they play nice together!!
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [release][aodh] aodh Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for aodh for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/aodh/aodh-3.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of aodh is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Doug

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

Re: [openstack-dev] [tripleo] CI is currently down: 2 blockers

[Emilien Macchi]

So here's an update about current situation:

Master / Newton
gate-tripleo-ci-centos-7-ovb-nonha
gate-tripleo-ci-centos-7-ovb-ha
The 2 jobs are supposed to pass, but some jobs are timing out in RH1 cloud.
In order to reduce the timeouts, Ben ran:
heat-manage purge_deleted 3
nova-manage db archive_deleted_rows --verbose --max_rows 100
sudo mysqlcheck -o -A

gate-tripleo-ci-centos-7-nonha-multinode
We merged the revert: https://review.openstack.org/#/c/370250/
At the time I'm writing this email, the job is still non-voting:
https://review.openstack.org/#/c/371133/
But hopefully Infra will merge this patch soon to bring it back in the gate.


stable/mitaka and stable/liberty
gate-tripleo-ci-centos-7-ovb-nonha works fine.
gate-tripleo-ci-centos-7-ovb-ha is broken because Galera was updated
in EPEL (and TripleO Mitaka still deploys EPEL).
I have 2 patches in order to fix the situation:
1) Fix Galera configuration to work with recent EPEL (kudos to Damien
for his help): https://review.openstack.org/#/c/371029/
2) (not required but good to have) Disable EPEL in tripleoclient
https://review.openstack.org/#/c/369559/ - I would understand if
people -1 this patch and I have no strong opinion about it.

I hope 1) will pass CI so we can just move forward.

It's end of day for me but if someone can monitor
http://tripleo.org/cistatus.html during Friday morning and make sure
everything it still running fine, we would appreciate it. Also please
report any bug related to CI and set the ci & alert tags.

Thanks, and let's keep focusing on Newton release!

On Thu, Sep 15, 2016 at 11:26 AM, Emilien Macchi  wrote:
> On Wed, Sep 14, 2016 at 10:13 PM, Emilien Macchi  wrote:
>> Hi,
>>
>> Just a heads-up before end of day:
>>
>> 1) multinode job is failing 80% of time. James and myself did some
>> attempts to revert or fix things but we have been unfortunate until
>> now.
>> Everything is documented here: 
>> https://bugs.launchpad.net/tripleo/+bug/1623606
>
> We found out that https://review.openstack.org/#/c/368760/ is breaking
> us, so we will revert it and work on it again later.
>
>> 2) ovb jobs are timeing out during NetworkDeployment because
>> 99-refresh-completed is not signaling to Heat due to instance-id being
>> detected as null by os-apply-config.
>> James proposed a revert: https://review.openstack.org/#/c/370250/
>> But the patch can't be merged because of 1).
>
> We are going to merge James's revert, we think it will bring back OVB jobs.
>
> To merge the reverts, we need to disable voting on multinode jobs:
> https://review.openstack.org/#/c/370922/
>
> Please do not merge anything today (except the 2 reverts) until our
> situation becomes more stable. Probably tonight or tomorrow.
> Once situation is better, I or someone else in the team will give an
> update here.
>
> Thanks for your understanding,
>
>> I'll continue to work on it tomorrow but if you're able to jump in and
>> make progress on it, this downtime is very critical at this stage of
>> the cycle.
>>
>> Any help is highly welcome.
>>
>> Thanks,
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [Congress] Congress horizon plugin - congressclient/congress API auth issue - help

[Eric K]

Anusha and Aimee,

Circling back on this issue: it seems that you are seeing different things
with regards to horizon authentication using keystone v2. I think we can
make good progress if we can clarify where we stand.

Anusha said setting the auth_url explicitly to v2 works. Aimee said it
didn¹t.

So just to clarify:

1. Anusha did you mean set this line
https://github.com/openstack/congress/blob/master/congress_dashboard/api/co
ngress.py#L75
To:
`auth_url = 'http://:5000/v2.0¹` ?

2. Aimee, is that what you tried?

3. Do you still get different results?

>From Anusha¹s commit message in this patch
(https://review.openstack.org/#/c/305063/), the current code should fail
because `auth_url = getattr(settings, 'OPENSTACK_KEYSTONE_URL¹)`[L75]
grabs the .../v3 URL (devstack default), yet `auth =
keystoneclient.auth.identity.v2.Token(`[L77] expects a .../v2.0 URL. So
could we have a workaround simply by doing something like `auth_url =
auth_url.replace('v3', 'v2.0¹)`? (*)

Thanks again for all the investigative work!

Eric

(*) Another potential issue is ports:
https://ask.openstack.org/en/question/67846/difference-between-keystone-por
t-5000-and-35357/

On 7/22/16, 9:06 AM, "Aimee Ukasick"  wrote:

>All - I made the change to the auth_url that  Anusha suggested.
>Same problem as before " Cannot authorize API client"
>2016-07-22 14:13:50.835861 * calling policies_list =
>client.list_policy()*
>2016-07-22 14:13:50.836062 Unable to get policies list: Cannot
>authorize API client.
>
>I used the token from the log output to query the Congress API with
>the keystone v3 token - no issues.
>curl -X GET -H "X-Auth-Token: 18ec54ac811b49aa8265c3d535ba0095" -H
>"Cache-Control: no-cache" "http://192.168.56.103:1789/v1/policies;
>
>So I really think the problem is that the python-congressclient
>doesn't support identity v3.
>I thought it did, but then I came across this:
>"support keystone v3 api and session based authentication "
>https://bugs.launchpad.net/python-congressclient/+bug/1564361
>This is currently assigned to Anusha.
>I'd like to start work on it since I am becoming familiar with keystone
>v3.
>
>Thoughts?
>
>aimee
>
>
>
>
>On Fri, Jul 22, 2016 at 8:07 AM, Aimee Ukasick
> wrote:
>> Thanks Anusha! I will retest this today. I guess I need to learn more
>> about Horizon as well - thanks for pointing me in the right direction.
>>
>> aimee
>>
>>
>>
>> On Fri, Jul 22, 2016 at 6:30 AM, Anusha Ramineni
>> wrote:
>>> Hi Aimee,
>>>
>>> I think devstack by default configured horizon to use v3 .
>>> For V2 authentication, from the logs , auth_url doesn't seem to be set
>>> explicitly to v2 auth_url .
>>>
>>> I have always set explicit v2 auth which worked fine.
>>> For eg:- auth_url = 'http://:5000/v2.0' , for V2
>>>authentication
>>>
>>> I have raised a patch, to take the auth_url from horizon settings
>>>instead of
>>> from request.
>>> https://review.openstack.org/#/c/345828/1
>>>
>>> Please set explict v2 auth_url as mentioned above in
>>>OPENSTACK_KESYTONE_URL
>>> in /openstack_dashboard/local/local_settings.py and restart
>>>apache2
>>> server . Then v2 authentication should go through fine.
>>>
>>> For v3 , need to add relevant code for v3 authentication in
>>>contrib/horizon
>>> as presently it is hardcoded to use only v2. but yes, the code from
>>>plugin
>>> model patch is still a WIP , so doesn't work for v3 authentication I
>>>guess
>>> I'll have a look at it and let you know .
>>>
>>>
>>> Best Regards,
>>> Anusha
>>>
>>> On 21 July 2016 at 21:56, Tim Hinrichs  wrote:

 So clearly an authentication problem then.

 Anusha, do you have any ideas?  (Aimee, I think Anusha has worked with
 Keystone authentication most recently, so she's your best bet.)

 Tim

 On Thu, Jul 21, 2016 at 8:59 AM Aimee Ukasick
  wrote:
>
> The  Policy/Data Sources web page throws the same errors. I am
> planning to recheck direct API calls using v3 auth today or tomorrow.
>
> aimee
>
> On Thu, Jul 21, 2016 at 10:49 AM, Tim Hinrichs  wrote:
> > Hi Aimee,
> >
> > Do the other APIs work?  That is, is it a general problem
> > authenticating, or
> > is the problem limited to list_policies?
> >
> > Tim
> >
> > On Wed, Jul 20, 2016 at 3:54 PM Aimee Ukasick
> > 
> > wrote:
> >>
> >> Hi all,
> >>
> >> I've been working on Policy UI (Horizon): Unable to get policies
> >> list (devstack) (https://bugs.launchpad.net/congress/+bug/1602837)
> >> for the past 3 days. Anusha is correct - it's an authentication
> >> problem, but I have not been able to fix it.
> >>
> >> I grabbed the relevant code in congress.py from Anusha's horizon
> >> plugin model patchset (https://review.openstack.org/#/c/305063/3)
>and
> >> 

[openstack-dev] [keystone] Retrospective for Newton

[Steve Martinelli]

I like what Matt [1] and Armando [2] have done for post-mortems /
retrospectives, so I'm borrowing both. Rather than use our specs repo I
think we should just use an etherpad [3] for now. Please help fill it in
and give feedback on how the release went. I'll start priming the content
now but would like to discuss the content in Barcelona.

As Matt said: I know it's fun to troll, but please keep it constructive and
respectful.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103814.html
[2] https://review.openstack.org/#/c/360207/12

*** [3] https://etherpad.openstack.org/p/keystone-newton-retrospective ***


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

[openstack-dev] What's Up, Doc? 16 September

[Lana Brindley]

Hi everyone,

Newton goes out in three weeks, and the release team and I have been busy 
working with our cross-project liaisons to ensure the docs suite is up to date 
and ready to go. Don't forget that you can contact any of us (or just send mail 
to the docs mailing list) if you have any questions about the Newton docs 
release. 

This week, I've also been working on Summit planning, and drafting my PTL 
candidacy, which you can read here: 
http://lists.openstack.org/pipermail/openstack-docs/2016-September/009112.html 
Big thanks to everyone who has emailed me over the past few days to offer their 
support. Knowing you all have my back is the reason I keep doing this :)  

== Progress towards Newton ==

19 days to go!

Bugs closed so far: 444

Release managers: Olena Logvinova and Alexandra Settle

Release tasks are being tracked here: 
https://etherpad.openstack.org/p/NewtonRelease

Install Guide testing is being tracked here: 
https://wiki.openstack.org/wiki/Documentation/NewtonDocTesting

== The Road to Barcelona ==

* I have a draft schedule starting to take shape, which you can see here: 
https://etherpad.openstack.org/p/Ocata-DocsSessions I'll put this into Sched 
once the tool becomes available, and your early feedback is welcome. 
Additionally, if you're interested in moderating a session in Barcelona, please 
let me know. 
* By now, you should be well on the way to having your travel and accommodation 
booked for Barcelona. In case you're still working on it, though, there's 
travel information available on the Summit site here: 
https://www.openstack.org/summit/barcelona-2016/travel/
* Looking a little further forward, Foundation have now announced that the 
first Project Team Gathering (PTG) will be held in Atlanta, US, on Feb 20-24: 
http://www.openstack.org/ptg

== Speciality Team Reports ==

This will be the last Speciality Team report before we release Newton, as focus 
shifts to final preparations, testing, and release notes. I'd like to take this 
opportunity to thank all our speciality team leads, who work very hard behind 
the scenes to keep their books in top shape, and their teams working together 
towards a common goal. Our docs suite wouldn't be what it is without these hard 
working people.

'''HA Guide: Andrew Beekhof'''
No report this week.

'''Install Tutorials: Lana Brindley'''
Core Guide testing is underway! Check out progress and sign up here: 
https://wiki.openstack.org/wiki/Documentation/NewtonDocTesting Next meeting: 27 
September August 0600UTC.

'''Networking Guide: Edgar Magana'''
No report this week.

'''Security Guide: Nathaniel Dillon'''
No report this week.

'''User Guides: Joseph Robinson'''
No report this week.

'''Ops Guide: Shilla Saebi, Darren Chan'''
No report this week.

'''API Guide: Anne Gentle'''
Working with teams who want to write guides similar to FirstApp: Murano and 
Heat for example.
This patch moves Cinder v1 API to Deprecated: 
https://review.openstack.org/#/c/370407/ Thanks Mark Voelker for all the links 
to go with the patch!

'''Config/CLI Ref: Tomoyuki Kato'''
Updating Config reference for Newton release. We need to help, especially for 
vendor plug-in configuration.

'''Training labs: Pranav Salunke, Roger Luethi'''
No report this week.

'''Training Guides: Matjaz Pancur'''
No report this week.

'''Hypervisor Tuning Guide: Blair Bethwaite
No report this week.

'''UX/UI Guidelines: Michael Tullis, Rodrigo Caballero'''
No report this week.

== Doc team meeting ==

Next meetings:

The US meeting was held this week, you can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-09-14

Next meetings:
APAC: Wednesday 21 September, 00:30 UTC
US: Wednesday 28 September, 19:00 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#16_September_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] [release][cinder] cinder Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for cinder for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/cinder/cinder-9.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of cinder is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Doug

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

[openstack-dev] [nova] Retrospective for Newton

[Matt Riedemann]

During the Nova team meeting today [1] we agreed to start an etherpad 
for retrospective feedback on the Newton cycle. I've started that here [2].


I've started filling that out a bit with some thoughts off the top of my 
head. If you have thoughts on how the release went, please post those in 
the etherpad. We plan on having a fishbowl session at the summit to go 
over some of the bigger items in there and see what actions we can take 
to improve.


I know it's fun to troll, but please keep it constructive and respectful.

[1] 
http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-09-15-21.00.log.html

[2] https://etherpad.openstack.org/p/nova-newton-retrospective

--

Thanks,

Matt Riedemann


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

[openstack-dev] [QA] Announcing my candidacy for PTL of the Ocata

[Masayuki Igawa]

Hi everyone,

I'd like to announce my candidacy for Ocata cycle as the PTL for the Quality
Assurance program/team/project/etc. First off, I would like to thank you all
the contributors, core reviewers, PTLs and anyone who involves and makes the
OpenStack better.

Let me introduce myself, briefly. I have joined the OpenStack community since
2012 as a developer. Now, I'm a core member of some QA/Infra projects such as
Tempest, Tempest-lib(deprecated), OpenStack-health, stackviz, subunit2sql[1].
And I played the mentors/instructors role at the upstream training in Japan
several times. It was a great experience to know the difficulty of telling
people how OpenStack community is going.

This Newton cycle has also been a very exciting one for the QA program. New
QA projects like stackviz and OpenStack-health are emerging and growing. For
distributed and stable project testing, we have been working on making the
tempest service clients consistent and migrating it to the lib. It is also an
excellent job in progress. And we improved Tempest-cli and its user workflow.
Thanks to the improvements, we can use Tempest in very simple steps now. And I
especially focused on improving UI side of tempest, OpenStack-health, etc. I
think this is also a great step for better UX.

In Ocata cycle, I believe cleaning up Tempest/DevStack will be one of the top
priority works such as making consistency, cleaning up pluggable modules. We
will continue to do it this cycle, too. And I also think improving UI and UX
is one of the most important things for QA. For example, OpenStack-health
should show more variety of data and be improved its performance. And regarding
the tempest cli, the first implementation phase was almost done, and we need
to get user feedbacks and improve them.

I think our OpenStack QA work is unique and excellent compare to the other open
source projects. And as you know, it is very exciting not boring these days. I
hope more and more contributors will participate in the OpenStack development,
especially the QA. So I will continue to advertise our great the OpenStack QA
works and review and make patches for better QA, of course. And any
contribution like reporting bugs, suggesting a lack of documentations, are
appreciated, too.
Join us and happy hacking!


[1] http://stackalytics.com/?user_id=igawa

Thanks for your consideration!
Masayuki Igawa

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

Re: [openstack-dev] [nova] Question about fixing missing soft deleted rows

[Sylvain Bauza]

Le 15/09/2016 03:21, Matt Riedemann a écrit :

I'm looking for other input on a question I have in this change:

https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py

We've had a few patches like this where we don't (soft) delete entries 
related to an instance when that instance record is (soft) deleted. 
These then cause the archive command to fail because of the 
referential constraint.


Then we go in and add a new entry in the instance_destroy method so we 
start (soft) deleting *new* things, but we don't cleanup anything old.


In the change above this is working around the fact we might have 
lingering consoles entries for an instance that's being archived.


One suggestion I made was adding a database migration that soft 
deletes any console entries where the related instance is deleted 
(deleted != 0). Is that a bad idea? It's not a schema migration, it's 
data cleanup so archive works. We could do the same thing with a 
nova-manage command, but we don't know that someone has run it like 
they do with the DB migrations.


Another idea is doing it in the nova-manage db online_data_migrations 
command which should be run on upgrade. If we landed something like 
that in say Ocata, then we could remove the TODO in the archive code 
in Pike.


Other thoughts?



The real problem I see with a nova-manage db online_data_migrations or a 
database migration is that we are not fixing the root problem, which is 
that anytime someone is soft-deleting an instance, we're not also (soft 
or hard) deleting the related entries.


If we were providing that script, it would be needed to call it 
idempotentically, right?
If so, MHO is that a single nova-manage command (or subcommand) could be 
enough, using a marker and a limit.


The other alternative I could see is that the archive command would be 
healing the DB by deleting the entries that should have been 
(soft/hard)deleted if the related instance is soft-deleted too.


-Sylvain



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

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi John,

I have sent mail to 'eventv...@openstack.org', waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos [mailto:openstack@sodarock.com] 
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek  
wrote:
> Hi John,
>
> I have read the information given at 
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps needed to get an invitation letter.
>
> Good luck!
>
>
> On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek 
>  wrote:
>> Hi Devs, Stackers,
>>
>>
>>
>> While applying visa from Pune (India), I came to know that Invitation 
>> letter is required in Spanish language and its mandatory.
>>
>> Has anyone from India has faced similar kind of issue while applying 
>> for visa?
>>
>>
>>
>> If not please let me know from which city you have applied for the Visa.
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Abhishek Kekane
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest 
>> confidence for the sole use of the addressee and may contain legally 
>> privileged, confidential, and proprietary data. If you are not the 
>> intended recipient, please advise the sender by replying promptly to 
>> this email and then delete and destroy this email and any attachments 
>> without any further use, copying or forwarding.
>>
>> _
>> _  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> Disclaimer: This email and any attachments are sent in strictest 
> confidence for the sole use of the addressee and may contain legally 
> privileged, confidential, and proprietary data. If you are not the 
> intended recipient, please advise the sender by replying promptly to 
> this email and then delete and destroy this email and any attachments 
> without any further use, copying or forwarding.
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Christian Berendt]

> On 15 Sep 2016, at 08:12, Steven Dake (stdake)  wrote:
> 
> c)   Split the repository shortly after tagging 3.0.0 – creating a 
> kolla-ansible deliverable for Ocata.

+1

Christian.


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

Re: [openstack-dev] [all] Ocata Design Summit - Proposed slot allocation

[Thierry Carrez]

Clint Byrum wrote:
> Excerpts from Thierry Carrez's message of 2016-09-15 09:37:47 +0200:
>> Emilien Macchi wrote:
>>> On Wed, Sep 14, 2016 at 1:51 PM,   wrote:
 Also if you don't plan to use all of your
>
> allocated slots, let us know so that we can propose them to other teams.
>
 Just so that we are not forgotten (in case there is some space left), the
 storlets dev team would greatly appreciate 2fb and 2-3wr.
 Many thanks in advance!
 Eran
>>>
>>> In PuppetOpenStack we have:
>>> 1fb 2wr
>>>
>>> And I'm really not sure we'll use them all:
>>> https://etherpad.openstack.org/p/ocata-puppet
>>>
>>> As you can see, we don't have much topics now, so I'm quite sure we
>>> could give one wr to you.
>>
>> I keep a list of non-official-yet-but-could-use-summit-space teams, and
>> will propose any leftover space to them soon. Let me know if you don't
>> plan to use all of your allocated slots and I'll put them in that pool.
>>
> 
> I'm hoping the ArchWG lands on that list. We'll probably need some face
> time just to hug it out by the time summit rolls around. :)

I feel like the Arch WG could steal one of the cross-project workshop
spaces, if you propose it as described at [1].

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103657.html

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Gerard Braad]

>> a)   Do not split the repository between rc1 and Summit or shortly
>> thereafter at all, keeping the Ansible implementation intact in Ocata
>> b)   Split the repository shortly after tagging RC1 – creating of a
>> kolla-ansible deliverable for Ocata.
>> c)   Split the repository shortly after tagging 3.0.0 – creating a
>> kolla-ansible deliverable for Ocata.

My vote is for C.

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

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org’ to explain your issue and also give reference of this 
ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar [mailto:jankih...@gmail.com]
Sent: Thursday, September 15, 2016 11:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
> wrote:
Hi John,

I have sent mail to 'eventv...@openstack.org', 
waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 
[mailto:openstack@sodarock.com]
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek 
> wrote:
> Hi John,
>
> I have read the information given at
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos 
> [mailto:openstack@sodarock.com]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps needed to get an invitation letter.
>
> Good luck!
>
>
> On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek 
> > wrote:
>> Hi Devs, Stackers,
>>
>>
>>
>> While applying visa from Pune (India), I came to know that Invitation
>> letter is required in Spanish language and its mandatory.
>>
>> Has anyone from India has faced similar kind of issue while applying
>> for visa?
>>
>>
>>
>> If not please let me know from which city you have applied for the Visa.
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Abhishek Kekane
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence for the sole use of the addressee and may contain legally
>> privileged, confidential, and proprietary data. If you are not the
>> intended recipient, please advise the sender by replying promptly to
>> this email and then delete and destroy this email and any attachments
>> without any further use, copying or forwarding.
>>
>> _
>> _  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> Disclaimer: This email and any attachments are sent in strictest
> confidence for the sole use of the addressee and may contain legally
> privileged, confidential, and proprietary data. If you are not the
> intended recipient, please advise the sender by replying promptly to
> this email and then delete and destroy this email and any attachments
> without 

Re: [openstack-dev] Spain Visa for Indian contributors

[M Ranga Swami Reddy]

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

> Hi Janki,
>
>
>
> I will keep you posted about this. Mean time sent mail to ‘
> eventv...@openstack.org’ to explain your issue and also give reference of
> this ML.
>
>
>
> Thank you,
>
>
>
> Abhishek Kekane
>
>
>
> *From:* Janki Chhatbar [mailto:jankih...@gmail.com]
> *Sent:* Thursday, September 15, 2016 11:51 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Spain Visa for Indian contributors
>
>
>
> Hi Abhishek
>
> I am Janki. I am applying for visa from India. I haven't applied yet but a
> friend of mine is facing the same issue of needing an invitation letter in
> Spanish.
>
> May be everyone applying from India can request to have the letter in
> Spanish too.
>
> Let me know how you proceed further. It would help me while applying.
>
> Thanks
>
> Janki
>
>
>
> On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
>
> Hi John,
>
> I have sent mail to 'eventv...@openstack.org', waiting for positive reply.
>
> One reply I got from Kendall is,
>
> We only send the letter in English. No one else applying for a visa has
> had a problem getting their visa with just the English letter so the letter
> you received should be sufficient.
>
> I will show this reply mail at VFS center and hopefully they will take no
> objection about this.
>
> Thank you for your time,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com]
>
> Sent: Thursday, September 15, 2016 11:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> On that page they seem to list a contact email:
>
> eventv...@openstack.org
>
> Hopefully they can help with the issue.
>
> John
>
> On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> > Hi John,
> >
> > I have read the information given at
> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
> > and got the invitation letter but it's in English language. Problem is
> that Visa centers in India are demanding this invitation letter in English
> as well as Spanish language.
> >
> > Thank you,
> >
> > Abhishek Kekane
> >
> > -Original Message-
> > From: John Villalovos [mailto:openstack@sodarock.com]
> > Sent: Thursday, September 15, 2016 9:45 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] Spain Visa for Indian contributors
> >
> > There is information on the Visa process at:
> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
> >
> > Not sure if you have already read that information.
> >
> > They talk about the steps needed to get an invitation letter.
> >
> > Good luck!
> >
> >
> > On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> >> Hi Devs, Stackers,
> >>
> >>
> >>
> >> While applying visa from Pune (India), I came to know that Invitation
> >> letter is required in Spanish language and its mandatory.
> >>
> >> Has anyone from India has faced similar kind of issue while applying
> >> for visa?
> >>
> >>
> >>
> >> If not please let me know from which city you have applied for the Visa.
> >>
> >>
> >>
> >>
> >>
> >> Thank you,
> >>
> >>
> >>
> >> Abhishek Kekane
> >>
> >>
> >> _
> >> _
> >> Disclaimer: This email and any attachments are sent in strictest
> >> confidence for the sole use of the addressee and may contain legally
> >> privileged, confidential, and proprietary data. If you are not the
> >> intended recipient, please advise the sender by replying promptly to
> >> this email and then delete and destroy this email and any attachments
> >> without any further use, copying or forwarding.
> >>
> >> _
>
> >> _  OpenStack Development Mailing List (not for usage questions)
>
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __
> > Disclaimer: This email and any attachments are sent in strictest
> > confidence for the sole use of the addressee and may contain legally
> > privileged, confidential, and 

Re: [openstack-dev] [all] Ocata Design Summit - Proposed slot allocation

[Thierry Carrez]

Emilien Macchi wrote:
> On Wed, Sep 14, 2016 at 1:51 PM,   wrote:
>> Also if you don't plan to use all of your
>>>
>>> allocated slots, let us know so that we can propose them to other teams.
>>>
>> Just so that we are not forgotten (in case there is some space left), the
>> storlets dev team would greatly appreciate 2fb and 2-3wr.
>> Many thanks in advance!
>> Eran
> 
> In PuppetOpenStack we have:
> 1fb 2wr
> 
> And I'm really not sure we'll use them all:
> https://etherpad.openstack.org/p/ocata-puppet
> 
> As you can see, we don't have much topics now, so I'm quite sure we
> could give one wr to you.

I keep a list of non-official-yet-but-could-use-summit-space teams, and
will propose any leftover space to them soon. Let me know if you don't
plan to use all of your allocated slots and I'll put them in that pool.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Ocata Design Summit - Proposed slot allocation

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2016-09-15 09:37:47 +0200:
> Emilien Macchi wrote:
> > On Wed, Sep 14, 2016 at 1:51 PM,   wrote:
> >> Also if you don't plan to use all of your
> >>>
> >>> allocated slots, let us know so that we can propose them to other teams.
> >>>
> >> Just so that we are not forgotten (in case there is some space left), the
> >> storlets dev team would greatly appreciate 2fb and 2-3wr.
> >> Many thanks in advance!
> >> Eran
> > 
> > In PuppetOpenStack we have:
> > 1fb 2wr
> > 
> > And I'm really not sure we'll use them all:
> > https://etherpad.openstack.org/p/ocata-puppet
> > 
> > As you can see, we don't have much topics now, so I'm quite sure we
> > could give one wr to you.
> 
> I keep a list of non-official-yet-but-could-use-summit-space teams, and
> will propose any leftover space to them soon. Let me know if you don't
> plan to use all of your allocated slots and I'll put them in that pool.
> 

I'm hoping the ArchWG lands on that list. We'll probably need some face
time just to hug it out by the time summit rolls around. :)

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

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Swapnil Kulkarni]

On Thu, Sep 15, 2016 at 11:42 AM, Steven Dake (stdake)  wrote:
> Core Reviewers:
>
>
>
> The facts:
>
> We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be
> closed out as dupes, fixed, wontfix, or the like.
>
> The core reviewer team has had various discussions around splitting the
> repository at various times but has not come to a concrete conclusion via a
> vote.
>
> Once RC1 is tagged, the stable/newton branch will be created automatically.
>
> All rc2 bug fixes will require bug IDs and backports to stable/newton to
> enable the ability to manage the release of rc2 and 3.0.0.
>
> There is an expectation for core reviewers to do the work of backporting to
> stable/newton – only our backports team typically does this work – however
> during release we really need everyone’s participation.
>
>
>
> My understanding of general consensus beliefs:
>
> We believe splitting out the Ansible implementation into a separate
> repository will produce a better outcome for both Kolla-Ansible and
> Kolla-Kubernetes
>
> We have been unable to achieve consensus on the right timing for a repo
> split in the past but generally believe the timing is right at some point
> between rc1 and Summit or shortly thereafter, if we are to do the repo split
> during Newton or very early Ocata.)
>
>
>
> This vote is a multiple choice (one choice please) vote.  Feel free to
> discuss before making a decision.
>
>
>
> Please vote:
>
> a)   Do not split the repository between rc1 and Summit or shortly
> thereafter at all, keeping the Ansible implementation intact in Ocata
>
> b)   Split the repository shortly after tagging RC1 – creating of a
> kolla-ansible deliverable for Ocata.
>
> c)   Split the repository shortly after tagging 3.0.0 – creating a
> kolla-ansible deliverable for Ocata.
>
>
>
> Voting is open for 7 days until September 21st, 2016. Please do not abstain
> on this critical vote.  Remember, no veto vote is available in roll-call
> votes.  If a majority can’t be reached on any one choice, but there is a
> majority around B & C, (which are the same idea, but different timing) a
> second vote will be triggered around when to split the repository.  The
> implication there is if you vote for b or c, your voting for a repository
> split.  If you vote for A you are voting for no repository split.  I hate to
> overload voting in this way.  It is only an optimization to speed things up
> as execution may need to happen now, or can be pushed out a month, or may
> not be needed at this time.
>
>
>
> Regards
>
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


my vote is for option C.

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

Re: [openstack-dev] Spain Visa for Indian contributors

[Kekane, Abhishek]

Hi,

Yes it’s request from embassy than for Indian citizens invitation letter should 
be in Spanish as well English language.
I have sent mail to openstack visa team.

Thank you,

Abhishek Kekane

From: M Ranga Swami Reddy [mailto:swamire...@gmail.com]
Sent: Thursday, September 15, 2016 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the 
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek 
> wrote:
Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org’ to explain your issue 
and also give reference of this ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar [mailto:jankih...@gmail.com]
Sent: Thursday, September 15, 2016 11:51 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
> wrote:
Hi John,

I have sent mail to 'eventv...@openstack.org', 
waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 
[mailto:openstack@sodarock.com]
Sent: Thursday, September 15, 2016 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

On that page they seem to list a contact email:

eventv...@openstack.org

Hopefully they can help with the issue.

John

On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek 
> wrote:
> Hi John,
>
> I have read the information given at
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
> and got the invitation letter but it's in English language. Problem is that 
> Visa centers in India are demanding this invitation letter in English as well 
> as Spanish language.
>
> Thank you,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos 
> [mailto:openstack@sodarock.com]
> Sent: Thursday, September 15, 2016 9:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> There is information on the Visa process at:
> https://www.openstack.org/summit/barcelona-2016/travel/#visa
>
> Not sure if you have already read that information.
>
> They talk about the steps needed to get an invitation letter.
>
> Good luck!
>
>
> On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek 
> > wrote:
>> Hi Devs, Stackers,
>>
>>
>>
>> While applying visa from Pune (India), I came to know that Invitation
>> letter is required in Spanish language and its mandatory.
>>
>> Has anyone from India has faced similar kind of issue while applying
>> for visa?
>>
>>
>>
>> If not please let me know from which city you have applied for the Visa.
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Abhishek Kekane
>>
>>
>> _
>> _
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence for the sole use of the addressee and may contain legally
>> privileged, confidential, and proprietary data. If you are not the
>> intended recipient, please advise the sender by replying promptly to
>> this email and then delete and destroy this email and any attachments
>> without any further use, copying or forwarding.
>>
>> _
>> _  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about fixing missing soft deleted rows

[Clint Byrum]

Excerpts from Matt Riedemann's message of 2016-09-14 20:21:09 -0500:
> I'm looking for other input on a question I have in this change:
> 
> https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py
> 
> We've had a few patches like this where we don't (soft) delete entries 
> related to an instance when that instance record is (soft) deleted. 
> These then cause the archive command to fail because of the referential 
> constraint.
> 
> Then we go in and add a new entry in the instance_destroy method so we 
> start (soft) deleting *new* things, but we don't cleanup anything old.
> 
> In the change above this is working around the fact we might have 
> lingering consoles entries for an instance that's being archived.
> 
> One suggestion I made was adding a database migration that soft deletes 
> any console entries where the related instance is deleted (deleted != 
> 0). Is that a bad idea? It's not a schema migration, it's data cleanup 
> so archive works. We could do the same thing with a nova-manage command, 
> but we don't know that someone has run it like they do with the DB 
> migrations.
> 
> Another idea is doing it in the nova-manage db online_data_migrations 
> command which should be run on upgrade. If we landed something like that 
> in say Ocata, then we could remove the TODO in the archive code in Pike.

In a former life doing highly scalable MySQL, we ditched all of the FK
checks because they were just extra work on write. Instead we introduced
workers that would walk tables and apply rules. They'd do something like
this:

SELECT * FROM book WHERE id > ? ORDER BY id LIMIT 10

And then check those 10 records for any referential integrity issues. If
they found a true orphan like you describe, they'd archive it and move
on. These workers would also sleep a bit between queries (usually about
half as long as the last query took) so they were never a constant drain
on the database. Then after sleeping, the worker takes the last id, and
passes it in. So it basically walks the table by id. If it ever gets
less than 10 records, it goes back to the minimum ID.

Doing this with many million record tables was quite effective,
generally most rows that were archived by something like this were
created by manual manipulation of the database, or legitimate bugs in
the software.

The benefit of doing this is you get to choose how much write and read
capacity you want to commit to consistency.

So, a thought is, rather than one-shot db migration script things, a
worker could be written that just crawls around the various project
databases and reports on, or fixes, known issues.
> 
> Other thoughts?
> 

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

[openstack-dev] [OSSN-0066] MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


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

Re: [openstack-dev] Spain Visa for Indian contributors

[Janki Chhatbar]

Hi Abhishek

I am Janki. I am applying for visa from India. I haven't applied yet but a
friend of mine is facing the same issue of needing an invitation letter in
Spanish.

May be everyone applying from India can request to have the letter in
Spanish too.

Let me know how you proceed further. It would help me while applying.

Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

> Hi John,
>
> I have sent mail to 'eventv...@openstack.org', waiting for positive reply.
>
> One reply I got from Kendall is,
>
> We only send the letter in English. No one else applying for a visa has
> had a problem getting their visa with just the English letter so the letter
> you received should be sufficient.
>
> I will show this reply mail at VFS center and hopefully they will take no
> objection about this.
>
> Thank you for your time,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com]
> Sent: Thursday, September 15, 2016 11:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> On that page they seem to list a contact email:
>
> eventv...@openstack.org
>
> Hopefully they can help with the issue.
>
> John
>
> On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> > Hi John,
> >
> > I have read the information given at
> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
> > and got the invitation letter but it's in English language. Problem is
> that Visa centers in India are demanding this invitation letter in English
> as well as Spanish language.
> >
> > Thank you,
> >
> > Abhishek Kekane
> >
> > -Original Message-
> > From: John Villalovos [mailto:openstack@sodarock.com]
> > Sent: Thursday, September 15, 2016 9:45 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] Spain Visa for Indian contributors
> >
> > There is information on the Visa process at:
> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
> >
> > Not sure if you have already read that information.
> >
> > They talk about the steps needed to get an invitation letter.
> >
> > Good luck!
> >
> >
> > On Wed, Sep 14, 2016 at 8:51 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> >> Hi Devs, Stackers,
> >>
> >>
> >>
> >> While applying visa from Pune (India), I came to know that Invitation
> >> letter is required in Spanish language and its mandatory.
> >>
> >> Has anyone from India has faced similar kind of issue while applying
> >> for visa?
> >>
> >>
> >>
> >> If not please let me know from which city you have applied for the Visa.
> >>
> >>
> >>
> >>
> >>
> >> Thank you,
> >>
> >>
> >>
> >> Abhishek Kekane
> >>
> >>
> >> _
> >> _
> >> Disclaimer: This email and any attachments are sent in strictest
> >> confidence for the sole use of the addressee and may contain legally
> >> privileged, confidential, and proprietary data. If you are not the
> >> intended recipient, please advise the sender by replying promptly to
> >> this email and then delete and destroy this email and any attachments
> >> without any further use, copying or forwarding.
> >>
> >> _
> >> _  OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __
> > Disclaimer: This email and any attachments are sent in strictest
> > confidence for the sole use of the addressee and may contain legally
> > privileged, confidential, and proprietary data. If you are not the
> > intended recipient, please advise the sender by replying promptly to
> > this email and then delete and destroy this email and any attachments
> > without any further use, copying or forwarding.
> >
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

[openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Steven Dake (stdake)]

Core Reviewers:

The facts:
We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be 
closed out as dupes, fixed, wontfix, or the like.
The core reviewer team has had various discussions around splitting the 
repository at various times but has not come to a concrete conclusion via a 
vote.
Once RC1 is tagged, the stable/newton branch will be created automatically.
All rc2 bug fixes will require bug IDs and backports to stable/newton to enable 
the ability to manage the release of rc2 and 3.0.0.
There is an expectation for core reviewers to do the work of backporting to 
stable/newton – only our backports team typically does this work – however 
during release we really need everyone’s participation.

My understanding of general consensus beliefs:
We believe splitting out the Ansible implementation into a separate repository 
will produce a better outcome for both Kolla-Ansible and Kolla-Kubernetes
We have been unable to achieve consensus on the right timing for a repo split 
in the past but generally believe the timing is right at some point between rc1 
and Summit or shortly thereafter, if we are to do the repo split during Newton 
or very early Ocata.)

This vote is a multiple choice (one choice please) vote.  Feel free to discuss 
before making a decision.

Please vote:

a)   Do not split the repository between rc1 and Summit or shortly 
thereafter at all, keeping the Ansible implementation intact in Ocata

b)   Split the repository shortly after tagging RC1 – creating of a 
kolla-ansible deliverable for Ocata.

c)   Split the repository shortly after tagging 3.0.0 – creating a 
kolla-ansible deliverable for Ocata.

Voting is open for 7 days until September 21st, 2016. Please do not abstain on 
this critical vote.  Remember, no veto vote is available in roll-call votes.  
If a majority can’t be reached on any one choice, but there is a majority 
around B & C, (which are the same idea, but different timing) a second vote 
will be triggered around when to split the repository.  The implication there 
is if you vote for b or c, your voting for a repository split.  If you vote for 
A you are voting for no repository split.  I hate to overload voting in this 
way.  It is only an optimization to speed things up as execution may need to 
happen now, or can be pushed out a month, or may not be needed at this time.

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

[openstack-dev] [release][panko] panko Newton RC1 available

[Doug Hellmann]

Hello everyone,

The release candidate for panko for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/panko/panko-1.0.0.0rc1.tar.gz

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

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

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

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

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

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

Note that the "master" branch of panko is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Doug

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

[openstack-dev] [release] Release countdown for week R-2, 19-23 Sept

[Doug Hellmann]

Focus
-

All teams should be working on release-critical bugs before the
final release.

General Notes
-

Projects following the milestone release model that missed the RC1
target date should prepare an RC1 as soon as possible.

Release Actions
---

Projects not following the milestone-based release model who want
stable/newton branches created should talk to the release team about
their needs. Remember, we always create stable branches from tagged
commits, so we need the tag to exist before we branch.

Watch for translation patches and merge them quickly to ensure we
have as many user-facing strings translated as possible in the
release candidates. If your project has already been branched, make
sure those patches are also applied to the stable branch.

Liaisons for projects with independent deliverables should import
the release history by preparing patches to openstack/releases.

Important Dates
---

Newton RC-1, 15 Sept.

Newton release schedule: http://releases.openstack.org/newton/schedule.html

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