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] (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: openstack@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"}  |
|

[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-operators] External access to OpenStack services

2016-07-30 Thread Matt Fischer 
I'd say that operators running Glance, which is probably almost everyone,
just put a public glance endpoint in the catalog. Maybe there's some
special cases beyond that but that's the base design.

On Jul 30, 2016 6:22 PM, "Serguei Bezverkhi (sbezverk)" 
wrote:

> Hi Joseph,
>
>
>
> I am working on kolla-kubernetes project, you probably heard about it. At
> this point, we have some services, example glance, running on the
> kubernetes cluster which we need to expose to external users. My goal is to
> collect information about how OpenStack operators provide access for their
> external users so we would consider it during designing of our approach of
> exposing these services. More details we get from the operators community,
> more chance that we will design something that will not break your current
> practices when eventually you move to run your Openstack services in
> kubernetes environment.
>
>
>
> Thank you
>
>
>
> Serguei
>
>
>
> *From:* Joseph Bajin [mailto:josephba...@gmail.com]
> *Sent:* Saturday, July 30, 2016 4:03 PM
> *To:* Serguei Bezverkhi (sbezverk) 
> *Cc:* openstack-operators@lists.openstack.org
> *Subject:* Re: [Openstack-operators] (no subject)
>
>
>
> We let our people access the Glance API.  Glance uses Keystone, so user
> authentication is done the same way all the other services are done within
> OpenStack.  We allow the glance api ports to be available to them so they
> can use the service.
>
>
>
> What are you thinking that would prevent you from offering this to your
> customers?  I'm curious to know as glance is used in a lot of places.
>
>
>
> On Fri, Jul 29, 2016 at 4:30 PM, Serguei Bezverkhi (sbezverk) <
> sbezv...@cisco.com> wrote:
>
>
> Hello folks,
>
> I am curious if any of you allow your cliens to access let's say glance
> API by using glance client cli. If you do, I would appreciate if you could
> share how it is done. Do you expose glance api ports to outside with some
> sort of authentication proxy protection or it is done differently.
>
> Thank you
>
> Serguei
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] (no subject)

2016-07-30 Thread Joseph Bajin 
We let our people access the Glance API.  Glance uses Keystone, so user
authentication is done the same way all the other services are done within
OpenStack.  We allow the glance api ports to be available to them so they
can use the service.

What are you thinking that would prevent you from offering this to your
customers?  I'm curious to know as glance is used in a lot of places.

On Fri, Jul 29, 2016 at 4:30 PM, Serguei Bezverkhi (sbezverk) <
sbezv...@cisco.com> wrote:

>
> Hello folks,
>
> I am curious if any of you allow your cliens to access let's say glance
> API by using glance client cli. If you do, I would appreciate if you could
> share how it is done. Do you expose glance api ports to outside with some
> sort of authentication proxy protection or it is done differently.
>
> Thank you
>
> Serguei
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[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] DiscoveryFailure: Could not determine a suitable URL for the plugin

2016-07-30 Thread William Josefsson 
I found a typo for auth_url in nova.conf [neutron] that caused this error!

On Sat, Jul 30, 2016 at 11:13 PM, William Josefsson <
william.josef...@gmail.com> wrote:

> Hi list, I get this error on centos 7 and liberty when I try to boot a
> small vm. Anyone who can share what may be causing this? Will
>
>
> $ nova boot --image Cirros --flavor m1.tiny --nic
> net-id=e8e69f4d-d650-4f08-1252-bd8adfc192cb \
> --security-group default --key-name mykey myinstance
>
> ERROR (ClientException): Unexpected API Error. Please report this at
> http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
>  (HTTP 500)
> (Request-ID: req-1343e5c3-62d3-4818-a7fb-26f5c61da381)
>
>
> # NOVA-API.LOG ON CONTROLLER
>
> 2016-07-30 23:05:11.678 3358 WARNING oslo_config.cfg
> [req-1343e5c3-62d3-4818-a7fb-26f5c61da381 f722963394d74760947e297bd1f7e794
> 03f3af397b254c1980f51cf41a9503ee - - -] Option "username" from group
> "neutron" is deprecated. Use option "user-name" from group "neutron".
> *2016-07-30 23:05:11.703 3358 WARNING
> keystoneclient.auth.identity.generic.base
> [req-1343e5c3-62d3-4818-a7fb-26f5c61da381 f722963394d74760947e297bd1f7e794
> 03f3af397b254c1980f51cf41a9503ee - - -] Discovering versions from the
> identity service failed when creating the password plugin. Attempting to
> determine version from URL.*
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> [req-1343e5c3-62d3-4818-a7fb-26f5c61da381 f722963394d74760947e297bd1f7e794
> 03f3af397b254c1980f51cf41a9503ee - - -] Unexpected exception in API method
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions Traceback
> (most recent call last):
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line
> 478, in wrapped
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> return f(*args, **kwargs)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line
> 73, in wrapper
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> return func(*args, **kwargs)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line
> 73, in wrapper
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> return func(*args, **kwargs)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py",
> line 611, in create
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> **create_kwargs)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/hooks.py", line 149, in inner
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions rv =
> f(*args, **kwargs)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1587, in create
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> check_server_group_quota=check_server_group_quota)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1187, in
> _create_instance
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> auto_disk_config, reservation_id, max_count)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 961, in
> _validate_and_build_base_options
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> pci_request_info, requested_networks)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
> 1092, in create_pci_requests_for_sriov_ports
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> neutron = get_client(context, admin=True)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 237,
> in get_client
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> auth_token = _ADMIN_AUTH.get_token(_SESSION)
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py",
> line 200, in get_token
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> return self.get_access(session).auth_token
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
> "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py",
> line 240, in get_access
> 2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
> self.auth_ref = self.get_auth_ref(session)
> 2016-07-30 23:05:11.704 3358 ERROR

