Re: [openstack-dev] [nova] [container] [docker] [magnum] [zun] nova-docker alternatives ?

2016-07-30 Thread Ton Ngo 

for a second I thought that would be a great life cycle operation for
bays  .. :)
Ton,



From:   Adrian Otto 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/29/2016 11:31 AM
Subject:Re: [openstack-dev] [nova] [container] [docker] [magnum] [zun]
nova-docker alternatives ?



s/mentally/centrally/

Autocorrect is not my friend.

  On Jul 29, 2016, at 11:26 AM, Adrian Otto 
  wrote:

  Yasmin,

  One option you have is to use the libvirt-lxc nova virt driver, and
  use an image that has a docker daemon installed on it. That would
  give you a way to place docker containers on a data plane the uses no
  virtualization, but you need to individually manage each instance.
  Another option is to add Magnum to your cloud (with or without a
  libvirt-lxc nova virt driver) and use Magnum to mentally manage each
  container cluster. We refer to such clusters as bays.

  Adrian

On Jul 29, 2016, at 11:01 AM, Yasemin DEMİRAL (BİLGEM BTE) <
yasemin.demi...@tubitak.gov.tr> wrote:


nova-docker is a dead project, i learned irc channel.
I need the hypervisor for nova, and I cant installation
nova-docker in physical openstack systems. In devstack, I could
deploy nova-docker.
What can I do ? openstack-magnum or openstack-zun project is
useful for me ?? I dont know.
Do you have any ideas ?

Yasemin Demiral

__

OpenStack Development Mailing 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] (no subject)

2016-07-30 Thread Farhad Sunavala 
Yes, this was intentionally done.The logical-source-port is important only at 
the point of classification.All successive classifications rely only on the 5 
tuple and MPLS label (chain ID).
Consider an extension of the scenario you mention below.
Sources: (similar to your case)a b
Port-pairs: (added ppe and ppf)ppcppdppeppf
Port-pair-groups: (added ppge and ppgf)ppgcppgdppgeppgf
Flow-classifiers:fc1: logical-source-port of a && tcpfc2: logical-source-port 
of b && tcp
Port-chains:pc1: fc1 && (ppgc + ppge)pc2: fc2 && (ppgd + ppgc + ppgf)


The flow-classifier has logical-src-port and protocol=tcpThe logical-src-port 
has no relevance in the middle of the chain.
In the middle of the chain, the only relevant flow-classifier is protocol=tcp.
If we allow it, we cannot distinguish TCP traffic coming out of ppgc (and 
subsequently ppc) as to whether to mark it with the label for pc1 or the label 
for pc2.
In other words, within a tenant the flow-classifiers need to be unique wrt the 
5 tuples.
thanks,Farhad.
Date: Fri, 29 Jul 2016 18:01:05 +0300
From: Artem Plakunov 
To: openst...@lists.openstack.org
Subject: [Openstack] [networking-sfc] Flow classifier conflict logic
Message-ID: <579b6fb1.3030...@lvk.cs.msu.su>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hello.
We have two deployments with networking-sfc:
mirantis 8.0 (liberty) and mirantis 9.0 (mitaka).

I noticed a difference in how flow classifiers conflict with each other 
which I do not understand. I'm not sure if it is a bug or not.

I did the following on mitaka:
1. Create tenant 1 and network 1
2. Launch vms A and B in network 1
3. Create tenant 2, share network 1 to it with RBAC policy, launch vm C 
in network 1
4. Create tenant 3, share network 1 to it with RBAC policy, launch vm D 
in network 1
5. Setup sfc:
    create two port pairs for vm C and vm D with a bidirectional port
    create two port pair groups with these pairs (one pair in one group)
    create flow classifier 1: logical-source-port = vm A port, protocol 
= tcp
    create flow classifier 2: logical-source-port = vm B port, protocol 
= tcp
    create chain with group 1 and classifier 1
    create chain with group 2 and classifier 2 - this step gives the 
following error:

Flow Classifier 7f37c1ba-abe6-44a0-9507-5b982c51028b conflicts with Flow 
Classifier 4e97a8a5-cb22-4c21-8e30-65758859f501 in port chain 
d1070955-fae9-4483-be9e-0e30f2859282.
Neutron server returns request_ids: 
['req-9d0eecec-2724-45e8-84b4-7ccf67168b03']

