date:20160824

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

2016-08-24 Thread Weyl, Alexey (Nokia - IL)

Hi Yujun,

You can find the names of the lables in the constants.py file.

In addition, the restriction on the physical_static datasource is done in it’s 
driver.py.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, August 25, 2016 4:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi, Ifat,

I searched for edge_labels in the project. It seems it is validated only in 
`vitrage/evaluator/template_validation/template_syntax_validator.py`. Where is 
such restriction applied in static_datasources?

--
Yujun

On Wed, Aug 24, 2016 at 3:19 PM Afek, Ifat (Nokia - IL) 
> wrote:
Hi Yujun,

Indeed, we have some restrictions on the relationship types that can be used in 
the static datasources. I think we should remove these restrictions, and allow 
any kind of relationship type.

Best regards,
Ifat.

From: Yujun Zhang
Date: Monday, 22 August 2016 at 08:37
I'm following the sample configuration in docs [1] to verify how static 
datasources works.

It seems `backup` relationship is not displayed in the entity graph view and 
neither is it included in topology show.

There is an enumeration for edge labels [2]. Should relationship in static 
datasource be limited to it?

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst
[2] 
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L49
__
OpenStack Development Mailing 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] [kloudbuster] test LBAAS at scale

2016-08-24 Thread Akshay Kumar Sanghai

Hi Alec,
Thanks for your inputs. I would really like to develop this feature. I
don't know if i can handle it, but I would try my best. Can you suggest
some pointers on how to start and how can we discuss in detail about the
tasks?

Thanks
Akshay

On Wed, Aug 24, 2016 at 7:37 AM, Alec Hothan (ahothan) 
wrote:

> Hi Akshay,
>
> I suppose you're talking about LBAAS v2?
>
> Adding support for lbaas in kloudbuster will require some amount of work
> which can be kept to a minimum if done properly, this addition would be a
> pretty good way to test lbaas at scale.
> The tricky part is to modify the staging code without breaking the other
> features (multicast and storage) since this staging is specific to HTTP
> scale test.
> The current staging for HTTP scale is based on the following template (I
> show the server side only):
>
> [Router-[HTTP server VM]*]*
>
> The natural extension for supporting LBAAS is to replace each HTTP server
> with a LB group + N HTTP servers:
>
> [Router--[LB---[HTTP server VM]*]*]*
>
> Implementing this would require the following modifications (just a rough
> description of the tasks):
>
>- add an additional config option to specify the number of server VMs
>per LB group (defaults to none/no LB) 
>- if LB is configured, the current config server count would become a
>LB group count
>- the staging code for the HTTP servers needs to be modified to handle
>the case of LB: 
>   - instead of creating as many HTTP servers as the server count
>   argument, create as many LB groups
>   - for each LB group, create the requested HTTP server VMs per group
>   and add them to the group
>- floating IP if requested need to apply to the LB port instead of the
>HTTP servers 
>- naturally the teardown code will have to also support cleaning up LB
>resources 
>
>
>- HTTP clients will need to connect to the LB VIP address (instead of
>the HTTP server IP address) 
>
> I can help you go through these individual tasks in detail in the code if
> you feel you can handle that, it's just python coding.
>
>
> The VMs running the HTTP traffic generators are currently always
> associated 1:1 to a server VM. With the above template extension you will
> end up with as many HTTP client VMs as LB groups:
>
> (removed the router for better clarity):
>
> [HTTP client VM---[LB---[HTTP server VM]*]*]*
>
> This is not ideal because each HTTP traffic generator can only support a
> relatively low number of connections (in the few thousands) while an HTTP
> server instance can easily support many times this load especially for
> light HTTP traffic (i.e. replies that are very short).
>
> So another improvement (which we had on our roadmap) would be to support
> N:1 mapping:
>
> [[HTTP client VM]*LB---[HTTP server VM]*]*]*
>
> this could be a separate extension.
> Let me know if you'd like to do this and we can help navigate the code.
>
> Thanks
>
>Alec
>
>
>
> From: Akshay Kumar Sanghai 
> Date: Tuesday, August 23, 2016 at 2:07 PM
> To: Alec Hothan 
> Cc: "Yichen Wang (yicwang)" , "OpenStack Development
> Mailing List (not for usage questions)"  >
> Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem
>
> 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
>
>
>
__
OpenStack Development Mailing 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] App Catalog IRC meeting Thursday August 25th

2016-08-24 Thread Christopher Aedo

Join us Thursday for our weekly meeting, scheduled for August 25th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Tomorrow we will be talking more about the next steps we will be
taking in implementing GLARE as a back-end for the Community App
Catalog.  We've seen some really rapid progress the last few weeks so
hopefully we'll be flipping the switch soon!

Hope to see you there tomorrow!

__
OpenStack Development Mailing 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] Need more undercloud resources

2016-08-24 Thread Paul Belanger

On Wed, Aug 24, 2016 at 02:11:32PM -0400, James Slagle wrote:
> The latest recurring problem that is failing a lot of the nonha ssl
> jobs in tripleo-ci is:
> 
> https://bugs.launchpad.net/tripleo/+bug/1616144
> tripleo-ci: nonha jobs failing with Unable to establish connection to
> https://192.0.2.2:13004/v1/a90407df1e7f4f80a38a1b1671ced2ff/stacks/overcloud/f9f6f712-8e89-4ea9-a34b-6084dc74b5c1
> 
> This error happens while polling for events from the overcloud stack
> by tripleoclient.
> 
> I can reproduce this error very easily locally by deploying with an
> ssl undercloud with 6GB ram and 2 vcpus. If I don't enable swap,
> something gets OOM killed. If I do enable swap, swap gets used (< 1GB)
> and then I hit this error almost every time.
> 
> The stack keeps deploying but the client has died, so the job fails.
> My investigation so far has only pointed out that it's the swap
> allocation that is delaying things enough to cause the failure.
> 
> We do not see this error in the ha job even though it deploys more
> nodes. As of now, my only suspect is that it's the overhead of the
> initial SSL connections causing the error.
> 
> If I test with 6GB ram and 4 vcpus I can't reproduce the error,
> although much more swap is used due to the increased number of default
> workers for each API service.
> 
> However, I suggest we just raise the undercloud specs in our jobs to
> 8GB ram and 4 vcpus. These seem reasonable to me because those are the
> default specs used by infra in all of their devstack single and
> multinode jobs spawned on all their other cloud providers. Our own
> multinode job for the undercloud/overcloud and undercloud only job are
> running on instances of these sizes.
> 
Close, our current flavors are 8vCPU, 8GB RAM, 80GB HDD. I'd recommend doing
that for the undercloud just to be consistent.

[1] http://docs.openstack.org/infra/system-config/contribute-cloud.html

> Yes, this is just sidestepping the problem by throwing more resources
> at it. The reality is that we do not prioritize working on optimizing
> for speed/performance/resources. We prioritize feature work that
> indirectly (or maybe it's directly?) makes everything slower,
> especially at this point in the development cycle.
> 
> We should therefore expect to have to continue to provide more and
> more resources to our CI jobs until we prioritize optimizing them to
> run with less.
> 
I actually believe these problem highlights how large tripleo-ci has grown, and
in need of a refactor. While we won't solve this problem today, I do think
tripleo-ci is to monolithic today. I believe there is some discussion on
breaking jobs into different scenarios, but I haven't had a chance to read up on
that.

I'm hoping in Barcelona we can have a topic on CI pipelines and how better to
optimize our runs.

> Let me know if there is any disagreement on making these changes. If
> there isn't, I'll apply them in the next day or so. If there are any
> other ideas on how to address this particular bug for some immediate
> short term relief, please let me know.
> 
> -- 
> -- James Slagle
> --
> 
> __
> OpenStack Development Mailing 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] [vitrage] relationship_type in static_datasources

2016-08-24 Thread Yujun Zhang

Hi, Ifat,

I searched for edge_labels in the project. It seems it is validated only in
`vitrage/evaluator/template_validation/template_syntax_validator.py`. Where
is such restriction applied in static_datasources?

--
Yujun

On Wed, Aug 24, 2016 at 3:19 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yujun,
>
> Indeed, we have some restrictions on the relationship types that can be
> used in the static datasources. I think we should remove these
> restrictions, and allow any kind of relationship type.
>
> Best regards,
> Ifat.
>
> From: Yujun Zhang
> Date: Monday, 22 August 2016 at 08:37
>
> I'm following the sample configuration in docs [1] to verify how static
> datasources works.
>
> It seems `backup` relationship is not displayed in the entity graph view
> and neither is it included in topology show.
>
> There is an enumeration for edge labels [2]. Should relationship in static
> datasource be limited to it?
>
> [1]
> https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst
> [2]
> https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L49
>
> __
> OpenStack Development Mailing 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][vote] Core nomination for Dave Walker (Daviey on irc)

2016-08-24 Thread Swapnil Kulkarni

On Aug 24, 2016 2:15 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
>

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

2016-08-24 Thread joehuang

> But v[E]CPE just isn't cloud to me. And trying to morph Nova or other 
> OpenStack services that were designed to run as services in a datacenter 
> just isn't something I feel the OpenStack community needs to be focusing 
> on. Run Nova (or Kubernetes, or Mesos, or any other cloud management 
> platform) in the datacenter. Run a custom software application on the 
> set-top boxes that can communicate with datacenter cloud services. Let's 
> please not commandeer one of them to fit a model it was never built for.

Funny point of view. Let's look at the mission of OpenStack:

"to produce the ubiquitous Open Source Cloud Computing platform that enables
building interoperable public and private clouds regardless of size, by being
simple to implement and massively scalable while serving the cloud users'
needs."

It mentioned that "regardless of size", and you also mentioned "cloud to me:
lots of hardware consolidation".

May we call an edge site which include 10 hardware as a cloud? If 10 is ok, how
about 5 or 3?

>From OpenStack mission, it should be able to run "regardless of size", but 
>from 
your definition, what's the hardware number is the thresshold for OpenStack, 
especially
Nova to run, and so that it could be called a cloud?

I proposed to introduce plugin mechnism in Nova/Cinder API layer, just like 
Neutron
what has been done, so that Nova/Cinder can also run in samll size scenario.

The plugin mechanism can also be used for Tricircle project. During the 
Tricircle
big-tent project application[1], TCs's worried that Nova API-Gateway/Cinder 
API-Gateway
will reimplement some Nova/Cinder API. If Nova/Cinder can provide the plugin 
mechnism
in its API layer like what Neutron did, then innovation can be introduce to 
reach the OpenStack
 mission "regardless of size". 

Just as Jay implied(that's my imaging, forgive me if it's wrong :) ), one 
implementation
to fit all size is impossible.

[1] Tricircle big-tent project application 
https://review.openstack.org/#/c/338796/

Best Regards
Chaoyi Huang (joehuang)

From: Jay Pipes [jaypi...@gmail.com]
Sent: 25 August 2016 8:37
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][massively distributed][architecture] 
Coordination between actions/WGs

On 08/24/2016 04:26 AM, Peter Willis wrote:
> Colleagues,
>
> I'd like to confirm that scalability and multi-site operations are key
> to BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, MEC, IoT, where we
> will have compute highly distributed around the network (from thousands
> to millions of sites). BT would therefore support a Massively
> Distributed WG and/or work on scalability and multi-site operations in
> the Architecture WG.

Love all the TLAs.

I've asked this before to numerous Telco product managers and engineers,
but I've yet to get a solid answer from any of them, so I'll repeat the
question here...

How is vCPE a *cloud* use case?

 From what I understand, the v[E]CPE use case is essentially that Telcos
want to have the set-top boxen/routers that are running cable television
apps (i.e. AT U-verse or Verizon FiOS-like things for US-based
customers) and home networking systems (broadband connectivity to a
local central office or point of presence, etc) be able run on virtual
machines to make deployment and management of new applications easier.
Since all those home routers and set-top boxen are essentially just
Linux boxes, the infrastructure seems to be there to make this a
cost-savings reality for Telcos. [1]

The problem is that that isn't remotely a cloud use case. Or at least,
it doesn't describe what I think of as cloud.

Cloud to me means:

* Lots of hardware consolidated in datacenters for efficiency and
security/management
* Software-as-a-Service interface, meaning the service is driven by
users/tenants (i.e. no IT helpdesk to call to provision something) and
provided over the Internet to a dumb device or browser
* (HTTP) API-driven access to launch compute, storage and network
resources from large pools of those resources

