[openstack-dev] [kolla] Need clarify about baremetal host group and role in Ansible

[duon...@vn.fujitsu.com]

Hi all, sean-k-mooney,

In recent baremetal patchset [1] from sean-k-mooney, file 
ansible/inventory/multinode has following code snippet:

> [baremetal:children]
> control
> network
> compute
> storage

But all-in-one inventory does not have any change, so I have some questions 
after read through code base:
- Why all-in-one is treated differently.
- Do you treat every nodes as baremetal node?
If the answer is "yes" so why we put it in "baremetal" role/group, I think it 
is quite misleading.
- Why many host setup playbooks are placed in baremetal role? I think we can 
factor out to more general role.

Fix me if I wrong.


[1] https://review.openstack.org/#/c/325631

Best regards,

duonghq
PODC - Fujitsu Vietnam Ltd.



__
OpenStack Development Mailing 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] [bifrost] Question about the "nics" argument provide to ansible os_ironic module.

[hu . zhijiang]

Hi Bifrost Team,

>From the code study about Bifrost and Shade I found that the "nics" 
argument provide to ansible's os_ironic module is used for creating ports 
for a bare metal. I think it is related to neutron. But for bifrost which 
uses ironic in standalone mode, there is no need to create ports like 
this. So I don't know why we need to provide the "nics" argument. Is it 
optional or even shall be hidden from Bifrost user's eyes?

Thanks.

B.R.,
Zhijiang


__
OpenStack Development Mailing 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] NoMethodRegisteredException when deploying Murano environment

[wuhan]

hi, I deployed an environment and the deployment log shows
[yaql.language.exceptions.NoMethodRegisteredException]: Unknown method 
"listNeutronExtensions" for receiver 
I use mitaka version.
How to solve this error?


Wu Han



__
OpenStack Development Mailing 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][networking-ovs-dpdk][dvr] how to use dvr with networking-ovs-dpdk

[huangdenghui]

hi
Is it possible to use dvr with networking-ovs-dpdk now? If not, is it on 
the roadmap of networking-ovs-dpdk?


发自网易邮箱手机版__
OpenStack Development Mailing 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] [gate] [cinder] A current major cause for gate failure - cinder backups

[Sean Dague]

The gate is in a bad state, as people may have noticed. We're only at a 
50% characterization for integrated-gate right now - 
http://status.openstack.org/elastic-recheck/data/integrated_gate.html 
which means there are a lot of unknown bugs in there.


Spot checking one job - gate-tempest-dsvm-postgres-full-ubuntu-xenial - 
6 of the 7 fails were failure of cinder backup - 
http://logs.openstack.org/92/355392/4/gate/gate-tempest-dsvm-postgres-full-ubuntu-xenial/582fbd7/console.html#_2016-08-17_04_55_24_109972 
- though they were often different tests.


With the current state of privsep logging (hundreds of lines at warn 
level) it is making it difficult for me to narrow this down further. I 
do suspect this might be another concurrency shake out from os-brick, so 
it probably needs folks familiar to go through logs with a fine toothed 
comb to get to root cause. If anyone can jump on that, it would be great.


This is probably not the only big new issue, but it seems like a pretty 
concrete one that solving would help drop out merge window (which is 16 
hours).


-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] [all][massively distributed][architecture] Coordination between actions/WGs

[joehuang]

Hello, Adrien,

How about different focus for different working gruop? For example, "massively 
distributed" working group can focus on identifying the use cases, challenges, 
issues in current openstack to support such fog/edge computing scenario, and 
even including the use cases/scenario from ETSI mobile edge computing 
(http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing,  
  
https://portal.etsi.org/portals/0/tbpages/mec/docs/mobile-edge_computing_-_introductory_technical_white_paper_v1%2018-09-14.pdf).
 For "architecture" working group, how about to focus on dicsussing technology 
solution/proposal to address these issues/challenges?

We have discussed/exchanged ideas a lot before/in/after Austin summit. As 
Tricircle has worked in the multisite area for several cycles, a lots of use 
cases/challengs/issues also have been identified, the proposal of Tricircle 
could be one basis to be discussed in "arhictecture" working group, other 
proposals are also welcome.

Best Regards
Chaoyi Huang (joehuang)


From: lebre.adr...@free.fr [lebre.adr...@free.fr]
Sent: 23 August 2016 18:17
To: OpenStack Development Mailing List; openstack-operators
Cc: discovery-...@inria.fr
Subject: [openstack-dev] [all][massively distributed][architecture] 
Coordination between actions/WGs

Hi Folks,

During the last summit, we suggested to create a new working group that deals 
with the massively distributed use case:
How can OpenStack be "slightly" revised to operate Fog/Edge Computing 
infrastructures, i.e. infrastructures composed of several sites.
The first meeting we did in Austin showed us that additional materials were 
mandatory to better understand the scope as well as the actions we can perform 
in this working group.

After exchanging with different persons and institutions, we have identified 
several actions that we would like to achieve and that make the creation of 
such a working group relevant from our point of view.

Among the list of possible actions, we would like to identify major scalability 
issues and clarify intra-site vs inter-site exchanges between the different 
services of OpenStack in a multi-site context (i.e. with the vanilla OpenStack 
code).
Such information will enable us to better understand how and where each service 
should be deployed and whether it should be revised.

We have started an action with the Performance WG  with the ultimate goal to 
analyse how OpenStack behaves from the performance aspect as well as the 
interactions between the various services in such a context.

Meanwhile, we saw during this summer the Clynt's proposal about the 
Architecture WG.

Although we are very exciting about this WG (we are convinced it will be 
valuable for the whole community), we are wondering
whether the  actions we envision in the Massively distributed WG will not 
overlap the ones (scalability, multi-site operations ...) that could be 
performed in the Archictecture WG.

The goal of this email is to :

(i) understand whether the fog/edge computing use case is in the scope of 
the Architecture WG.

(ii) if not, whether it makes sense to create a working group that focus on 
scalability and multi-site challenges (Folks from Orange Labs and British 
Telecom for instance already told us that they are interesting by such a 
use-case).

(iii) what is the best way to coordinate our efforts with the actions 
performed in other WGs such as the Performance and Architecture ones (e.g., 
actions performed/decisions taken in the Architecture WG can have impacts on 
the massively distributed WG and thus  drive the way we should perform actions 
to progress to the Fog/Edge Computing target)


According to the feedback, we will create dedicated wiki pages for the 
massively distributed WG.
Remarks/comments welcome.

Ad_rien_
Further information regarding the Fog/Edge Computing use-case we target is 
available at http://beyondtheclouds.github.io

__
OpenStack Development Mailing 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] puppet-syntax jobs are currently broken

[Emilien Macchi]

FTR, it was fixed upstream and everything should be back to normal now.

On Tue, Aug 23, 2016 at 4:26 PM, Emilien Macchi  wrote:
> Hi,
>
> TripleO CI is currently failing on puppet-syntax jobs, this is due to
> an update in the gems we rely on for testing the Puppet syntax.
> The fixes are available for review:
> https://review.openstack.org/#/q/status:open++topic:puppetlabs_spec_helper/pin
>
> It's a temporary fix, until we sort things out upstream:
> https://tickets.puppetlabs.com/browse/MODULES-3776
>
> We'll need to backport it into stable/liberty and stable/mitaka asap.
>
> Thanks for reviewing it asap!
> --
> 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] [kolla] Kolla configuration files owner and permission

[Jeffrey Zhang]

Using the same user for running service and the configuration files is
danger. i.e. the service running user shouldn't be change the
configuration files.

a simple attack like:
* a hacker hacked into nova-api container with nova user
* he can change the /etc/nova/rootwrap.conf file and
/etc/nova/rootwrap.d file, which he can get much greater authority
with sudo
* he also can change the /etc/nova/nova.conf file to use another
privsep_command.helper_command to get greater authority
[privsep_entrypoint]
helper_command=sudo nova-rootwrap /etc/nova/rootwrap.conf
privsep-helper --config-file /etc/nova/nova.conf

So right rule should be: do not let the service running user have
write permission to configuration files,

about for the nova.conf file, i think root:root with 644 permission
or root:nova with 640 should be enough
for the directory file, root:root with 755 or root:nova with 750
should be enough.

On Tue, Aug 23, 2016 at 11:11 PM, Steven Dake (stdake)  wrote:
>
>
>
>
>
> On 8/23/16, 7:05 AM, "Gerard Braad"  wrote:
>
>>On Tue, Aug 23, 2016 at 9:56 PM, lương hữu tuấn  wrote:
>>> I also prefer a dedicated user ("kolla" seems the best choice) as same > On 
>>> Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke  wrote:
 In my experience operators prefer a dedicated user (kolla:kolla), though I