The only thing neutron logs have is this from server.log:
2016-07-29 14:15:57.889 18917 INFO neutron.api.v2.resource 
[req-9d0eecec-2724-45e8-84b4-7ccf67168b03 
0b807c8616614b84a4b16a318248d28c 9de9dcec18424398a75a518249707a61 - - -] 
create failed (client error): Flow Classifier 
7f37c1ba-abe6-44a0-9507-5b982c51028b conflicts with Flow Classifier 
4e97a8a5-cb22-4c21-8e30-65758859f501 in port chain 
d1070955-fae9-4483-be9e-0e30f2859282.

I tried the same in liberty and it works and sfc successfully routes 
traffic from both vms to their respective port groups

Liberty setup:
neutron version 7.0.4
neutronclient version 3.1.1
networking-sfc version 1.0.0 (from pip package)

Mitaka setup:
neutron version 8.1.1
neutronclient version 5.0.0 (tried using 3.1.1 with same outcome)
networking-sfc version 1.0.1.dev74 (from master branch commit 
6730b6810355761cf55f04a40cd645f065f15752)

I'll attach the output of commands neutron port-list, port-pair-list, 
port-pair-group-list, flow-classifier-list and port-chain-list.

Is this an intended flow classifier behavior? If so, why? The port 
chains and all their participants are different.
-- next part --
root@node-8:~# neutron port-list
+--+--+---+--+
| id                                  | name | mac_address      | fixed_ips     
                                                                       |
+--+--+---+--+
| 0a75ef50-3d06-467b-8321-a0b9dc406a2b |      | fa:16:3e:e0:48:81 | 
{"subnet_id": "533598bc-0bfd-4e92-9133-33ffe5043d57", "ip_address": 
"172.20.2.168"}  |
| 0c88fc4a-83f7-4194-bb9c-1b5864795e18 |      | fa:16:3e:f3:e9:ea | 
{"subnet_id": "69838436-ff18-40c4-bc62-8811e4ef6c7c", "ip_address": 
"192.168.44.2"}  |
| 0f6bddbb-a5a6-459a-a9b3-d4ae0806e5a6 |      | fa:16:3e:f7:27:1f | 
{"subnet_id": "1e69d4a3-9696-49c0-a5b7-5de71d7db0b5", "ip_address": 
"10.0.40.3"}    |
| 1731aae5-cd3a-4373-b9b9-6bca775ea4c6 |      | fa:16:3e:d7:0f:87 | 
{"subnet_id": "69838436-ff18-40c4-bc62-8811e4ef6c7c", "ip_address": 
"192.168.44.6"}  |
| 1c15d87e-78dd-40b8-ba68-13f55017be01 |      | fa:16:3e:a8:fe:ca | 
{"subnet_id": "533598bc-0bfd-4e92-9133-33ffe5043d57", "ip_address": 
"172.20.2.130"}  |
|

Re: [openstack-dev] [mistral] Promoting Dawid Deja to core reviewers

2016-07-30 Thread Lingxian Kong 
+1, good job, Dawid!

Regards!
---
Lingxian Kong


On Sat, Jul 30, 2016 at 10:59 PM, Elisha, Moshe (Nokia - IL)
 wrote:
> Hi,
>
> I am not a core reviewer but having met Dawid in person and working closely
> with him on some important bug fixes – I fully support the idea.
>
> From: Anastasia Kuznetsova 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Friday, 29 July 2016 at 15:53
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [mistral] Promoting Dawid Deja to core
> reviewers
>
> Renat,
>
> I fully support Dawid's promotion! Here is my +1 for Dawid.
>
> Dawid,
>
> I will be glad to see you in the Mistral core team.
>
> On Fri, Jul 29, 2016 at 2:39 PM, Renat Akhmerov 
> wrote:
>>
>> Hi,
>>
>> I’d like to promote Dawid Deja working at Intel (ddeja in IRC) to Mistral
>> core reviewers.
>>
>> The reasons why I want to see Dawid in the core team is that he provides
>> amazing, very thorough reviews.
>> Just by looking at a few of them I was able to make a conclusion that he
>> knows the system architecture very well
>> although he started contributing actively not so long ago. He always sees
>> things deeply, can examine a problem
>> from different angles, demonstrates solid technical background in general.
>> He is in top 5 reviewers now by a number
>> of reviews and the only one who still doesn’t have core status. He also
>> implemented several very important changes
>> during Newton cycle. Some of them were in progress for more than a year
>> (flexible RPC) but Dawid helped to knock
>> them down elegantly.
>>
>> Besides purely professional skills that I just mentioned I also want to
>> say that it’s a great pleasure to work with
>> Dawid. He’s a bright cheerful guy and a good team player.
>>
>> Dawid’s statistics is here:
>> http://stackalytics.com/?module=mistral-group=commits_id=dawid-deja-0
>>
>>
>> I’m hoping for your support in making this promotion.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Anastasia Kuznetsova
>
> __
> OpenStack Development Mailing 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] [all][tc] establishing project-wide goals

2016-07-30 Thread Amrith Kumar 
Doug,

Thanks for doing this. In the interests of transparency and full disclosure, I 
was at the leadership training and heard about this idea there (and was 
strongly in favor of it then, as I am now).

I think it is very important that OpenStack not devolve into a loose 
confederation of bags of code that are governed in similar ways, but rather a 
collection of software that address a set of meaningful needs in a consistent 
and compatible way. The goal is that to operators and deployers, OpenStack is a 
platform consisting of projects that work well together (the thing I called 
'consistent and compatible' earlier).

I see from the comments in the review [1] that there is some concern about the 
section on 'acknowledgement'.

Of what material benefit is it if the TC were to mandate something and the 
communication to the projects is some open-loop process? The 'acknowledgement' 
that Doug refers to in the review is merely a mechanism to 'close' that loop 
and ensure that projects affirm that they have been informed of the project 
wide goals, and that the PTL's will take some concrete steps that can be 
tracked through our usual processes (bugs, reviews, and so on) to ensure that 
the mandates are met.

To a more coherent and consistent platform!

-amrith



> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Friday, July 29, 2016 4:55 PM
> To: openstack-dev 
> Subject: [openstack-dev] [all][tc] establishing project-wide goals
> 
> One of the outcomes of the discussion at the leadership training
> session earlier this year was the idea that the TC should set some
> community-wide goals for accomplishing specific technical tasks to
> get the projects synced up and moving in the same direction.
> 
> After several drafts via etherpad and input from other TC and SWG
> members, I've prepared the change for the governance repo [1] and
> am ready to open this discussion up to the broader community. Please
> read through the patch carefully, especially the "goals/index.rst"
> document which tries to lay out the expectations for what makes a
> good goal for this purpose and for how teams are meant to approach
> working on these goals.
> 
> I've also prepared two patches proposing specific goals for Ocata
> [2][3].  I've tried to keep these suggested goals for the first
> iteration limited to "finish what we've started" type items, so
> they are small and straightforward enough to be able to be completed.
> That will let us experiment with the process of managing goals this
> time around, and set us up for discussions that may need to happen
> at the Ocata summit about implementation.
> 
> For future cycles, we can iterate on making the goals "harder", and
> collecting suggestions for goals from the community during the forum
> discussions that will happen at summits starting in Boston.
> 
> Doug
> 
> [1] https://review.openstack.org/349068 describe a process for managing
> community-wide goals
> [2] https://review.openstack.org/349069 add ocata goal "support python
> 3.5"
> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo
> libraries"
> 
> __
> OpenStack Development Mailing 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] [oslo][nova][requirements] Getting oslo.context 2.6.0 into the gate

2016-07-30 Thread Amrith Kumar 
Jamie,

I’ve updated your review re: u-c oslo.context==2.7.0 in Trove. It will fail but 
that is understood. I’ve manually tested o.c 2.7.0 and it appears to work.

-amrith

From: Jamie Lennox [mailto:jamielen...@gmail.com]
Sent: Saturday, July 30, 2016 2:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [oslo][nova][requirements] Getting oslo.context 
2.6.0 into the gate