[Openstack] DiscoveryFailure: Could not determine a suitable URL for the plugin

2016-07-30 Thread William Josefsson 
Hi list, I get this error on centos 7 and liberty when I try to boot a
small vm. Anyone who can share what may be causing this? Will


$ nova boot --image Cirros --flavor m1.tiny --nic
net-id=e8e69f4d-d650-4f08-1252-bd8adfc192cb \
--security-group default --key-name mykey myinstance

ERROR (ClientException): Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
 (HTTP 500)
(Request-ID: req-1343e5c3-62d3-4818-a7fb-26f5c61da381)


# NOVA-API.LOG ON CONTROLLER

2016-07-30 23:05:11.678 3358 WARNING oslo_config.cfg
[req-1343e5c3-62d3-4818-a7fb-26f5c61da381 f722963394d74760947e297bd1f7e794
03f3af397b254c1980f51cf41a9503ee - - -] Option "username" from group
"neutron" is deprecated. Use option "user-name" from group "neutron".
*2016-07-30 23:05:11.703 3358 WARNING
keystoneclient.auth.identity.generic.base
[req-1343e5c3-62d3-4818-a7fb-26f5c61da381 f722963394d74760947e297bd1f7e794
03f3af397b254c1980f51cf41a9503ee - - -] Discovering versions from the
identity service failed when creating the password plugin. Attempting to
determine version from URL.*
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
[req-1343e5c3-62d3-4818-a7fb-26f5c61da381 f722963394d74760947e297bd1f7e794
03f3af397b254c1980f51cf41a9503ee - - -] Unexpected exception in API method
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions Traceback
(most recent call last):
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line
478, in wrapped
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions return
f(*args, **kwargs)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line
73, in wrapper
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions return
func(*args, **kwargs)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line
73, in wrapper
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions return
func(*args, **kwargs)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py",
line 611, in create
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
**create_kwargs)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/hooks.py", line 149, in inner
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions rv =
f(*args, **kwargs)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1587, in create
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
check_server_group_quota=check_server_group_quota)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1187, in
_create_instance
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
auto_disk_config, reservation_id, max_count)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 961, in
_validate_and_build_base_options
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
pci_request_info, requested_networks)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line
1092, in create_pci_requests_for_sriov_ports
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
neutron = get_client(context, admin=True)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 237,
in get_client
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
auth_token = _ADMIN_AUTH.get_token(_SESSION)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py",
line 200, in get_token
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions return
self.get_access(session).auth_token
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py",
line 240, in get_access
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
self.auth_ref = self.get_auth_ref(session)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/generic/base.py",
line 184, in get_auth_ref
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions
self._plugin = self._do_create_plugin(session)
2016-07-30 23:05:11.704 3358 ERROR nova.api.openstack.extensions   File

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-operators] [kolla] question of default users for operators

2016-07-30 Thread Fox, Kevin M 
+1


From: Melvin Hillsman
Sent: Friday, July 29, 2016 9:22:02 PM
To: Steven Dake (stdake); openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [kolla] question of default users for 
operators

Personally, if OpenStack default is to have a member or _member_ as an operator 
I would prefer there be a user according to the default.

Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org


From: "Steven Dake (stdake)"
Date: Friday, July 29, 2016 at 10:35 PM
To: 
"openstack-operators@lists.openstack.org"
Subject: [Openstack-operators] [kolla] question of default users for operators

Hey folks,

In Kolla we have a significant bug in that Horizon can't be used because it 
requires a member user.  We have a few approaches to fixing this problem in 
mind, but want to understand what Operators want.  Devstack itself has switched 
between member and _member_ although Devstack isn't our reference: Operators 
are.

Which of those do operators prefer (if either).

Another question was whether we should create a default user named "user" and 
use this in place of member.

Thoughts welcome.

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

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