>>
>>kolla:kolla seems more logical and simpler to reason about.
>>
>
> kolla:kolla still works with multi-user approach and permissions 660 on 
> /etc/kolla files.
>
> Regards
> -steve
>
>>
>>--
>>
>>   Gerard Braad | http://gbraad.nl
>>   [ Doing Open Source Matters ]
>>
>>__
>>OpenStack Development Mailing 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



-- 
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] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

[Jeffrey Zhang]

+1

On Wed, Aug 24, 2016 at 4:45 AM, Steven Dake (stdake)  wrote:
> Kolla core reviewers,
>
> I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day
> review stats [1] place him in the middle of the pack for reviewers and his
> 60 day stats[2] are about equivalent.  Dave participates heavily in IRC and
> has done some good technical work including the Watcher playbook and
> container.  He also worked on Sensu, but since we are unclear if we are
> choosing Sensu or Tig, that work is on hold.  He will also be helping us
> sort out how to execute with PBR going into the future on our stable and
> master branches.  Dave has proven to me his reviews are well thought out and
> he understands the Kolla Architecture.  Dave is part time like many Kolla
> core reviewers and is independent of any particular affiliation.
>
> Consider this nomination as a +1 from me.
>
> As a reminder, a +1 vote indicates you approve of the candidate, an abstain
> vote indicates you don't care or don't know for certain, and a –1 vote
> indicates a veto.  If a veto occurs or a unanimous response is reached prior
> to our 7 day voting window which concludes on August 30th, voting will be
> closed early.
>
> [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
>



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

[openstack-dev] My openstack account is invalid after change it

[zhuna]

Dear,

I changed my openstack account to my new email address because my old email 
address is abandoned, now i can not login with my new email address, it prompts 
my new email address is not verified, every time I click verify my new account,
It prompts " your request was successfully processed! please verify your 
INBOX", but I never receive email about it.

I guess it sends verification email to my our email address, what should I do 
because my old email address can not be used?
__
OpenStack Development Mailing 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] [Magnum] Release schedule of magnumclient

[Hongbin Lu]

Hi team,

As discussed at the team meeting, Aug 29-02 (next week) is the final release 
for client libraries [1]. We are going to freeze the python-magnumclient repo 
for preparing the client release. If you have *client* patches for newton 
release, please submit it by the end of this week.

According to the schedule, the feature freeze is next week as well but I am OK 
to be flexible about that. However, we needs to deliver the first release 
candidate no later than the RC1 target week (Sep 12-16) so please try to submit 
all your *server* patches before the RC1 target week, or let me know if you 
need more time.

[1] https://releases.openstack.org/newton/schedule.html

Best regards,
Hongbin
__
OpenStack Development Mailing 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] [kolla] future of Debian images

[Christian Berendt]

Hello everybody.

With this mail I want to propose the deprecation and removal of Debian images 
from the Kolla project.

* On the gates we only test the build of binary images for the following 
distributions: centos,  oraclelinux, ubuntu-trusty, ubuntu-xenial 
(https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/projects.yaml#L5485-L5510)

* The most Dockerfile templates do not handle Debian for binary images (only 37 
templates handle base_distro type debian, 108 templates handle base_distro type 
ubuntu)

Christian.

--
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139



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] [kloudbuster] authorization failed problem

[Akshay Kumar Sanghai]

Hi Yichen, Alec,

The kloudbuster project worked perfectly fine for me. Now I want to
integrate lbaas for scale testing. Can you guys help in how do i achieve
that? Please include me for any contribution.

Thanks
Akshay Sanghai

On Fri, Apr 8, 2016 at 8:15 AM, Alec Hothan (ahothan) 
wrote:

>
>
> From: Akshay Kumar Sanghai 
> Date: Thursday, April 7, 2016 at 1:46 AM
> To: "Yichen Wang (yicwang)" , Alec Hothan <
> ahot...@cisco.com>
> Cc: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem
>
> Thanks Yichen and Alec.
> Yichen, It was what I was looking for. I started with Rally , but faced
> problem with defining the number of router per tenant and traffic
> generation. Then, I found that there is a new project Kloudbuster. I faced
> some issues , but with your help , I succeeded in running it.
> One suggestion: I think Rally developers  are also trying for the traffic
> generation. So just make sure, we don't have two things for the same work
> under the openstack umbrella.
>
>
> We're also using Rally to test our control plane. Data plane testing at
> scale is a whole different ballgame (than control plane) and we had very
> specific scale test requirements in mind for our own usage as far back as
> late 2014, which is why we developed kloudbuster in Feb 2015 with HTTP
> traffic at scale. At that time there was no solution available for doing
> automated data plane scale testing, even today as you can see the number of
> solutions is actually very limited.
> Anyway if the Rally developers are interested to discuss about it, I or
> Yichen would be happy to discuss.
>
>
> One Request:  I have not contributed to any project till now. I am
> interested in contributing to the Kloudbuster project. Please suggest how
> to start and help me in getting up to speed.
>
>
> There is currently no bug backlog in kloudbuster. Since we use it quite a
> lot, every issue we run into is fixed pretty quickly but it is likely there
> are uncovered issues when run in a different environment.
> There are also obviously many feature enhancements of any size but we only
> add when there is an ask as we want to keep the code small (do one thing
> but do it well).
> If you use it and find a bug or need some enhancement, you're welcome to
> contribute and we can help root cause and fix.
> Have you been looking for traffic generation for any particular purpose?
> We use it for testing our openstack data plane at scale (and storage now).
>
> Regards,
>
>   Alec
>
>
>
>
> Regards,
> Akshay
>
> On Wed, Apr 6, 2016 at 1:44 PM, Yichen Wang (yicwang) 
> wrote:
>
>> Hi, Akshay,
>>
>>
>>
>> Just curious, how do you find KloudBuster so far? Does it do its job and
>> fit your needs? J
>>
>>
>>
>> Thanks very much!
>>
>>
>>
>> Regards,
>>
>> Yichen
>>
>>
>>
>> *From:* Alec Hothan (ahothan)
>> *Sent:* Tuesday, April 5, 2016 9:54 AM
>> *To:* Akshay Kumar Sanghai ; Yichen Wang
>> (yicwang) 
>> *Cc:* OpenStack List 
>>
>> *Subject:* Re: [openstack-dev] [kloudbuster] authorization failed problem
>>
>>
>>
>>
>>
>> Akshay,
>>
>>
>>
>> Note that version 6 is now released so please use the official image from
>> the OpenStack App Catalog and update your code to latest.
>>
>> The doc has also been updated, you might want to have a look at the new
>> arch section and gallery - those should help you with the questions you had
>> below regarding the scale test staging and traffic flows.
>>
>> http://kloudbuster.readthedocs.org/en/latest/index.html
>>
>>
>>
>> Thanks
>>
>>
>>
>>Alec
>>
>>
>>
>>
>>
>> *From: *Akshay Kumar Sanghai 
>> *Date: *Wednesday, March 30, 2016 at 11:11 AM
>> *To: *"Yichen Wang (yicwang)" 
>> *Cc: *Alec Hothan , OpenStack List <
>> openstack-dev@lists.openstack.org>
>> *Subject: *Re: [openstack-dev] [kloudbuster] authorization failed problem
>>
>>
>>
>> Hi Yichen,
>>
>> Thanks a lot . I will try with v6 and reach out to you for further help.
>>
>>
>>
>> Regards,
>>
>> Akshay
>>
>>
>>
>> On Wed, Mar 30, 2016 at 11:35 PM, Yichen Wang (yicwang) <
>> yicw...@cisco.com> wrote:
>>
>> Hi, Akshay,
>>
>>
>>
>> From the log you attached, the good news is you got KloudBuster installed
>> and running fine! The problem is the image you are using (v5) is outdated
>> for the latest KloudBuster main code. J
>>
>>
>>
>> Normally for every version of KloudBuster, it needs certain version of
>> image to support the full functionality. In the case when new feature is
>> brought in, we tag the main code with a new version, and bump up the image
>> version. Like from v5 to v6, we added the capability to support storage
>> testing on cinder volume and ephemeral disks as well. We are right in our
>> time for publishing the v6 image to the OpenStack App Catalog, which may
>> take another day or two. This is why you are seeing the connection to the
>> redis agent in KB-Proxy is failing…
>>
>>
>>
>> In order to unblock you, here is the R

Re: [openstack-dev] [oslo] RPC call not appearing to retry

[Eric K]

On 8/16/16, 9:28 AM, "Mehdi Abaakouk"  wrote:

>Hi,
>
>Le 2016-08-15 04:50, Eric K a écrit :
>> Hi all, I'm running into an issue with oslo-messaging PRC call not
>> appearing to retry. If I do oslo_messaging.RPCClient(transport, target,
>> timeout=5, retry=10).call(self.context, method, **kwargs) using a topic
>> with no listeners, I consistently get the MessagingTimeout exception in
>> 5
>> seconds, with no apparent retry attempt. Any tips on whether this is a
>> user error or a bug or a feature? Thanks so much!
>
>About retry, from 
>http://docs.openstack.org/developer/oslo.messaging/rpcclient.html:
>
>"By default, cast() and call() will block until the message is
>successfully sent. However, the retry parameter can be used to have
>message sending fail with a MessageDeliveryFailure after the given
>number of retries."
>
>It looks like it retries in case of MessageDeliveryFailure not
>MessagingTimeout.
>
>Cheers,
>
>-- 
>Mehdi Abaakouk
>mail: sil...@sileht.net
>irc: sileht

Thank you, Mehdi! I¹ll assume that going forward.

>From the way the doc is worded and from the example that followed, it
sounded like setting the retry parameter changes the eventual exception
thrown after the retries are exhausted, not that it retries on that
exception.
"the retry parameter can be used to have message sending fail with a
MessageDeliveryFailure after the given number of retries."

I wonder what the true intended behavior is. Thanks again!

Cheers,

Eric



__
OpenStack Development Mailing 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] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

[Steven Dake (stdake)]

Kolla core reviewers,

I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day 
review stats [1] place him in the middle of the pack for reviewers and his 60 
day stats[2] are about equivalent.  Dave participates heavily in IRC and has 
done some good technical work including the Watcher playbook and container.  He 
also worked on Sensu, but since we are unclear if we are choosing Sensu or Tig, 
that work is on hold.  He will also be helping us sort out how to execute with 
PBR going into the future on our stable and master branches.  Dave has proven 
to me his reviews are well thought out and he understands the Kolla 
Architecture.  Dave is part time like many Kolla core reviewers and is 
independent of any particular affiliation.

Consider this nomination as a +1 from me.

As a reminder, a +1 vote indicates you approve of the candidate, an abstain 
vote indicates you don't care or don't know for certain, and a –1 vote 
indicates a veto.  If a veto occurs or a unanimous response is reached prior to 
our 7 day voting window which concludes on August 30th, voting will be closed 
early.

[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] [tripleo] puppet-syntax jobs are currently broken

[Emilien Macchi]

Hi,

TripleO CI is currently failing on puppet-syntax jobs, this is due to
an update in the gems we rely on for testing the Puppet syntax.
The fixes are available for review:
https://review.openstack.org/#/q/status:open++topic:puppetlabs_spec_helper/pin

It's a temporary fix, until we sort things out upstream:
https://tickets.puppetlabs.com/browse/MODULES-3776

We'll need to backport it into stable/liberty and stable/mitaka asap.

Thanks for reviewing it asap!
-- 
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] [searchlight] [glance] Will glance community image sharing make it into Newton?

[Tripp, Travis S]

Hello Glance team,

We’re looking into implementing the Glance Community Image sharing support 
within Searchlight for Newton, but it looks like several patches are 
outstanding. Can you let us know how likely it is that this will land in Newton 
and when you expect them to land?

Thanks,
Travis
__
OpenStack Development Mailing 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] [tacker] Proposing Yong Sheng Gong for Tacker core team

[Stephen Wong]

+1

On Tue, Aug 23, 2016 at 8:55 AM, Sridhar Ramaswamy 
wrote:

> Tackers,
>
> I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong is
> a seasoned OpenStacker and has been contributing to Tacker project since
> Nov 2015 (early Mitaka). He has been the major force in helping Tacker to
> shed its *Neutronisms*. He has low tolerance on unevenness in the code
> base and he fixes them as he goes. Yong also participated in the Enhanced
> Placement Awareness (EPA) blueprint in the Mitaka cycle. For Newton he took
> up himself cleaning up the DB schema and in numerous reviews to keep the
> project going. He has been a dependable member of the Tacker community [1].
>
> Please chime in with your +1 / -1 votes.
>
> thanks,
> Sridhar
>
> [1] http://stackalytics.com/report/contribution/tacker/90
>
> __
> OpenStack Development Mailing 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] [tacker] Proposing Yong Sheng Gong for Tacker core team

[Sripriya Seetharam]

+1

Sripriya

From: Sridhar Ramaswamy 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, August 23, 2016 at 8:55 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core team

Tackers,

I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong is a 
seasoned OpenStacker and has been contributing to Tacker project since Nov 2015 
(early Mitaka). He has been the major force in helping Tacker to shed its 
Neutronisms. He has low tolerance on unevenness in the code base and he fixes 
them as he goes. Yong also participated in the Enhanced Placement Awareness 
(EPA) blueprint in the Mitaka cycle. For Newton he took up himself cleaning up 
the DB schema and in numerous reviews to keep the project going. He has been a 
dependable member of the Tacker community [1].

Please chime in with your +1 / -1 votes.

thanks,
Sridhar

[1] 
http://stackalytics.com/report/contribution/tacker/90
__
OpenStack Development Mailing 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] [tacker] Proposing Yong Sheng Gong for Tacker core team

[bharath thiruveedula]

+1
From: jankih...@gmail.com
Date: Tue, 23 Aug 2016 22:37:09 +0530
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core 
team

+1

On 23-Aug-2016 10:36 pm, "HADDLETON, Robert W (Bob)"  
wrote:

  

  
  
+1

  

  On 8/23/2016 10:55 AM, Sridhar Ramaswamy wrote:



  
  
Tackers,





I'd like to
  propose Yong Sheng Gong to join the Tacker core team. Yong is
  a seasoned OpenStacker and has been contributing to Tacker
  project since Nov 2015 (early Mitaka). He has been the major
  force in helping Tacker to shed its Neutronisms. He
  has low tolerance on unevenness in the code base and he fixes
  them as he goes. Yong also participated in the Enhanced
  Placement Awareness (EPA) blueprint in the Mitaka cycle. For
  Newton he took up himself cleaning up the DB schema and in
  numerous reviews to keep the project going. He has been a
  dependable member of the Tacker community [1].





Please chime
  in with your +1 / -1 votes.




thanks,

Sridhar




[1] http://stackalytics.com/report/contribution/tacker/90
  
  

  
  

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




  


__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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




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

Re: [openstack-dev] [neutron] Let's clean up APi reference

[Boden Russell]

I probably missed this, but is there a way for out-of-tree plugins that
have extensions to add them to the api-ref?

For example, suppose we wanted to api-ref the extensions in [1].

Thanks

[1] http://goo.gl/cGVXMN


On 8/18/16 6:16 AM, Akihiro Motoki wrote:
> Hi Neutron team,
> 
> As you may know, the OpenStack API references have been moved into
> individual project repositories, but it contains a lot of wrong
> information now :-(
> 
> Let's clean up API reference.
> It's now time to start the clean up and finish the cleanup by Newton-1.
> 
> I prepared the etherpad page to share the guideline of the cleanup and
> useful information.
> This page shares my experience of 'router' resource cleanup.
> 
> https://etherpad.openstack.org/p/neutron-api-ref-sprint
> 
> I hope everyone work on at least one resource :)
> The etherpad page has the progress tracking section (bottom of the page)
> Make sure to add your name when you start to work.
> 
> Feel free to ask me if you have a question.
> 
> Thanks,
> Akihiro
> 
> __
> OpenStack Development Mailing 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] [puppet] weekly meeting #91

[Iury Gregory]

No topic/discussion in our agenda, we cancelled the meeting, see you next
week!



2016-08-22 16:19 GMT-03:00 Iury Gregory :

> Hi Puppeteers!
>
> We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4
>
> Here's a first agenda:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160823
>
> Feel free to add topics, and any outstanding bug and patch.
>
> See you tomorrow!
> Thanks,
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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

Re: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core team

[Janki Chhatbar]

+1

On 23-Aug-2016 10:36 pm, "HADDLETON, Robert W (Bob)" <
bob.haddle...@nokia.com> wrote:

> +1
>
> On 8/23/2016 10:55 AM, Sridhar Ramaswamy wrote:
>
> Tackers,
>
> I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong is
> a seasoned OpenStacker and has been contributing to Tacker project since
> Nov 2015 (early Mitaka). He has been the major force in helping Tacker to
> shed its *Neutronisms*. He has low tolerance on unevenness in the code
> base and he fixes them as he goes. Yong also participated in the Enhanced
> Placement Awareness (EPA) blueprint in the Mitaka cycle. For Newton he took
> up himself cleaning up the DB schema and in numerous reviews to keep the
> project going. He has been a dependable member of the Tacker community [1].
>
> Please chime in with your +1 / -1 votes.
>
> thanks,
> Sridhar
>
> [1] http://stackalytics.com/report/contribution/tacker/90
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core team

[HADDLETON, Robert W (Bob)]

+1

On 8/23/2016 10:55 AM, Sridhar Ramaswamy wrote:

Tackers,