Furthermore, applications written for the cloud (i.e. cloud-native apps)
are built from the ground up to assume and tolerate failure, to be as
close to shared-nothing as possible, to not need to be aware of where
they are running or what particular server they are running on and to
rely on well-defined APIs between (micro-)services.

v[E]CPE describes a purpose-built Telco application that doesn't meet
any of the above definitions of what "cloud" is all about.

vCPE also doesn't look like a cloud-native application either: A single
customer's vCPE software application is not capable of running on more
than one machine at a time (since obviously it's running on the
customer's set-top box or router).

Look, I'm all about designing Nova and other cloud services to function
well in distributed environments where multiple datacenters are running
a single OpenStack deployment spread over many regions.

But

Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?

2016-08-24 Thread Doug Wiegley


> On Mar 23, 2016, at 4:17 PM, Doug Wiegley  
> wrote:
> 
> Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> 
> I’m thinking in this order:
> 
> - remove jenkins jobs
> - wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
> they see this coming before the job breaks)
> - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> - remove v1 code from neutron-lbaas

FYI, all of the above have completed, and the final removal is in the merge 
queue: https://review.openstack.org/#/c/286381/

Mitaka will be the last stable branch with lbaas v1.

Thanks,
doug

> 
> Since newton is now open for commits, this process is going to get started.
> 
> Thanks,
> doug
> 
> 
> 
>> On Mar 8, 2016, at 11:36 AM, Eichberger, German  
>> wrote:
>> 
>> Yes, it’s Database only — though we changed the agent driver in the DB from 
>> V1 to V2 — so if you bring up a V2 with that database it should reschedule 
>> all your load balancers on the V2 agent driver.
>> 
>> German
>> 
>> 
>> 
>> 
>> On 3/8/16, 3:13 AM, "Samuel Bercovici"  wrote:
>> 
>>> So this looks like only a database migration, right?
>>> 
>>> -Original Message-
>>> From: Eichberger, German [mailto:german.eichber...@hpe.com] 
>>> Sent: Tuesday, March 08, 2016 12:28 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
>>> weready?
>>> 
>>> Ok, for what it’s worth we have contributed our migration script: 
>>> https://review.openstack.org/#/c/289595/ — please look at this as a 
>>> starting point and feel free to fix potential problems…
>>> 
>>> Thanks,
>>> German
>>> 
>>> 
>>> 
>>> 
>>> On 3/7/16, 11:00 AM, "Samuel Bercovici"  wrote:
>>> 
 As far as I recall, you can specify the VIP in creating the LB so you will 
 end up with same IPs.
 
 -Original Message-
 From: Eichberger, German [mailto:german.eichber...@hpe.com]
 Sent: Monday, March 07, 2016 8:30 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
 weready?
 
 Hi Sam,
 
 So if you have some 3rd party hardware you only need to change the 
 database (your steps 1-5) since the 3rd party hardware will just keep 
 load balancing…
 
 Now for Kevin’s case with the namespace driver:
 You would need a 6th step to reschedule the loadbalancers with the V2 
 namespace driver — which can be done.
 
 If we want to migrate to Octavia or (from one LB provider to another) it 
 might be better to use the following steps:
 
 1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
 Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
 Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format 
 file into some scripts which recreate the load balancers with your 
 provider of choice —
 
 6. Run those scripts
 
 The problem I see is that we will probably end up with different VIPs 
 so the end user would need to change their IPs…
 
 Thanks,
 German
 
 
 
 On 3/6/16, 5:35 AM, "Samuel Bercovici"  wrote:
 
> As for a migration tool.
> Due to model changes and deployment changes between LBaaS v1 and LBaaS 
> v2, I am in favor for the following process:
> 
> 1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, 
> Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS 
> v1 3.
> Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
> over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
> make room to some custom modification for mapping between v1 and v2
> models)
> 
> What do you think?
> 
> -Sam.
> 
> 
> 
> 
> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: Friday, March 04, 2016 2:06 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
> weready?
> 
> Ok. Thanks for the info.
> 
> Kevin
> 
> From: Brandon Logan [brandon.lo...@rackspace.com]
> Sent: Thursday, March 03, 2016 2:42 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
> weready?
> 
> Just for clarity, V2 did not reuse tables, all the tables it uses are 
> only for it.  The main problem is that v1 and v2 both have a pools 
> resource, but v1 and v2's pool

Re: [openstack-dev] [fuel] Propose Denis Egorenko for fuel-library core

2016-08-24 Thread Emilien Macchi

I'm surprised Denis was not core before.
He has been a tremendous core reviewer for the Puppet OpenStack modules.

My vote doesn't count but I'm still encouraging this effort. Congrats
Denis, it's well deserved!

On Wed, Aug 24, 2016 at 5:33 PM, Sergii Golovatiuk
 wrote:
> +1
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Aug 24, 2016 at 10:49 PM, Matthew Mosesohn 
> wrote:
>>
>> +1 Denis is excellent at reviews and spotting CI failure root causes.
>> I definitely support him.
>>
>> On Wed, Aug 24, 2016 at 11:36 PM, Alex Schultz 
>> wrote:
>> > Ahoy Fuel Cores,
>> >
>> > I would like to propose Denis Egorenko for fuel-library core.  Denis is
>> > always providing great reviews[0] and continues to help keep Fuel moving
>> > forward.  He's the #3 reviewer and committer of the last 90 days[1] and
>> > 180
>> > days[2].
>> >
>> > Please vote with a +1/-1. Voting will close on August 31st.
>> >
>> > Thanks,
>> > -Alex
>> >
>> > [0] http://stackalytics.com/?user_id=degorenko
>> > [1] http://stackalytics.com/report/contribution/fuel-library/90
>> > [2] http://stackalytics.com/report/contribution/fuel-library/180
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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
>



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

2016-08-24 Thread Ryan Hallisey

+1

-Ryan

- Original Message -
From: "Michał Jastrzębski" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, August 24, 2016 10:41:57 AM
Subject: Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker 
(Daviey on irc)

+1 good job Davey:)

On 24 August 2016 at 08:27, Mauricio Lima  wrote:
> +1
>
> 2016-08-24 9:15 GMT-03:00 Kwasniewska, Alicja
> :
>>
>> +1
>>
>>
>>
>> From: Eduardo Gonzalez [mailto:dabar...@gmail.com]
>> Sent: Wednesday, August 24, 2016 1:42 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker
>> (Daviey on irc)
>>
>>
>>
>> +1
>>
>>
>>
>> On Wed, Aug 24, 2016, 1:25 PM Martin André  wrote:
>>
>> +1
>>
>> On Tue, Aug 23, 2016 at 10:45 PM, 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
>> >
>>
>> __
>> OpenStack Development Mailing 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

__
OpenStack Development Mailing 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] Need more undercloud resources

2016-08-24 Thread Giulio Fidente


On 08/25/2016 01:51 AM, Steve Baker wrote:

Heat now has efficient polling of nested events, but it doesn't look
like tripleoclient is using that.

Its not clear if the current polling is contributing to the above issue
but I'd definitely recommend switching over.


was simple enough so here is a change which switches to it

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


This is the recommended approach:
http://git.openstack.org/cgit/openstack/python-heatclient/tree/heatclient/osc/v1/stack.py#n180


This is what tripleoclient does currently:

http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/tripleoclient/utils.py#n272


The get_events call is low-overhead, but the get_stack call isn't, and
calling it in a loop won't be helping.

poll_for_events currently doesn't have an argument for specifying the
nested_depth for what events to log. I can add that to heatclient unless
you can live with only logging the events for the top level resources.


right, if you do I'll update the submission to use it ... also looks 
like we might need a mechanism to suppress events logging; shall I pass 
some fake fd to out= or can we change it to make None not logging, maybe 
defaulting it to stdout but skip if it is None?

--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente

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

2016-08-24 Thread Jay Pipes


On 08/24/2016 04:26 AM, Peter Willis wrote:

Colleagues,

I'd like to confirm that scalability and multi-site operations are key
to BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, MEC, IoT, where we
will have compute highly distributed around the network (from thousands
to millions of sites). BT would therefore support a Massively
Distributed WG and/or work on scalability and multi-site operations in
the Architecture WG.


Love all the TLAs.

I've asked this before to numerous Telco product managers and engineers, 
but I've yet to get a solid answer from any of them, so I'll repeat the 
question here...


How is vCPE a *cloud* use case?

From what I understand, the v[E]CPE use case is essentially that Telcos 
want to have the set-top boxen/routers that are running cable television 
apps (i.e. AT U-verse or Verizon FiOS-like things for US-based 
customers) and home networking systems (broadband connectivity to a 
local central office or point of presence, etc) be able run on virtual 
machines to make deployment and management of new applications easier. 
Since all those home routers and set-top boxen are essentially just 
Linux boxes, the infrastructure seems to be there to make this a 
cost-savings reality for Telcos. [1]


The problem is that that isn't remotely a cloud use case. Or at least, 
it doesn't describe what I think of as cloud.


Cloud to me means:

* Lots of hardware consolidated in datacenters for efficiency and 
security/management
* Software-as-a-Service interface, meaning the service is driven by 
users/tenants (i.e. no IT helpdesk to call to provision something) and 
provided over the Internet to a dumb device or browser
* (HTTP) API-driven access to launch compute, storage and network 
resources from large pools of those resources


Furthermore, applications written for the cloud (i.e. cloud-native apps) 
are built from the ground up to assume and tolerate failure, to be as 
close to shared-nothing as possible, to not need to be aware of where 
they are running or what particular server they are running on and to 
rely on well-defined APIs between (micro-)services.


v[E]CPE describes a purpose-built Telco application that doesn't meet 
any of the above definitions of what "cloud" is all about.


vCPE also doesn't look like a cloud-native application either: A single 
customer's vCPE software application is not capable of running on more 
than one machine at a time (since obviously it's running on the 
customer's set-top box or router).


Look, I'm all about designing Nova and other cloud services to function 
well in distributed environments where multiple datacenters are running 
a single OpenStack deployment spread over many regions.


But v[E]CPE just isn't cloud to me. And trying to morph Nova or other 
OpenStack services that were designed to run as services in a datacenter 
just isn't something I feel the OpenStack community needs to be focusing 
on. Run Nova (or Kubernetes, or Mesos, or any other cloud management 
platform) in the datacenter. Run a custom software application on the 
set-top boxes that can communicate with datacenter cloud services. Let's 
please not commandeer one of them to fit a model it was never built for.


My two cents,
-jay

[1] I say cost-savings because instead of shipping the customer a new 
piece of hardware when they purchase a new service (or sending a 
lineman), instead the telco now simply sends a command to the customer's 
router or set-top box to launch a VM that provides that service. One 
could say that the Telcos could just as easily ship a monolithic 
software application that would run on the set-top box and allow 
features to be toggled on and off, and I'm pretty sure many telco 
software applications are already like this, but deploying and managing 
monolithic applications is more complicated and expensive than shipping 
a VM image that contains a custom-built service that the customer can 
use at will.


p.s. I also don't think it's a good idea to run nova-compute on a fitbit 
watch.


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

Re: [openstack-dev] [infra][neutron] IPv6 gate issue in OSIC cloud

2016-08-24 Thread Sean Dague


On 08/24/2016 05:57 PM, Brian Haley wrote:

On 08/24/2016 04:52 PM, Brian Haley wrote:

Hi,

Starting sometime earlier in the week, gate jobs started failing that
were
running in the OSIC cloud, due to a loss of connectivity to VMs
running there
when Neutron L3 was configured.  I wanted to send some information out
on what
we found in case other deployment tools trip over the same issue.


And I didn't mean to leave out all the people that helped track this
down and expedite the patches - clarkb, dougwig, sc68cal, mordred,
armax, sdague... many thanks everyone!


Thanks for helping drive this to completion. It's been a wild couple of 
days :)


-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] [TripleO][CI] Need more undercloud resources

2016-08-24 Thread Steve Baker

On 25/08/16 06:11, James Slagle wrote:

The latest recurring problem that is failing a lot of the nonha ssl
jobs in tripleo-ci is:

https://bugs.launchpad.net/tripleo/+bug/1616144
tripleo-ci: nonha jobs failing with Unable to establish connection to
https://192.0.2.2:13004/v1/a90407df1e7f4f80a38a1b1671ced2ff/stacks/overcloud/f9f6f712-8e89-4ea9-a34b-6084dc74b5c1

This error happens while polling for events from the overcloud stack
by tripleoclient.

I can reproduce this error very easily locally by deploying with an
ssl undercloud with 6GB ram and 2 vcpus. If I don't enable swap,
something gets OOM killed. If I do enable swap, swap gets used (< 1GB)
and then I hit this error almost every time.

The stack keeps deploying but the client has died, so the job fails.
My investigation so far has only pointed out that it's the swap
allocation that is delaying things enough to cause the failure.

We do not see this error in the ha job even though it deploys more
nodes. As of now, my only suspect is that it's the overhead of the
initial SSL connections causing the error.

If I test with 6GB ram and 4 vcpus I can't reproduce the error,
although much more swap is used due to the increased number of default
workers for each API service.

However, I suggest we just raise the undercloud specs in our jobs to
8GB ram and 4 vcpus. These seem reasonable to me because those are the
default specs used by infra in all of their devstack single and
multinode jobs spawned on all their other cloud providers. Our own
multinode job for the undercloud/overcloud and undercloud only job are
running on instances of these sizes.

Yes, this is just sidestepping the problem by throwing more resources
at it. The reality is that we do not prioritize working on optimizing
for speed/performance/resources. We prioritize feature work that
indirectly (or maybe it's directly?) makes everything slower,
especially at this point in the development cycle.

We should therefore expect to have to continue to provide more and
more resources to our CI jobs until we prioritize optimizing them to
run with less.

Let me know if there is any disagreement on making these changes. If
there isn't, I'll apply them in the next day or so. If there are any
other ideas on how to address this particular bug for some immediate
short term relief, please let me know.

Heat now has efficient polling of nested events, but it doesn't look
like tripleoclient is using that.

Its not clear if the current polling is contributing to the above issue
but I'd definitely recommend switching over.

This is the recommended approach:
http://git.openstack.org/cgit/openstack/python-heatclient/tree/heatclient/osc/v1/stack.py#n180

This is what tripleoclient does currently:

http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/tripleoclient/utils.py#n272

The get_events call is low-overhead, but the get_stack call isn't, and
calling it in a loop won't be helping.

poll_for_events currently doesn't have an argument for specifying the
nested_depth for what events to log. I can add that to heatclient unless
you can live with only logging the events for the top level resources.

__
OpenStack Development Mailing 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] Intermittent gate failures

2016-08-24 Thread Armando M.

On 24 August 2016 at 10:30, Armando M.  wrote:

>
>
> On 22 August 2016 at 18:25, Armando M.  wrote:
>
>>
>>
>> On 22 August 2016 at 09:51, Armando M.  wrote:
>>
>>> Neutrinos,
>>>
>>> Since the merge of test [1], a race has surfaced, which leads to failure
>>> as reported in [2]. A number of Neutron's jobs are affected, and even
>>> though the failure is only intermittent, it is particularly bad for the
>>> linux bridge job.
>>>
>>> If I can ask you to hold your +2/+W until [3] puts the fire out, zuul
>>> will be grateful.
>>>
>>
>> An update:
>>
>> We have [1] in the gate queue, and Kevin is going full steam with [2],
>> which will mitigate the other intermittent issues we're facing in
>> functional and unit tests. Please bear with us.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/358753/
>> [2] https://review.openstack.org/#/c/356530/
>>
>>
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/327191/
>>> [2] https://bugs.launchpad.net/neutron/+bug/1615710
>>> [3] https://review.openstack.org/#/c/358753/
>>>
>>
>
> One more update:
>
> We're not quite out of the woods, yet so approve/recheck gently please.
>
> Things have become slightly better but we still have a pending fix for
> Neutron [1]. Recently we also observed zuul nodes dying unexpectedly on the
> OSIC cloud (that runs Neutron on IPv6) and that had an impact on the
> overall sluggishness of the gate [2]. Once all of the fixes are in, we
> should be back in business...until the next fire!
>

Another (final) update:

Changes [1] have merged. That should take care of the infra node resets.

At this point, there's [2] to wrap up, but things look largely recovered
[3,4] (though we need [5] to fully see a current picture). Please keep an
eye on [6], and help report/address critical fixes in the busy times ahead.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/Ia044fff2a1731ab6c04f82aea47096b425e0c0a0,n,z
[2] https://review.openstack.org/#/c/356530/
[3]
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=3
[4]
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=5
[5] https://review.openstack.org/#/c/358462/
[6]
https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW%3Alist=CONFIRMED=gate-failure


>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/356530/
> [2] https://bugs.launchpad.net/neutron/+bug/1616282
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][neutron] IPv6 gate issue in OSIC cloud

2016-08-24 Thread Brian Haley


On 08/24/2016 04:52 PM, Brian Haley wrote:

Hi,

Starting sometime earlier in the week, gate jobs started failing that were
running in the OSIC cloud, due to a loss of connectivity to VMs running there
when Neutron L3 was configured.  I wanted to send some information out on what
we found in case other deployment tools trip over the same issue.


And I didn't mean to leave out all the people that helped track this down and 
expedite the patches - clarkb, dougwig, sc68cal, mordred, armax, sdague... many 
thanks everyone!


-Brian

__
OpenStack Development Mailing 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] [Magnum] Release schedule of magnumclient

2016-08-24 Thread Hongbin Lu

Hi Shu,

That BP is targeted for Newton. It would be great if it can be implemented in 
Magnum-UI. Thanks for volunteering to take the work.

Best regards,
Hongbin

> -Original Message-
> From: Shuu Mutou [mailto:shu-mu...@rf.jp.nec.com]
> Sent: August-24-16 3:51 AM
> To: openstack-dev@lists.openstack.org
> Cc: Haruhiko Katou
> Subject: Re: [openstack-dev] [Magnum] Release schedule of magnumclient
> 
> Hi Hongbin,
> 
> Also, Magnum-UI will meet "Soft StringFreeze" next week.
> 
> If the following BP [1] can reach to release in this cycle, I will
> implement it into Magnum-UI until next week.
> 
> How do you think about the release timing of the BP?
> 
> [1] https://blueprints.launchpad.net/magnum/+spec/rename-bay-to-cluster
> 
> 
> Thanks,
> Shu
> 
> 
> > -Original Message-
> > From: Hongbin Lu [mailto:hongbin...@huawei.com]
> > Sent: Wednesday, August 24, 2016 6:32 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [Magnum] Release schedule of magnumclient
> >
> > 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 Development Mailing 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] [tempest][cinder] Clone feature toggle not in clone tests

2016-08-24 Thread Jordan Pittier

On Wed, Aug 24, 2016 at 6:06 PM, Slade Baumann  wrote:

> I am attempting to disable clone tests in tempest as they aren't
> functioning in NFS. But the tests test_volumes_clone.py and
> test_volumes_clone_negative.py don't have the "clone" feature
> toggle in them. I thought it obvious that if clone is disabled
> in tempest, the tests that simply clone should be disabled.
>
> So I put up a bug and fix for it, but have been talking with
> Jordan Pittier and he suggested I come to the mailing list to
> get this figured out.
>
> I'm not asking for reviews, unless you want to give them.
> I'm simply asking if this is the right way to go about this
> or if there is something else I need to do to get this into
> Tempest.
>
> Here are the bug and fix:
> https://bugs.launchpad.net/tempest/+bug/1615770
> https://review.openstack.org/#/c/358813/
>
> I would appreciate any suggestion or direction in this problem.
>
> For extra reference, the clone toggle flag was added here:
> https://bugs.launchpad.net/tempest/+bug/1488274
>
> Hi,
Thanks for starting this thread. My point about this patch is, as "volume
clone" is part of the core requirements [1] every Cinder drive must
support, I don't see a need for a feature flag. The feature flag already
exists, but that doesn't mean we should encourage its usage.

Now, if this really helps the NFS driver (although I don"t know why we
couldn't support clone with NFS)... I don't have a strong opinion on this
patch.

I -1ed the patch for consistency: I agree that there should be a minimum
set of features expected from a Cinder driver.

[1]
http://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality

Cheers,
Jordan

-- 
 
__
OpenStack Development Mailing 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] Propose Denis Egorenko for fuel-library core

2016-08-24 Thread Sergii Golovatiuk

+1

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

On Wed, Aug 24, 2016 at 10:49 PM, Matthew Mosesohn 
wrote:

> +1 Denis is excellent at reviews and spotting CI failure root causes.
> I definitely support him.
>
> On Wed, Aug 24, 2016 at 11:36 PM, Alex Schultz 
> wrote:
> > Ahoy Fuel Cores,
> >
> > I would like to propose Denis Egorenko for fuel-library core.  Denis is
> > always providing great reviews[0] and continues to help keep Fuel moving
> > forward.  He's the #3 reviewer and committer of the last 90 days[1] and
> 180
> > days[2].
> >
> > Please vote with a +1/-1. Voting will close on August 31st.
> >
> > Thanks,
> > -Alex
> >
> > [0] http://stackalytics.com/?user_id=degorenko
> > [1] http://stackalytics.com/report/contribution/fuel-library/90
> > [2] http://stackalytics.com/report/contribution/fuel-library/180
> >
> > 
> __
> > OpenStack Development Mailing 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] [RDO] [TripleO] [Packstack] qemu-kvm >= 2.3 now explicitely required for OpenStack Nova >= Newton

2016-08-24 Thread David Moreau Simard

This may have had unintended consequences when testing RDO on RHEL [1].

This is because the extra repository URL is:
http://mirror.centos.org/centos/$releasever/virt/$basearch/kvm-common/

$releasever is expanded to "7Server", not 7.
We've temporarily replaced $releasever by 7 until we figure out the
right way to go about this.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1369944

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Wed, Aug 24, 2016 at 3:14 PM, David Moreau Simard  wrote:
> Hi,
>
> Until now, the openstack-nova package in RDO had a lax requirement on
> qemu-kvm which potentially meant an older version of qemu-kvm (or
> qemu-kvm-rhel) would be installed [1].
>
> We have agreed at the RDO meeting this morning to go ahead and
> formally require qemu-kvm >= 2.3 from Newton onwards.
> This means that the base (~v1.5.3) qemu-kvm from CentOS (or
> qemu-kvm-rhel in RHEL) will no longer satisfy that requirement.
>
> The CentOS virt SIG maintains qemu-kvm-ev (>=2.3) which obsoletes
> qemu-kvm and will be preferred if it is available.
> This newer version is largely preferred to the one available by
> default in CentOS and RHEL due to improvements, bug fixes and features
> that are expected to be there by Nova.
>
> If you consume RDO's master trunk repositories (Delorean
> Newton/Delorean Master), this extra repository is already enabled in
> delorean-deps.repo [3] and you do not need to do anything.
> qemu-kvm-ev will automatically be installed in place of qemu-kvm.
>
> If you consume RDO from stable releases, the extra repository will
> automatically be enabled in the "centos-release-openstack-newton"
> package that will eventually be available.
> The repository will also be bundled in the "rdo-release.rpm" package
> [4] starting at Newton.
>
> Please let us know if you have any questions or notice any issues.
>
> Thanks !
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1367696
> [2]: https://wiki.centos.org/SpecialInterestGroup/Virtualization
> [3]: https://trunk.rdoproject.org/centos7-master/delorean-deps.repo
> [4]: https://github.com/redhat-openstack/rdo-release/pull/7
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]

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

2016-08-24 Thread Thai Q Tran

Hi Jason,
 
You should have access to it already. Just import from horizon the code you need. What you're looking for resides in the (request.user) object. Here are some usage examples, https://github.com/openstack/horizon/blob/master/openstack_dashboard/templatetags/context_selection.py
 
- Original message -From: Jason Pascucci To: "openstack-dev@lists.openstack.org" Cc:Subject: [openstack-dev] [horizon] [horizon-plugin]Date: Wed, Aug 24, 2016 12:05 PM    
Hi, 
  
What is the best method of obtaining the (name preferred) selected project (tenant) from the UI to pass to a plugin? 
  
-JRP 
  
  
__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-dev] [infra][neutron] IPv6 gate issue in OSIC cloud

2016-08-24 Thread Brian Haley


Hi,