On 27 July 2016 at 19:10, Tony Breeds 
> wrote:
On Mon, Jul 18, 2016 at 04:09:54PM +0200, Markus Zoeller wrote:
> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
> Portland and won't be available for the next 2h or so.
> If you can have a look at it and merge it, that would be great.
>
> References:
> [1]
> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
> [2] https://review.openstack.org/#/c/342604/1
> [3] https://bugs.launchpad.net/nova/+bug/1603979
> [4] logstash: http://goo.gl/79yFb9

I feel like we need to make a plan to more forward and that's going to require
some coordination.

The requirements team saw this coming in that nova's tests failed when 2.6.0
was added to the upper-constraints.txt.  We had a plan[1] but then failed to
execute.  The requirements team has a couple of TODOs from there but the
biggest one is to add actual cross-project gate checks so that we have *very
strong* signals that things will break.

So the state we're in is
oslo.context 2.6.0 is out and used in all projects that *do not* honor 
upper-constraints.txt
oslo.context 2.5.0 is being used by all projects that *do* honor 
upper-constraints.txt

The Path forward IMO is

a) Unblock oslo.context 2.6.0
- But leave upper-constraints.txt pointing to 2.5.0
- https://review.openstack.org/#/c/347608/
* We can test shims/fixes against this.

I think this gets easier with the release of 2.7 as we can hopefully just bump 
minimum requirements to here and forget the whole 2.6 mess.

b) Identify projects that break with > 2.5.0
- Seems like this is (at least)
- Trove

check job: https://review.openstack.org/#/c/349204/
[amrith] see comment above; this will not pass. Updated the review. Trove does 
respect u-c and is currently using 2.5.0; it respects the blacklist of 2.6.0.
- Nova

check job: https://review.openstack.org/#/c/348204/
- Designate

check job: https://review.openstack.org/#/c/349205/
- Others?
c) Add shims to them to work with 2.5.0 and newer
- Nova: https://review.openstack.org/#/c/342604/ and 
https://review.openstack.org/#/c/348057/
d) Bump u-c to point at "the latest"
e) Bump the minium in g-r to 2.6.0
f) Remove items from 'c'

Notes:
 - The requirements team will not be able to merge any change that bumps
   oslo.context in u-c until step 'd'.  The reality here is due to our
   tooling/gating that probably means that all u-c changes will be paused
 - As stated in my pre-amble we're working on testing to make this better.
 - We almost certainly need a corss-project session during the design summit to
   discuss the API boundry for the context and how projects are
   expected/allowed to use it.

Thanks Tony. I think this will work well. I hope not many other projects will 
need the same shims nova did as we've patched a few already.
I completely agree on the cross-project oslo.context session and offer to take 
that one as there are a number of plans around improving it that have not been 
properly communicated.

Yours Tony.

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2016-07-15.log.html#t2016-07-15T03:42:24

__
OpenStack Development Mailing 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] Retirement of openstack/cloud-init repository

2016-07-30 Thread Joshua Harlow 
Right this is step #1 there, although slightly different because this 
project isn't really retired, its just moved to a different place; but 
good enough :-P


Andreas Jaeger wrote:

On 07/30/2016 03:20 AM, Morgan Fainberg wrote:

[...]
As I recall we no longer "move" the git repositories. We simply remove
the permissions/ACLs so new reviews aren't added/approved, and often the
repo is emptied with only a readme pointing to the new location.


Full documentation for the steps:
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

Andreas


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

[openstack-dev] [neutron] Metering agent add port statistics

2016-07-30 Thread Gilad Zohari 
Hi,

You posted a project for "Google summer of code 2016" named: "Neutron - 
Metering agent add port statistics".
https://wiki.openstack.org/wiki/Internship_ideas

The project is listed as 'Open' on the wiki and i could’t find a "open project" 
regarding this on the GSOC website or project:openstack/neutron. 

If this project has not been taken up by GSOC2016, can I offer to implement 
this outside of GSOC2016?

If so, would it be possible to discuss this with rosella_s , the proposed GSOC 
mentor for this project?

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

Re: [openstack-dev] [oslo][nova][requirements] Getting oslo.context 2.6.0 into the gate

2016-07-30 Thread Jamie Lennox 
On 27 July 2016 at 19:10, Tony Breeds  wrote:

> On Mon, Jul 18, 2016 at 04:09:54PM +0200, Markus Zoeller wrote:
> > Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
> > change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
> > Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
> > Portland and won't be available for the next 2h or so.
> > If you can have a look at it and merge it, that would be great.
> >
> > References:
> > [1]
> >
> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
> > [2] https://review.openstack.org/#/c/342604/1
> > [3] https://bugs.launchpad.net/nova/+bug/1603979
> > [4] logstash: http://goo.gl/79yFb9
>
> I feel like we need to make a plan to more forward and that's going to
> require
> some coordination.
>
> The requirements team saw this coming in that nova's tests failed when
> 2.6.0
> was added to the upper-constraints.txt.  We had a plan[1] but then failed
> to
> execute.  The requirements team has a couple of TODOs from there but the
> biggest one is to add actual cross-project gate checks so that we have
> *very
> strong* signals that things will break.
>
> So the state we're in is
> oslo.context 2.6.0 is out and used in all projects that *do not* honor
> upper-constraints.txt
> oslo.context 2.5.0 is being used by all projects that *do* honor
> upper-constraints.txt
>
> The Path forward IMO is
>
> a) Unblock oslo.context 2.6.0
> - But leave upper-constraints.txt pointing to 2.5.0
> - https://review.openstack.org/#/c/347608/
> * We can test shims/fixes against this.
>

I think this gets easier with the release of 2.7 as we can hopefully just
bump minimum requirements to here and forget the whole 2.6 mess.


> b) Identify projects that break with > 2.5.0
> - Seems like this is (at least)
> - Trove
>

check job: https://review.openstack.org/#/c/349204/

- Nova
>

check job: https://review.openstack.org/#/c/348204/

- Designate
>

check job: https://review.openstack.org/#/c/349205/

- Others?
> c) Add shims to them to work with 2.5.0 and newer
> - Nova: https://review.openstack.org/#/c/342604/ and
> https://review.openstack.org/#/c/348057/
> d) Bump u-c to point at "the latest"
> e) Bump the minium in g-r to 2.6.0
> f) Remove items from 'c'
>
> Notes:
>  - The requirements team will not be able to merge any change that bumps
>oslo.context in u-c until step 'd'.  The reality here is due to our
>tooling/gating that probably means that all u-c changes will be paused
>  - As stated in my pre-amble we're working on testing to make this better.
>  - We almost certainly need a corss-project session during the design
> summit to
>discuss the API boundry for the context and how projects are
>expected/allowed to use it.
>

Thanks Tony. I think this will work well. I hope not many other projects
will need the same shims nova did as we've patched a few already.
I completely agree on the cross-project oslo.context session and offer to
take that one as there are a number of plans around improving it that have
not been properly communicated.


> Yours Tony.
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2016-07-15.log.html#t2016-07-15T03:42:24
>
> __
> OpenStack Development Mailing 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][stable] Please consider our application for stable:follows-policy for Kolla

2016-07-30 Thread Steven Dake (stdake) 
Hey folks,

I just wanted to let the core team and others in the community know this tag 
application was rejected.  The Kolla core team made a choice when we decided to 
make Liberty non-dangerous.  We knew at the time it would imperil an 
application for stable:follows-policy.  We thought at the time, and I still 
believe we made the right call that having a working Liberty was more important 
then having a tag in the governance repository.

The tag does explain expectations, which we should follow even though our 
application was rejected.  We as a team have already committed to supporting 
Kolla z streams (aka maintenance releases) on a 45 day schedule and to follow 
the stable policy.  Let's continue to stick with that activity, follow 
stable:follows-policy, and do the right thing for Operators and OpenStack.

Regards
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Saturday, July 23, 2016 at 12:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][stable] Please consider our application for 
stable:follows-policy for Kolla

[Forgot kolla tag]

From: Steven Dake >
Date: Saturday, July 23, 2016 at 12:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [stable] Please consider our application for stable:follows-policy for 
Kolla

Hey folks,

The review is here:
https://review.openstack.org/346455
__
OpenStack Development Mailing 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] Retirement of openstack/cloud-init repository