I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong 
is a seasoned OpenStacker and has been contributing to Tacker project 
since Nov 2015 (early Mitaka). He has been the major force in helping 
Tacker to shed its /Neutronisms/. He has low tolerance on unevenness 
in the code base and he fixes them as he goes. Yong also participated 
in the Enhanced Placement Awareness (EPA) blueprint in the Mitaka 
cycle. For Newton he took up himself cleaning up the DB schema and in 
numerous reviews to keep the project going. He has been a dependable 
member of the Tacker community [1].


Please chime in with your +1 / -1 votes.

thanks,
Sridhar

[1] http://stackalytics.com/report/contribution/tacker/90


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


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

Re: [openstack-dev] [neutron][flavor][lbaas]Running neutron flavor commands using cli

[Evgeny Fedoruk]

Hi Ahana,

Neutron Flavors, as it is now, is just an initial implementation with no 
scheduling or meta templating implemented.
The flavor actually has its identifiers ena/dis, and service type it belongs to.
The flavor profile has identifiers, driver FQN, ena/dis and metainfo (which has 
no implementation right now)
There is also a table binding those two entities.

When LB is created with flavor but not with a provider, LBaaS plugin is 
requesting neutron's flavor plugin to get the provider while supplying flavor 
id.
Then, neutron's flavor plugin gets the first suitable provider.  No scheduling 
is in place yet.

Driver has no chance to know which flavor or service profile was used to invoke 
it.

In past, I used the flavors extension in past and succeeded to create LB while 
specifying flavor in. Can try to help you with this.

In order to make the current flavors plugin useful before flavors templating 
and meta are in place,
I pushed this change, so driver will be able to get its provider meta info when 
needed.
https://review.openstack.org/#/c/318153
It's just a neutron side of the work, I'm planning to  push the LBaaS side 
soon, which will show how it can be used
And also a driver code which uses it.

Regarding the full implementation of flavors and its usage in LBaaS, the RST is 
here  
https://github.com/openstack/neutron-specs/blob/master/specs/mitaka/neutron-flavor-framework-templates.rst

I plan to implement it or part of it, but have some conceptual questions on the 
RST

Regards,
Evgeny


From: Ahana Ghosh [mailto:ahana.gh...@citrix.com]
Sent: Tuesday, August 23, 2016 6:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][flavor][lbaas]Running neutron flavor 
commands using cli

Hi,

We have a few questions regarding using flavor support in Mitaka-

* We are trying to setup 3 flavors which can be used by LBaaS users 
during Loadbalancer creation. All of the 3 flavours will point to the same 
provider/driver. The driver should be able to understand which flavour was used 
for loadbalancer creation. Can this be done?

* Unfortunately I am stuck in the first step itself. I have enabled 
"flavour" extension in neutron.conf. As an admin I am unable to create & list 
flavours. I am getting a 404 error when I do "" command.

* Could you give me an idea as to when neutron flavors will be fully 
implemented?

Regards,
Ahana


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.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] [new][keystone] keystoneauth1 2.12.0 release (newton)

[no-reply]

We are mirthful to announce the release of:

keystoneauth1 2.12.0: Authentication Library for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

2.12.0
^^

HTTP connections work under Windows Subsystem for Linux


Bug Fixes
*

* [bug 1614688
  (https://bugs.launchpad.net/keystoneauth/+bug/1614688)] HTTP
  connections were failing under Windows subsystem for Linux because
  TCP_KEEPCNT was being set and that environment does not support such
  override yet.

Changes in keystoneauth1 2.11.1..2.12.0
---

e3009ab Disables TCP_KEEPCNT when using Windows Subsystem for Linux
fee1f8b Updated from global requirements
fe7ea40 Allow identity plugins to discover relative version urls
acbd414 Update the home-page in setup.cfg


Diffstat (except docs and test files)
-

keystoneauth1/_utils.py|  8 +++
keystoneauth1/identity/base.py | 10 ++-
keystoneauth1/session.py   |  4 +-
.../notes/bug-1614688-c4a1bd54f4ba5644.yaml|  9 +++
setup.cfg  |  2 +-
test-requirements.txt  |  2 +-
8 files changed, 124 insertions(+), 7 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 8568319..adc760a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ flake8-docstrings==0.2.1.post1 # MIT
-bandit>=1.0.1 # Apache-2.0
+bandit>=1.1.0 # Apache-2.0



__
OpenStack Development Mailing 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] [tacker] Proposing Yong Sheng Gong for Tacker core team

[Sridhar Ramaswamy]

 Tackers,

I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong is a
seasoned OpenStacker and has been contributing to Tacker project since Nov
2015 (early Mitaka). He has been the major force in helping Tacker to shed
its *Neutronisms*. He has low tolerance on unevenness in the code base and
he fixes them as he goes. Yong also participated in the Enhanced Placement
Awareness (EPA) blueprint in the Mitaka cycle. For Newton he took up
himself cleaning up the DB schema and in numerous reviews to keep the
project going. He has been a dependable member of the Tacker community [1].

Please chime in with your +1 / -1 votes.

thanks,
Sridhar

[1] http://stackalytics.com/report/contribution/tacker/90
__
OpenStack Development Mailing 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][flavor][lbaas]Running neutron flavor commands using cli

[Ahana Ghosh]

Hi,

We have a few questions regarding using flavor support in Mitaka-

* We are trying to setup 3 flavors which can be used by LBaaS users 
during Loadbalancer creation. All of the 3 flavours will point to the same 
provider/driver. The driver should be able to understand which flavour was used 
for loadbalancer creation. Can this be done?

* Unfortunately I am stuck in the first step itself. I have enabled 
"flavour" extension in neutron.conf. As an admin I am unable to create & list 
flavours. I am getting a 404 error when I do "" command.

* Could you give me an idea as to when neutron flavors will be fully 
implemented?

Regards,
Ahana

__
OpenStack Development Mailing 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] [lbaas][flavor]Using flavor framework in Mitaka

[Evgeny Fedoruk]

Hi Ahana,

Neutron Flavors, as it is now, is just an initial implementation with no 
scheduling or meta templating implemented.
The flavor actually has its identifiers ena/dis, and service type it belongs to.
The flavor profile has identifiers, driver FQN, ena/dis and metainfo (which has 
no implementation right now)
There is also a table binding those two entities.

When LB is created with flavor but not with a provider, LBaaS plugin is 
requesting neutron's flavor plugin to get the provider while supplying flavor 
id.
Then, neutron's flavor plugin gets the first suitable provider.  No scheduling 
is in place yet.

Driver has no chance to know which flavor or service profile was used to invoke 
it.

In past, I used the flavors extension in past and succeeded to create LB while 
specifying flavor in. Can try to help you with this.

In order to make the current flavors plugin useful before flavors templating 
and meta are in place,
I pushed this change, so driver will be able to get its provider meta info when 
needed.
https://review.openstack.org/#/c/318153
It's just a neutron side of the work, I'm planning to  push the LBaaS side 
soon, which will show how it can be used
And also a driver code which uses it.

Regards,
Evgeny


From: Ahana Ghosh [mailto:ahana.gh...@citrix.com]
Sent: Monday, August 22, 2016 8:28 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [lbaas][flavor]Using flavor framework in Mitaka

Hi,

We have a few questions regarding using flavor support in Mitaka-

* We are trying to setup 3 flavors which can be used by LBaaS users 
during Loadbalancer creation. All of the 3 flavours will point to the same 
provider/driver. The driver should be able to understand which flavour was used 
for loadbalancer creation. Can this be done?

* Unfortunately I am stuck in the first step itself. I have enabled 
"flavour" extension in neutron.conf. As an admin I am unable to create & list 
flavours. I am getting a 404 error when I do "" command. Could someone 
please help me resolve this issue?

* If the same flavour is being supported by different service 
providers, will the tenant be unaware about which service provider is providing 
LBAAS service as the admin uses a scheduling algorithm to use LBAAS service 
provided by different service providers for a single flavour?

* What is the difference between a flavor and a flavor profile?

Regards,
Ahana



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.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] [tripleo] release reminder

[Emilien Macchi]

This is a quick release update:

- We're currently R-6, "Final release for non-client libraries".
- Next week will be R-5, "Feature freeze" and "newton-3 milestone".
We'll proceed to a TripleO b3 release. If you need FFE, please submit
it using ML.
- Official Newton release for TripleO will be Oct 17-21 week (2 weeks
trailing release).

If you need more informations about Newton release management, please look:
https://releases.openstack.org/newton/schedule.html

Also, Doug is currently working on Ocata release schedule, please have a look:
https://review.openstack.org/#/c/357214/ (you'll notice the release
cadence is a bit different).

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] [kolla] Kolla configuration files owner and permission

[Steven Dake (stdake)]

On 8/23/16, 7:05 AM, "Gerard Braad"  wrote:

>On Tue, Aug 23, 2016 at 9:56 PM, lương hữu tuấn  wrote:
>> I also prefer a dedicated user ("kolla" seems the best choice) as same > On 
>> Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke  wrote:
>>> In my experience operators prefer a dedicated user (kolla:kolla), though I
>
>kolla:kolla seems more logical and simpler to reason about.
>

kolla:kolla still works with multi-user approach and permissions 660 on 
/etc/kolla files.

Regards
-steve

>
>-- 
>
>   Gerard Braad | http://gbraad.nl
>   [ Doing Open Source Matters ]
>
>__
>OpenStack Development Mailing 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] [new][documentation] openstackdocstheme 1.5.0 release

[no-reply]

We are enthusiastic to announce the release of:

openstackdocstheme 1.5.0: OpenStack Docs Theme

With source available at:

http://git.openstack.org/cgit/openstack/openstackdocstheme

Please report issues through launchpad:

http://bugs.launchpad.net/openstack-manuals

For more details, please see below.

1.5.0
^

Adds a theme variable, "sidebar_dropdown" to configure the display of
the new API sidebar dropdown menu.


New Features


* The automatic table of contents that appears in the body of the
  documentation can be disabled by setting "display_toc" to "False" in
  the "html_theme_options" option in "conf.py".

  For example:

 html_theme_options = {
  "display_toc": False,
 }

* Adds the option to configure the display of a sidebar dropdown
  menu for published API References and Guides. In conf.py, set the
  theme variable, "html_theme_options" to include the parameter,
  "sidebar_dropdown" as "api_ref". For example:

 html_theme_options = {
  "sidebar_dropdown": "api_ref",
   }

  The extensions parameter should include the sphinx extension,
  "os_api_ref".

 extensions = [
 'os_api_ref',
 ]

* Publishes an API Reference demo which is integrated with the API
  sidebar dropdown menu.

Changes in openstackdocstheme 1.4.0..1.5.0
--

4714998 API References dropdown menu
5907244 Allow automatic toc to be disabled


Diffstat (except docs and test files)
-

.gitignore |   1 +
api-ref/source/_static/css/README.md   |   5 +
api-ref/source/conf.py | 173 +
api-ref/source/index.rst   |   9 ++
api-ref/source/parameters.yaml |  24 +++
api-ref/source/service.inc | 165 
api-ref/source/update-server-resp.json |   5 +
openstackdocstheme/theme/openstackdocs/js.html |   4 +-
.../theme/openstackdocs/localtoc.html  |   4 +-
.../theme/openstackdocs/sidebartoc.html|  23 +--
.../theme/openstackdocs/sidebartoc_menu.html   |  17 ++
.../openstackdocs/sidebartoc_menu_apiref.html  |  19 +++
openstackdocstheme/theme/openstackdocs/theme.conf  |   2 +
...low-disabling-toc-in-body-d98d3a6e633fa28e.yaml |  14 ++
.../sidebar_dropdown_apiref-993b4dba4c0369f6.yaml  |  29 
test-requirements.txt  |   2 +
tox.ini|  15 +-
18 files changed, 496 insertions(+), 26 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 1abb102..1ec5a83 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10,0 +11,2 @@ reno>=1.8.0 # Apache2
+
+os-api-ref>=0.4.0 # Apache-2.0



__
OpenStack Development Mailing 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] [new][keystone] keystonemiddleware 4.9.0 release (newton)

[no-reply]

We are psyched to announce the release of:

keystonemiddleware 4.9.0: Middleware for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystonemiddleware

With package available at:

https://pypi.python.org/pypi/keystonemiddleware

Please report issues through launchpad:

http://bugs.launchpad.net/keystonemiddleware

For more details, please see below.

Changes in keystonemiddleware 4.8.0..4.9.0
--

d4b0be8 Updated from global requirements
1686c4f Updated from global requirements
7ba3677 Updated from global requirements
7dd636e Updated from global requirements
d0716d2 Use AccessInfo in UserAuthPlugin instead of custom


Diffstat (except docs and test files)
-

keystonemiddleware/auth_token/__init__.py  |   7 +-
keystonemiddleware/auth_token/_user_plugin.py  | 187 ++---
requirements.txt   |   6 +-
test-requirements.txt  |   2 +-
5 files changed, 21 insertions(+), 185 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 73679d9..2bf8572 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6,2 +6,2 @@ keystoneauth1>=2.10.0 # Apache-2.0
-oslo.config>=3.12.0 # Apache-2.0
-oslo.context!=2.6.0,>=2.4.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0
+oslo.context>=2.6.0 # Apache-2.0
@@ -14 +14 @@ pycadf!=2.0.0,>=1.1.0 # Apache-2.0
-python-keystoneclient!=1.8.0,!=2.1.0,>=1.7.0 # Apache-2.0
+python-keystoneclient!=2.1.0,>=2.0.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 526cea2..97b9086 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -24 +24 @@ python-memcached>=1.56 # PSF
-bandit>=1.0.1 # Apache-2.0
+bandit>=1.1.0 # Apache-2.0



__
OpenStack Development Mailing 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] Weekly meeting Aug 23

[Emilien Macchi]

Hi,

We did our weekly meeting and you can read the notes here:
http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-08-23-14.00.html

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] [ironic] Driver removal policies - should we make it softer?

[Vladyslav Drok]

On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby  wrote:

> Hi,
>
>
>
> I admit, I didn't read the entire thread [0], but did read the summary
> [1]. I like this, except that I'm not sure about #3. What's the rationale
> of adding a new config option 'enable_unsupported_drivers' that defaults to
> False. Versus not having it, and "just" logging a warning if they are
> loading an unsupported (in-tree) driver?
>
>
>
> If I understand this...
>
>
>
> If we have 'enable_unsupported_drivers': since it defaults to False, the
> conductor will fail on startup, if an unsupported driver is in the
> enabled_drivers config. (The conductor will emit a warning in the logs, or
> maybe it won't?) The operator (if they haven't changed it), will now change
> it to True if they want to use any unsupported drivers. The conductor will
> start up and emit a warning in the logs.
>
>
>
> If we don't have an enable_unsupported_drivers config, will the conductor
> start up and emit a warning in the logs?
>

We have not added any deprecation warnings to drivers. I think that just
gives a bit more time to switch to other drivers and it will make the
removal more visible, as the current spec states: "Third party driver teams
that do not implement a reliable reporting CI test system by the N release
feature freeze (see Deliverable milestones above) will be removed from the
ironic source tree.", IIUC meaning that conductor will fail startup not
being able to find the removed code.


>
>
> I was also wondering, where is the value for the 'supported' flag for each
> driver going to be kept? Hard-coded in the driver code?
>

Yep, seems like it.


>
>
> --ruby
>
>
>
>
>
> On 2016-08-19, 10:15 AM, "Jim Rollenhagen"  wrote:
>
>
>
> Hi Ironickers,
>
>
>
> There was a big thread here[0] about Cinder, driver removal, and standard
>
> deprecation policy. If you haven't read through it yet, please do before
>
> continuing here. :)
>
>
>
> The outcome of that thread is summarized well here.[1]
>
>
>
> I know that I previously had a different opinion on this, but I think we
>
> should go roughly the same route, for the sake of the users.
>
>
>
> 1) A ``supported`` flag for each driver that is True if and only if the
> driver
>
>is tested in infra or third-party CI (and meets our third party CI
>
>requirements).
>
> 2) If the supported flag is False for a driver, deprecation is implied (and
>
>a warning is emitted at load time). A driver may be removed per standard
>
>deprecation policies, with turning the supported flag False to start the
>
>clock.
>
> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>
>drivers marked supported=False. If a driver is in enabled_drivers, has
>
>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>
>will fail to start. Setting enable_unsupported_drivers=True will allow
>
>ironic-conductor to start with warnings emitted.
>
>
>
> It is important to note that (3) does still technically break the standard
>
> deprecation policy (old config may not work with new version of ironic).
>
> However, this is a much softer landing than the original plan. FWIW, I do
>
> expect (but not hope!) this part will be somewhat contentious.
>
>
>
> I'd like to hear thoughts and get consensus on this from the rest of the
>
> ironic community, so please do reply whether you agree or disagree.
>
>
>
> I'm happy to do the work required (update spec, code patches, doc updates)
>
> when we do come to agreement.
>
>
>
> // jim
>
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101428.html
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101898.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
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

[Znoinski, Waldemar]

We’ll disable testing on nova stable/liberty till I have a moment to look into 
the problem(s) properly – should happen in next few days.
CI had some trouble on stable/mitaka for a moment couple of weeks back but it’s 
fixed since.

From: Znoinski, Waldemar
Sent: Monday, August 22, 2016 9:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: RE: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

I’ll have a look.

From: Timofei Durakov [mailto:tdura...@mirantis.com]
Sent: Monday, August 22, 2016 8:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

Hi everyone,