Starting sometime earlier in the week, gate jobs started failing that were 
running in the OSIC cloud, due to a loss of connectivity to VMs running there 
when Neutron L3 was configured.  I wanted to send some information out on what 
we found in case other deployment tools trip over the same issue.


The problem was the VMs in OSIC are IPv6-only by default, so must be reachable 
using a global IPv6 address.  At boot, everything was fine - IPv6 address and 
default route were configured, but when IPv6 forwarding was enabled, poof!  The 
problem is that the default behavior in Linux is to remove any IPv6 default 
routes when forwarding is enabled, and that action caused connectivity loss to 
systems outside the OSIC datacenter using IPv6.  Luckily there's a sysctl to 
control this, and there is a patch out [1] that is working it's way through the 
check queue now.


So if you're creating puppet, chef, etc, scripts and deploying in an IPv6-only 
environment, you might need a few tweaks to not hit the same issue.


-Brian

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

__
OpenStack Development Mailing 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] Propose Denis Egorenko for fuel-library core

2016-08-24 Thread Matthew Mosesohn

+1 Denis is excellent at reviews and spotting CI failure root causes.
I definitely support him.

On Wed, Aug 24, 2016 at 11:36 PM, Alex Schultz  wrote:
> Ahoy Fuel Cores,
>
> I would like to propose Denis Egorenko for fuel-library core.  Denis is
> always providing great reviews[0] and continues to help keep Fuel moving
> forward.  He's the #3 reviewer and committer of the last 90 days[1] and 180
> days[2].
>
> Please vote with a +1/-1. Voting will close on August 31st.
>
> Thanks,
> -Alex
>
> [0] http://stackalytics.com/?user_id=degorenko
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> [2] http://stackalytics.com/report/contribution/fuel-library/180
>
> __
> OpenStack Development Mailing 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] [fuel] Propose Denis Egorenko for fuel-library core

2016-08-24 Thread Alex Schultz

Ahoy Fuel Cores,

I would like to propose Denis Egorenko for fuel-library core.  Denis is
always providing great reviews[0] and continues to help keep Fuel moving
forward.  He's the #3 reviewer and committer of the last 90 days[1] and 180
days[2].

Please vote with a +1/-1. Voting will close on August 31st.

Thanks,
-Alex

[0] http://stackalytics.com/?user_id=degorenko
[1] http://stackalytics.com/report/contribution/fuel-library/90
[2] http://stackalytics.com/report/contribution/fuel-library/180
__
OpenStack Development Mailing 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][dvr][fip] fg device allocated private ip address

2016-08-24 Thread Carl Baldwin

On Tue, Aug 16, 2016 at 6:17 PM, huangdenghui  wrote:

> Hi Carl
> Thanks for reply. I was wondering how this works? fg device has one
> private ip address, and the interface on upstream router has two ip
> address, one is private ip address, and the other one is public ip address,
> Can fg device do arp proxy for this situation?
>

Sorry for the delay. I was traveling and I guess this one slipped by.

The answer is yes, it can do proxy arp for this situation.

Carl
__
OpenStack Development Mailing 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] Intermittent gate failures

2016-08-24 Thread Sean M. Collins

Armando M. wrote:
> One more update:
> 
> We're not quite out of the woods, yet so approve/recheck gently please.
> 
> Things have become slightly better but we still have a pending fix for
> Neutron [1]. Recently we also observed zuul nodes dying unexpectedly on the
> OSIC cloud (that runs Neutron on IPv6) and that had an impact on the
> overall sluggishness of the gate [2]. Once all of the fixes are in, we
> should be back in business...until the next fire!


IPv6 only OpenStack installations sort of snuck up on us. :)

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [RDO] [TripleO] [Packstack] qemu-kvm >= 2.3 now explicitely required for OpenStack Nova >= Newton

2016-08-24 Thread David Moreau Simard

Hi,

Until now, the openstack-nova package in RDO had a lax requirement on
qemu-kvm which potentially meant an older version of qemu-kvm (or
qemu-kvm-rhel) would be installed [1].

We have agreed at the RDO meeting this morning to go ahead and
formally require qemu-kvm >= 2.3 from Newton onwards.
This means that the base (~v1.5.3) qemu-kvm from CentOS (or
qemu-kvm-rhel in RHEL) will no longer satisfy that requirement.

The CentOS virt SIG maintains qemu-kvm-ev (>=2.3) which obsoletes
qemu-kvm and will be preferred if it is available.
This newer version is largely preferred to the one available by
default in CentOS and RHEL due to improvements, bug fixes and features
that are expected to be there by Nova.

If you consume RDO's master trunk repositories (Delorean
Newton/Delorean Master), this extra repository is already enabled in
delorean-deps.repo [3] and you do not need to do anything.
qemu-kvm-ev will automatically be installed in place of qemu-kvm.

If you consume RDO from stable releases, the extra repository will
automatically be enabled in the "centos-release-openstack-newton"
package that will eventually be available.
The repository will also be bundled in the "rdo-release.rpm" package
[4] starting at Newton.

Please let us know if you have any questions or notice any issues.

Thanks !

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1367696
[2]: https://wiki.centos.org/SpecialInterestGroup/Virtualization
[3]: https://trunk.rdoproject.org/centos7-master/delorean-deps.repo
[4]: https://github.com/redhat-openstack/rdo-release/pull/7

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

__
OpenStack Development Mailing 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] collaboration request with vendors

2016-08-24 Thread Emilien Macchi

TripleO does support multiple vendors for different type of backends.
Here are some examples:
Neutron networking: Cisco, Nuage, Opencontrail, Midonet, Plumgrid, Biswitch
Cinder: Dell, Netapp, Ceph

TripleO developers are struggling to maintain the environment files
that allow to deploy those backends because it's very hard to test
them:
- not enough hardware
- zero knowledge at how to deploy the actual backend system
- no time to test all backends

Recently, we made some changes in TripleO CI that will help us to
scale the way we test TripleO in the future.
One of those changes is that we can now deploy TripleO using nodepool
instances like devstack jobs.

I wrote a prototype of TripleO job scenario:
https://review.openstack.org/#/c/360039/ that will allow us to have
more CI jobs with less services installed on each, so we can save
performances while increasing services coverage.
I would like to re-use those bits to test our vendors backends.

Here's the proposal:
- for vendors backends that can be deployed using TripleO itself
(open-source backend systems like OpenContrail, Midonet, etc): we
could re-use the scenario approach by adding new scenarios for each
backend.
The jobs would only be triggered if we touch environment files related
on the backend in THT or the puppet profiles for the backend in
puppet-tripleo or the puppet backend class in puppet-neutron for the
backend (all thanks to Zuul magic).

- for vendors backends that can't be deployed using TripleO itself
(not implemented in the services and / or not open-source):
Like most of you probably did for devstack jobs in neutron/cinder's
gates, work with us to implement CI jobs that would deploy TripleO
with your backend. I don't have the exact technical solution right
now, but at least I would like to know who would be interested by this
collaboration.

This request would be a win/win:
- tripleo developers would produce a better installer, actually tested
on different backends/plugins.
- vendors would get more feedback at how their plugin work in
real-life with TripleO.

I would like to know who is interested by this collaboration.

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

[openstack-dev] [horizon] [horizon-plugin]

2016-08-24 Thread Jason Pascucci

Hi,

What is the best method of obtaining the (name preferred) selected project 
(tenant) from the UI to pass to a plugin?

-JRP


__
OpenStack Development Mailing 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] Need more undercloud resources

2016-08-24 Thread Emilien Macchi