2016-07-30 Thread Andreas Jaeger 
On 07/30/2016 03:20 AM, Morgan Fainberg wrote:
> [...]
> As I recall we no longer "move" the git repositories. We simply remove
> the permissions/ACLs so new reviews aren't added/approved, and often the
> repo is emptied with only a readme pointing to the new location.

Full documentation for the steps:
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

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


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

Re: [openstack-dev] [mistral] Promoting Dawid Deja to core reviewers

2016-07-30 Thread Elisha, Moshe (Nokia - IL) 
Hi,

I am not a core reviewer but having met Dawid in person and working closely 
with him on some important bug fixes – I fully support the idea.

From: Anastasia Kuznetsova 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, 29 July 2016 at 15:53
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [mistral] Promoting Dawid Deja to core reviewers

Renat,

I fully support Dawid's promotion! Here is my +1 for Dawid.

Dawid,

I will be glad to see you in the Mistral core team.

On Fri, Jul 29, 2016 at 2:39 PM, Renat Akhmerov 
> wrote:
Hi,

I’d like to promote Dawid Deja working at Intel (ddeja in IRC) to Mistral core 
reviewers.

The reasons why I want to see Dawid in the core team is that he provides 
amazing, very thorough reviews.
Just by looking at a few of them I was able to make a conclusion that he knows 
the system architecture very well
although he started contributing actively not so long ago. He always sees 
things deeply, can examine a problem
from different angles, demonstrates solid technical background in general. He 
is in top 5 reviewers now by a number
of reviews and the only one who still doesn’t have core status. He also 
implemented several very important changes
during Newton cycle. Some of them were in progress for more than a year 
(flexible RPC) but Dawid helped to knock
them down elegantly.

Besides purely professional skills that I just mentioned I also want to say 
that it’s a great pleasure to work with
Dawid. He’s a bright cheerful guy and a good team player.

Dawid’s statistics is here: 
http://stackalytics.com/?module=mistral-group=commits_id=dawid-deja-0


I’m hoping for your support in making this promotion.

Thanks

Renat Akhmerov
@Nokia


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




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

[openstack-dev] [Neutron] Mid-cycle agenda

2016-07-30 Thread Armando M. 
Neutrinos,

For those of you who are going to attend the Neutron mid-cycle [1] in
person or be engaged on IRC, please refer to [2] for a list of topics we
should give some attention and priority during our time in Cork.

The list of topics is already pretty packed, however if you would like to
include some other topic please reach out to me and we will find a
place/time for it.

As usual we'll report back on the ML on the progress made and following
steps ahead of Feature Freeze.

Many thanks,
Armando

[1] https://etherpad.openstack.org/p/newton-neutron-midcycle
[2] https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems
__
OpenStack Development Mailing 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][tc] establishing community-wide goals

2016-07-30 Thread Qiming Teng 
Thanks for working on this.
Modified the subject to be 'community-wide goals'.

-Qiming
On Fri, Jul 29, 2016 at 04:55:22PM -0400, Doug Hellmann wrote:
> One of the outcomes of the discussion at the leadership training
> session earlier this year was the idea that the TC should set some
> community-wide goals for accomplishing specific technical tasks to
> get the projects synced up and moving in the same direction.
> 
> After several drafts via etherpad and input from other TC and SWG
> members, I've prepared the change for the governance repo [1] and
> am ready to open this discussion up to the broader community. Please
> read through the patch carefully, especially the "goals/index.rst"
> document which tries to lay out the expectations for what makes a
> good goal for this purpose and for how teams are meant to approach
> working on these goals.
> 
> I've also prepared two patches proposing specific goals for Ocata
> [2][3].  I've tried to keep these suggested goals for the first
> iteration limited to "finish what we've started" type items, so
> they are small and straightforward enough to be able to be completed.
> That will let us experiment with the process of managing goals this
> time around, and set us up for discussions that may need to happen
> at the Ocata summit about implementation.
> 
> For future cycles, we can iterate on making the goals "harder", and
> collecting suggestions for goals from the community during the forum
> discussions that will happen at summits starting in Boston.
> 
> Doug
> 
> [1] https://review.openstack.org/349068 describe a process for managing 
> community-wide goals
> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
> libraries"
> 
> __
> OpenStack Development Mailing 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