got a question on that Intel NFV CI: has statistics for stable branches been 
checked either?
I have a patch to stable/liberty [1] that failed on all Intel NFV CI jobs 2 
times in a row. Who could help me to figure out the root cause for that?

Thanks in advance,
Timofey.

[1] - https://review.openstack.org/#/c/358439/

On Mon, Aug 8, 2016 at 6:27 PM, Ptacek, MichalX 
mailto:michalx.pta...@intel.com>> wrote:
Change deployed,
Thanks for your comments,

Michal

-Original Message-
From: Markus Zoeller 
[mailto:mzoel...@linux.vnet.ibm.com]
Sent: Monday, August 08, 2016 3:15 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting permission

On 03.08.2016 22:02, Znoinski, Waldemar wrote:
> Thanks
> Much appreciated
>
> Making use of the opportunity here... what's the next big thing a CI
> (like one testing NFV) should be doing? (multinode or there's
> something else more important?)

Two tiny nits on the comment the CI is giving a change:

"Build failed (check pipeline). To recheck leave a comment with
intel-nfv-ci recheck. For more info go to
https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-NFV-CI.";

1) Could you put the recheck command in quotation? Like:
   To recheck leave a comment with 'intel-nfv-ci recheck'.
2) The link to the wiki seems to be wrong (hyphen vs. underscore):
   https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI

--
Regards, Markus Zoeller (markus_z)

>  >-Original Message-
>  >From: Matt Riedemann 
> [mailto:mrie...@linux.vnet.ibm.com]
>  >Sent: Wednesday, August 3, 2016 8:28 PM
>  >To: 
> openstack-dev@lists.openstack.org
>  >Subject: Re: [openstack-dev] [nova] [infra] Intel NFV CI voting
> permission  >  >On 8/3/2016 8:18 AM, Znoinski, Waldemar wrote:
>  >> [WZ] Hi Matt, do we need, a Gerrit-style, +2 on that from someone?
>  >> Infra Team doesn't keep these settings in their puppet/config
> files on git -  >all the Gerrit changes are done via Gerrit GUI so
> they rely on Cores to add CIs  >to the appropriate ci group, nova-ci in this 
> case.
>  >>
>  >>
>  >
>  >Sorry, I wasn't sure what the next step here was, I guess it was the
> nova-ci  >membership change, which is done now:
>  >
>  >https://review.openstack.org/#/admin/groups/511,members
>  >
>  >--
>  >
>  >Thanks,
>  >
>  >Matt Riedemann
>  >
>  >
>  >__
>  >
>  >OpenStack Development Mailing List (not for usage questions)
>  >Unsubscribe: OpenStack-dev-
>  
> >requ...@lists.openstack.org?subject:unsubscribe
>  >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Intel Research and Development Ireland Limited Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County
> Kildare Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Intel Research and Development Ireland Limited
Registered in Ireland
Reg

Re: [openstack-dev] [kolla] Kolla configuration files owner and permission

[Gerard Braad]

On Tue, Aug 23, 2016 at 9:56 PM, lương hữu tuấn  wrote:
> I also prefer a dedicated user ("kolla" seems the best choice) as same > On 
> Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke  wrote:
>> In my experience operators prefer a dedicated user (kolla:kolla), though I

kolla:kolla seems more logical and simpler to reason about.


-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]

__
OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission

[lương hữu tuấn]

I also prefer a dedicated user ("kolla" seems the best choice) as same as
other projects in OpenStack.

Cheers,

Tuan

On Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke  wrote:

> In my experience operators prefer a dedicated user (kolla:kolla), though I
> can't see any major problem with your root:kolla approach.
>
>
> On 23/08/16 14:40, Steven Dake (stdake) wrote:
>
>>
>>
>>
>>
>>
>> On 8/23/16, 1:04 AM, "duon...@vn.fujitsu.com" 
>> wrote:
>>
>> Hi S.Dake,
>>>
>>> Hello Kollish,
>
> I am working on bp ansible-specific-task-become so I need community
> opinion about Kolla configuration files owner and permissions.
>
> For files in "/var/lib/kolla", it's quite clear that the owner should
> be 'root' as currently.
>
> For files in "/etc/kolla":  After discussion with S.Dake on IRC, he
> recommends /etc/kolla is owned by root and all files in it is 660 
> (writable
> by a group).
>

 Just to add a bit of clarity, the rationale for this idea is that a
 group of operators could add themselves to the kolla group on all of the
 nodes and use their specific ssh keys to operate OpenStack.  > This is why
 the group concept in unix was invented 50 odd years ago ;)

>>>
>>> I just notice that if the directory has 660, so non-root user cannot
>>> access file in this folder. It seems conflict with group purpose.
>>> Should it be 770 for folders?
>>>
>>
>> Yes 770 for folders 660 for files seeded by the user ids and their ssh
>> keys in the host playbook that is in the review queue.  Changes to the host
>> playbook in the review queue should come later for this group based model.
>>
>> The real question is what do operators prefer?  Single user (non-root),
>> Multi-user (non-root), or Single user (root).
>>
>> Regards
>> -steve
>>
>>>
>>> Regards
 -steve

>>>
>>>
>>> Best regards,
>>>
>>> duonghq
>>> PODC - Fujitsu Vietnam Ltd.
>>>
>>>
>>>
>>> 
>>> __
>>> 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
>
__
OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission

[Paul Bourke]

In my experience operators prefer a dedicated user (kolla:kolla), though 
I can't see any major problem with your root:kolla approach.


On 23/08/16 14:40, Steven Dake (stdake) wrote:






On 8/23/16, 1:04 AM, "duon...@vn.fujitsu.com"  wrote:


Hi S.Dake,


Hello Kollish,

I am working on bp ansible-specific-task-become so I need community opinion 
about Kolla configuration files owner and permissions.

For files in "/var/lib/kolla", it's quite clear that the owner should be 'root' 
as currently.

For files in "/etc/kolla":  After discussion with S.Dake on IRC, he recommends 
/etc/kolla is owned by root and all files in it is 660 (writable by a group).


Just to add a bit of clarity, the rationale for this idea is that a group of 
operators could add themselves to the kolla group on all of the nodes and use 
their specific ssh keys to operate OpenStack.  > This is why the group concept 
in unix was invented 50 odd years ago ;)


I just notice that if the directory has 660, so non-root user cannot access 
file in this folder. It seems conflict with group purpose.
Should it be 770 for folders?


Yes 770 for folders 660 for files seeded by the user ids and their ssh keys in 
the host playbook that is in the review queue.  Changes to the host playbook in 
the review queue should come later for this group based model.

The real question is what do operators prefer?  Single user (non-root), 
Multi-user (non-root), or Single user (root).

Regards
-steve



Regards
-steve



Best regards,

duonghq
PODC - Fujitsu Vietnam Ltd.



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

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



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

Re: [openstack-dev] [kolla] Kolla configuration files owner and permission

[Steven Dake (stdake)]

On 8/23/16, 1:04 AM, "duon...@vn.fujitsu.com"  wrote:

>Hi S.Dake,
>
>>> Hello Kollish,
>>>
>>> I am working on bp ansible-specific-task-become so I need community opinion 
>>> about Kolla configuration files owner and permissions.
>>>
>>> For files in "/var/lib/kolla", it's quite clear that the owner should be 
>>> 'root' as currently.
>>>
>>> For files in "/etc/kolla":  After discussion with S.Dake on IRC, he 
>>> recommends /etc/kolla is owned by root and all files in it is 660 (writable 
>>> by a group).
>>
>> Just to add a bit of clarity, the rationale for this idea is that a group of 
>> operators could add themselves to the kolla group on all of the nodes and 
>> use their specific ssh keys to operate OpenStack.  > This is why the group 
>> concept in unix was invented 50 odd years ago ;)
>
>I just notice that if the directory has 660, so non-root user cannot access 
>file in this folder. It seems conflict with group purpose.
>Should it be 770 for folders?

Yes 770 for folders 660 for files seeded by the user ids and their ssh keys in 
the host playbook that is in the review queue.  Changes to the host playbook in 
the review queue should come later for this group based model.

The real question is what do operators prefer?  Single user (non-root), 
Multi-user (non-root), or Single user (root).

Regards
-steve
>
>> Regards
>> -steve
>
>
>Best regards,
>
>duonghq
>PODC - Fujitsu Vietnam Ltd.
>
>
>
>__
>OpenStack Development Mailing 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] [murano] Separating guides from murano developers documentation

[Andreas Jaeger]

On 2016-08-23 14:55, Kirill Zaitsev wrote:
> It’s always hard to chip away from your code, even from documentation
> =))) But if that is the way most OpenStack projects do and if it would
> make our install docs more visible — I agree with the idea.

Then start with INstall docs: Those are still part of your tree but
published in central place, see
http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html
http://docs.openstack.org/contributor-guide/project-install-guide.html

Draft combined guide is at
http://docs.openstack.org/project-install-guide/draft/index.html