On Wed, Aug 24, 2016 at 2:11 PM, James Slagle  wrote:
> The latest recurring problem that is failing a lot of the nonha ssl
> jobs in tripleo-ci is:
>
> https://bugs.launchpad.net/tripleo/+bug/1616144
> tripleo-ci: nonha jobs failing with Unable to establish connection to
> https://192.0.2.2:13004/v1/a90407df1e7f4f80a38a1b1671ced2ff/stacks/overcloud/f9f6f712-8e89-4ea9-a34b-6084dc74b5c1
>
> This error happens while polling for events from the overcloud stack
> by tripleoclient.
>
> I can reproduce this error very easily locally by deploying with an
> ssl undercloud with 6GB ram and 2 vcpus. If I don't enable swap,
> something gets OOM killed. If I do enable swap, swap gets used (< 1GB)
> and then I hit this error almost every time.
>
> The stack keeps deploying but the client has died, so the job fails.
> My investigation so far has only pointed out that it's the swap
> allocation that is delaying things enough to cause the failure.
>
> We do not see this error in the ha job even though it deploys more
> nodes. As of now, my only suspect is that it's the overhead of the
> initial SSL connections causing the error.
>
> If I test with 6GB ram and 4 vcpus I can't reproduce the error,
> although much more swap is used due to the increased number of default
> workers for each API service.
>
> However, I suggest we just raise the undercloud specs in our jobs to
> 8GB ram and 4 vcpus. These seem reasonable to me because those are the
> default specs used by infra in all of their devstack single and
> multinode jobs spawned on all their other cloud providers. Our own
> multinode job for the undercloud/overcloud and undercloud only job are
> running on instances of these sizes.
>
> Yes, this is just sidestepping the problem by throwing more resources
> at it. The reality is that we do not prioritize working on optimizing
> for speed/performance/resources. We prioritize feature work that
> indirectly (or maybe it's directly?) makes everything slower,
> especially at this point in the development cycle.
>
> We should therefore expect to have to continue to provide more and
> more resources to our CI jobs until we prioritize optimizing them to
> run with less.
>
> Let me know if there is any disagreement on making these changes. If
> there isn't, I'll apply them in the next day or so. If there are any
> other ideas on how to address this particular bug for some immediate
> short term relief, please let me know.

For short term, +1 for extending the flavor and add the required RAM.
For long term, I'm working on extending our CI jobs to cover multiple
scenarios with less services installed on them. I hope it will help to
consume less resources on every job. Any help is welcome.

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

Re: [openstack-dev] [tripleo] Testing optional composable services in the CI

2016-08-24 Thread Emilien Macchi

Ok I have  PoC ready for review and feedback:

- First iteration of scenario001 job in TripleO CI:
https://review.openstack.org/#/c/360039
I checked, and the job is not triggered if we don't touch Sahara files directly.

- Patch in THT that tries to modify Sahara files:
https://review.openstack.org/#/c/360040
I checked, and when running "check experimental", the job is triggered
because we modify puppet/services/sahara-base.yaml.

So the mechanism is in place (experimental status now) but ready for review.
Please give any feedback.

Once we have this mechanism in place, we'll be able to add more
services coverage, and run the jobs in a smart way thanks to Zuul.

Thanks,

On Wed, Aug 17, 2016 at 3:52 PM, Emilien Macchi  wrote:
> On Wed, Aug 17, 2016 at 7:20 AM, James Slagle  wrote:
>> On Wed, Aug 17, 2016 at 4:04 AM, Dmitry Tantsur  wrote:
>>> However, the current gate system allows to run jobs based on files affected.
>>> So we can also run a scenario covering ironic on THT check/gate if
>>> puppet/services/*ironic* is affected, but not in the other cases. This won't
>>> cover all potential failures, but it would be of great help anyway. It
>>> should also run in experimental pipeline, so that it can be triggered on any
>>> patch.
>>>
>>> This is in addition to periodic jobs you're proposing, not replacing them.
>>> WDYT?
>>
>> Using the files affected to trigger a scenario test that uses the
>> affected composable service sounds like a really good idea to me.
>>
>
> I have a PoC, everything is explained in commit message:
> https://review.openstack.org/#/c/356675/
>
> Please review it and give feedback !
>
>>
>> --
>> -- James Slagle
>> --
>>
>> __
>> OpenStack Development Mailing 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



-- 
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] [TripleO] TripleO Deep dive sessions for CI topics.

2016-08-24 Thread James Slagle

On Wed, Aug 24, 2016 at 12:17 PM, Carlos Camacho Gonzalez
 wrote:
> Hello guys!
>
> I will like to ask you a question related to future TripleO deep dive
> sessions.
>
> What about having a specific series for CI? I read some people kind of
> “complaining” on IRC when CI does not work properly and assuming that taking
> care of CI is part of everyone's work let's try go have more eyes on CI
> (including me).
>
> I believe if more people its actually able to debug “real” CI issues we will
> be able to decrease the amount of work that these tasks take from the team.
>
> I added to https://etherpad.openstack.org/p/tripleo-deep-dive-topics a
> section with some topics, feel free to add/edit items and let's discuss it
> on the weekly meeting to see if in a mid-term we can have some introduction
> to CI.

I think this is a great idea. What I'd like to know before planning
something like this is what specific things do people need help on
when it comes to debugging failed jobs. How have folks tried to debug
jobs that have failed and gotten stuck?

Most of the time it is looking at logs and trying to reproduce
locally. I'd be happy to show that, but I feel like we've already
covered that to a large degree. So, I'd like to dig a little more into
specific ways people get stuck with failures and then we can directly
address those.

Ideally, a root cause of a failure could always be found, but that is
just not going to be the case given other constraints. It often comes
down to what one is able to reproduce locally, and how to mitigate the
issues as best we can (see email I just sent for an example).

Let me know or add the specifics to the etherpad and I'll pull
something together if there are no other volunteers :).

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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][CI] Need more undercloud resources

2016-08-24 Thread James Slagle

The latest recurring problem that is failing a lot of the nonha ssl
jobs in tripleo-ci is:

This error happens while polling for events from the overcloud stack
by tripleoclient.

The stack keeps deploying but the client has died, so the job fails.
My investigation so far has only pointed out that it's the swap
allocation that is delaying things enough to cause the failure.

We do not see this error in the ha job even though it deploys more
nodes. As of now, my only suspect is that it's the overhead of the
initial SSL connections causing the error.

If I test with 6GB ram and 4 vcpus I can't reproduce the error,
although much more swap is used due to the increased number of default
workers for each API service.

We should therefore expect to have to continue to provide more and
more resources to our CI jobs until we prioritize optimizing them to
run with less.

--
-- James Slagle
--

Re: [openstack-dev] [Neutron] Intermittent gate failures

2016-08-24 Thread Armando M.

On 22 August 2016 at 18:25, Armando M.  wrote:

>
>
> On 22 August 2016 at 09:51, Armando M.  wrote:
>
>> Neutrinos,
>>
>> Since the merge of test [1], a race has surfaced, which leads to failure
>> as reported in [2]. A number of Neutron's jobs are affected, and even
>> though the failure is only intermittent, it is particularly bad for the
>> linux bridge job.
>>
>> If I can ask you to hold your +2/+W until [3] puts the fire out, zuul
>> will be grateful.
>>
>
> An update:
>
> We have [1] in the gate queue, and Kevin is going full steam with [2],
> which will mitigate the other intermittent issues we're facing in
> functional and unit tests. Please bear with us.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/358753/
> [2] https://review.openstack.org/#/c/356530/
>
>
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/327191/
>> [2] https://bugs.launchpad.net/neutron/+bug/1615710
>> [3] https://review.openstack.org/#/c/358753/
>>
>

One more update:

We're not quite out of the woods, yet so approve/recheck gently please.

Things have become slightly better but we still have a pending fix for
Neutron [1]. Recently we also observed zuul nodes dying unexpectedly on the
OSIC cloud (that runs Neutron on IPv6) and that had an impact on the
overall sluggishness of the gate [2]. Once all of the fixes are in, we
should be back in business...until the next fire!

Cheers,
Armando

[1] https://review.openstack.org/#/c/356530/
[2] https://bugs.launchpad.net/neutron/+bug/1616282
__
OpenStack Development Mailing 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] [bifrost] Question about the "nics" argument provide to ansible os_ironic module.

2016-08-24 Thread Clint Byrum

Excerpts from hu.zhijiang's message of 2016-08-24 11:11:04 +0800:
> 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?

Nics are still needed for drivers that need to know the boot MAC of the
machine, such as PXE.

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

Re: [openstack-dev] [OpenStack-docs] [api-ref][ceilometer][nova][senlin][swift][zaqar] OpenStack Docs theme migration

2016-08-24 Thread Hayes, Graham

Hi All,

We are nearly ready to release the new version of os-api-ref.

This required a temporary section of code to allow the docs to build
with both oslosphinx and openstackdocstheme.

Currently only Nova, Ceilometer, Zaqar, Senlin and Swift are
outstanding.

We will be releasing the new version of the library pretty soon.

It will not be before 16:00 UTC tomorrow afternoon, but could be
any time after that. Any of the projects above that have not merged
their "os-api-ref-1.0.0-prep" change will have a broken api-ref site.

When we have released the library, and confirmed projects are using it,
I will submit a new round of reviews to remove the temp code.

Thanks!

Graham

On 19/08/2016 17:16, Hayes, Graham wrote:
> Hi All,
>
> I have just pushed reviews to all the repos using os-api-ref, to allow
> us to migrate to the new sphinx theme gracefully.
>
> I have pushed reviews to the following repos:
>
> openstack/networking-sfc
> openstack/ceilometer
> openstack/glance
> openstack/heat
> openstack/ironic
> openstack/keystone
> openstack/manila
> openstack/designate
> openstack/trove
> openstack/neutron-lib
> openstack/nova
> openstack/sahara
> openstack/searchlight
> openstack/senlin (*)
> openstack/swift
> openstack/zaqar
>
> with the topic "os-api-ref-1.0.0-prep" [0]
>
> If I have missed anyone, please let me know.
>
> The next step would be to merge all of these, and then [1], and then do
> a release of the os-api-ref library.
>
> * Senlin looked like it was using the new theme already - so if they
> want to continue they can. just be warned that the visual styling will
> change at some point.
>
> Thanks,
>
> Graham
>
>
> 0 - https://review.openstack.org/#/q/topic:os-api-ref-1.0.0-prep
> 1 - https://review.openstack.org/#/c/322430/
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>

__
OpenStack Development Mailing 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] Developer's productivity with MuranoPL

2016-08-24 Thread Stan Lagun

Hi Alex,

I'm two hands up for making developers life easier. However we should
remember that MuranoPL is not a scripting language and not a Python
replacement. There's very little point in writing Hello Word on MuranoPL.
And once you go for even the simplest app possible you will still have to
have OpenStack installed, manifest file written, class created etc. So the
only use case that I see is to type some simple statement that doesn't
involve any deployment or other I/O
and see how it works. In 80% of cases the same could be done in yaql CLI
tool. That's why I don't expect it to be that much of a productivity boost.
IMO debugger will do much better. And we could have an expression
evaluation functionality within debugger.

Btw, most of the steps you mentioned can be solved by an application stub
generator and configuration setting that will make murano take packages
from the local folder

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Tue, Aug 16, 2016 at 7:31 AM, Alexander Tivelkov 
wrote:

> Hi folks,
>
> The developer's productivity and ease of use is critical for the language
> adoption, and I believe we have issues with these in MuranoPL. The things
> are slowly getting better (thanks to the guys who are bulding th MuranoPL
> syntax checker [1] which will be a very useful tool), but that's not
> enough: we need more tools to simplify dev's life.
>
> Let me provide a quick example: what does it take to run a "Hello World"
> in MuranoPL?
> To create such an introductory MuranoPL program the developer has to:
> 1) Install Murano with the rest of openstack (i.e. spin up devstack with
> Murano and Glare plugins)
> 2) Write the actual HelloWorld "program" (mind the absence of simple
> "print" function and the non-so-obvious need to extend
> io.murano.Application class for the example to be runnable as murano's
> entry point)
> 3) Write the UI.yaml file to provide the input object graph (even if there
> is no user-supplied paramters - we still have to have this file)
> 4) Write a manifest.yaml
> 5) zip the program, the ui and the manifest into a package
> 6) Upload the package to Glare
> 7) Create an environment in Murano dashboard
> 8) Add the demo app to the environment
> 9) Deploy the environment
>
> I hope I din't miss any step. Even excluding the time to spin up devstack
> (and the high probability that a newcomer will not do that properly from
> the first attempt) this is going to take at least 30 minutes. Even when the
> environment is set up, the whole "make code changes - recreate the package
> - reupload the package - recreate the environment - redepoy" cycle is
> cumbersome.
>
> What do we need is a simple and easy way to run MuranoPL code without the
> need to set up all the server-sides components, generate object model and
> interact with all the production-grade machinery murano has under the hood.
> To do something like:
>
>$ cat "- print('Hello, World')" > ./hello.yaml
>$ murano-pl ./hello.yaml
>
> Ideally there should be an interactive REPL-like shell, with smart
> indentation and code completion similar to the Python's (we have one for
> yaql, and so we should for MuranoPL).
>
> That is not a very hard thing to do, and it will simplify the developers'
> onboarding dramatically.
>
> So, I propose to start with a simple thing: to separate the MuranoPL
> interpreter (mostly the code located in murano.dsl package, plus some other
> stuff) from the rest of Murano. Put it into a standalone reporitory, so it
> may be packaged and distributed independently. The developers will just
> need to 'pip install murano-pl' to have the local interpreter without all
> the dependencies on murano api, engine, database etc. This new package may
> include the murano-pl test-runner (this tool is currently part of the main
> murano repo and is hard to use since it requires to have a valid config
> file which is not a proper option for a cli tool). Then we may include some
> other devloper-side tools, such as a murano-pl debugger (when we finally
> have one: this is a separate topic).
> Finally, we will need to remove the core library (murano.engine.system)
> package from the main murano repo and also make it a standalone
> repo/package with its own lifecycle (it would be very helpfull if we could
> release/update the core library more frequently). So the main murano repo
> (and appropriate package) will contain only the server-side murano
> components: the REST API, the engine, DB api, model and migrations etc.
>
> When this is done we may begin adding other developer's productivity
> tools: starting with debugger and then to various kinds of IDE
> integrations.
>
> Thoughts, opinions?
>
>
> [1] https://github.com/openstack/murano-specs/blob/master/
> specs/newton/approved/validation-tool.rst
> --
> Regards,
> Alexander Tivelkov
>
> __
> OpenStack Development

[openstack-dev] [neutron][neutron-lib] No meeting today

2016-08-24 Thread Boden Russell

Our small neutron-lib crowd is busy today, so we won't hold the meeting.

For neutron-lib planning/tasks/etc., please see [1].
If time permits, please take a pass through the neutron-lib reviews [2].

Thanks

[1] https://etherpad.openstack.org/p/nl-planning
[2] https://review.openstack.org/#/q/project:openstack/neutron-lib

__
OpenStack Development Mailing 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] TripleO Deep dive sessions for CI topics.

2016-08-24 Thread Carlos Camacho Gonzalez

Hello guys!

I will like to ask you a question related to future TripleO deep dive
sessions.

What about having a specific series for CI? I read some people kind of
“complaining” on IRC when CI does not work properly and assuming that
taking care of CI is part of everyone's work let's try go have more eyes on
CI (including me).

I believe if more people its actually able to debug “real” CI issues we
will be able to decrease the amount of work that these tasks take from the
team.

I added to https://etherpad.openstack.org/p/tripleo-deep-dive-topics a
section with some topics, feel free to add/edit items and let's discuss it
on the weekly meeting to see if in a mid-term we can have some introduction
to CI.

Thanks!!!
__
OpenStack Development Mailing 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] [tempest][cinder] Clone feature toggle not in clone tests

2016-08-24 Thread Slade Baumann

I am attempting to disable clone tests in tempest as they aren'tfunctioning in NFS. But the tests test_volumes_clone.py andtest_volumes_clone_negative.py don't have the "clone" featuretoggle in them. I thought it obvious that if clone is disabledin tempest, the tests that simply clone should be disabled.So I put up a bug and fix for it, but have been talking withJordan Pittier and he suggested I come to the mailing list toget this figured out. I'm not asking for reviews, unless you want to give them.I'm simply asking if this is the right way to go about thisor if there is something else I need to do to get this intoTempest.Here are the bug and fix:https://bugs.launchpad.net/tempest/+bug/1615770https://review.openstack.org/#/c/358813/I would appreciate any suggestion or direction in this problem.For extra reference, the clone toggle flag was added here:https://bugs.launchpad.net/tempest/+bug/1488274


__
OpenStack Development Mailing 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] Request to create puppet-qdr

2016-08-24 Thread Alex Schultz

On Wed, Aug 24, 2016 at 9:45 AM, Andy Smith  wrote:

> Hi,
>
> We have a puppet module for the qpid-dispatch-router. The
> oslo.messaging AMQP 1.0 driver support for the router
> feature is part of the newton oslo.messaging release (5.9.0).
>
> This module is presently in a user repository and we would like to
> move it to OpenStack so that it may evolve under a stronger process
> and gain community contribution and review.
>
> The existing repository is here: https://github.com/ajssmith/puppet-qdr
>
> Please, let us know next steps to proceed.
>
>
http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html

You can also join us in #puppet-openstack on freenode if you have further
questions.

Thanks,
-Alex


> Thanks,
> Andy Smith
>
> __
> OpenStack Development Mailing 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] [puppet] Request to create puppet-qdr

2016-08-24 Thread Andy Smith

Hi,

We have a puppet module for the qpid-dispatch-router. The 
oslo.messaging AMQP 1.0 driver support for the router 
feature is part of the newton oslo.messaging release (5.9.0).

This module is presently in a user repository and we would like to
move it to OpenStack so that it may evolve under a stronger process
and gain community contribution and review.

The existing repository is here: https://github.com/ajssmith/puppet-qdr

Please, let us know next steps to proceed.

Thanks,
Andy Smith

__
OpenStack Development Mailing 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] My openstack account is invalid after change it

2016-08-24 Thread Jeremy Stanley

On 2016-08-24 15:16:19 + (+), Jay Faulkner wrote:
> Is this the typical way we do OpenStack account support? This
> email honestly sounds a little phishy :).

Probably only for users who don't read. Normally, I think people who
follow the "Forgot password?" link at
https://openstackid.org/accounts/user/login see the sentence on the
next page above the Web form where it says, "If you no longer have
access to the email address associated with your OpenStackID, please
send an email to i...@openstack.org with the relevant details."
-- 
Jeremy Stanley

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

Re: [openstack-dev] NoMethodRegisteredException when deploying Murano environment

2016-08-24 Thread Stan Lagun

Hi,

most likely it is caused by using wrong version of the core library
package. Some parts of it are written in Python rather than in MuranoPL and
located inside murano source codes. So if you use newer version of core
library with older version of Murano you get this error. In particular it
cannot find
https://github.com/openstack/murano/blob/stable/mitaka/murano/engine/system/net_explorer.py#L195
method which is available since mitaka.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

On Wed, Aug 24, 2016 at 4:37 AM, Kirill Zaitsev 
wrote:

> Hi, it’s impossible to say without knowing what application you’re trying
> to deploy. Also this mailing list is not the best place for usage questions
> =) Please come to our IRC channel #murano — we would try to help you find
> what went wrong.
>
> --
> Kirill Zaitsev
> Murano Project Tech Lead
> Software Engineer at
> Mirantis, Inc
>
> On 24 août 2016 at 05:57:32, wuhan (wuhan9...@163.com) wrote:
>
> listNeutronExtensions
>
>
> __
> OpenStack Development Mailing 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] Interface in PEER2PEER live migration

2016-08-24 Thread Daniel P. Berrange

On Wed, Aug 24, 2016 at 05:07:50PM +0200, Alberto Planas Dominguez wrote:
> Unfortunately was closed as invalid, and the solution provided is
> completely unrelated. The solution suggested is based on
> `live_migration_inbound_addr`, that is related with the libvirtd URI,
> not the qmeu one. I tested several times and yes, this solution is not
> related with the problem.

The "live_migration_inbound_addr" configuration parameters was intended
to affect both libvirt & QEMU traffic. If that is not working correctly,
then we should be fixing that, nto adding yet another parameter.

> 
> I worked in a patch for mater here:
> 
> https://review.openstack.org/#/c/356558/
> 
> This patch worked as expected. This create a second URI, based on the
> hostname given in live_migration_uri parameter, to build a second one
> that will be used by qemu/kvm for the second connection.
> 
> So, for example if:
> 
> live_migration_uri=qemu+tcp://fast.%s/system
> 
> this patch will create a second uri:
> 
> migrate_uri=tcp://fast.%s/

While you can do that hack, the fact that is works is simply luck - it
certainly was not designed with this kind of usage in mind. We would
in fact like to remove the live_migration_uri config parameter entirely
and having the libvirt driver automatically use the correct URI. As such
adding further URI config parmaeters is not a direction we want to go
in.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] My openstack account is invalid after change it

2016-08-24 Thread Jay Faulkner

Is this the typical way we do OpenStack account support? This email honestly 
sounds a little phishy :).

-Jay

> On Aug 24, 2016, at 8:00 AM, Jimmy Mcarthur  wrote:
> 
> Hi -
> 
> I'd be happy to assist you with your login problem. Please email me directly 
> and we'll get you going.
> 
> Thank you!
> Jimmy McArthur
> 
> 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 Development Mailing 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] Interface in PEER2PEER live migration

2016-08-24 Thread Alberto Planas Dominguez

Hi!

I have a question about live migration in a p2p scenario. We have a
deployment where the compute nodes have several interfaces. The
hostname is associate with one of them, that is used for nova to do all
the communication, and also the live migration.

The thing is that we want to use the fast interface to do the live
migration. According to the documentation this is easy:

* Configure libvirtd to listen in the fast interface in every compute
node

* Configure in nova.conf live_migration_uri to point to the correct URI
where libvirtd is listening

* Done!

Doing this makes the live-migration works ... but in the slow
interface!

Digging into libvirt driver for nova, looks like that the problem is
that in a p2p there are two connections. One to libvirtd level, and
another in the qemu/kvm level. The first one is the one configured with
the live_migration_uri parameter, but the second one is not configured
anywhere in nova.

The second connection is were the bulk of data is happening, according
to `iftop`. Digging a bit more, I discover that I can force the
interface where qemu will listen (parameter -incoming in qemu), but we
need to pass the correct URI from the nova side.

I consider this a bug, and I created this bug report:

https://bugs.launchpad.net/nova/+bug/1614063

Unfortunately was closed as invalid, and the solution provided is
completely unrelated. The solution suggested is based on
`live_migration_inbound_addr`, that is related with the libvirtd URI,
not the qmeu one. I tested several times and yes, this solution is not
related with the problem.

I worked in a patch for mater here:

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

This patch worked as expected. This create a second URI, based on the
hostname given in live_migration_uri parameter, to build a second one
that will be used by qemu/kvm for the second connection.

So, for example if:

live_migration_uri=qemu+tcp://fast.%s/system

this patch will create a second uri:

migrate_uri=tcp://fast.%s/

that is used in the libvirt API migrateToURI[23] to specify the URI for
QEMU.

This worked. I backported it to Mitaka and Liberty and works as
expected (checked with and w/out the patch with iftop several times)

The thing is that this patch and solution can not be discussed further
because the bug related was marked as invalid, but the issue is still
there.

I checked and rechecked the comments in the bug report to make sure
that I am not missing something. But I am unable to!

So, if the patch and the bug are not valid, how can I do a p2p live
migration when both connections (the libvirtd one, used as a first
parameter in migrateToURI[23], and miguri parameter in the same API)
are pointing to the same interface?


-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

__
OpenStack Development Mailing 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] My openstack account is invalid after change it

2016-08-24 Thread Jimmy Mcarthur


Hi -

I'd be happy to assist you with your login problem. Please email me 
directly and we'll get you going.


Thank you!
Jimmy McArthur

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

Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Gerrit-StoryBoard integration is live, and other updates

2016-08-24 Thread Ricardo Carrillo Cruz

Congratulations, and thanks to everyone involved in this.
This is a huge milestone :-) .

Cheers

2016-08-24 16:53 GMT+02:00 Zara Zaimeche :

> Hi, all! A few exciting StoryBoard updates incoming.
>
> 1. StoryBoard is now integrated with Gerrit (thanks, zaro)!
> ---
>
> This is the big one! And I am as happy as a clam.:)  To use this
> incredible new power, in StoryBoard, find the task id to the left of the
> task you're about to send a patch for. Then put:
>
> Task: $task_id
>
> into the commit message. When the patch is sent, this will update the
> status of the relevant task in StoryBoard, and post a comment linking to
> the gerrit change. Stories also have unique ids, found to the left of each
> story in the list of stories, so if you include:
>
> Story: $story_id
>
> you can easily browse from gerrit to the related StoryBoard story. There
> is an example of the syntax here:
>
> https://review.openstack.org/#/c/355079/
>
> If you'd like to try it out yourself but don't have any pressing patches
> to send, you can make a story over at our test instance,
> https://storyboard-dev.openstack.org , and then send a nonsense patch to
> a project in review-dev (https://review-dev.openstack.org/), citing the
> relevant task and/or story.
>
> zaro has done the vast majority of the work on this, so thank you, zaro
> (again)!!! And thanks to everyone in the infra team who helped with reviews
> to config and switching things on. :)
>
> 2. Worklists and boards are more discoverable
> -
>
> Now logged-out users can easily find the lists of worklists and boards,
> and users can filter them by title, or by tasks or stories they contain.
> You'll find them on the main sidebar, just below the 'dashboard' option. A
> worklist lets you order a custom todo list (eg: to convey priority), or
> provide a handy filter of tasks/stories (eg: 'show all 'todo' tasks in
> story foo). A board allows you to create several lists side-by-side, so
> that you can track the movement of tasks. This means you can, say, create a
> board with 'todo', 'review', and 'merged' lanes, filtered by project, and
> the contents of these will update as people send patches to gerrit. Here's
> an example:
>
> https://storyboard.openstack.org/#!/board/14
>
> 3. More usable developer docs
> -
>
> Matthew Bodkin has updated our developer docs so that they can be used to
> launch a StoryBoard instance. They should be functional now (we aim for the
> stars). Thanks, Matthew! He's also helped with multiple misc ui fixes
> recently, so thanks again.
>
> On the horizon...
> -
>
> There is a TC Ocata goal to remove incubated oslo code, which affects two
> StoryBoard projects (the api and the python client). I've made a story for
> it over here: https://storyboard.openstack.org/#!/story/2000707 ; if
> other affected projects are using StoryBoard, it makes sense to list tasks
> there so they're easier to find. This is exactly the sort of cross-project
> work that StoryBoard is designed for, so let's give it a workout! I could
> do with some guidance or examples on removing and replacing the incubated
> oslo code (especially for the python client, which uses the old apiclient
> module). If people are interested in running scripts against StoryBoard and
> doing more specific browses and filters on results, our python client is
> the answer, so I'm interested in a) tidying it up and b)finding out
> people's workflow and how they would expect to interact with the python
> client from the commandline.
>
> That's all for now (sorry this was so long!). The StoryBoard meeting is at
> 15:00 UTC today (and every Wednesday) in #openstack-meeting. We are also
> always available in #storyboard, for chatter (and occasionally
> development). Happy task-tracking! :)
>
> Best Wishes,
>
> Zara
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
OpenStack Development Mailing 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] [OpenStack-Infra][StoryBoard] Gerrit-StoryBoard integration is live, and other updates

2016-08-24 Thread Zara Zaimeche


Hi, all! A few exciting StoryBoard updates incoming.

1. StoryBoard is now integrated with Gerrit (thanks, zaro)!
---

This is the big one! And I am as happy as a clam.:)  To use this 
incredible new power, in StoryBoard, find the task id to the left of the 
task you're about to send a patch for. Then put:


Task: $task_id

into the commit message. When the patch is sent, this will update the 
status of the relevant task in StoryBoard, and post a comment linking to 
the gerrit change. Stories also have unique ids, found to the left of 
each story in the list of stories, so if you include:


Story: $story_id

you can easily browse from gerrit to the related StoryBoard story. There 
is an example of the syntax here:


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

If you'd like to try it out yourself but don't have any pressing patches 
to send, you can make a story over at our test instance, 
https://storyboard-dev.openstack.org , and then send a nonsense patch to 
a project in review-dev (https://review-dev.openstack.org/), citing the 
relevant task and/or story.


zaro has done the vast majority of the work on this, so thank you, zaro 
(again)!!! And thanks to everyone in the infra team who helped with 
reviews to config and switching things on. :)


2. Worklists and boards are more discoverable
-

Now logged-out users can easily find the lists of worklists and boards, 
and users can filter them by title, or by tasks or stories they contain. 
You'll find them on the main sidebar, just below the 'dashboard' option. 
A worklist lets you order a custom todo list (eg: to convey priority), 
or provide a handy filter of tasks/stories (eg: 'show all 'todo' tasks 
in story foo). A board allows you to create several lists side-by-side, 
so that you can track the movement of tasks. This means you can, say, 
create a board with 'todo', 'review', and 'merged' lanes, filtered by 
project, and the contents of these will update as people send patches to 
gerrit. Here's an example:


https://storyboard.openstack.org/#!/board/14

3. More usable developer docs
-

Matthew Bodkin has updated our developer docs so that they can be used 
to launch a StoryBoard instance. They should be functional now (we aim 
for the stars). Thanks, Matthew! He's also helped with multiple misc ui 
fixes recently, so thanks again.


On the horizon...
-

There is a TC Ocata goal to remove incubated oslo code, which affects 
two StoryBoard projects (the api and the python client). I've made a 
story for it over here: 
https://storyboard.openstack.org/#!/story/2000707 ; if other affected 
projects are using StoryBoard, it makes sense to list tasks there so 
they're easier to find. This is exactly the sort of cross-project work 
that StoryBoard is designed for, so let's give it a workout! I could do 
with some guidance or examples on removing and replacing the incubated 
oslo code (especially for the python client, which uses the old 
apiclient module). If people are interested in running scripts against 
StoryBoard and doing more specific browses and filters on results, our 
python client is the answer, so I'm interested in a) tidying it up and 
b)finding out people's workflow and how they would expect to interact 
with the python client from the commandline.


That's all for now (sorry this was so long!). The StoryBoard meeting is 
at 15:00 UTC today (and every Wednesday) in #openstack-meeting. We are 
also always available in #storyboard, for chatter (and occasionally 
development). Happy task-tracking! :)


Best Wishes,

Zara

__
OpenStack Development Mailing 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] [gate] [cinder] A current major cause for gate failure - cinder backups

2016-08-24 Thread John Griffith

Patch is up, see LP bug reference in Lisa message.

On Aug 24, 2016 10:35, "Jay S. Bryant" 
wrote:

> Lisa,
>
> Great debug!  Thank you!
>
> Let me know when a patch is up and I will take a look.
>
> Jay
>
> On 08/24/2016 02:24 AM, Li, Xiaoyan wrote:
>
>> Hi,
>>
>> I noticed that as VolumesBackupsV1Test and VolumesBackupsV2Test use same
>> volume to do backup creation test etc.
>> When creating backup from volume, it needs to attach volume. As both two
>> tests use same volume, they attach the volume at same time, and leads
>> failure.
>> I opened a bug https://bugs.launchpad.net/tempest/+bug/1616338, and will
>> fix it.
>>
>> Best wishes
>> Lisa
>>
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: Wednesday, August 24, 2016 10:21 AM
>> To: OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> Subject: [openstack-dev] [gate] [cinder] A current major cause for gate
>> failure - cinder backups
>>
>> 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: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: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][vote] Core nomination for Dave Walker (Daviey on irc)

2016-08-24 Thread Michał Jastrzębski

+1 good job Davey:)

On 24 August 2016 at 08:27, Mauricio Lima  wrote:
> +1
>
> 2016-08-24 9:15 GMT-03:00 Kwasniewska, Alicja
> :
>>
>> +1
>>
>>
>>
>> From: Eduardo Gonzalez [mailto:dabar...@gmail.com]
>> Sent: Wednesday, August 24, 2016 1:42 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker
>> (Daviey on irc)
>>
>>
>>
>> +1
>>
>>
>>
>> On Wed, Aug 24, 2016, 1:25 PM Martin André  wrote:
>>
>> +1
>>
>> On Tue, Aug 23, 2016 at 10:45 PM, 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
>> >
>>
>> __
>> OpenStack Development Mailing 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] [kloudbuster] test LBAAS at scale

2016-08-24 Thread Alec Hothan (ahothan)

Hi Akshay,

I suppose you're talking about LBAAS v2?

Adding support for lbaas in kloudbuster will require some amount of work which 
can be kept to a minimum if done properly, this addition would be a pretty good 
way to test lbaas at scale.
The tricky part is to modify the staging code without breaking the other 
features (multicast and storage) since this staging is specific to HTTP scale 
test.
The current staging for HTTP scale is based on the following template (I show 
the server side only):

[Router-[HTTP server VM]*]*

The natural extension for supporting LBAAS is to replace each HTTP server with 
a LB group + N HTTP servers:

[Router--[LB---[HTTP server VM]*]*]*

Implementing this would require the following modifications (just a rough 
description of the tasks):

  *   add an additional config option to specify the number of server VMs per 
LB group (defaults to none/no LB) 
  *   if LB is configured, the current config server count would become a LB 
group count
  *   the staging code for the HTTP servers needs to be modified to handle the 
case of LB: 
 *   instead of creating as many HTTP servers as the server count argument, 
create as many LB groups
 *   for each LB group, create the requested HTTP server VMs per group and 
add them to the group
  *   floating IP if requested need to apply to the LB port instead of the HTTP 
servers 
  *   naturally the teardown code will have to also support cleaning up LB 
resources 

  *   HTTP clients will need to connect to the LB VIP address (instead of the 
HTTP server IP address) 

I can help you go through these individual tasks in detail in the code if you 
feel you can handle that, it's just python coding.


The VMs running the HTTP traffic generators are currently always associated 1:1 
to a server VM. With the above template extension you will end up with as many 
HTTP client VMs as LB groups:

(removed the router for better clarity):

[HTTP client VM---[LB---[HTTP server VM]*]*]*

This is not ideal because each HTTP traffic generator can only support a 
relatively low number of connections (in the few thousands) while an HTTP 
server instance can easily support many times this load especially for light 
HTTP traffic (i.e. replies that are very short).

So another improvement (which we had on our roadmap) would be to support N:1 
mapping:

[[HTTP client VM]*LB---[HTTP server VM]*]*]*

this could be a separate extension.
Let me know if you'd like to do this and we can help navigate the code.

Thanks

   Alec



From: Akshay Kumar Sanghai 
>
Date: Tuesday, August 23, 2016 at 2:07 PM
To: Alec Hothan >
Cc: "Yichen Wang (yicwang)" >, 
"OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kloudbuster] authorization failed problem

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


__
OpenStack Development Mailing 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] [gate] [cinder] A current major cause for gate failure - cinder backups

2016-08-24 Thread Jay S. Bryant


Lisa,

Great debug!  Thank you!

Let me know when a patch is up and I will take a look.

Jay

On 08/24/2016 02:24 AM, Li, Xiaoyan wrote:

Hi,

I noticed that as VolumesBackupsV1Test and VolumesBackupsV2Test use same volume 
to do backup creation test etc.
When creating backup from volume, it needs to attach volume. As both two tests 
use same volume, they attach the volume at same time, and leads failure. 
I opened a bug https://bugs.launchpad.net/tempest/+bug/1616338, and will fix it.

Best wishes
Lisa

-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Wednesday, August 24, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [gate] [cinder] A current major cause for gate failure 
- cinder backups

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

__
OpenStack Development Mailing 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] [gate] [cinder] A current major cause for gate failure - cinder backups

2016-08-24 Thread Sean McGinnis

On Wed, Aug 24, 2016 at 07:24:54AM +, Li, Xiaoyan wrote:
> Hi,
> 
> I noticed that as VolumesBackupsV1Test and VolumesBackupsV2Test use same 
> volume to do backup creation test etc. 
> When creating backup from volume, it needs to attach volume. As both two 
> tests use same volume, they attach the volume at same time, and leads 
> failure.   
> I opened a bug https://bugs.launchpad.net/tempest/+bug/1616338, and will fix 
> it.
> 
> Best wishes
> Lisa

Thanks Lisa!

__
OpenStack Development Mailing 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] [watcher] Nominate Prashanth Hari as core for watcher-specs

2016-08-24 Thread Susanne Balle

+1

Susanne

On Wed, Aug 17, 2016 at 7:10 AM, Чадин Александр 
wrote:

> +1
>
> ___
> Alexander Chadin,
> Engineer
> Software Solutions Department
> Servionica Ltd.
> Work email: a.cha...@servionica.ru
> Mobile: +7(916)693-58-81
>
>
> __
> OpenStack Development Mailing 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] OVH wants to thank the OpenStack Community

2016-08-24 Thread Jean-Daniel Bonnetot

Hi ML,

If you have contributed to OpenStack during the past year, OVH would like to 
offer you a $150 voucher code to test our OpenStack Public Cloud. 
You have until September 15th 2016 to activate the voucher and is valid for up 
to 3 months from the date of activation. 
This is our way of thanking you for all the work that you do, release after 
release.
Go to http://weareopenstack.ovh/ to register, it's on a “first-come, 
first-served” basis.

Thank you Stackers.

--
Jean-Daniel Bonnetot
http://www.ovh.com
@pilgrimstack




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

2016-08-24 Thread lương hữu tuấn

Oh, my bad for the write permission of nova user. That should not be like
this. Thanks Jeffrey.

Cheers,

T

On Wed, Aug 24, 2016 at 2:39 PM, Jeffrey Zhang 
wrote:

> On Wed, Aug 24, 2016 at 5:24 PM, lương hữu tuấn 
> wrote:
> > However, with config file as nova.conf or in this case e.g. kolla.conf,
> it
> > should be kolla:kolla and only owner can write as well, it means 644
> since
> > the kolla service is run under the name of kolla user, it is the same
> with
> > other services in OpenStack.
>
> there is no kolla.conf file in any containers.
>
> >
> > With the folder, e.g. /etc/kolla or /etc/nova, it should be also
> > read/write/executable with kolla user and kolla group since kolla service
> > running with kolla user should have permission to get information from
> > kolla.conf.
>
> for the nova.conf, why the nova user need to write/change the nova.conf
> file?
>
>
>
>
> --
> 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 Development Mailing 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)

2016-08-24 Thread Mauricio Lima

+1

2016-08-24 9:15 GMT-03:00 Kwasniewska, Alicja 
:

> +1
>
>
>
> *From:* Eduardo Gonzalez [mailto:dabar...@gmail.com]
> *Sent:* Wednesday, August 24, 2016 1:42 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [kolla][vote] Core nomination for Dave
> Walker (Daviey on irc)
>
>
>
> +1
>
>
>
> On Wed, Aug 24, 2016, 1:25 PM Martin André  wrote:
>
> +1
>
> On Tue, Aug 23, 2016 at 10:45 PM, 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
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] What's Happening in OpenStack-Ansible (WHOA) - August 2016

2016-08-24 Thread Major Hayden

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

The August edition of the What's Happening in OpenStack-Ansible (WHOA) report 
is here!

  
https://major.io/2016/08/23/whats-happening-in-openstack-ansible-whoa-august-2016/

Yesterday's report covers the OpenStack-Ansible mid-cycle meeting, the latest 
releases, and links to detailed changes in each release.  Previous reports are 
always available here:

  https://major.io/tag/whoa/

Did you see something in the report you want to know more about?  Is there 
something missing that should have been included?  I love feedback -- send me 
some! :)

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIsBAEBCAAWBQJXvaBPDxxtYWpvckBtaHR4Lm5ldAAKCRBzcFHgwQEfsXC3D/0W
NzygxrJ0YQH4feQBTRWbtMP3mtlCX740nSjM4F1TV0OyH9I7y4xE4SotSVvsOtjB
E0dEp8WPNpfxcmzb1ORu5kMgCYWjyDMs+c9Dk40G3dV3dXwJ/D1xWOOMcwKCzyQr
WHnDxjrkL7nBnWckRX1jGLxeYflEQ4ZVRLK9dTEr8duLuvoZo1gujFbNKsGy0z6R
B0NxIoNGiA4L8lzXHKXLPWjM6Bw6d+K3ZYZ06/g6VQ67BP7J0BaFYqnmpWa5kWVR
+z6bXoCGLJAOP0dTAvdFJ6dOb6SrW1FQGNkmDcn13eY80ecHKs91uFk1htJ2pv28
jKIlYvmGzNxxlqrwkLm5upYnnnujCE6uJydlQ0HO/hQ0lJYGL5FGxsZ5v/Gv65f0
DVPZtra8z2dMl6eOzSEnriIFGBzU5YDALKxGTJvz4N+nfn5o6F2RJLGqOlMWD9/G
h75Vjj8aSYEJQzAAxM3I08ND/zoAf/H9G8SqqdLDlpSu3RfKNK27w0AHucXcFEFq
HNJJFFyiMdiU+Gzt7lJOdSGENxtSRJgGeE07dCUKotP5zB2gZJsv5hRDZJGA0jbV
9oqocygKmx5oaS02/DeS4twROQZiR4p6haV9fe4O28EiTX6zdzN/RdKX3fOmeeKJ
rZyGJ62JU3nV+JAu2tTxhQbIpwjhr89owenXseum5g==
=W15A
-END PGP SIGNATURE-

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

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

2016-08-24 Thread Jeffrey Zhang

On Wed, Aug 24, 2016 at 5:24 PM, lương hữu tuấn  wrote:
> However, with config file as nova.conf or in this case e.g. kolla.conf, it
> should be kolla:kolla and only owner can write as well, it means 644 since
> the kolla service is run under the name of kolla user, it is the same with
> other services in OpenStack.

there is no kolla.conf file in any containers.

>
> With the folder, e.g. /etc/kolla or /etc/nova, it should be also
> read/write/executable with kolla user and kolla group since kolla service
> running with kolla user should have permission to get information from
> kolla.conf.

for the nova.conf, why the nova user need to write/change the nova.conf file?




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

2016-08-24 Thread Kwasniewska, Alicja

+1

From: Eduardo Gonzalez [mailto:dabar...@gmail.com]
Sent: Wednesday, August 24, 2016 1:42 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker 
(Daviey on irc)


+1

On Wed, Aug 24, 2016, 1:25 PM Martin André 
> wrote:
+1

On Tue, Aug 23, 2016 at 10:45 PM, 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
>

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

2016-08-24 Thread Eduardo Gonzalez

+1

On Wed, Aug 24, 2016, 1:25 PM Martin André  wrote:

> +1
>
> On Tue, Aug 23, 2016 at 10:45 PM, 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
> >
>
> __
> OpenStack Development Mailing 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] NoMethodRegisteredException when deploying Murano environment

2016-08-24 Thread Kirill Zaitsev

Hi, it’s impossible to say without knowing what application you’re trying to 
deploy. Also this mailing list is not the best place for usage questions =) 
Please come to our IRC channel #murano — we would try to help you find what 
went wrong.

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

On 24 août 2016 at 05:57:32, wuhan (wuhan9...@163.com) wrote:

listNeutronExtensions

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

[openstack-dev] [all][massively distributed][architecture] Coordination between actions/WGs

2016-08-24 Thread Peter Willis

Colleagues,

I'd like to confirm that scalability and multi-site operations are key to
BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, MEC, IoT, where we will
have compute highly distributed around the network (from thousands to
millions of sites). BT would therefore support a Massively Distributed WG
and/or work on scalability and multi-site operations in the Architecture WG.

Best Regards,
Peter Willis.
BT Research
__
OpenStack Development Mailing 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] [gate] [cinder] A current major cause for gate failure - cinder backups

2016-08-24 Thread Sean Dague


On 08/24/2016 03:24 AM, Li, Xiaoyan wrote:

Hi,

I noticed that as VolumesBackupsV1Test and VolumesBackupsV2Test use same volume 
to do backup creation test etc.
When creating backup from volume, it needs to attach volume. As both two tests 
use same volume, they attach the volume at same time, and leads failure. 
I opened a bug https://bugs.launchpad.net/tempest/+bug/1616338, and will fix it.


Thank you for looking into this. Please let me know when you have any 
patches up to address the bug so we can prioritize them merging.


Have a great day.

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

2016-08-24 Thread Martin André

+1

On Tue, Aug 23, 2016 at 10:45 PM, 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
>

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

2016-08-24 Thread Mooney, Sean K

You can enable dvr today with ovs-dpdk(e.g. netdev datapath) and it will 
function well enough to pass tempet test but no.

Dvr with the netdev datapath has very poor performance. So much so that it is 
not useable in a production deployment.

This is because dvr uses kernel namespace + tap devices to perform the routing. 
Tap devices are not accelerated by dpdk
So when you add them to the dpdk datapath they are not processed in a polling 
manner by the dpdk pmd thread. Tap device
When attached to the netdev datapath are instead processed by the single 
threaded netdev datapath resulting in a maximum forwarding
Rate of ~40,000 pps. To put that in perspective kernel ovs can forward packets 
via a tap device at ~480,000pps
and dpdk will give you 5mpps+ via vhost-user so using dvr with ovs-dpdk today 
is not a viable option.

I did a poc of dvr style routing with neutron 12 months ago based on work I did 
in 2014. The blueprint was rejected as I had not figured out how to fully 
eliminate the network namespaces
In the north sourth case. We started looking at this problem again a few weeks 
ago and hope to develop a solution that will work with all ovs datapath In 
ocata.

Today the best way to get dvr style routing with ovs-dpdk that perfroms well is 
to use a controller such as ovn or odl which implement routing as openflow 
rules.
Using openflow rules for routing which is how my poc worked is more efficient 
then kernel routing even with kernel ovs. With ovs-dpdk openflow routing removes
The bottleneck that is introduced by the linux kernel interfaces allowing the 
full performance of the datapath to be maintained. Both ovn and odl have
Support for ovs-dpdk/vhost-user and both provide openflow based routing that 
can be used today.

Our current recommended configuration when using the ovs neutron agent with 
ovs-dpdk compute nodes is to use centralized ha routing on network nodes 
running kernel ovs or
Use provider routing. Both solutions will give significant performance 
improvements over dvr with ovs-dpdk.

Regards
Sean.

From: huangdenghui [mailto:hdh_1...@163.com]
Sent: Wednesday, August 24, 2016 3:29 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron][networking-ovs-dpdk][dvr] how to use dvr 
with networking-ovs-dpdk

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

Re: [openstack-dev] [TripleO][UI] Port number for frontend app

2016-08-24 Thread Hugh Brock

On Wed, Aug 24, 2016 at 12:18 PM, Dmitry Tantsur  wrote:
> On 08/22/2016 08:08 AM, Honza Pokorny wrote:
>>
>> Hello folks,
>>
>> We've been using port 3000 for the GUI during development and testing.
>> Now that we're working on packaging and shipping our code, we're
>> wondering if port 3000 is still the best choice.
>>
>> Would 3000 conflict with any other services?  Is there a better option?
>
>
> I think the best option is to run it as wsgi in the same Apache instance as
> e.g. Horizon (and I guess Keystone and other services in the future as
> well), just with a different leading path. Not sure how doable it is though.
>

I am sure that that is the Correct Way to do it. We don't want another
process listening on a different port after we've put all this effort
into getting everything in WSGI. Is that doable in the time we have
remaining?

--Hugh

-- 
  ,   ,| Hugh Brock, hbr...@redhat.com
  )-_"""_-(| Director of Engineering, OpenStack Management
 ./ o\ /o \.   | TripleO: Install, configure, and scale OpenStack.
. \__/ \__/ .  | http://rdoproject.org, http://tripleo.org
...   V   ...  |
... - - - ...  | "I know that you believe you understand what you
 .   - -   .   | think I said, but I'm not sure you realize that what
  `-.-´| you heard is not what I meant." --Robert McCloskey
 "TripleOwl"

__
OpenStack Development Mailing 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][UI] Port number for frontend app

2016-08-24 Thread Dmitry Tantsur


On 08/22/2016 08:08 AM, Honza Pokorny wrote:

Hello folks,

We've been using port 3000 for the GUI during development and testing.
Now that we're working on packaging and shipping our code, we're
wondering if port 3000 is still the best choice.

Would 3000 conflict with any other services?  Is there a better option?


I think the best option is to run it as wsgi in the same Apache instance 
as e.g. Horizon (and I guess Keystone and other services in the future 
as well), just with a different leading path. Not sure how doable it is 
though.




Thanks

Honza Pokorny

__
OpenStack Development Mailing 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][UI] Port number for frontend app

2016-08-24 Thread Jiri Tomasek




On 22.8.2016 08:08, Honza Pokorny wrote:

Hello folks,

We've been using port 3000 for the GUI during development and testing.
Now that we're working on packaging and shipping our code, we're
wondering if port 3000 is still the best choice.

Would 3000 conflict with any other services?  Is there a better option?

Thanks

Honza Pokorny

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


It would probably be nice to run it on port 80. Not sure if it will 
collide with anything in undercloud. Horizon maybe?


-- Jirka

__
OpenStack Development Mailing 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] [designate] Meeting Canceled this week

2016-08-24 Thread Hayes, Graham

Hi All,

As we are in the middle of our midcycle, we are going to skip the
meeting this week.

Thanks,

Graham

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

2016-08-24 Thread lương hữu tuấn

Hi Jeffrey,

You are right with the rootwrap file since it is the root wrapper of the
specific service, e.g. nova. Then we should permit it as root:root and only
the owner can write.

However, with config file as nova.conf or in this case e.g. kolla.conf, it
should be kolla:kolla and only owner can write as well, it means 644 since
the kolla service is run under the name of kolla user, it is the same with
other services in OpenStack.

With the folder, e.g. /etc/kolla or /etc/nova, it should be also
read/write/executable with kolla user and kolla group since kolla service
running with kolla user should have permission to get information from
kolla.conf.

Br,

Tuan

On Wed, Aug 24, 2016 at 3:22 AM, Jeffrey Zhang 
wrote:

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

2016-08-24 Thread Paul Bourke


+1

On 23/08/16 21:45, 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



__
OpenStack Development Mailing 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] [tricircle]agenda of weekly meeting Aug.24

2016-08-24 Thread joehuang

Hello, team,



Agenda of Aug.24 weekly meeting:


# progress review and concerns on the features like micro versions, policy 
control, dynamic pod binding, cross pod L2 networking

# How to address TCs concerns in Tricircle big-tent application

# open discussion


How to join:

#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi Huang ( joehuang )
__
OpenStack Development Mailing 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] Nova API sub-team meeting

2016-08-24 Thread Alex Xu

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

Thanks
__
OpenStack Development Mailing 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] [Magnum] Release schedule of magnumclient

2016-08-24 Thread Shuu Mutou

Hi Hongbin,

Also, Magnum-UI will meet "Soft StringFreeze" next week.

If the following BP [1] can reach to release in this cycle, 
I will implement it into Magnum-UI until next week.

How do you think about the release timing of the BP?

[1] https://blueprints.launchpad.net/magnum/+spec/rename-bay-to-cluster


Thanks,
Shu


> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Wednesday, August 24, 2016 6:32 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Magnum] Release schedule of magnumclient
> 
> 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

Re: [openstack-dev] [gate] [cinder] A current major cause for gate failure - cinder backups

2016-08-24 Thread Li, Xiaoyan

Hi,

I noticed that as VolumesBackupsV1Test and VolumesBackupsV2Test use same volume 
to do backup creation test etc. 
When creating backup from volume, it needs to attach volume. As both two tests 
use same volume, they attach the volume at same time, and leads failure. 
I opened a bug https://bugs.launchpad.net/tempest/+bug/1616338, and will fix it.

Best wishes
Lisa

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Wednesday, August 24, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [gate] [cinder] A current major cause for gate failure 
- cinder backups

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

__
OpenStack Development Mailing 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] [vitrage] relationship_type in static_datasources

2016-08-24 Thread Afek, Ifat (Nokia - IL)

Hi Yujun,

Indeed, we have some restrictions on the relationship types that can be used in 
the static datasources. I think we should remove these restrictions, and allow 
any kind of relationship type.

Best regards,
Ifat.

From: Yujun Zhang
Date: Monday, 22 August 2016 at 08:37

I'm following the sample configuration in docs [1] to verify how static 
datasources works.

It seems `backup` relationship is not displayed in the entity graph view and 
neither is it included in topology show.

There is an enumeration for edge labels [2]. Should relationship in static 
datasource be limited to it?

[1] 
https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst
[2] 
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L49
__
OpenStack Development Mailing 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] [searchlight] [glance] Will glance community image sharing make it into Newton?

2016-08-24 Thread Erno Kuvaja

On Tue, Aug 23, 2016 at 8:08 PM, Tripp, Travis S  wrote:
> 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
>
>

Hi Travis,

Thanks for looking forward for the feature. We are not aiming Newton
with this, but more realistically O-1.

Best,
Erno

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

80 matches

Mail list logo