Andreas

> -- 
> Kirill Zaitsev
> Murano Project Tech Lead
> Software Engineer at
> Mirantis, Inc
> 
> On 16 août 2016 at 23:19:39, Serg Melikyan (smelik...@mirantis.com
> ) wrote:
> 
>> Hi folks,
>>
>> at this moment all murano documentation (including admin & user
>> guides) is published only in one place [0], but actually all other
>> projects store there only developer documentation and guides are
>> separated. I propose to follow same model with murano documentation.
>> What do you think?
>>
>> References:
>> [0] docs.openstack.org/developer/murano/
>>
>> -- 
>> Serg Melikyan, Development Manager at Mirantis, Inc.
>> http://mirantis.com | smelik...@mirantis.com
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

[openstack-dev] [tripleo] Barcelona Design Summit space needs

[Emilien Macchi]

Team,

Thierry sent an email to all PTLs about space needs for next Summit.

Here's what we can have:

* Fishbowl sessions (from Wednesday 4pm to Friday noon)
Our traditional largish rooms organized in fishbowl style, with
advertised session content on the summit schedule for increased external
participation. Ideal for when wider feedback is essential.

* Workroom sessions (from Wednesday 4pm to Friday noon)
Smaller rooms organized in boardroom style, with topic buried in the
session description, in an effort to limit attendance and not overcrowd
the room. Ideal to get work done and prioritize work in small teams.

* Contributors meetup (Friday afternoon)
Half-day session on Friday afternoon to get into the Ocata action while
decisions and plans are still hot, or to finish discussions started
during the week, whatever works for you.

Note:
- Ops summit on Tuesday morning until 4pm
- Cross-project workshops from Tuesday 4pm to Wednesday 4pm

As a reminder, here's what we had for Austin:
Fishbowl slots (Wed-Thu): 2
Workroom slots (Tue-Thu): 3
Contributors meetup (Fri): 1/2

Notes from Thierry:
"We'll have less slots compared to Austin, and new teams to accommodate.
So as a rule of thumb, you should probably require *less* slots than in
Austin. It's also worth noting that the Ocata cycle will be a short
cycle (likely only 15 weeks between the design summit and feature
freeze, including thanksgiving and other end-of-year holidays), so there
is no need to plan too much work."

I created an etherpad for topic ideas, feel free to start thinking about it:
https://etherpad.openstack.org/p/ocata-tripleo

Once we gather some feedback on the topics, shardy or me will contact
Thierry to ask for the fair number of rooms.
Thanks for reading so far,
-- 
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] [murano] Separating guides from murano developers documentation

[Kirill Zaitsev]

It’s always hard to chip away from your code, even from documentation =))) But 
if that is the way most OpenStack projects do and if it would make our install 
docs more visible — I agree with the idea.

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

On 16 août 2016 at 23:19:39, Serg Melikyan (smelik...@mirantis.com) wrote:

Hi folks,  

at this moment all murano documentation (including admin & user  
guides) is published only in one place [0], but actually all other  
projects store there only developer documentation and guides are  
separated. I propose to follow same model with murano documentation.  
What do you think?  

References:  
[0] docs.openstack.org/developer/murano/  

--  
Serg Melikyan, Development Manager at Mirantis, Inc.  
http://mirantis.com | smelik...@mirantis.com  

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


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

Re: [openstack-dev] [TripleO][CI] Memory shortage in HA jobs, please increase it

[Emilien Macchi]

On Fri, Aug 19, 2016 at 10:04 AM, Sagi Shnaidman  wrote:
> Hi, Derek
>
> I suspect Sahara can cause it, it started to run on overcloud since my patch
> was merged: https://review.openstack.org/#/c/352598/
> I don't think it ever ran on jobs, because was either improperly configured
> or disabled. And according to reports it's most memory consuming service on
> overcloud controllers.

I have a patch to disable Sahara by default in upstream CI:
https://review.openstack.org/#/c/352886/

Though it will make upgrades failing because Sahara was installed by
default before.
Should we consider this patch or should I abandon it?

>
> On Fri, Aug 19, 2016 at 12:41 PM, Derek Higgins  wrote:
>>
>> On 19 August 2016 at 00:07, Sagi Shnaidman  wrote:
>> > Hi,
>> >
>> > we have a problem again with not enough memory in HA jobs, all of them
>> > constantly fails in CI: http://status-tripleoci.rhcloud.com/
>>
>> Have we any idea why we need more memory all of a sudden? For months
>> the overcloud nodes have had 5G of RAM, then last week[1] we bumped it
>> too 5.5G now we need it bumped too 6G.
>>
>> If a new service has been added that is needed on the overcloud then
>> bumping to 6G is expected and probably the correct answer but I'd like
>> to see us avoiding blindly increasing the resources each time we see
>> out of memory errors without investigating if there was a regression
>> causing something to start hogging memory.
>>
>> Sorry if it seems like I'm being picky about this (I seem to resist
>> these bumps every time they come up) but there are two good reasons to
>> avoid this if possible
>> o at peak we are currently configured to run 75 simultaneous jobs
>> (although we probably don't reach that at the moment), and each HA job
>> has 5 baremetal nodes so bumping from 5G too 6G increases the amount
>> of RAM ci can use at peak by 375G
>> o When we bump the RAM usage of baremetal nodes from 5G too 6G what
>> we're actually doing is increasing the minimum requirements for
>> developers from 28G(or whatever the number is now) too 32G
>>
>> So before we bump the number can we just check first if its justified,
>> as I've watched this number increase from 2G since we started running
>> tripleo-ci
>>
>> thanks,
>> Derek.
>>
>> [1] - https://review.openstack.org/#/c/353655/
>>
>> > I've created a patch that will increase it[1], but we need to increase
>> > it
>> > right now on rh1.
>> > I can't do it now, because unfortunately I'll not be able to watch this
>> > if
>> > it works and no problems appear.
>> > TripleO CI cloud admins, please increase the memory for baremetal flavor
>> > on
>> > rh1 tomorrow (to 6144?).
>> >
>> > Thanks
>> >
>> > [1] https://review.openstack.org/#/c/357532/
>> > --
>> > Best regards
>> > Sagi Shnaidman
>
>
>
>
> --
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [nova] next notification subteam meeting

[Balázs Gibizer]

Hi, 

The next notification subteam meeting will be held on 2016.08.23 17:00 UTC [1] 
on #openstack-meeting-4.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160823T17

__
OpenStack Development Mailing 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][QoS] Question about QoS bandwidth limit rule

[dongcan ye]

Hi, all

I had tested Neutron QoS function, we can apply the bandwidth limit rule
for instance's port, but router ports are excluded from bandwidth policy.

In Neutron ovs agent, we can see the ovs-vsctl command set
ingress_policing_rate and ingress_policing_burst, instance apply to "qvo"
device, router port apply to "qr" device.

They are both interfaces of OVS, why the bandwidth policy can't take effect
in "qr" device?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][cinder] Live-migration job status update

[Timofei Durakov]

Hello everyone,

As you may notice, gate-tempest-dsvm-multinode-live-migration job became
voting. It tests live-migration against no shared storage environment, and
uses Ubuntu Xenial. List of tests being executed:

   - tempest.api.compute.admin.test_live_migration.LiveBlockMigra
   tionTestJSON.test_live_block_migration
   - tempest.api.compute.admin.test_live_migration.LiveAutoBlockM
   igrationV225TestJSON.test_live_block_migration
   - tempest.api.compute.admin.test_live_migration.LiveBlockMigra
   tionTestJSON.test_live_block_migration_paused
   - tempest.api.compute.admin.test_live_migration.LiveAutoBlockM
   igrationV225TestJSON.test_live_block_migration_paused

test_volume_backed_live_migration is skipped due to [1].

Next step is to re-enable again testing against NFS shared storage for
ephemerals. There is a bug [2] that affects stability and requires
additional research(possible test could be excluded, as it's done now for
[1]). Also, there is a patch [3] in progress that adds testing of serial
consoles and live migration.
After that, the plan is to re-enable Ceph as a backend and consider of
including job for stable branches either.

Also, volunteers for fixing [1](the reason of [cinder] in a list of tags)
and [2] are required. If anyone is interested, you are very welcome to
participate in fixing that 2.

Thanks,
Timofey.

[1] - https://bugs.launchpad.net/nova/+bug/1524898
[2] - https://bugs.launchpad.net/nova/+bug/1590929
[3] - https://review.openstack.org/#/c/347471/
__
OpenStack Development Mailing 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] [new][horizon] XStatic-smart-table 1.4.13.1 release

[no-reply]

We are overjoyed to announce the release of:

XStatic-smart-table 1.4.13.1: Installed /home/jenkins/workspace
/xstatic-angular-smart-table-announce-
release/.eggs/setuptools_scm-1.11.1-py2.7.egg

XStatic-smart-table ---

smart-table javascript library packaged for setuptools (easy_install)
/ pip.

This package is intended to be used by **any** project that needs
these files.

It intentionally does **not** provide any extra code except some
metadata **nor** has any extra requirements. You MAY use some minimal
support code from the XStatic base package, if you like.

You can find more info about the xstatic packaging way in the package
`XStatic`.

For more details, please see below.

Changes in XStatic-smart-table 1.4.13.0..1.4.13.1
-

9a6a776 Correct the entry point file name


Diffstat (except docs and test files)
-

xstatic/pkg/angular_smart_table/__init__.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)




__
OpenStack Development Mailing 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] no nova bugs team meeting today

[Markus Zoeller]

I get dragged into some internal stuff recently and didn't have time to
prepare anything or host the meeting.

One noteworthy thing though, please tag any bug report, which
potentially blocks the RC in a few weeks, with "newton-rc-potential":

https://bugs.launchpad.net/nova/+bugs?field.tag=newton-rc-potential

There's less than 3 weeks left until RC1 target week starts.

-- 
Regards, Markus Zoeller (markus_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

[openstack-dev] [murano][glare] Should we make glare jobs voting

[Kirill Zaitsev]

With 3d milestone and feature freeze just behind the corner and all the talks 
about glare moving to a separate repo/project — I’m wondering if we should make 
our glare-integration jobs voting?

Our gate-tempest-dsvm-murano-glare-backend is pretty stable at this point and 
has helped us find at least 1 legitimate bug in glare integration, while our 
3d-party CI glare jobs are still not running the tests properly and require a 
bit more love before turning them on.
At the same time I’m looking forward to moving to glare api v1.0 and this would 
mean these jobs would have to be re-worked, the moment we switch.

So right now I’m slightly inclined to leave the jobs non-voting and make them 
voting as soon as we switch to glare v1. This would require some discipline 
with not merging the patches, that break glare integration, but would save us 
the hassle of turning the job up and down. But I would also like to ask for 
teams opinion on the matter.

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

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

Re: [openstack-dev] [Fuel] Need Help in adding multiple External networks in Fuel 9.0

[Sergey Vasilenko]

>
> eth0 : Admin ( PXE), Management (101), Storage (102), Internal (1000-1030)
> eth1 : External ( Public )
> eth2 : None
>
> I am using *fuel 9.0* and i want to use provider network / Multiple
> external networks with fuel. i had vlan networks on *eth1* as below
>
> *eth1 : 192.168.200.0/24  ( Native ),
> 192.168.201.0/24  ( Trunk, 201 tagged ).
> 192.168.202.0/24  ( Trunk, 202 tagged )*
>
>
> How i can add other two networks( 201, 202 ) to my cloud as external
> network. appreciate anyone help on this.
>

For creating tagged vlans over external network you should:
1. modify /etc/neutron/plugin.ini to add vlan-range for physnet1, (ex:
network_vlan_ranges
= physnet1:201:202) and restart neutron-server on all controller nodes
2. Create additional floating networks by  Neutron API, ex: neutron
net-create floating201 --tenant-id=8a1d1a6f96db4beeb964a285e2a95413
 --router:external=true --provider:physical_network=physnet1
--provider:network_type=vlan --provider:segmentation_id=201
3. Create subnet for network above (ex: neutron subnet-create xxx1
--name=floating201_subnet --cidr=192.168.201.0/24
--network-id=8859c63e-c8e1-422c-9cda-d3e9d5ab6a20 --enable_dhcp=False
--gateway_ip=192.168.201.1)
4. Create router for handle SNAT:
# neutron router-create router201
--tenant-id=8a1d1a6f96db4beeb964a285e2a95413
# neutron router-gateway-set router201 floating201
# neutron router-interface-add router201 your_internal_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] [all][massively distributed][architecture] Coordination between actions/WGs

[lebre . adrien]

Hi Folks, 

During the last summit, we suggested to create a new working group that deals 
with the massively distributed use case:
How can OpenStack be "slightly" revised to operate Fog/Edge Computing 
infrastructures, i.e. infrastructures composed of several sites. 
The first meeting we did in Austin showed us that additional materials were 
mandatory to better understand the scope as well as the actions we can perform 
in this working group. 

After exchanging with different persons and institutions, we have identified 
several actions that we would like to achieve and that make the creation of 
such a working group relevant from our point of view. 

Among the list of possible actions, we would like to identify major scalability 
issues and clarify intra-site vs inter-site exchanges between the different 
services of OpenStack in a multi-site context (i.e. with the vanilla OpenStack 
code). 
Such information will enable us to better understand how and where each service 
should be deployed and whether it should be revised.  

We have started an action with the Performance WG  with the ultimate goal to 
analyse how OpenStack behaves from the performance aspect as well as the 
interactions between the various services in such a context. 

Meanwhile, we saw during this summer the Clynt's proposal about the 
Architecture WG.

Although we are very exciting about this WG (we are convinced it will be 
valuable for the whole community), we are wondering
whether the  actions we envision in the Massively distributed WG will not 
overlap the ones (scalability, multi-site operations ...) that could be 
performed in the Archictecture WG.

The goal of this email is to : 

(i) understand whether the fog/edge computing use case is in the scope of 
the Architecture WG. 

(ii) if not, whether it makes sense to create a working group that focus on 
scalability and multi-site challenges (Folks from Orange Labs and British 
Telecom for instance already told us that they are interesting by such a 
use-case).

(iii) what is the best way to coordinate our efforts with the actions 
performed in other WGs such as the Performance and Architecture ones (e.g., 
actions performed/decisions taken in the Architecture WG can have impacts on 
the massively distributed WG and thus  drive the way we should perform actions 
to progress to the Fog/Edge Computing target)


According to the feedback, we will create dedicated wiki pages for the 
massively distributed WG. 
Remarks/comments welcome. 

Ad_rien_
Further information regarding the Fog/Edge Computing use-case we target is 
available at http://beyondtheclouds.github.io

__
OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission

[duon...@vn.fujitsu.com]

Hi S.Dake,

>> Hello Kollish,
>>
>> I am working on bp ansible-specific-task-become so I need community opinion 
>> about Kolla configuration files owner and permissions.
>>
>> For files in "/var/lib/kolla", it's quite clear that the owner should be 
>> 'root' as currently.
>>
>> For files in "/etc/kolla":  After discussion with S.Dake on IRC, he 
>> recommends /etc/kolla is owned by root and all files in it is 660 (writable 
>> by a group).
>
> Just to add a bit of clarity, the rationale for this idea is that a group of 
> operators could add themselves to the kolla group on all of the nodes and use 
> their specific ssh keys to operate OpenStack.  > This is why the group 
> concept in unix was invented 50 odd years ago ;)

I just notice that if the directory has 660, so non-root user cannot access 
file in this folder. It seems conflict with group purpose.
Should it be 770 for folders?

> Regards
> -steve


Best regards,

duonghq
PODC - Fujitsu Vietnam Ltd.



__
OpenStack Development Mailing 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][qos]

[Ofer Ben-Yacov]

Hi.

I was asked to look for a solution / develop traffic control component.
The idea is that provider / tenant will be able to enforce rate limit, do
traffic shaping and prioritize traffic from several VMs (policy) - not like
the qos in neutron now which can do this on single VM port.

My initial thought is to do it using SFC to route the traffic to a Traffic
Control service.

Do any of you know if there is some one that currently develop a project
like that for me to join?

If no work is done, do any of you would like to join in developing such
project?

Do you suggestion other than SFC to approach this?

Best Regards,
Ofer Ben-Yacov.
__
OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission

[Tuan Luong]

It indeed makes me frightened when i just stopped at the part of 
"writable by a group" of configuration files and tried myself to figure 
out what you guys discussing on IRC.

Thanks Steve for making clear about "group of operators".

Cheers,

Tuan


On 08/23/2016 07:29 AM, Steven Dake (stdake) wrote:





On 8/22/16, 7:24 PM, "duon...@vn.fujitsu.com"  wrote:


Hello Kollish,

I am working on bp ansible-specific-task-become so I need community opinion 
about Kolla configuration files owner and permissions.

For files in "/var/lib/kolla", it's quite clear that the owner should be 'root' 
as currently.

For files in "/etc/kolla":  After discussion with S.Dake on IRC, he recommends 
/etc/kolla is owned by root and all files in it is 660 (writable by a group).

Just to add a bit of clarity, the rationale for this idea is that a group of 
operators could add themselves to the kolla group on all of the nodes and use 
their specific ssh keys to operate OpenStack.  This is why the group concept in 
unix was invented 50 odd years ago ;)

Regards
-steve


Anybody has idea about this topic?

Best regards,

Ha Quang Duong (Mr.)
PODC - Fujitsu Vietnam Ltd.


__
OpenStack Development Mailing 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