Re: [openstack-dev] [neutron] Social at the summit

[Darek Smigiel]

Great idea Kyle,
This place looked awesome.

FYI, I’ve sent request for reservation. Just in case if Thursday would be 
crowded, especially that a lot of teams could have the same idea.

Thanks,
Darek

> On Apr 26, 2016, at 8:27 PM, Kyle Mestery  wrote:
> 
> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a reservation 
> but it should be able to hold 50+ people. See y'all at 6PM Thursday!
> 
> Kyle
> 
>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery  wrote:
>> 
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>> 
>> Thanks folks!
>> 
>>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
>>> +1 :)
>>> 
>>> Han Zhou
>>> Irc: zhouhan
>>> 
>>> 
>>> On Monday, April 25, 2016, Korzeniewski, Artur
>>>  wrote:
 
 Sign me up :)
 
 Artur
 IRC: korzen
 
 -Original Message-
 From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
 Sent: Monday, April 25, 2016 7:19 PM
 To: OpenStack Development Mailing List (not for usage questions)
 
 Subject: Re: [openstack-dev] [neutron] Social at the summit
 
 Count me in!
 Will be good to meet all you guys!
 
 Darek (dasm) Smigiel
 
> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>  wrote:
> 
> 
>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
>> wrote:
>> 
>> WAT???
>> 
>> It was never supposed to be core only. Everyone is welcome!
> 
> +2
> 
> irony intended.
> 
> Socials are not controlled by gerrit ACLs.  :-)
> 
> doug
> 
>> 
>> Sent from my iPhone
>> 
>>> On 25 Apr 2016, at 11:56, Edgar Magana 
>>> wrote:
>>> 
>>> Would you extend it to ex-cores?
>>> 
>>> Edgar
>>> 
>>> 
>>> 
>>> 
 On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
 
 Ihar, Henry and I were talking and we thought Thursday night makes
 sense for a Neutron social in Austin. If others agree, reply on this 
 thread
 and we'll find a place.
 
 Thanks!
 Kyle
 
 ___
 ___ OpenStack Development Mailing 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
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing 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 

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[Bharath Kumar Gubbala]

Thanks madhu, I will try it out below patchset.

From: Madhusudhan Kandadai [madhusudhan.openst...@gmail.com]
Sent: 27 April 2016 03:28
To: Bharath Kumar Gubbala
Cc: OpenStack Development Mailing List (not for usage questions); Alex 
Geevarghese; Paul Michali; hen...@gessau.net
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

Hi Bharath,

Yes. Did you have this patch 
https://review.openstack.org/#/c/281493/
 before you run "tox -e api" ? There was a change in neutron that removed vpn 
and fw tests and its in their tree. However, to make it work for vpn api tests, 
we need to figure out a way to implement the changes in vpn tree. However for 
time being, patch 281493 needs to be cherry picked until we get a timeline to 
implement in vpnaas tree.

If you have cycles, feel free to take on 
https://review.openstack.org/#/c/281493
 and once that merges, 
https://review.openstack.org/#/c/279787/
 is the traditional way of running tempest tests using tempest plugin. Hope 
this helps.

Regards,
Madhu

On Mon, Apr 25, 2016 at 11:14 AM, Bharath Kumar Gubbala 
> wrote:

Hi Henry,


Do you have any info on below query in the thread.(is 'tox -e api' working in 
neutron-vpnaas ?)



Thanks,

bharath



From: bharath >
Sent: 08 April 2016 01:53
To: OpenStack Development Mailing List (not for usage questions); Alex 
Geevarghese; 
madhusudhan.openst...@gmail.com; 
p...@michali.net
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

Thanks Paul for info.

Yes i had run the tests locally under VPN-repo.

My analysis:

  *   VPN test cases were using the neutron client for VPN services 
(which no longer supported by neutron).

 Thats why its throwing "tempest.lib.exceptions.NotFound: 
Object not found"

  *   In the case of FW , there were using router client directly 
instead of neutron client.


I will check with madhusudhan for additional info.



Madhu,
Let me know if you have info on "tox api" support.
If it is an known issue, i can take it up and complete fix

Thanks,
bharath




On Friday 08 April 2016 01:00 AM, Paul Michali wrote:
Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved to the 
VPN repo, but I don't know if a job was ever created for this so that the tests 
actually run. You may want to check with the author who moved the tests 
(madhusudan-kandadai) under commit 3cae934a, to see if the CI job was ever 
created. It is possible that it was never completed.

Likewise, I don't know if support was added to tox.ini for the api test. I've 
never run the test, granted I've been away from VPN for a while and only 
involved intermittently since Liberty, so I may be a bit out of touch.

Regards,

PCM


On Thu, Apr 7, 2016 at 2:23 PM bharath 
> wrote:

Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1
  ==> In this commit messages it says it kindof expected failure.

Can someone provide some clarification on this

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

Re: [openstack-dev] backwards compatibility followup

[Robert Collins]

On 26 April 2016 at 18:41, Ian Cordasco  wrote:
>
>> On Apr 26, 2016, at 6:32 PM, Perry, Sean  wrote:
>>
>> What if we update the docs and tell people to put any services on a shared 
>> system into independent virtualenvs?
>>
>> If a box only runs neutron or whatever all is well. The issue happens when 
>> you mix and match services on a single host. Which is exactly what 
>> virtualenv was intended to fix.
>
> Except that a fair portion of respondents to the OpenStack User Survey talk 
> about using packages provided by the distribution of Linux they happen to be 
> on. Those cannot be installed into virtual environments.

Right. The specific situation is 'same python environment' - so distro
packages all land in the same python environment. You can make
packages of virtualenvs and other such things - and folk wanting to be
able to do same-node-no-container-distro-package in-place upgrade
solutions would be looking at such things if we decide we don't want
to support/enable this.

Some distros were in the room, and e.g. I believe it was Dan that said
RH don't support - in their packaging - mixed versions: upgrade nova,
and neutron would be upgraded too in the given example. So its
possible that while some folk aspire to it, many other folk are either
accepting downtime, or running their control plane on isolated
operating system instances (whether physical, VM or containers is
irrelevant).

At the party tonight I ran into Brian Demers and a colleague whose
name I have forgotten :( - but they have a backwards compat use case
we hadn't touched on in the session: running their Neutron plugin
against both stable and master of Neutron.

This is a classic colocation situation. There are a few possible scenarios:
 - run stable branches of the plugin and backport everything
- tricky if new oslo features are needed, but the existing pattern.
- also tricky for users, since there would be lots of releases of
both stable and master
 - run master against stable neutron using stable neutron oslo
 - means they can't use any new oslo features, and they would
depend on oslo not breaking any API's they use in master - so depends
on oslo API compat
 - or they have to provide backports within their tree and monkey
patch them into place, of new/changed things from oslo
 - run master against stable neutron using master oslo
- means neutron would have to work with master oslo - so the same
compat story, just from the other side


(Clearly there are also Neutron API driver things to discuss, but this
is in the context of the libraries thread :)).

I wonder how many other folk are trying to attempt such a thing -
anyone care to raise their metaphorical hand?

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Place kolla-mesos in openstack-attic

[Kwasniewska, Alicja]

+1

Kind regards,
Alicja Kwaśniewska

From: Vikram Hosakote (vhosakot) [mailto:vhosa...@cisco.com]
Sent: Tuesday, April 26, 2016 9:44 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

+1 for the attic.

Regards,
Vikram Hosakote
IRC: vhosakot

From: Ryan Hallisey >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, April 25, 2016 at 5:00 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

+1

- Original Message -
From: "Angus Salkeld" >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Sent: Sunday, April 24, 2016 11:01:38 AM
Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in
openstack-attic



+1
On Sat, 23 Apr 2016 3:08 am Michał Rostecki < 
michal.roste...@gmail.com > wrote:


+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

__
OpenStack Development Mailing 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] More on the topic of DELIMITER, the Quota Management Library proposal

[Vilobh Meshram]

Thanks everyone for being there at the Design Summit talk on Cross project
Quotas.

Points from the discussion are captured in this etherpad[1] for reference.

-Vilobh
[1] https://etherpad.openstack.org/p/newton-quota-library

On Tue, Apr 26, 2016 at 9:33 AM, Jay Pipes  wrote:

> On 04/25/2016 02:05 PM, Joshua Harlow wrote:
>
>> Is the generation stuff going to be exposed outside of the AP?
>>
>
> No, wasn't planning on it.
>
> I'm sort of hoping not(?), because a service (if one everyone wanted to
>> create it) for say zookeeper (or etcd or consul...) could use its
>> built-in generation equivalent (every znode has a version that u can use
>> to do equivalent things).
>>
>> Thus it's like the gist I posted earlier @
>>
>> https://gist.github.com/harlowja/e7175c2d76e020a82ae94467a1441d85
>>
>> So might be nice to not expose such a thing outside of the db-layer.
>>
>> Amrith Kumar wrote:
>>
>>> On Sat, 2016-04-23 at 21:41 +, Amrith Kumar wrote:
>>>
 Ok to beer and high bandwidth. FYI Jay the distributed high perf db we
 did a couple of years ago is now open source. Just saying. Mysql plug
 compatible 

>>>
>>> -amrith


 --
 Amrith Kumar
 amr...@tesora.com


  Original message 
 From: Jay Pipes
 Date: 04/23/2016 4:10 PM (GMT-05:00)
 To: Amrith Kumar,
 openstack-dev@lists.openstack.org
 Cc: vilob...@yahoo-inc.com, nik.koma...@gmail.com, Ed Leafe
 
 Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Quota
 Management Library proposal


 Looking forward to arriving in Austin so that I can buy you a beer,
 Amrith, and have a high-bandwidth conversation about how you're
 wrong. :P

>>>
>>>
>>> Jay and I chatted and it took a long time to come to an agreement
>>> because we weren't able to find any beer.
>>>
>>> Here's what I think we've agreed about. The library will store data in
>>> two tables;
>>>
>>> 1. the detail table which stores the individual claims and the resource
>>> class.
>>> 2. a generation table which stores the resource class and a generation.
>>>
>>> When a claim is received, the requestor performs the following
>>> operations.
>>>
>>> begin
>>>
>>>  select sum(detail.claims) as total_claims,
>>>  generation.resource as resource,
>>>  generation.generation last_generation
>>>  from detail, generation
>>>  where detail.resource = generation.resource
>>>  and generation.resource =
>>>  group by generation.generation, generation.resource
>>>
>>>  if total_claims + this_claim<  limit
>>>  insert into detail values (this_claim, resource)
>>>
>>>  update generation
>>>  set generation = generation + 1
>>>  where generation = last_generation
>>>
>>>  if @@rowcount = 1
>>>  -- all good
>>>  commit
>>>  else
>>>  rollback
>>>  -- try again
>>>
>>>
>>>
>>> There will be some bootstrapping that will be required for the situation
>>> where there are no detail records for a given resource and so on but I
>>> think we can figure that out easily. The easiest way I can think of
>>> doing that is to lose the join and do both the queries (one against the
>>> detail and one against the generation table within the same
>>> transaction).
>>>
>>> Using the generation table update as the locking mechanism that prevents
>>> multiple requestors from making concurrent claims.
>>>
>>> So long as people don't go and try and read these tables and change
>>> tables outside of the methods that the library provides, we can
>>> guarantee that this is al safe and will not oversubscribe.
>>>
>>> -amrith
>>>
>>> Comments inline.

 On 04/23/2016 11:25 AM, Amrith Kumar wrote:

> On Sat, 2016-04-23 at 10:26 -0400, Andrew Laski wrote:
>
>> On Fri, Apr 22, 2016, at 09:57 PM, Tim Bell wrote:
>>
>> I have reservations on f and g.
>>>
>>>
>>> On f., We have had a number of discussions in the past about
>>> centralising quota (e.g. Boson) and the project teams of the other
>>> components wanted to keep the quota contents ‘close’. This can
>>> always be reviewed further with them but I would hope for at least
>>>
>> a

> standard schema structure of tables in each project for the
>>>
>> handling

> of quota.
>>>
>>>
>>> On g., aren’t all projects now nested projects ? If we have the
>>> complexity of handling nested projects sorted out in the common
>>> library, is there a reason why a project would not want to support
>>> nested projects ?
>>>
>>>
>>> One other issue is how to do reconcilliation, each project needs
>>>
>> to

> 

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Vikram Choudhary]

I have added the point about the common flow classifier to the etherpad.
Hope we will discuss about that as well.
On Apr 27, 2016 3:03 AM, "Cathy Zhang"  wrote:

> Hi Anil,
>
>
>
> Sorry just checked the email. We ended it around 1:45pm.
>
> It is mostly a get-to-know each other f2f meet-up lunch. Not much
> technical discussion. You can refer to the etherpad on the discussion
> notes.
>
>
>
> Thanks,
>
> Cathy
>
>
>
> *From:* Anil Vishnoi [mailto:vishnoia...@gmail.com]
> *Sent:* Tuesday, April 26, 2016 11:13 AM
> *To:* Cathy Zhang
> *Cc:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc
> project f2f2 meet-up place and time
>
>
>
> cathy, you guys are still there? I got stuck in some other meeting.
>
>
>
> On Fri, Apr 22, 2016 at 5:03 PM, Anil Vishnoi 
> wrote:
>
> Sounds good. Thanks Cathy.
>
>
>
> Anil
>
>
>
> On Fri, Apr 22, 2016 at 3:30 PM, Cathy Zhang 
> wrote:
>
> Hi Everyone,
>
>
>
> As we discussed in our project meeting, we should have a f2f meeting
> during the summit.
>
> let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
>
> Since Salon C is a big room, I will put a sign “Networking-SFC Project
> Meet-Up” on the table.
>
>
>
> Thanks,
>
> Cathy
>
>
>
>
>
>
>
> --
>
> Thanks
>
> Anil
>
>
>
>
>
> --
>
> Thanks
>
> Anil
>
> __
> OpenStack Development Mailing 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] [TC][tricircle] ask help from TC and other guru in the OpenStack community

[joehuang]

Hi, Flavio,

Thank you very much for the guide. Except for the
 bug Shinobu reported, being TC
 approved big tent project will benefit
 both to Tricircle and OpenStack
 community. Thanks again, will check
 the gap first.

BR
Chaoyi Huang(joehuang)

Sent from HUAWEI AnyOffice
发件人：shinobu.kj
收件人：flavio,openstack-dev,
时间：2016-04-26 17:05:32
主题:Re: [openstack-dev] [TC][tricircle] ask help from TC and other guru in the 
OpenStack community

Flavio,

On Tue, Apr 26, 2016 at 11:12 PM, Flavio Percoco  wrote:
> On 26/04/16 20:39 +0900, Shinobu Kinjo wrote:
>>
>> On Tue, Apr 26, 2016 at 12:47 PM, joehuang  wrote:
>>>
>>> Hi, TCs and guru,
>>>
>>>
>>>
>>> If tricircle planned to apply being TC approved big tent project, would
>>> someone help to guide our project?
>>
>>
>> I also would like to know what we should do for that so that we focus
>> on specific things.
>
>
> Hey Folks,
>
> I'm not sure if you have read these docs but I'd probably start here:
>
> - http://governance.openstack.org/reference/new-projects-requirements.html
> - http://docs.openstack.org/project-team-guide

Thanks for those pointers.
My original question is:

https://bugs.launchpad.net/tricircle/+bug/1562416

Cheers,
S

>
> I see you guys have a repo and you're actively contributing to it, which is
> great. What kind of guidance are you guys looking for?
>
> Cheers,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] Social at the summit

[Kyle Mestery]

I propose we meet at Bangers on Rainey St. at 6PM. I don't have a reservation 
but it should be able to hold 50+ people. See y'all at 6PM Thursday!

Kyle

> On Apr 25, 2016, at 1:07 PM, Kyle Mestery  wrote:
> 
> OK, there is enough interest, I'll find a place on 6th Street for us
> and get a reservation for Thursday around 7 or so.
> 
> Thanks folks!
> 
>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
>> +1 :)
>> 
>> Han Zhou
>> Irc: zhouhan
>> 
>> 
>> On Monday, April 25, 2016, Korzeniewski, Artur
>>  wrote:
>>> 
>>> Sign me up :)
>>> 
>>> Artur
>>> IRC: korzen
>>> 
>>> -Original Message-
>>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>>> Sent: Monday, April 25, 2016 7:19 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>> 
>>> Count me in!
>>> Will be good to meet all you guys!
>>> 
>>> Darek (dasm) Smigiel
>>> 
 On Apr 25, 2016, at 12:13 PM, Doug Wiegley
  wrote:
 
 
> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
> wrote:
> 
> WAT???
> 
> It was never supposed to be core only. Everyone is welcome!
 
 +2
 
 irony intended.
 
 Socials are not controlled by gerrit ACLs.  :-)
 
 doug
 
> 
> Sent from my iPhone
> 
>> On 25 Apr 2016, at 11:56, Edgar Magana 
>> wrote:
>> 
>> Would you extend it to ex-cores?
>> 
>> Edgar
>> 
>> 
>> 
>> 
>>> On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
>>> 
>>> Ihar, Henry and I were talking and we thought Thursday night makes
>>> sense for a Neutron social in Austin. If others agree, reply on this 
>>> thread
>>> and we'll find a place.
>>> 
>>> Thanks!
>>> Kyle
>>> 
>>> ___
>>> ___ OpenStack Development Mailing 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
>> 
>> 
>> __
>> OpenStack Development Mailing 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] Devstack liberty with keystone v3

[ZhiQiang Fan]

Sorry, I didn't notice you're using liberty branch, that patch is for
master, not sure if it can be cherry-picked to stable/liberty

As Dolph Mathews pointed out, you're using keystoneclient.v2 to request to
keystone API v3, so it fails with 404, which command are you using?
``openstack catalog list`` ?

On Wed, Apr 27, 2016 at 1:34 AM, kiran vemuri UH  wrote:

> Hello Sean,
>
> I tried doing what you suggested and what  ZhiQiang Fan  suggested as
> well.
>
> But both of them give me similar error when I try to fetch keystone
> catalog.
>
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.10.50.101:5000/v3/tokens
>
> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.10.50.101
>
> DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
> 404 93
>
> DEBUG:keystoneclient.session:Request returned failure status: 404
>
> Authorization Failed: The resource could not be found. (HTTP 404)
> (Request-ID: req-a2b71b1d-b58f-46c3-9e99-2837699a5750)
>
> --
>
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.10.50.101:5000/v3/tokens
>
> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.10.50.101
>
> DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
> 404 93
>
> DEBUG:keystoneclient.session:Request returned failure status: 404
>
> Authorization Failed: The resource could not be found. (HTTP 404)
> (Request-ID: req-ff589197-07af-47bf-8d66-4cc575a12924)
>
> --
>
> Also, I am doubtful if openrc change result in all the services using v3?
>
> Thanks,
> Kiran Vemuri
>
>
> *kiran vemuri*
> www.kiranvemuri.info
> Tel: (832)-701-8281
> kkvem...@uh.edu
>
> __
> OpenStack Development Mailing 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] [Nomad]BoF Session presentation

[Zhipeng Huang]

Hi all,

Thanks for attending today's session, please find the presentation slide at
http://www.slideshare.net/zhipengh/making-workload-nomadic-when-accelerated

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] backwards compatibility followup

[Ian Cordasco]

> On Apr 26, 2016, at 6:32 PM, Perry, Sean  wrote:
> 
> What if we update the docs and tell people to put any services on a shared 
> system into independent virtualenvs?
> 
> If a box only runs neutron or whatever all is well. The issue happens when 
> you mix and match services on a single host. Which is exactly what virtualenv 
> was intended to fix.

Except that a fair portion of respondents to the OpenStack User Survey talk 
about using packages provided by the distribution of Linux they happen to be 
on. Those cannot be installed into virtual environments.


__
OpenStack Development Mailing 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] backwards compatibility followup

[Perry, Sean]

From: Robert Collins [robe...@robertcollins.net]
Sent: Tuesday, April 26, 2016 4:07 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] backwards compatibility followup

Here is the choice I think we're still struggling with:
 - should we support in-place upgrades? If we do, we need at least 1,
possibly more, versions of compatibility such that e.g. mitaka Nova
can run with newton olso+clientlibs
 - or should we explicitly state that we don't support in-place
upgrades - that deployment methods must be architected to avoid ever
encountering the situation where a client or one of N services is
going to be upgraded on a single python environment: all clients and
services must be upgraded together, or none.


What if we update the docs and tell people to put any services on a shared 
system into independent virtualenvs?

If a box only runs neutron or whatever all is well. The issue happens when you 
mix and match services on a single host. Which is exactly what virtualenv was 
intended to fix.
__
OpenStack Development Mailing 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.config] Encrypt the sensitive options

[Guangyu Suo]

I think there is a little misunderstanding over here, the key point about
this problem is that you store your password as *plaintext* in the
configuration file, maybe this password is also the password of many other
systems. You can't stop the right person to do the right thing, if someone
gets the encryped password, and he can also get into the box, then he is
the right person, just like somebody gets your password through "brute
force" attack, you can't stop him to do the right thing. If someone gets
the entryped password, but he can not get into the box, he can do nothing,
and this is our goal. So I think split the global configuration file to
"general" and "secure" files, and encrypt the secure file is the right way
to do this.


2016-04-26 16:05 GMT-05:00 Doug Hellmann :

> Excerpts from Morgan Fainberg's message of 2016-04-26 10:17:30 -0500:
> > On Tue, Apr 26, 2016 at 9:24 AM, Jordan Pittier <
> jordan.pitt...@scality.com>
> > wrote:
> >
> > >
> > >
> > > On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange <
> berra...@redhat.com>
> > > wrote:
> > >
> > >> On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
> > >> > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> > >> > > Hello, oslo team
> > >> > >
> > >> > > For now, some sensitive options like password or token are
> configured
> > >> as
> > >> > > plaintext, anyone who has the priviledge to read the configure
> file
> > >> can get
> > >> > > the real password, this may be a security problem that can't be
> > >> > > unacceptable for some people.
> > >>
> > > It's not a security problem if your config files have the proper
> > > permissions.
> > >
> > >
> > >> > >
> > >> > > So the first solution comes to my mind is to encrypt these options
> > >> when
> > >> > > configuring them and decrypt them when reading them in
> oslo.config.
> > >> This is
> > >> > > a bit like apache/openldap did, but the difference is these
> softwares
> > >> do a
> > >> > > salt hash to the password, this is a one-way encryption that
> can't be
> > >> > > decrypted, these softwares can recognize the hashed value. But if
> we
> > >> do
> > >> > > this work in oslo.config, for example the admin_password in
> > >> > > keystone_middleware section, we must feed the keystone with the
> > >> plaintext
> > >> > > password which will be hashed in keystone to compare with the
> stored
> > >> hashed
> > >> > > password, thus the encryped value in oslo.config must be decryped
> to
> > >> > > plaintext. So we should encrypt these options using symmetrical or
> > >> > > unsymmetrical method with a key, and put the key in a well secured
> > >> place,
> > >> > > and decrypt them using the same key when reading them.
> > >>
> > > The issue here is to find a "well secured place". We should not only
> move
> > > the problem somewhere else.
> > >
> > >
> > >> > >
> > >> > > Of course, this feature should be default closed. Any ideas?
> > >> >
> > >> > Managing the encryption keys has always been the issue blocking
> > >> > implementing this feature when it has come up in the past. We can't
> have
> > >> > oslo.config rely on a separate OpenStack service for key management,
> > >> > because presumably that service would want to use oslo.config and
> then
> > >> > we have a dependency cycle.
> > >> >
> > >> > So, we need a design that lets us securely manage those encryption
> keys
> > >> > before we consider adding encryption. If we solve that, it's then
> > >> > probably simpler to encrypt an entire config file instead of
> worrying
> > >> > about encrypting individual values (something like how ansible vault
> > >> > works).
> > >>
> > >> IMHO encrypting oslo config files is addressing the wrong problem.
> > >> Rather than having sensitive passwords stored in the main config
> > >> files, we should have them stored completely separately by a secure
> > >> password manager of some kind. The config file would then merely
> > >> contain the name or uuid of an entry in the password manager. The
> > >> service (eg nova-compute) would then query that password manager
> > >> to get the actual sensitive password data it requires. At this point
> > >> oslo.config does not need to know/care about encryption of its data
> > >> as there's no longer sensitive data stored.
> > >>
> > > This looks complicated. I like text files that I can quickly view and
> > > edit, if I am authorized to (through good old plain Linux permissions).
> > >
> > >
> > >>
> > >> Regards,
> > >> Daniel
> > >>
> > >
> > oslo.config already supports multiple configuration files. As long as the
> > configuration sections are appropriately combined (they should be? if not
> > there is a gap), we can rely on that feature to handle the split between
> > "secure" options and "general options". I am strongly against encrypting
> > the whole file (it doesn't really solve the problem that well). There is
> a
>
> Yes, sorry, I wasn't clear but I assumed this was understood to be how 

Re: [openstack-dev] [openstack-manuals] What the status of DocImpact

[ZhiQiang Fan]

Thanks, @Matt and @Doug, I agree that it's time to consider project holds
its document in its own repository. There is a gap between document team
and our projects source code, even though they are excellent and working
hard, but our source code is growing fast in the same time, this problem is
getting worse after we switch to Big Tent mode.

@Lana: The patch I submitted is modified via script tools, and I have
provided extra patch to fix our tools to make it better. Anyway, thank you
for your input. Cheers

ZhiQiang

On Wed, Apr 27, 2016 at 1:29 AM, Lana Brindley 
wrote:

> No trouble. Yes, the config changes should be picked up automatically. You
> can't edit those files in the book directly, as a script writes them.
> That's why your change would have been declined.
>
> Thanks for asking the question, though :)
>
> L
>
> On 24/04/16 11:12, ZhiQiang Fan wrote:
> > Hi Lana,
> >
> > Thank you for explaining it!
> >
> > Yes, I noticed that the DocImpact bug track now has shifted to project
> its own, that why I submit a change by using the tool in
> openstack-doc-tools, but that change is disagreed by a doc core. Meanwhile
> I also find that there is rarely change merged for config reference update.
> >
> > So I want to know is the config reference automatically updated so no
> more individual commit is required?
> >
> > Best Regards,
> >
> > On Sun, Apr 24, 2016 at 11:28 PM, Lana Brindley <
> openst...@lanabrindley.com > wrote:
> >
> > Hi ZhiQiang,
> >
> > I am not sure I understand your question. The only change to
> DocImpact is that now the bug is created in the project's bug queue, not
> OpenStack manuals. There is no other automation for DocImpact.
> >
> > For the config ref, there is a script that we run to get any new
> changes. That will happen whether or not there is a DocImpact bug.
> >
> > Does that answer your question?
> >
> > Thanks,
> > Lana
> >
> > On 23/04/16 19:00, ZhiQiang Fan wrote:
> > > Hi Doc Team,
> > >
> > > I want to know the recent status of DocImpact tag, is it
> deprecated for config option changes now? If it's true, then what the
> workflow for config reference now, any hint or link?
> > >
> > > Previously, when a patch has impact to document, including config
> option changes, I usually ask contributors to add a DocImpact, hence there
> will be a bug track the document issue.
> > >
> > > Recently, a patch lands in Ceilometer which adds two new options,
> and Ceilometer receives the auto created document bug. However, when I
> submit a patch to openstack-manuals to fix it, I was told by a core that
> such change is not needed any more, I searched latest merged patch in
> openstack-manuals and found what he said is true, but still don't know why
> and what action I should follow in Ceilometer/Aodh projects
> > >
> > > Thank you very much!
> > >
> > > ZhiQiang Fan
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > --
> > Lana Brindley
> > Technical Writer
> > Rackspace Cloud Builders Australia
> > http://lanabrindley.com
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <
> http://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
> >
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] backwards compatibility followup

[Robert Collins]

Thanks everyone for coming to the backwards compat for clients and
libraries session.

Here are the things I think we agreed on:
 - clients need to talk to all versions of openstack clouds
 - oslo libraries already do need to do backwards compat - josh,
myself, dims, doug are all striving for that in reviews
 - some fraction of our deploys - somewhere between 1% and 50% - are
trying to do in-place upgrades where e.g. nova is upgraded and then
later neutron, which runs into neutron having to work with the new
libraries the nova upgrade dragged in.

Here is the choice I think we're still struggling with:
 - should we support in-place upgrades? If we do, we need at least 1,
possibly more, versions of compatibility such that e.g. mitaka Nova
can run with newton olso+clientlibs
 - or should we explicitly state that we don't support in-place
upgrades - that deployment methods must be architected to avoid ever
encountering the situation where a client or one of N services is
going to be upgraded on a single python environment: all clients and
services must be upgraded together, or none.

If we decide to support in-place upgrades, we can figure out how to
test that effectively; its a linear growth with the number of stable
releases we choose to support.

If we decide not to support them, we have no further requirement to
have any cross-over compat between OpenStack releases - while we will
still have to be backwards compatible on individual changes (so that
we can get them rolled out and used), we can do our garbage collection
much more rapidly - even same-cycle.


https://etherpad.openstack.org/p/newton-backwards-compat-libs

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Place kolla-mesos in openstack-attic

[Jeff Peeler]

On Sat, Apr 23, 2016 at 12:06 AM, Steven Dake (stdake)  wrote:
> Jeremy,
>
> Thanks for the information - you can tell I'm a bit dated ;)
>
> Folks, take this vote to mean what Jeremy has stated as far as repo
> deprecation goes.

+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] cross-project deployment tool meeting

[Andrew Woodward]

Please include me, I'm in GMT-7, so UTC 1600 is the earliest I can
participate.

On Tue, Apr 26, 2016 at 11:55 AM Jan Klare  wrote:

> Hi,
>
>  i just wanted to follow up on this session (
> https://etherpad.openstack.org/p/newton-deployment-tools-discussion) were
> we talked about a cross-project meeting for deployment tools. I would love
> to see something like that happen and it would be great if we can find a
> specific date (maybe monthly) to do something like that. If you are
> interested in going to such a meeting, please reply to this mail with a
> suggestion when you could join such a meeting.
>
> Cheers,
> Jan (OpenStack Chef)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing 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] [TC][tricircle] ask help from TC and other guru in the OpenStack community

[Shinobu Kinjo]

Flavio,

On Tue, Apr 26, 2016 at 11:12 PM, Flavio Percoco  wrote:
> On 26/04/16 20:39 +0900, Shinobu Kinjo wrote:
>>
>> On Tue, Apr 26, 2016 at 12:47 PM, joehuang  wrote:
>>>
>>> Hi, TCs and guru,
>>>
>>>
>>>
>>> If tricircle planned to apply being TC approved big tent project, would
>>> someone help to guide our project?
>>
>>
>> I also would like to know what we should do for that so that we focus
>> on specific things.
>
>
> Hey Folks,
>
> I'm not sure if you have read these docs but I'd probably start here:
>
> - http://governance.openstack.org/reference/new-projects-requirements.html
> - http://docs.openstack.org/project-team-guide

Thanks for those pointers.
My original question is:

https://bugs.launchpad.net/tricircle/+bug/1562416

Cheers,
S

>
> I see you guys have a repo and you're actively contributing to it, which is
> great. What kind of guidance are you guys looking for?
>
> Cheers,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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][vpnaas] VPNaaS tox api failure

[Madhusudhan Kandadai]

Hi Bharath,

Yes. Did you have this patch https://review.openstack.org/#/c/281493/
before you run "tox -e api" ? There was a change in neutron that removed
vpn and fw tests and its in their tree. However, to make it work for vpn
api tests, we need to figure out a way to implement the changes in vpn
tree. However for time being, patch 281493 needs to be cherry picked until
we get a timeline to implement in vpnaas tree.

If you have cycles, feel free to take on
https://review.openstack.org/#/c/281493 and once that merges,
https://review.openstack.org/#/c/279787/ is the traditional way of running
tempest tests using tempest plugin. Hope this helps.

Regards,
Madhu

On Mon, Apr 25, 2016 at 11:14 AM, Bharath Kumar Gubbala  wrote:

> Hi Henry,
>
>
> Do you have any info on below query in the thread.(is 'tox -e api' working
> in neutron-vpnaas ?)
>
>
>
> Thanks,
>
> bharath
>
>
> --
> *From:* bharath 
> *Sent:* 08 April 2016 01:53
> *To:* OpenStack Development Mailing List (not for usage questions); Alex
> Geevarghese; madhusudhan.openst...@gmail.com; p...@michali.net
> *Subject:* Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure
>
> Thanks Paul for info.
>
> Yes i had run the tests locally under VPN-repo.
>
> My analysis:
>
>- VPN test cases were using the neutron client for VPN
>services (which no longer supported by neutron).
>
>  Thats why its throwing "tempest.lib.exceptions.NotFound:
> Object not found"
>
>- In the case of FW , there were using router client directly
>instead of neutron client.
>
>
>
> I will check with madhusudhan for additional info.
>
>
>
> Madhu,
> Let me know if you have info on "tox api" support.
> If it is an known issue, i can take it up and complete fix
>
> Thanks,
> bharath
>
>
>
>
> On Friday 08 April 2016 01:00 AM, Paul Michali wrote:
>
> Are you running the test locally?
>
> IIRC, the tempest based API tests for VPN have been (are being) moved to
> the VPN repo, but I don't know if a job was ever created for this so that
> the tests actually run. You may want to check with the author who moved the
> tests (madhusudan-kandadai) under commit 3cae934a, to see if the CI job was
> ever created. It is possible that it was never completed.
>
> Likewise, I don't know if support was added to tox.ini for the api test.
> I've never run the test, granted I've been away from VPN for a while and
> only involved intermittently since Liberty, so I may be a bit out of touch.
>
> Regards,
>
> PCM
>
>
> On Thu, Apr 7, 2016 at 2:23 PM bharath  wrote:
>
>>
>> Hi,
>>
>> While running "tox -e api" i hitting " tempest.lib.NotFound" Error.
>>
>> Is it a known issue ? failures expected?
>>
>> https://review.openstack.org/#/c/291949/1
>> 
>> ==> In this commit messages it says it kindof expected failure.
>>
>> Can someone provide some clarification on this
>>
>> Thanks,
>> bharath
>> __
>> OpenStack Development Mailing 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:unsubscribehttps://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=
>
>
>
__
OpenStack Development Mailing 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-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

Hi Anil,

Sorry just checked the email. We ended it around 1:45pm.
It is mostly a get-to-know each other f2f meet-up lunch. Not much technical 
discussion. You can refer to the etherpad on the discussion notes.

Thanks,
Cathy

From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Tuesday, April 26, 2016 11:13 AM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

cathy, you guys are still there? I got stuck in some other meeting.

On Fri, Apr 22, 2016 at 5:03 PM, Anil Vishnoi 
> wrote:
Sounds good. Thanks Cathy.

Anil

On Fri, Apr 22, 2016 at 3:30 PM, Cathy Zhang 
> wrote:
Hi Everyone,

As we discussed in our project meeting, we should have a f2f meeting during the 
summit.
let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
Since Salon C is a big room, I will put a sign “Networking-SFC Project Meet-Up” 
on the table.

Thanks,
Cathy




--
Thanks
Anil



--
Thanks
Anil
__
OpenStack Development Mailing 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.config] Encrypt the sensitive options

[Doug Hellmann]

Excerpts from Morgan Fainberg's message of 2016-04-26 10:17:30 -0500:
> On Tue, Apr 26, 2016 at 9:24 AM, Jordan Pittier 
> wrote:
> 
> >
> >
> > On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange 
> > wrote:
> >
> >> On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
> >> > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> >> > > Hello, oslo team
> >> > >
> >> > > For now, some sensitive options like password or token are configured
> >> as
> >> > > plaintext, anyone who has the priviledge to read the configure file
> >> can get
> >> > > the real password, this may be a security problem that can't be
> >> > > unacceptable for some people.
> >>
> > It's not a security problem if your config files have the proper
> > permissions.
> >
> >
> >> > >
> >> > > So the first solution comes to my mind is to encrypt these options
> >> when
> >> > > configuring them and decrypt them when reading them in oslo.config.
> >> This is
> >> > > a bit like apache/openldap did, but the difference is these softwares
> >> do a
> >> > > salt hash to the password, this is a one-way encryption that can't be
> >> > > decrypted, these softwares can recognize the hashed value. But if we
> >> do
> >> > > this work in oslo.config, for example the admin_password in
> >> > > keystone_middleware section, we must feed the keystone with the
> >> plaintext
> >> > > password which will be hashed in keystone to compare with the stored
> >> hashed
> >> > > password, thus the encryped value in oslo.config must be decryped to
> >> > > plaintext. So we should encrypt these options using symmetrical or
> >> > > unsymmetrical method with a key, and put the key in a well secured
> >> place,
> >> > > and decrypt them using the same key when reading them.
> >>
> > The issue here is to find a "well secured place". We should not only move
> > the problem somewhere else.
> >
> >
> >> > >
> >> > > Of course, this feature should be default closed. Any ideas?
> >> >
> >> > Managing the encryption keys has always been the issue blocking
> >> > implementing this feature when it has come up in the past. We can't have
> >> > oslo.config rely on a separate OpenStack service for key management,
> >> > because presumably that service would want to use oslo.config and then
> >> > we have a dependency cycle.
> >> >
> >> > So, we need a design that lets us securely manage those encryption keys
> >> > before we consider adding encryption. If we solve that, it's then
> >> > probably simpler to encrypt an entire config file instead of worrying
> >> > about encrypting individual values (something like how ansible vault
> >> > works).
> >>
> >> IMHO encrypting oslo config files is addressing the wrong problem.
> >> Rather than having sensitive passwords stored in the main config
> >> files, we should have them stored completely separately by a secure
> >> password manager of some kind. The config file would then merely
> >> contain the name or uuid of an entry in the password manager. The
> >> service (eg nova-compute) would then query that password manager
> >> to get the actual sensitive password data it requires. At this point
> >> oslo.config does not need to know/care about encryption of its data
> >> as there's no longer sensitive data stored.
> >>
> > This looks complicated. I like text files that I can quickly view and
> > edit, if I am authorized to (through good old plain Linux permissions).
> >
> >
> >>
> >> Regards,
> >> Daniel
> >>
> >
> oslo.config already supports multiple configuration files. As long as the
> configuration sections are appropriately combined (they should be? if not
> there is a gap), we can rely on that feature to handle the split between
> "secure" options and "general options". I am strongly against encrypting
> the whole file (it doesn't really solve the problem that well). There is a

Yes, sorry, I wasn't clear but I assumed this was understood to be how we
would do it -- have a secure file and encrypt that. Whether any single
deployment decides to split that file or not is up to them. My point
was just that we should treat the file, not an individual option within
the file.

> history of having "secure" files and "generally viewable" config files
> (prior art, such as gerrit having a "general" config and a "secure" config)
> in many deployments. This also could be handled (decrypting the "secure"
> file) by the startup scripts (systemd is *very* good at order of
> operations/wait for signals); use of ramdisk and proper POSIX (and SELinux)
> attributes can limit concerns about access of the "secure" file (mix in
> some ramdisk, and a reboot of the system/systemd stopping the service, can
> also clear the "sensitive" data). Expect that the data is ultimately
> readable via direct memory access if the standard "best" practices are
> insufficient.
> 
> There was already talk of having oslo.config supporting an "external store"
> (direct access to hiera or 

Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

[Vikram Hosakote (vhosakot)]

+1 for the attic.

Regards,
Vikram Hosakote
IRC: vhosakot

From: Ryan Hallisey >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, April 25, 2016 at 5:00 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

+1

- Original Message -
From: "Angus Salkeld" >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Sent: Sunday, April 24, 2016 11:01:38 AM
Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic



+1
On Sat, 23 Apr 2016 3:08 am Michał Rostecki < 
michal.roste...@gmail.com > wrote:


+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

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

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

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

Re: [openstack-dev] [neutron] Social at the summit

[Shaughnessy, David]

+1
Thanks!

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Tuesday, April 26, 2016 6:31 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] Social at the summit

+1

Thanks for coordinating!

2016-04-25 10:55 GMT-05:00 Kyle Mestery :
> Ihar, Henry and I were talking and we thought Thursday night makes sense for 
> a Neutron social in Austin. If others agree, reply on this thread and we'll 
> find a place.
>
> Thanks!
> Kyle
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


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

Re: [openstack-dev] Devstack liberty with keystone v3

[Dolph Mathews]

On Tuesday, April 26, 2016, kiran vemuri UH  wrote:

> Hello Sean,
>
> I tried doing what you suggested and what  ZhiQiang Fan  suggested as
> well.
>
> But both of them give me similar error when I try to fetch keystone
> catalog.
>
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.10.50.101:5000/v3/tokens
>
> You have a v2 client configured with a versioned /v3/ endpoint, and the
API it's looking doesn't exist. Use a v3 client with the same endpoint.

> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.10.50.101
>
> DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
> 404 93
>
> DEBUG:keystoneclient.session:Request returned failure status: 404
>
> Authorization Failed: The resource could not be found. (HTTP 404)
> (Request-ID: req-a2b71b1d-b58f-46c3-9e99-2837699a5750)
>
> --
>
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.10.50.101:5000/v3/tokens
>
> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.10.50.101
>
> DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
> 404 93
>
> DEBUG:keystoneclient.session:Request returned failure status: 404
>
> Authorization Failed: The resource could not be found. (HTTP 404)
> (Request-ID: req-ff589197-07af-47bf-8d66-4cc575a12924)
>
> --
>
> Also, I am doubtful if openrc change result in all the services using v3?
>
> Thanks,
> Kiran Vemuri
>
>
> *kiran vemuri*
> www.kiranvemuri.info
> Tel: (832)-701-8281
> kkvem...@uh.edu 
>
__
OpenStack Development Mailing 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][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

[Tomasz Pa]

Hey Steven,

answers inline.

On Mon, Apr 25, 2016 at 9:27 AM, Steven Dake (stdake)  wrote:
>
> I disagree with your assertion.  You are gaming your data to provide the
> worst possible container (nova) because the RPMs pull in libvirt.  Kolla
> has no control over how Red Hat choses to package RDO, and at this time
> they choose to package libvirt as a dependency thereof.  Obviously it
> would be more optimal in a proper container system not to include libvirt
> in the dependencies installed with Nova.  If you really want that, use
> from source installs.  Then you could shave 1 minute off your upgrade time
> of a 64 node cluster.

Look here: http://paste.openstack.org/show/495459/ . As you can see
there're no libvirt dependencies there. It's only python-nova deps
there.
>
> A DSL does not solve this problem unless the DSL contains every dependency
> to install (from binary).  I don't see this as maintainable.

Agree being to detailed within the DSL can make the maintenance a
nightmare. I was thinking about some build automation which can
extract
dependencies (ie: repoquery --requires python-nova) and put each one
into a separate layer. We will just need a basic DSL with same
complexity as we have now in Dockerfiles which will be building
Dockerfiles dynamically.

Other approach could be setting a dedicated image for each of the
dependency and bind them together into the single image during build.

I'm also having Alpine linux in mind, this together with bazel can
make images really small.
>
> Just as a conclusion, deploying each dependency in a separate layer is an
> absolutely terrible idea.  Docker performance atleast is negatively
> affected by large layer counts, and aufs has a limit of 42 layers, so your
> idea is not viable asp resented.

This limit was 127 back in 2013.

-- 
Tomasz Paszkowski
SS7, Asterisk, SAN, Datacenter, Cloud Computing
+48500166299

__
OpenStack Development Mailing 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-sfc] Network-sfc project f2f2 meet-up place and time

[Akihiro Motoki]

2016-04-26 12:31 GMT-05:00 Henry Fourie :
> All,
>Please use the networking-sfc etherpad to record discussions at
> the meetups:
>
> https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting
>
>  - Louis
>
> -Original Message-
> From: Paul Carver [mailto:pcar...@paulcarver.us]
> Sent: Tuesday, April 26, 2016 10:20 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
> f2f2 meet-up place and time
>
> On 4/26/2016 00:35, Akihiro Motoki wrote:
>> Hi Cathy and folks interested in SFC and classifers!
>>
>> Can't we use a different room like Salon D?
>> Salon C is a lunch room and at that time there are no sessions in other 
>> rooms.
>> It would be great if we can use Salon D or E (after looking at the
>> first day's session) I think we can gather more easily and concentrate
>> the discussion if we use some different space.
>> Thought?
>>
>
> Akihiro,
>
> Unless I've misunderstood the emails, the plan for Tuesday is a social lunch 
> for the SFC team to get together. The plan for Wednesday is a working lunch 
> to discuss flow classifiers in various projects and figure out how to 
> converge on a single flow classifier API/model that can be shared by 
> everything that needs to specify flows.
>
> If that's correct, then meeting in Salon C for lunch on Tuesday makes sense. 
> For Wednesday we probably ought to grab boxed lunches and find a quiet room.

I was confused with networking-sfc f2f meeting and flow classifier one.
My previous mail is a suggestion for wednesday flow classifier meeting.
Thanks for point it out.

Akihiro


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

__
OpenStack Development Mailing 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-sfc] Network-sfc project f2f2 meet-up place and time

[Anil Vishnoi]

cathy, you guys are still there? I got stuck in some other meeting.

On Fri, Apr 22, 2016 at 5:03 PM, Anil Vishnoi  wrote:

> Sounds good. Thanks Cathy.
>
> Anil
>
> On Fri, Apr 22, 2016 at 3:30 PM, Cathy Zhang 
> wrote:
>
>> Hi Everyone,
>>
>>
>>
>> As we discussed in our project meeting, we should have a f2f meeting
>> during the summit.
>>
>> let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
>>
>> Since Salon C is a big room, I will put a sign “Networking-SFC Project
>> Meet-Up” on the table.
>>
>>
>>
>> Thanks,
>>
>> Cathy
>>
>>
>>
>
>
>
> --
> Thanks
> Anil
>



-- 
Thanks
Anil
__
OpenStack Development Mailing 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] Magnum supports 2 Nova flavor to provision minion nodes

[Hongbin Lu]

> -Original Message-
> From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com]
> Sent: April-26-16 3:01 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
> 
> Hi Hongbin, Ricardo
> This is mike, I am working with Gary now.
> Thanks for Ricardo's good suggestion. I have tried the "map/index"
> method ,  we can use it to passed the minion_flavor_map and the index
> into the minion cluster stack. It does work well.
> I think we can update magnum baymodel-create to set the N minion
> flavors in the minion_flavor_map and assign minion counts for each
> flavor.
> For example :
> magnum baymodel-create --name k8s-bay-model  --flavor-id minion-flavor-
> 0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types flavor

The suggested approach seems to break the existing behaviour. I think it is 
better to support this feature in a backward-compatible way. How about using 
labels:

$ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0 
--node-count 3 --labels extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2

> minion node and total minion nodes  count is 10. The magnum baymode.py
> will parse  this  dictionary and pass them to the heat template
> parameters minion_flavor_map, minion_flavor_count_map. Then the heat
> stack will work well.
> 
> kubecluster-fedora-ironic.yaml
> parameters:
>   minion_flavor_map:
> type: json
> default:
>   '0': minion-flavor-0
>   '1': minion-flavor-1
>   '2': minion-flavor-2
> 
>   minion_flavor_count_map:
> type: json
> default:
>   '0': 3
>   '1': 5
>   '2': 2
> 
> resources:
> kube_minions_flavors:
> type: OS::Heat::ResourceGroup
> properties:
>   count: { get_param: minion_flavors_counts }
>   resource_def:
> type: kubecluster-minion-fedora-ironic.yaml
> properties:
>   minion_flavor_map: {get_param: minion_flavor_map}
>   minion_flavor_count_map: {get_param: minion_flavor_count_map}
>   minion_flavor_index: '%index%'
> 
> How do you think about this interface in magnum baymodel to support N
> falvor to provision minion nodes? Do you have any comments about this
> design for this feature?
> 
> Thanks && Regards
> Mike Ma
> HP Servers Core Platform Software China Email wentao...@hpe.com
> 
> -Original Message-
> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
> Sent: Monday, April 25, 2016 3:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) 
> Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
> 
> Hi Ricardo,
> 
> This is really good suggestion. I'd like to see whether we can use
> "foreach"/"repeat" in ResourceGroup in Heat.
> 
> Regards,
> Gary Duan
> 
> -Original Message-
> From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
> Sent: Thursday, April 21, 2016 3:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
> 
> Hi Hongbin.
> 
> On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu 
> wrote:
> >
> >
> >
> >
> > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
> > [mailto:li-gong.d...@hpe.com]
> > Sent: April-20-16 3:39 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> > provision minion nodes
> >
> >
> >
> > Hi Folks,
> >
> >
> >
> > We are considering whether Magnum can supports 2 Nova flavors to
> > provision Kubernetes and other COE minion nodes.
> >
> > This requirement comes from the below use cases:
> >
> > -  There are 2 kind of baremetal machines in customer site:
> one is
> > legacy machines which doesn’t support UEFI secure boot and others are
> > new machines which support UEFI secure boot. User want to use Magnum
> > to provisions a Magnum bay of Kubernetes from these 2 kind of
> > baremetal machines and for the machines supporting secure boot, user
> > wants to use UEFI secure boot to boot them up. And 2 Kubernetes
> > label(secure-booted and
> > non-secure-booted) are created and User can deploy their
> > data-senstive/cirtical workload/containers/pods on the baremetal
> > machines which are secure-booted.
> >
> >
> >
> > This requirement requires Magnum to supports 2 Nova flavors(one is
> > “extra_spec: secure_boot=True” and the other doesn’t specify it)
> based
> > on the Ironic
> > feature(https://specs.openstack.org/openstack/ironic-
> specs/specs/kilo-
> > implemented/uefi-secure-boot.html
> > ).
> >
> >
> >
> > Could you kindly give me some comments on these requirement or
> whether
> > it is reasonable from your point? If you agree, we can write design
> > spec and 

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

Hi Akihiro,

We are at Salon C now. Could you come here to have lunch together and then we 
can move to Salon D after lunch if needed. 

Thanks,
Cathy

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, April 25, 2016 10:36 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

Hi Cathy and folks interested in SFC and classifers!

Can't we use a different room like Salon D?
Salon C is a lunch room and at that time there are no sessions in other rooms.
It would be great if we can use Salon D or E (after looking at the first day's 
session) I think we can gather more easily and concentrate the discussion if we 
use some different space.
Thought?

Akihiro

2016-04-22 17:30 GMT-05:00 Cathy Zhang :
> Hi Everyone,
>
>
>
> As we discussed in our project meeting, we should have a f2f meeting 
> during the summit.
>
> let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
>
> Since Salon C is a big room, I will put a sign “Networking-SFC Project 
> Meet-Up” on the table.
>
>
>
> Thanks,
>
> Cathy
>
>
__
OpenStack Development Mailing 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] Devstack liberty with keystone v3

[kiran vemuri UH]

Hello Sean,

I tried doing what you suggested and what  ZhiQiang Fan  suggested as well.

But both of them give me similar error when I try to fetch keystone catalog.

DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
http://10.10.50.101:5000/v3/tokens

INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
(1): 10.10.50.101

DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
404 93

DEBUG:keystoneclient.session:Request returned failure status: 404

Authorization Failed: The resource could not be found. (HTTP 404)
(Request-ID: req-a2b71b1d-b58f-46c3-9e99-2837699a5750)

--

DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
http://10.10.50.101:5000/v3/tokens

INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
(1): 10.10.50.101

DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
404 93

DEBUG:keystoneclient.session:Request returned failure status: 404

Authorization Failed: The resource could not be found. (HTTP 404)
(Request-ID: req-ff589197-07af-47bf-8d66-4cc575a12924)

--

Also, I am doubtful if openrc change result in all the services using v3?

Thanks,
Kiran Vemuri


*kiran vemuri*
www.kiranvemuri.info
Tel: (832)-701-8281
kkvem...@uh.edu
__
OpenStack Development Mailing 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-sfc] Network-sfc project f2f2 meet-up place and time

[Henry Fourie]

All,
   Please use the networking-sfc etherpad to record discussions at
the meetups:

https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting

 - Louis

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Tuesday, April 26, 2016 10:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

On 4/26/2016 00:35, Akihiro Motoki wrote:
> Hi Cathy and folks interested in SFC and classifers!
>
> Can't we use a different room like Salon D?
> Salon C is a lunch room and at that time there are no sessions in other rooms.
> It would be great if we can use Salon D or E (after looking at the 
> first day's session) I think we can gather more easily and concentrate 
> the discussion if we use some different space.
> Thought?
>

Akihiro,

Unless I've misunderstood the emails, the plan for Tuesday is a social lunch 
for the SFC team to get together. The plan for Wednesday is a working lunch to 
discuss flow classifiers in various projects and figure out how to converge on 
a single flow classifier API/model that can be shared by everything that needs 
to specify flows.

If that's correct, then meeting in Salon C for lunch on Tuesday makes sense. 
For Wednesday we probably ought to grab boxed lunches and find a quiet room.


__
OpenStack Development Mailing 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] Social at the summit

[Akihiro Motoki]

+1

Thanks for coordinating!

2016-04-25 10:55 GMT-05:00 Kyle Mestery :
> Ihar, Henry and I were talking and we thought Thursday night makes sense for 
> a Neutron social in Austin. If others agree, reply on this thread and we'll 
> find a place.
>
> Thanks!
> Kyle
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [openstack-manuals] What the status of DocImpact

[Lana Brindley]

No trouble. Yes, the config changes should be picked up automatically. You 
can't edit those files in the book directly, as a script writes them. That's 
why your change would have been declined.

Thanks for asking the question, though :)

L

On 24/04/16 11:12, ZhiQiang Fan wrote:
> Hi Lana,
> 
> Thank you for explaining it! 
> 
> Yes, I noticed that the DocImpact bug track now has shifted to project its 
> own, that why I submit a change by using the tool in openstack-doc-tools, but 
> that change is disagreed by a doc core. Meanwhile I also find that there is 
> rarely change merged for config reference update.
> 
> So I want to know is the config reference automatically updated so no more 
> individual commit is required?
> 
> Best Regards,
> 
> On Sun, Apr 24, 2016 at 11:28 PM, Lana Brindley  > wrote:
> 
> Hi ZhiQiang,
> 
> I am not sure I understand your question. The only change to DocImpact is 
> that now the bug is created in the project's bug queue, not OpenStack 
> manuals. There is no other automation for DocImpact.
> 
> For the config ref, there is a script that we run to get any new changes. 
> That will happen whether or not there is a DocImpact bug.
> 
> Does that answer your question?
> 
> Thanks,
> Lana
> 
> On 23/04/16 19:00, ZhiQiang Fan wrote:
> > Hi Doc Team,
> >
> > I want to know the recent status of DocImpact tag, is it deprecated for 
> config option changes now? If it's true, then what the workflow for config 
> reference now, any hint or link?
> >
> > Previously, when a patch has impact to document, including config 
> option changes, I usually ask contributors to add a DocImpact, hence there 
> will be a bug track the document issue.
> >
> > Recently, a patch lands in Ceilometer which adds two new options, and 
> Ceilometer receives the auto created document bug. However, when I submit a 
> patch to openstack-manuals to fix it, I was told by a core that such change 
> is not needed any more, I searched latest merged patch in openstack-manuals 
> and found what he said is true, but still don't know why and what action I 
> should follow in Ceilometer/Aodh projects
> >
> > Thank you very much!
> >
> > ZhiQiang Fan
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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



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

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Paul Carver]

On 4/26/2016 00:35, Akihiro Motoki wrote:

Hi Cathy and folks interested in SFC and classifers!

Can't we use a different room like Salon D?
Salon C is a lunch room and at that time there are no sessions in other rooms.
It would be great if we can use Salon D or E (after looking at the
first day's session)
I think we can gather more easily and concentrate the discussion if we
use some different space.
Thought?



Akihiro,

Unless I've misunderstood the emails, the plan for Tuesday is a social 
lunch for the SFC team to get together. The plan for Wednesday is a 
working lunch to discuss flow classifiers in various projects and figure 
out how to converge on a single flow classifier API/model that can be 
shared by everything that needs to specify flows.


If that's correct, then meeting in Salon C for lunch on Tuesday makes 
sense. For Wednesday we probably ought to grab boxed lunches and find a 
quiet room.



__
OpenStack Development Mailing 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] [Winstackers][Hyper-V] 27.07.2016 IRC meeting cancelled

[Claudiu Belu]

Hey y'all!

Tomorrow's Hyper-V IRC meeting (27.07.2016) is cancelled due to the OpenStack 
Summit.

We do however have a Winstackers work session tomorrow at 9:00 AM (local time 
in Austin) in Boardroom 401. Feel free to join us then and there!

Here's the event details and topics: 
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9367

Best regards,

Claudiu Belu

__
OpenStack Development Mailing 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] Social at the summit

[Sławek Kapłoński]

Hello,

+1

-- 
Pozdrawiam / Best regards
Sławek Kapłoński
sla...@kaplonski.pl

Dnia poniedziałek, 25 kwietnia 2016 17:21:56 CDT Korzeniewski, Artur pisze:
> Sign me up :)
> 
> Artur
> IRC: korzen
> 
> -Original Message-
> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
> Sent: Monday, April 25, 2016 7:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
>  Subject: Re: [openstack-dev] [neutron]
> Social at the summit
> 
> Count me in!
> Will be good to meet all you guys!
> 
> Darek (dasm) Smigiel
> 
> > On Apr 25, 2016, at 12:13 PM, Doug Wiegley  
wrote:
> >> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
> >> wrote:
> >> 
> >> WAT???
> >> 
> >> It was never supposed to be core only. Everyone is welcome!
> > 
> > +2
> > 
> > irony intended.
> > 
> > Socials are not controlled by gerrit ACLs.  :-)
> > 
> > doug
> > 
> >> Sent from my iPhone
> >> 
> >>> On 25 Apr 2016, at 11:56, Edgar Magana  wrote:
> >>> 
> >>> Would you extend it to ex-cores?
> >>> 
> >>> Edgar
> >>> 
>  On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
>  
>  Ihar, Henry and I were talking and we thought Thursday night makes
>  sense for a Neutron social in Austin. If others agree, reply on this
>  thread and we'll find a place.
>  
>  Thanks!
>  Kyle
>  
>  ___
>  ___ OpenStack Development Mailing 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


signature.asc
Description: This is a digitally signed message part.
__
OpenStack Development Mailing 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] Social at the summit

[Howard, Victor]

+2 Thanks.

On 4/26/16, 9:57 AM, "Ben Pfaff"  wrote:

>Sign me up, too.
>
>On Mon, Apr 25, 2016 at 01:07:02PM -0500, Kyle Mestery wrote:
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>> 
>> Thanks folks!
>> 
>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
>> > +1 :)
>> >
>> > Han Zhou
>> > Irc: zhouhan
>> >
>> >
>> > On Monday, April 25, 2016, Korzeniewski, Artur
>> >  wrote:
>> >>
>> >> Sign me up :)
>> >>
>> >> Artur
>> >> IRC: korzen
>> >>
>> >> -Original Message-
>> >> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>> >> Sent: Monday, April 25, 2016 7:19 PM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> 
>> >> Subject: Re: [openstack-dev] [neutron] Social at the summit
>> >>
>> >> Count me in!
>> >> Will be good to meet all you guys!
>> >>
>> >> Darek (dasm) Smigiel
>> >>
>> >> > On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>> >> >  wrote:
>> >> >
>> >> >
>> >> >> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka
>>
>> >> >> wrote:
>> >> >>
>> >> >> WAT???
>> >> >>
>> >> >> It was never supposed to be core only. Everyone is welcome!
>> >> >
>> >> > +2
>> >> >
>> >> > irony intended.
>> >> >
>> >> > Socials are not controlled by gerrit ACLs.  :-)
>> >> >
>> >> > doug
>> >> >
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >>> On 25 Apr 2016, at 11:56, Edgar Magana 
>> >> >>> wrote:
>> >> >>>
>> >> >>> Would you extend it to ex-cores?
>> >> >>>
>> >> >>> Edgar
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >>  On 4/25/16, 10:55 AM, "Kyle Mestery" 
>>wrote:
>> >> 
>> >>  Ihar, Henry and I were talking and we thought Thursday night
>>makes
>> >>  sense for a Neutron social in Austin. If others agree, reply on
>>this thread
>> >>  and we'll find a place.
>> >> 
>> >>  Thanks!
>> >>  Kyle
>> >> 
>> >>  
>>___
>> >>  ___ OpenStack Development Mailing 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
>> >
>> >
>> > 
>>_
>>_
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Re: [openstack-dev] [neutron] Social at the summit

[Mark Mielke]

I'm an interested observer new to the community. Depending upon time I
would like to join. Will the information be posted to the list for people
such as myself? If not, please cc: me.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] cross-project deployment tool meeting

[Jan Klare]

Hi,

 i just wanted to follow up on this session 
(https://etherpad.openstack.org/p/newton-deployment-tools-discussion 
) were we 
talked about a cross-project meeting for deployment tools. I would love to see 
something like that happen and it would be great if we can find a specific date 
(maybe monthly) to do something like that. If you are interested in going to 
such a meeting, please reply to this mail with a suggestion when you could join 
such a meeting.

Cheers,
Jan (OpenStack Chef)__
OpenStack Development Mailing 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] Social at the summit

[Miguel Lavalle]

Please count me and James Anziano in!

On Mon, Apr 25, 2016 at 11:56 AM, Edgar Magana 
wrote:

> Would you extend it to ex-cores?
>
> Edgar
>
>
>
>
> On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
>
> >Ihar, Henry and I were talking and we thought Thursday night makes sense
> for a Neutron social in Austin. If others agree, reply on this thread and
> we'll find a place.
> >
> >Thanks!
> >Kyle
> >
> >__
> >OpenStack Development Mailing 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] [oslo.config] Encrypt the sensitive options

[Morgan Fainberg]

On Tue, Apr 26, 2016 at 10:57 AM, Joshua Harlow 
wrote:

> Daniel P. Berrange wrote:
>
>> On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
>>
>>> Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
>>>
 Hello, oslo team

 For now, some sensitive options like password or token are configured as
 plaintext, anyone who has the priviledge to read the configure file can
 get
 the real password, this may be a security problem that can't be
 unacceptable for some people.

 So the first solution comes to my mind is to encrypt these options when
 configuring them and decrypt them when reading them in oslo.config.
 This is
 a bit like apache/openldap did, but the difference is these softwares
 do a
 salt hash to the password, this is a one-way encryption that can't be
 decrypted, these softwares can recognize the hashed value. But if we do
 this work in oslo.config, for example the admin_password in
 keystone_middleware section, we must feed the keystone with the
 plaintext
 password which will be hashed in keystone to compare with the stored
 hashed
 password, thus the encryped value in oslo.config must be decryped to
 plaintext. So we should encrypt these options using symmetrical or
 unsymmetrical method with a key, and put the key in a well secured
 place,
 and decrypt them using the same key when reading them.

 Of course, this feature should be default closed. Any ideas?

>>> Managing the encryption keys has always been the issue blocking
>>> implementing this feature when it has come up in the past. We can't have
>>> oslo.config rely on a separate OpenStack service for key management,
>>> because presumably that service would want to use oslo.config and then
>>> we have a dependency cycle.
>>>
>>> So, we need a design that lets us securely manage those encryption keys
>>> before we consider adding encryption. If we solve that, it's then
>>> probably simpler to encrypt an entire config file instead of worrying
>>> about encrypting individual values (something like how ansible vault
>>> works).
>>>
>>
>> IMHO encrypting oslo config files is addressing the wrong problem.
>> Rather than having sensitive passwords stored in the main config
>> files, we should have them stored completely separately by a secure
>> password manager of some kind. The config file would then merely
>> contain the name or uuid of an entry in the password manager. The
>> service (eg nova-compute) would then query that password manager
>> to get the actual sensitive password data it requires. At this point
>> oslo.config does not need to know/care about encryption of its data
>> as there's no longer sensitive data stored.
>>
>
> That reminds me of the internals of the keyring library that some of the
> openstack clients used to use. It would integrate with mac os keychain,
> linux secret services and things like kwallet and windows secret services
> via its abstractions (code @
> https://github.com/jaraco/keyring/tree/9.0/keyring/backends); perhaps
> oslo.config could integrate with that library (and overcome the issues that
> the python-*-client libraries had with using it/ejecting support for it).
>
> There are probably other similar libraries with similar backends that
> could be used also (but that's the one I know about). A pluggable backend
> might be nice since then u can integrate with your own secret service (for
> example I know yahoo has there own similar service).
>
>
We should not integrate with keyring. It has caused a large number of
issues and has very bad dependency changes (that tend to change in weird
ways). We should/could use something else.

--Morgan
__
OpenStack Development Mailing 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.config] Encrypt the sensitive options

[Guangyu Suo]

2016-04-26 10:33 GMT-05:00 Daniel P. Berrange :

> On Tue, Apr 26, 2016 at 04:24:52PM +0200, Jordan Pittier wrote:
> > On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange  >
> > wrote:
> >
> > > On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
> > > > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> > > > > Hello, oslo team
> > > > >
> > > > > For now, some sensitive options like password or token are
> configured
> > > as
> > > > > plaintext, anyone who has the priviledge to read the configure file
> > > can get
> > > > > the real password, this may be a security problem that can't be
> > > > > unacceptable for some people.
> > >
> > It's not a security problem if your config files have the proper
> > permissions.
>
> Permissions on disk is only one of many problems with storing passwords
> in config files. When people report bugs to upstream or vendors they
> frequently have to provide their configuration files as attachments to
> the bug. This easily compromises their passwords unless they remember
> to scrub them before attaching to the bug, which experiance shows most
> people forgot todo.  We've had countless issues with code inside openstack
> logging variables which contain passwords, causing us to come up with
> stupid hacks to try to scrub passwords before logging.  If you want to
> change your database password, you now forced to update the config
> files on 100's or 1000's of nodes. Sure mgmt tools can automate this
> but it would be better if the problem didn't exist in the first place
>
> > > > > So the first solution comes to my mind is to encrypt these options
> when
> > > > > configuring them and decrypt them when reading them in oslo.config.
> > > This is
> > > > > a bit like apache/openldap did, but the difference is these
> softwares
> > > do a
> > > > > salt hash to the password, this is a one-way encryption that can't
> be
> > > > > decrypted, these softwares can recognize the hashed value. But if
> we do
> > > > > this work in oslo.config, for example the admin_password in
> > > > > keystone_middleware section, we must feed the keystone with the
> > > plaintext
> > > > > password which will be hashed in keystone to compare with the
> stored
> > > hashed
> > > > > password, thus the encryped value in oslo.config must be decryped
> to
> > > > > plaintext. So we should encrypt these options using symmetrical or
> > > > > unsymmetrical method with a key, and put the key in a well secured
> > > place,
> > > > > and decrypt them using the same key when reading them.
> > >
> > The issue here is to find a "well secured place". We should not only move
> > the problem somewhere else.
>
> There is already barbican which could potentially fill that role:
>
>   "Barbican is a REST API designed for the secure storage, provisioning
>and management of secrets such as passwords, encryption keys and X.509
>Certificates." [1]
>
> On startup a process, such as nova, could contact barbican to retrieve
> the credentials it should use for authenticating with each other service
> that requires a password.
>

Barbican is designed for tenancy, right? And it must configure the
keystone_authtoken related options to work with keystone, and this will
have a dependency problem as Doug mentioned.


> > > > >
> > > > > Of course, this feature should be default closed. Any ideas?
> > > >
> > > > Managing the encryption keys has always been the issue blocking
> > > > implementing this feature when it has come up in the past. We can't
> have
> > > > oslo.config rely on a separate OpenStack service for key management,
> > > > because presumably that service would want to use oslo.config and
> then
> > > > we have a dependency cycle.
> > > >
> > > > So, we need a design that lets us securely manage those encryption
> keys
> > > > before we consider adding encryption. If we solve that, it's then
> > > > probably simpler to encrypt an entire config file instead of worrying
> > > > about encrypting individual values (something like how ansible vault
> > > > works).
> > >
> > > IMHO encrypting oslo config files is addressing the wrong problem.
> > > Rather than having sensitive passwords stored in the main config
> > > files, we should have them stored completely separately by a secure
> > > password manager of some kind. The config file would then merely
> > > contain the name or uuid of an entry in the password manager. The
> > > service (eg nova-compute) would then query that password manager
> > > to get the actual sensitive password data it requires. At this point
> > > oslo.config does not need to know/care about encryption of its data
> > > as there's no longer sensitive data stored.
> >
> > This looks complicated. I like text files that I can quickly view and
> edit,
> > if I am authorized to (through good old plain Linux permissions).
>
> As explained earlier, passwords in text files is awful for both security
> and managability at 

Re: [openstack-dev] [oslo.config] Encrypt the sensitive options

[Darren J Moffat]

On 04/26/16 16:33, Daniel P. Berrange wrote:

There is already barbican which could potentially fill that role:

   "Barbican is a REST API designed for the secure storage, provisioning
and management of secrets such as passwords, encryption keys and X.509
Certificates." [1]

On startup a process, such as nova, could contact barbican to retrieve
the credentials it should use for authenticating with each other service
that requires a password.


Where do the creds that nova would use to authenticate to barbican come 
from in that model ?



As explained earlier, passwords in text files is awful for both security
and managability at a large scale.


Agreed. Use of client side certs with TLS where the client side cert 
pathname is what goes into the configuration file can help - that way 
the config file has no credentials in it only pointers to them.  Though 
management of certs has its own problems but again Barbican can help here.



File permissions alone cannot solve that problem.


Agreed, but the combination of file permissions and split configuration 
can be a first step in that direction especially if the default 
configuration files are "split" rather than requiring the admin to know 
about that feature and to do it. It may also help if comments about this 
were placed in the default configuration files to encourage the behaviour.


--
Darren J Moffat

__
OpenStack Development Mailing 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.config] Encrypt the sensitive options

[Mike Bayer]

On 04/26/2016 09:32 AM, Daniel P. Berrange wrote:


IMHO encrypting oslo config files is addressing the wrong problem.
Rather than having sensitive passwords stored in the main config
files, we should have them stored completely separately by a secure
password manager of some kind. The config file would then merely
contain the name or uuid of an entry in the password manager. The
service (eg nova-compute) would then query that password manager
to get the actual sensitive password data it requires. At this point
oslo.config does not need to know/care about encryption of its data
as there's no longer sensitive data stored.


at the end of the day, if someone is on the machine where they can read 
those config files, they are on that machine where they can run any 
Python code they want which itself can be exactly the code in the 
openstack app that contacts this password service and gets the same 
information.   Or put another way, nova-compute still needs a password 
or key of some kind to connect to this password service anyway.


If what we're going for as far as passwords in config files is that they 
don't get committed to source repositories or copied out to public 
places, then fine, store them "somewhere else" just to note that these 
are special values.  But as far as someone on the machine (assuming 
per-user permissions to read the same files that the app can see have 
been acquired), there's always a key/password/token needed to get to 
"the password service", so they have access.   The best you can do is 
run some closed-source executable that has private keys buried within 
it, to at least make this attack more difficult, or if you are really 
looking for something inconvenient, an administrator has to manually 
type in a passphrase when starting up the services.  But we're using 
open source, source-code-present Python and I don't think we're doing 
passphrase-on-startup.   So being on the box means, you have the passwords.





Regards,
Daniel



__
OpenStack Development Mailing 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.config] Encrypt the sensitive options

[Joshua Harlow]

Daniel P. Berrange wrote:

On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:

Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:

Hello, oslo team

For now, some sensitive options like password or token are configured as
plaintext, anyone who has the priviledge to read the configure file can get
the real password, this may be a security problem that can't be
unacceptable for some people.

So the first solution comes to my mind is to encrypt these options when
configuring them and decrypt them when reading them in oslo.config. This is
a bit like apache/openldap did, but the difference is these softwares do a
salt hash to the password, this is a one-way encryption that can't be
decrypted, these softwares can recognize the hashed value. But if we do
this work in oslo.config, for example the admin_password in
keystone_middleware section, we must feed the keystone with the plaintext
password which will be hashed in keystone to compare with the stored hashed
password, thus the encryped value in oslo.config must be decryped to
plaintext. So we should encrypt these options using symmetrical or
unsymmetrical method with a key, and put the key in a well secured place,
and decrypt them using the same key when reading them.

Of course, this feature should be default closed. Any ideas?

Managing the encryption keys has always been the issue blocking
implementing this feature when it has come up in the past. We can't have
oslo.config rely on a separate OpenStack service for key management,
because presumably that service would want to use oslo.config and then
we have a dependency cycle.

So, we need a design that lets us securely manage those encryption keys
before we consider adding encryption. If we solve that, it's then
probably simpler to encrypt an entire config file instead of worrying
about encrypting individual values (something like how ansible vault
works).


IMHO encrypting oslo config files is addressing the wrong problem.
Rather than having sensitive passwords stored in the main config
files, we should have them stored completely separately by a secure
password manager of some kind. The config file would then merely
contain the name or uuid of an entry in the password manager. The
service (eg nova-compute) would then query that password manager
to get the actual sensitive password data it requires. At this point
oslo.config does not need to know/care about encryption of its data
as there's no longer sensitive data stored.


That reminds me of the internals of the keyring library that some of the 
openstack clients used to use. It would integrate with mac os keychain, 
linux secret services and things like kwallet and windows secret 
services via its abstractions (code @ 
https://github.com/jaraco/keyring/tree/9.0/keyring/backends); perhaps 
oslo.config could integrate with that library (and overcome the issues 
that the python-*-client libraries had with using it/ejecting support 
for it).


There are probably other similar libraries with similar backends that 
could be used also (but that's the one I know about). A pluggable 
backend might be nice since then u can integrate with your own secret 
service (for example I know yahoo has there own similar service).




Regards,
Daniel


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

[Vikram Choudhary]

+1 for keeping neutron-dynamic-routing CLI's in neutronclient repo like
other *aaS services.

Thanks
Vikram

On Tue, Apr 26, 2016 at 7:47 PM, Richard Theis  wrote:

> Hi,
>
> The latest devref [1] would place it in python-neutronclient as Henry
> noted. But stay tuned for results from the summit session.
>
> [1]
> https://github.com/openstack/python-neutronclient/blob/master/doc/source/devref/transition_to_osc.rst
>
> - Richard
>
>
> "Na Zhu"  wrote on 04/26/2016 08:29:21 AM:
>
> > From: "Na Zhu" 
> > To: hen...@gessau.net
> > Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> > 
> > Date: 04/26/2016 08:34 AM
> > Subject: Re: [openstack-dev] [neutron] OSC transition
> >
> > Hi Henry,
> >
> > Thanks your information, why you think neutron-dynamic-routing CLI
> > should live in python-neutronclient?
> > From this link http://docs.openstack.org/developer/python-
> > neutronclient/devref/transition_to_osc.htmlsection "Where does my CLI
> belong?
> > ", *aas CLI belongs to their own project, not project python-
> > neutronclient. BGP is also service like *aas, so I think BGP CLIs
> > should live in neutron-dynamic-routing, or a separate repo named
> > python-*client. Pls correct me if I am wrong, thanks.
> >
> >
> >
> > Regards,
> > Juno Zhu
> > IBM China Development Labs (CDL) Cloud IaaS Lab
> > Email: na...@cn.ibm.com
> > 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong
> > New District, Shanghai, China (201203)
> >
> >
> >
> > From:Henry Gessau 
> > To:"OpenStack Development Mailing List (not for usage
> > questions)" 
> > Date:2016/04/26 21:09
> > Subject:Re: [openstack-dev] [neutron] OSC transition
> >
> >
> >
> > Adding the [neutron] tag.
> >
> > I believe that the OSC extension for neutron-dynamic-routing should live
> in
> > the python-neutronclient repo. Keep in touch with Richard Theis as he is
> the
> > one leading the transition to OSC. He is rtheis on IRC.
> >
> > See:
> >
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/093139.html
>
> > https://review.openstack.org/309587
> >
> >
> > Na Zhu  wrote:
> > > Dear All,
> > >
> > >
> > > I have a question about OSC transition, recently, the community
> approves
> > > moving bgp out of neutron, as a service like other *aas. The BGP
> > CLIs need be
> > > removed from neutronclient. Because of OSC transition, I can not
> > just move the
> > > BGP CLIs code from python-neutronclient repo to neutron-dynamic-
> > routing repo.
> > > I have to refactor the code and do transition to OSC plugin system.
> > >
> > > From the
> > > link _http://docs.openstack.org/developer/python-openstackclient/
> > plugins.html_, the
> > > client has a separate repo, take designate as example, the CLI repo is
> > > python-designateclient, the project repo is designate. So for BGP,
> should I
> > > create a repo for CLI, or leverage project repo
> neutron-dynamic-routing?
> > >
> > >
> > >
> > >
> > > Regards,
> > > Juno Zhu
> > > IBM China Development Labs (CDL) Cloud IaaS Lab
> > > Email: na...@cn.ibm.com
> > > 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> > > District, Shanghai, China (201203)
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing 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-dev] [MassivelyDistributed] Massively distributed Clouds Working Group - Inaugural Meeting - This afternoon

[lebre . adrien]

Dear all, 

The inaugural meeting of the Massively Distributed Working Group will be held 
this afternoon at the Hilton  (4:40pm-6:10pm  - Level 6 - Salon)
I remind you that the objective of this working group is to investigate how the 
vanilla OpenStack can support the Fog/Edge Computing use-case. Our goal is not 
to create a new projet but to discuss and propose light/incremental revisions 
to the current code.

Further information available at: 
https://etherpad.openstack.org/p/massively-distributed-clouds. 

Best regards, 
Adrien


__
OpenStack Development Mailing 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.config] Encrypt the sensitive options

[Daniel P. Berrange]

On Tue, Apr 26, 2016 at 04:24:52PM +0200, Jordan Pittier wrote:
> On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange 
> wrote:
> 
> > On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
> > > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> > > > Hello, oslo team
> > > >
> > > > For now, some sensitive options like password or token are configured
> > as
> > > > plaintext, anyone who has the priviledge to read the configure file
> > can get
> > > > the real password, this may be a security problem that can't be
> > > > unacceptable for some people.
> >
> It's not a security problem if your config files have the proper
> permissions.

Permissions on disk is only one of many problems with storing passwords
in config files. When people report bugs to upstream or vendors they
frequently have to provide their configuration files as attachments to
the bug. This easily compromises their passwords unless they remember
to scrub them before attaching to the bug, which experiance shows most
people forgot todo.  We've had countless issues with code inside openstack
logging variables which contain passwords, causing us to come up with
stupid hacks to try to scrub passwords before logging.  If you want to
change your database password, you now forced to update the config
files on 100's or 1000's of nodes. Sure mgmt tools can automate this
but it would be better if the problem didn't exist in the first place

> > > > So the first solution comes to my mind is to encrypt these options when
> > > > configuring them and decrypt them when reading them in oslo.config.
> > This is
> > > > a bit like apache/openldap did, but the difference is these softwares
> > do a
> > > > salt hash to the password, this is a one-way encryption that can't be
> > > > decrypted, these softwares can recognize the hashed value. But if we do
> > > > this work in oslo.config, for example the admin_password in
> > > > keystone_middleware section, we must feed the keystone with the
> > plaintext
> > > > password which will be hashed in keystone to compare with the stored
> > hashed
> > > > password, thus the encryped value in oslo.config must be decryped to
> > > > plaintext. So we should encrypt these options using symmetrical or
> > > > unsymmetrical method with a key, and put the key in a well secured
> > place,
> > > > and decrypt them using the same key when reading them.
> >
> The issue here is to find a "well secured place". We should not only move
> the problem somewhere else.

There is already barbican which could potentially fill that role:

  "Barbican is a REST API designed for the secure storage, provisioning
   and management of secrets such as passwords, encryption keys and X.509
   Certificates." [1]

On startup a process, such as nova, could contact barbican to retrieve
the credentials it should use for authenticating with each other service
that requires a password.

> > > >
> > > > Of course, this feature should be default closed. Any ideas?
> > >
> > > Managing the encryption keys has always been the issue blocking
> > > implementing this feature when it has come up in the past. We can't have
> > > oslo.config rely on a separate OpenStack service for key management,
> > > because presumably that service would want to use oslo.config and then
> > > we have a dependency cycle.
> > >
> > > So, we need a design that lets us securely manage those encryption keys
> > > before we consider adding encryption. If we solve that, it's then
> > > probably simpler to encrypt an entire config file instead of worrying
> > > about encrypting individual values (something like how ansible vault
> > > works).
> >
> > IMHO encrypting oslo config files is addressing the wrong problem.
> > Rather than having sensitive passwords stored in the main config
> > files, we should have them stored completely separately by a secure
> > password manager of some kind. The config file would then merely
> > contain the name or uuid of an entry in the password manager. The
> > service (eg nova-compute) would then query that password manager
> > to get the actual sensitive password data it requires. At this point
> > oslo.config does not need to know/care about encryption of its data
> > as there's no longer sensitive data stored.
>
> This looks complicated. I like text files that I can quickly view and edit,
> if I am authorized to (through good old plain Linux permissions).

As explained earlier, passwords in text files is awful for both security
and managability at a large scale. File permissions alone cannot solve
that problem.

Regards,
Daniel

[1] https://wiki.openstack.org/wiki/Barbican
-- 
|: 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 :|

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

[Jeremy Stanley]

On 2016-04-26 17:29:40 +0200 (+0200), Roman Prykhodchenko wrote:
> I still don’t see python-fuelclient-9.0.0 on PyPi: 
> https://pypi.python.org/pypi/python-fuelclient 
> 
> 
> Shouldn’t someone investigate this?

It hasn't been tagged yet as far as I can tell (no 9.0.0 in the git
repo for openstack/python-fuelclient).
-- 
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] [Fuel] Fuel 9.0 is released

[Roman Prykhodchenko]

I still don’t see python-fuelclient-9.0.0 on PyPi: 
https://pypi.python.org/pypi/python-fuelclient 


Shouldn’t someone investigate this?

> 25 квіт. 2016 р. о 18:33 Daniele Pizzolli  
> написав(ла):
> 
> On Mon, Apr 25 2016, you wrote:
> 
>> Can we support alternative way to download ISO since p2p may be prevented in 
>> some company IT?
> 
> Hello,
> 
> It is supported... but not advertised. I am not sure if this is by
> purpose (maybe because in http there is no additional checksum, see
> later for offline verification). For example to download:
> 
> fuel-community-9.0.iso.torrent
> 
> you can use http:
> 
> http://seed-cz1.fuel-infra.org/fuelweb-community-release/fuel-community-9.0.iso
> http://seed-us1.fuel-infra.org/fuelweb-community-release/fuel-community-9.0.iso
> 
> You can get the links by yourself, by getting the torrent and for
> example using:
> 
> set -- fuel-community-9.0.iso.torrent
> aria2c --show-files -- "$1" \
>| awk '/^[a-zA-Z]/{p=0};/^URL List:/{q=1};/^ http/{p=1};p&{print $1}'
> 
> Sorry for the heavy awk usage... I do not know a simple way to print
> them!  Maybe some bittorrent client has an option for that.
> 
> If you are able to get the torrent file, you can also verify the
> checksum off line, for example by using btcheck.
> 
>> 
>> Thanks,
> 
> Best,
> Daniele
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [oslo.config] Encrypt the sensitive options

[Morgan Fainberg]

On Tue, Apr 26, 2016 at 9:24 AM, Jordan Pittier 
wrote:

>
>
> On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange 
> wrote:
>
>> On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
>> > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
>> > > Hello, oslo team
>> > >
>> > > For now, some sensitive options like password or token are configured
>> as
>> > > plaintext, anyone who has the priviledge to read the configure file
>> can get
>> > > the real password, this may be a security problem that can't be
>> > > unacceptable for some people.
>>
> It's not a security problem if your config files have the proper
> permissions.
>
>
>> > >
>> > > So the first solution comes to my mind is to encrypt these options
>> when
>> > > configuring them and decrypt them when reading them in oslo.config.
>> This is
>> > > a bit like apache/openldap did, but the difference is these softwares
>> do a
>> > > salt hash to the password, this is a one-way encryption that can't be
>> > > decrypted, these softwares can recognize the hashed value. But if we
>> do
>> > > this work in oslo.config, for example the admin_password in
>> > > keystone_middleware section, we must feed the keystone with the
>> plaintext
>> > > password which will be hashed in keystone to compare with the stored
>> hashed
>> > > password, thus the encryped value in oslo.config must be decryped to
>> > > plaintext. So we should encrypt these options using symmetrical or
>> > > unsymmetrical method with a key, and put the key in a well secured
>> place,
>> > > and decrypt them using the same key when reading them.
>>
> The issue here is to find a "well secured place". We should not only move
> the problem somewhere else.
>
>
>> > >
>> > > Of course, this feature should be default closed. Any ideas?
>> >
>> > Managing the encryption keys has always been the issue blocking
>> > implementing this feature when it has come up in the past. We can't have
>> > oslo.config rely on a separate OpenStack service for key management,
>> > because presumably that service would want to use oslo.config and then
>> > we have a dependency cycle.
>> >
>> > So, we need a design that lets us securely manage those encryption keys
>> > before we consider adding encryption. If we solve that, it's then
>> > probably simpler to encrypt an entire config file instead of worrying
>> > about encrypting individual values (something like how ansible vault
>> > works).
>>
>> IMHO encrypting oslo config files is addressing the wrong problem.
>> Rather than having sensitive passwords stored in the main config
>> files, we should have them stored completely separately by a secure
>> password manager of some kind. The config file would then merely
>> contain the name or uuid of an entry in the password manager. The
>> service (eg nova-compute) would then query that password manager
>> to get the actual sensitive password data it requires. At this point
>> oslo.config does not need to know/care about encryption of its data
>> as there's no longer sensitive data stored.
>>
> This looks complicated. I like text files that I can quickly view and
> edit, if I am authorized to (through good old plain Linux permissions).
>
>
>>
>> Regards,
>> Daniel
>>
>
oslo.config already supports multiple configuration files. As long as the
configuration sections are appropriately combined (they should be? if not
there is a gap), we can rely on that feature to handle the split between
"secure" options and "general options". I am strongly against encrypting
the whole file (it doesn't really solve the problem that well). There is a
history of having "secure" files and "generally viewable" config files
(prior art, such as gerrit having a "general" config and a "secure" config)
in many deployments. This also could be handled (decrypting the "secure"
file) by the startup scripts (systemd is *very* good at order of
operations/wait for signals); use of ramdisk and proper POSIX (and SELinux)
attributes can limit concerns about access of the "secure" file (mix in
some ramdisk, and a reboot of the system/systemd stopping the service, can
also clear the "sensitive" data). Expect that the data is ultimately
readable via direct memory access if the standard "best" practices are
insufficient.

There was already talk of having oslo.config supporting an "external store"
(direct access to hiera or similar?) for certain options. That may be
significantly better (and ultimately more controlled) than trying to wedge
encryption into configuration files.
__
OpenStack Development Mailing 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] Social at the summit

[Ben Pfaff]

Sign me up, too.

On Mon, Apr 25, 2016 at 01:07:02PM -0500, Kyle Mestery wrote:
> OK, there is enough interest, I'll find a place on 6th Street for us
> and get a reservation for Thursday around 7 or so.
> 
> Thanks folks!
> 
> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
> > +1 :)
> >
> > Han Zhou
> > Irc: zhouhan
> >
> >
> > On Monday, April 25, 2016, Korzeniewski, Artur
> >  wrote:
> >>
> >> Sign me up :)
> >>
> >> Artur
> >> IRC: korzen
> >>
> >> -Original Message-
> >> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
> >> Sent: Monday, April 25, 2016 7:19 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [neutron] Social at the summit
> >>
> >> Count me in!
> >> Will be good to meet all you guys!
> >>
> >> Darek (dasm) Smigiel
> >>
> >> > On Apr 25, 2016, at 12:13 PM, Doug Wiegley
> >> >  wrote:
> >> >
> >> >
> >> >> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
> >> >> wrote:
> >> >>
> >> >> WAT???
> >> >>
> >> >> It was never supposed to be core only. Everyone is welcome!
> >> >
> >> > +2
> >> >
> >> > irony intended.
> >> >
> >> > Socials are not controlled by gerrit ACLs.  :-)
> >> >
> >> > doug
> >> >
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >>> On 25 Apr 2016, at 11:56, Edgar Magana 
> >> >>> wrote:
> >> >>>
> >> >>> Would you extend it to ex-cores?
> >> >>>
> >> >>> Edgar
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >>  On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
> >> 
> >>  Ihar, Henry and I were talking and we thought Thursday night makes
> >>  sense for a Neutron social in Austin. If others agree, reply on this 
> >>  thread
> >>  and we'll find a place.
> >> 
> >>  Thanks!
> >>  Kyle
> >> 
> >>  ___
> >>  ___ OpenStack Development Mailing 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
> >
> >
> > __
> > OpenStack Development Mailing 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] [oslo.config] Encrypt the sensitive options

[Jordan Pittier]

On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange 
wrote:

> On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
> > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> > > Hello, oslo team
> > >
> > > For now, some sensitive options like password or token are configured
> as
> > > plaintext, anyone who has the priviledge to read the configure file
> can get
> > > the real password, this may be a security problem that can't be
> > > unacceptable for some people.
>
It's not a security problem if your config files have the proper
permissions.


> > >
> > > So the first solution comes to my mind is to encrypt these options when
> > > configuring them and decrypt them when reading them in oslo.config.
> This is
> > > a bit like apache/openldap did, but the difference is these softwares
> do a
> > > salt hash to the password, this is a one-way encryption that can't be
> > > decrypted, these softwares can recognize the hashed value. But if we do
> > > this work in oslo.config, for example the admin_password in
> > > keystone_middleware section, we must feed the keystone with the
> plaintext
> > > password which will be hashed in keystone to compare with the stored
> hashed
> > > password, thus the encryped value in oslo.config must be decryped to
> > > plaintext. So we should encrypt these options using symmetrical or
> > > unsymmetrical method with a key, and put the key in a well secured
> place,
> > > and decrypt them using the same key when reading them.
>
The issue here is to find a "well secured place". We should not only move
the problem somewhere else.


> > >
> > > Of course, this feature should be default closed. Any ideas?
> >
> > Managing the encryption keys has always been the issue blocking
> > implementing this feature when it has come up in the past. We can't have
> > oslo.config rely on a separate OpenStack service for key management,
> > because presumably that service would want to use oslo.config and then
> > we have a dependency cycle.
> >
> > So, we need a design that lets us securely manage those encryption keys
> > before we consider adding encryption. If we solve that, it's then
> > probably simpler to encrypt an entire config file instead of worrying
> > about encrypting individual values (something like how ansible vault
> > works).
>
> IMHO encrypting oslo config files is addressing the wrong problem.
> Rather than having sensitive passwords stored in the main config
> files, we should have them stored completely separately by a secure
> password manager of some kind. The config file would then merely
> contain the name or uuid of an entry in the password manager. The
> service (eg nova-compute) would then query that password manager
> to get the actual sensitive password data it requires. At this point
> oslo.config does not need to know/care about encryption of its data
> as there's no longer sensitive data stored.
>
This looks complicated. I like text files that I can quickly view and edit,
if I am authorized to (through good old plain Linux permissions).


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

[Akihiro Motoki]

It is neutron related topic. I added [neutron] tag to the subject.

2016-04-26 7:19 GMT-05:00 Na Zhu :
> Dear All,
>
>
> I have a question about OSC transition, recently, the community approves
> moving bgp out of neutron, as a service like other *aas. The BGP CLIs need
> be removed from neutronclient. Because of OSC transition, I can not just
> move the BGP CLIs code from python-neutronclient repo to
> neutron-dynamic-routing repo. I have to refactor the code and do transition
> to OSC plugin system.

In the most recent discussion [1], we are thinking to keep CLI supports for *aas
in python-neutronclient repo so that users can use CLI (OSC plugin) just by
installing python-neutronclient. I am fine to keep BGP stuff in the
neutronclient repo.
neutron-dynamic-routing is not listed in [1] yet but we can add
dynamic-routing stuff here.

[1] 
https://github.com/openstack/python-neutronclient/blob/master/doc/source/devref/transition_to_osc.rst

Akihiro

>
> From the link
> http://docs.openstack.org/developer/python-openstackclient/plugins.html, the
> client has a separate repo, take designate as example, the CLI repo is
> python-designateclient, the project repo is designate. So for BGP, should I
> create a repo for CLI, or leverage project repo neutron-dynamic-routing?
>
>
>
>
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
>
> __
> OpenStack Development Mailing 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] OSC transition

[Richard Theis]

Hi,

The latest devref [1] would place it in python-neutronclient as Henry 
noted. But stay tuned for results from the summit session.

[1] 
https://github.com/openstack/python-neutronclient/blob/master/doc/source/devref/transition_to_osc.rst

- Richard


"Na Zhu"  wrote on 04/26/2016 08:29:21 AM:

> From: "Na Zhu" 
> To: hen...@gessau.net
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 04/26/2016 08:34 AM
> Subject: Re: [openstack-dev] [neutron] OSC transition
> 
> Hi Henry,
> 
> Thanks your information, why you think neutron-dynamic-routing CLI 
> should live in python-neutronclient?
> From this link http://docs.openstack.org/developer/python-
> neutronclient/devref/transition_to_osc.htmlsection "Where does my CLI 
belong?
> ", *aas CLI belongs to their own project, not project python-
> neutronclient. BGP is also service like *aas, so I think BGP CLIs 
> should live in neutron-dynamic-routing, or a separate repo named 
> python-*client. Pls correct me if I am wrong, thanks.
> 
> 
> 
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong 
> New District, Shanghai, China (201203)
> 
> 
> 
> From:Henry Gessau 
> To:"OpenStack Development Mailing List (not for usage 
> questions)" 
> Date:2016/04/26 21:09
> Subject:Re: [openstack-dev] [neutron] OSC transition
> 
> 
> 
> Adding the [neutron] tag.
> 
> I believe that the OSC extension for neutron-dynamic-routing should live 
in
> the python-neutronclient repo. Keep in touch with Richard Theis as he is 
the
> one leading the transition to OSC. He is rtheis on IRC.
> 
> See:
> 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093139.html
> https://review.openstack.org/309587
> 
> 
> Na Zhu  wrote:
> > Dear All,
> > 
> > 
> > I have a question about OSC transition, recently, the community 
approves
> > moving bgp out of neutron, as a service like other *aas. The BGP 
> CLIs need be
> > removed from neutronclient. Because of OSC transition, I can not 
> just move the
> > BGP CLIs code from python-neutronclient repo to neutron-dynamic-
> routing repo.
> > I have to refactor the code and do transition to OSC plugin system.
> > 
> > From the
> > link _http://docs.openstack.org/developer/python-openstackclient/
> plugins.html_, the
> > client has a separate repo, take designate as example, the CLI repo is
> > python-designateclient, the project repo is designate. So for BGP, 
should I
> > create a repo for CLI, or leverage project repo 
neutron-dynamic-routing?
> > 
> > 
> > 
> > 
> > Regards,
> > Juno Zhu
> > IBM China Development Labs (CDL) Cloud IaaS Lab
> > Email: na...@cn.ibm.com
> > 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> > District, Shanghai, China (201203)
> > 
> > 
> > 
__
> > OpenStack Development Mailing 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] [TC][tricircle] ask help from TC and other guru in the OpenStack community

[Flavio Percoco]

On 26/04/16 20:39 +0900, Shinobu Kinjo wrote:

On Tue, Apr 26, 2016 at 12:47 PM, joehuang  wrote:

Hi, TCs and guru,



If tricircle planned to apply being TC approved big tent project, would
someone help to guide our project?


I also would like to know what we should do for that so that we focus
on specific things.


Hey Folks,

I'm not sure if you have read these docs but I'd probably start here:

- http://governance.openstack.org/reference/new-projects-requirements.html
- http://docs.openstack.org/project-team-guide

I see you guys have a repo and you're actively contributing to it, which is
great. What kind of guidance are you guys looking for?

Cheers,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: 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] [Glance] Glare and future of artifacts in OpenStack.

[Flavio Percoco]

On 22/04/16 11:35 -0500, Monty Taylor wrote:

On 04/22/2016 10:10 AM, Jay Pipes wrote:


3) On Slide 9, you have this in "future work (in Newton)":

"Tasks (asynchronous workflows) support."

Please, please, please NO.

There is absolutely no reason to couple a service that operates on
artifacts in an asynchronous fashion with a service that provides
metadata about those artifacts.

It was a mistake to do this in Glance and it would be a mistake to do
this in Glare. If you really want some async task processing function,
create a totally separate service that does that. Don't put it in Glare.


+1000

The public task interface in glance is one of the worst user 
experiences in all of OpenStack. Luckily with the new image upload 
work we're moving to a place where tasks can go into a dark hole where 
they belong.


Just one note here. I believe Mike refered to having a task engine and not a
public task API as you know it today. The task engine would be used internally
in Glance/Glare. It actually exists already.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: 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] [oslo.config] Encrypt the sensitive options

[Daniel P. Berrange]

On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:
> Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> > Hello, oslo team
> > 
> > For now, some sensitive options like password or token are configured as
> > plaintext, anyone who has the priviledge to read the configure file can get
> > the real password, this may be a security problem that can't be
> > unacceptable for some people.
> > 
> > So the first solution comes to my mind is to encrypt these options when
> > configuring them and decrypt them when reading them in oslo.config. This is
> > a bit like apache/openldap did, but the difference is these softwares do a
> > salt hash to the password, this is a one-way encryption that can't be
> > decrypted, these softwares can recognize the hashed value. But if we do
> > this work in oslo.config, for example the admin_password in
> > keystone_middleware section, we must feed the keystone with the plaintext
> > password which will be hashed in keystone to compare with the stored hashed
> > password, thus the encryped value in oslo.config must be decryped to
> > plaintext. So we should encrypt these options using symmetrical or
> > unsymmetrical method with a key, and put the key in a well secured place,
> > and decrypt them using the same key when reading them.
> > 
> > Of course, this feature should be default closed. Any ideas?
> 
> Managing the encryption keys has always been the issue blocking
> implementing this feature when it has come up in the past. We can't have
> oslo.config rely on a separate OpenStack service for key management,
> because presumably that service would want to use oslo.config and then
> we have a dependency cycle.
> 
> So, we need a design that lets us securely manage those encryption keys
> before we consider adding encryption. If we solve that, it's then
> probably simpler to encrypt an entire config file instead of worrying
> about encrypting individual values (something like how ansible vault
> works).

IMHO encrypting oslo config files is addressing the wrong problem.
Rather than having sensitive passwords stored in the main config
files, we should have them stored completely separately by a secure
password manager of some kind. The config file would then merely
contain the name or uuid of an entry in the password manager. The
service (eg nova-compute) would then query that password manager
to get the actual sensitive password data it requires. At this point
oslo.config does not need to know/care about encryption of its data
as there's no longer sensitive data stored.

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] [neutron] OSC transition

[Na Zhu]

Hi Henry,

Thanks your information, why you think neutron-dynamic-routing CLI should 
live in python-neutronclient?
>From this link 
http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html
 
section "Where does my CLI belong? ", *aas CLI belongs to their own 
project, not project python-neutronclient. BGP is also service like *aas, 
so I think BGP CLIs should live in neutron-dynamic-routing, or a separate 
repo named python-*client. Pls correct me if I am wrong, thanks.



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Henry Gessau 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   2016/04/26 21:09
Subject:Re: [openstack-dev] [neutron] OSC transition



Adding the [neutron] tag.

I believe that the OSC extension for neutron-dynamic-routing should live 
in
the python-neutronclient repo. Keep in touch with Richard Theis as he is 
the
one leading the transition to OSC. He is rtheis on IRC.

See:
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093139.html
https://review.openstack.org/309587


Na Zhu  wrote:
> Dear All,
> 
> 
> I have a question about OSC transition, recently, the community approves
> moving bgp out of neutron, as a service like other *aas. The BGP CLIs 
need be
> removed from neutronclient. Because of OSC transition, I can not just 
move the
> BGP CLIs code from python-neutronclient repo to neutron-dynamic-routing 
repo.
> I have to refactor the code and do transition to OSC plugin system.
> 
> From the
> link 
_http://docs.openstack.org/developer/python-openstackclient/plugins.html_, 
the
> client has a separate repo, take designate as example, the CLI repo is
> python-designateclient, the project repo is designate. So for BGP, 
should I
> create a repo for CLI, or leverage project repo neutron-dynamic-routing?
> 
> 
> 
> 
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
> 
> 
> 
__
> OpenStack Development Mailing 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] [oslo.config] Encrypt the sensitive options

[Doug Hellmann]

Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:
> Hello, oslo team
> 
> For now, some sensitive options like password or token are configured as
> plaintext, anyone who has the priviledge to read the configure file can get
> the real password, this may be a security problem that can't be
> unacceptable for some people.
> 
> So the first solution comes to my mind is to encrypt these options when
> configuring them and decrypt them when reading them in oslo.config. This is
> a bit like apache/openldap did, but the difference is these softwares do a
> salt hash to the password, this is a one-way encryption that can't be
> decrypted, these softwares can recognize the hashed value. But if we do
> this work in oslo.config, for example the admin_password in
> keystone_middleware section, we must feed the keystone with the plaintext
> password which will be hashed in keystone to compare with the stored hashed
> password, thus the encryped value in oslo.config must be decryped to
> plaintext. So we should encrypt these options using symmetrical or
> unsymmetrical method with a key, and put the key in a well secured place,
> and decrypt them using the same key when reading them.
> 
> Of course, this feature should be default closed. Any ideas?

Managing the encryption keys has always been the issue blocking
implementing this feature when it has come up in the past. We can't have
oslo.config rely on a separate OpenStack service for key management,
because presumably that service would want to use oslo.config and then
we have a dependency cycle.

So, we need a design that lets us securely manage those encryption keys
before we consider adding encryption. If we solve that, it's then
probably simpler to encrypt an entire config file instead of worrying
about encrypting individual values (something like how ansible vault
works).

Doug

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

Re: [openstack-dev] [neutron] OSC transition

[Henry Gessau]

Adding the [neutron] tag.

I believe that the OSC extension for neutron-dynamic-routing should live in
the python-neutronclient repo. Keep in touch with Richard Theis as he is the
one leading the transition to OSC. He is rtheis on IRC.

See:
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093139.html
https://review.openstack.org/309587


Na Zhu  wrote:
> Dear All,
> 
> 
> I have a question about OSC transition, recently, the community approves
> moving bgp out of neutron, as a service like other *aas. The BGP CLIs need be
> removed from neutronclient. Because of OSC transition, I can not just move the
> BGP CLIs code from python-neutronclient repo to neutron-dynamic-routing repo.
> I have to refactor the code and do transition to OSC plugin system.
>  
> From the
> link 
> _http://docs.openstack.org/developer/python-openstackclient/plugins.html_, the
> client has a separate repo, take designate as example, the CLI repo is
> python-designateclient, the project repo is designate. So for BGP, should I
> create a repo for CLI, or leverage project repo neutron-dynamic-routing?
> 
> 
> 
> 
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
> 
> 
> __
> OpenStack Development Mailing 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] [oslo.config] Encrypt the sensitive options

[Guangyu Suo]

Hello, oslo team

For now, some sensitive options like password or token are configured as
plaintext, anyone who has the priviledge to read the configure file can get
the real password, this may be a security problem that can't be
unacceptable for some people.

So the first solution comes to my mind is to encrypt these options when
configuring them and decrypt them when reading them in oslo.config. This is
a bit like apache/openldap did, but the difference is these softwares do a
salt hash to the password, this is a one-way encryption that can't be
decrypted, these softwares can recognize the hashed value. But if we do
this work in oslo.config, for example the admin_password in
keystone_middleware section, we must feed the keystone with the plaintext
password which will be hashed in keystone to compare with the stored hashed
password, thus the encryped value in oslo.config must be decryped to
plaintext. So we should encrypt these options using symmetrical or
unsymmetrical method with a key, and put the key in a well secured place,
and decrypt them using the same key when reading them.

Of course, this feature should be default closed. Any ideas?
__
OpenStack Development Mailing 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] OSC transition

[Na Zhu]

Dear All,


I have a question about OSC transition, recently, the community approves 
moving bgp out of neutron, as a service like other *aas. The BGP CLIs need 
be removed from neutronclient. Because of OSC transition, I can not just 
move the BGP CLIs code from python-neutronclient repo to 
neutron-dynamic-routing repo. I have to refactor the code and do 
transition to OSC plugin system.
 
>From the link 
http://docs.openstack.org/developer/python-openstackclient/plugins.html, 
the client has a separate repo, take designate as example, the CLI repo is 
python-designateclient, the project repo is designate. So for BGP, should 
I create a repo for CLI, or leverage project repo neutron-dynamic-routing?




Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)

__
OpenStack Development Mailing 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] [TC][tricircle] ask help from TC and other guru in the OpenStack community

[Shinobu Kinjo]

On Tue, Apr 26, 2016 at 12:47 PM, joehuang  wrote:
> Hi, TCs and guru,
>
>
>
> If tricircle planned to apply being TC approved big tent project, would
> someone help to guide our project?

I also would like to know what we should do for that so that we focus
on specific things.

>
>
>
> I would like to have one  virtual design summit for Tricircle on UTC 2:00am
> on Friday ( Beijing Time 10:00am Apr. 29), ( Austin time: 9:00pm Apr.28 )
>
>
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
>
>
>
> 
> From: joehuang
> Sent: 26 April 2016 11:40
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev][tricircle] virtual design summit for Newton
>
> Hello,
>
>
>
> Most of our team members in Tricircle are not able to attend the OpenStack
> Austin summit, so we have to have a virtual design summit:
>
>
>
> One etherpad is opened for the topics to be discussed for the virtual Newton
> design summit, please list the topics you want to discuss in the etherpad:
>
>
>
> https://etherpad.openstack.org/p/TricircleNeutonDesignSummit
>
>
>
> The date and time to have this virtual design summit will be at UTC 2:00am
> on Friday ( Beijing Time 10:00am) Apr. 29. ( Austin time: 9:00pm Apr.28 )
>
>
>
> To make Tricircle fully follow OpenStack projects open source development, I
> think we need to apply Tricircle as TC approved big tent project in Newton,
> so this is also one important topic to be discussed.
>
>
>
> Any suggestion are welcome.
>
>
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
>
> 
> From: joehuang
> Sent: 19 April 2016 16:33
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [tricircle]weekly meeting of Apr. 19
>
> This week we will discuss the object operation not implemented.
>
>
>
> IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on
> every Wednesday starting from UTC 13:00.
>
>
>
> Agenda:
>
> # object operation not implemented
>
> # tempest test
>
> # Reliable aync. Job – items left
>
> # Link: https://etherpad.openstack.org/p/TricircleToDo
>
>
>
> If you  have other topics to be discussed in the weekly meeting, please
> reply the mail.
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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][Neutron][Monasca] Traffic counters at Layer 3

[Rubab Syed]

Thanks for replying.

Yes, Armando. I've seen it and I'm using that approach to cater explicit
labels/traffic the user wants to monitor by providing CIDRs in my plugin's
configuration file. However, it gives overall bandwidth for a particular
label. I want the traffic going in, out and generated at the router in
separate metrics. like

qrouter.in_packets_sec
qrouter.forward_packets_sec
qrouter.out_packets_sec

Akihiro, I'm doing something similar. Instead of consuming notifications
(which are insufficient in my case) generated by metering agent, I'm
collecting router's traffic counters from already deployed iptables per
network namespace through monasca agent[1] that performs checks against
your system after configured intervals.

I'm using the approach that if a user deploys monasca agent on a node and
qrouter plugin is enabled, per router per tenant in/out/generated traffic
can be visualized using grafana and used for alarm generation without
having to configure something(such as manual label and rule creation) on
neutron side.

I just want to make sure I'm not missing any traffic passing through
router. Makes sense?

[1] https://github.com/openstack/monasca-agent

Thanks!


On Tue, Apr 26, 2016 at 10:24 AM, Akihiro Motoki  wrote:

> Neutron already supports L3 router with network namespaces which send
> notifications, as Armando mentioned.
> Ceilometer can consume these notification and I think monisca can do
> similar things.
> I believe you can collect enough information for neutron ovs
> implementation.
>
> 2016-04-25 13:20 GMT-05:00 Rubab Syed :
> > Hi folks,
> >
> > I'm writing a plugin for Monasca to monitor traffic at layer 3. My
> Neutron
> > backend is OVS and I'm using iptables of network namespaces for getting
> > traffic counters. Would the following rules in router namespace cover all
> > the traffic at layer 3 per router per tenant?
> >
> > - Chain MONASCA-INPUT in filter table
> >- src: anywhere dest: gateway port IP   // north-south traffic for
> > SNATed and FIPs
> >
> > - Chain MONASCA-FORWARD in filter table
> >   - src: anywhere   dest: anywhere  // east-west traffic
> > inter-network and intra-network
> >
> > - Chain MONASCA-OUTPUT in filter table
> >   - src: gateway port dest: anywhere  // north-south traffic from
> > VMs to public network
> >
> >
> > Would these be sufficient or am I missing something?
> >
> > Thanks!
> >
> > Rubab
> >
> >
> __
> > OpenStack Development Mailing 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] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)]

es and other COE minion nodes.

>>

>> This requirement comes from the below use cases:

>>

>> -  There are 2 kind of baremetal machines in customer site: one is

>> legacy machines which doesn’t support UEFI secure boot and others are

>> new machines which support UEFI secure boot. User want to use Magnum

>> to provisions a Magnum bay of Kubernetes from these 2 kind of

>> baremetal machines and for the machines supporting secure boot, user

>> wants to use UEFI secure boot to boot them up. And 2 Kubernetes

>> label(secure-booted and

>> non-secure-booted) are created and User can deploy their

>> data-senstive/cirtical workload/containers/pods on the baremetal

>> machines which are secure-booted.

>>

>>

>>

>> This requirement requires Magnum to supports 2 Nova flavors(one is

>> “extra_spec: secure_boot=True” and the other doesn’t specify it) based

>> on the Ironic

>> feature(https://specs.openstack.org/openstack/ironic-specs/specs/kilo-

>> implemented/uefi-secure-boot.html

>> ).

>>

>>

>>

>> Could you kindly give me some comments on these requirement or whether

>> it is reasonable from your point? If you agree, we can write design

>> spec and implement this feature?

>>

>>

>>

>> I think the requirement is reasonable, but I would like to solve the

>> problem in a generic way. In particular, there could be another user

>> who might ask for N nova flavors to provision COE nodes in the future.

>> A challenge to support N groups of Nova instances is how to express

>> arbitrary number of resource groups (with different flavors) in a Heat

>> template (Magnum uses Heat template to provision COE clusters). Heat

>> doesn’t seem to support the logic of looping from 1 to N. There could

>> be other challenges/complexities along the way. If the proposed design

>> can address all the challenges and the implementation is clean, I am

>> OK to add support for this feature. Thoughts from others?

> This looks similar to the way we looked at passing a list of availability 
> zones. Mathieu asked and got a good answer:

> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088175.html

>

> Something similar can probably be used to pass multiple flavors? Just in case 
> it helps.

>

> Cheers,

>Ricardo

>

>>

>>

>> Regards,

>>

>> Gary

>>

>>

>> __

>>  OpenStack Development Mailing List (not for usage questions)

>> Unsubscribe:

>> OpenStack-dev-request at 
>> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>?subject:unsubscribe

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

>>

> __

> OpenStack Development Mailing List (not for usage questions)

> Unsubscribe: OpenStack-dev-request at 
> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>?subject:unsubscribe

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

>

> __

> OpenStack Development Mailing List (not for usage questions)

> Unsubscribe: OpenStack-dev-request at 
> lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>?subject:unsubscribe

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

>

> --

> Best Regards, Eli Qiao (乔立勇)

> Intel OTC China

-- next part --

A non-text attachment was scrubbed...

Name: liyong_qiao.vcf

Type: text/x-vcard

Size: 123 bytes

Desc: not available

URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20160426/8890d7c8/attachment.vcf>


Mike Ma
HP Servers Core Platform Software China
Mobile +86 18610248322
Email wentao...@hpe.com<mailto:wentao...@hpe.com>

[http://h71028.www7.hp.com/hpe_logo_email_signature/HPE_logo_email_signature.png]<http://www.hpe.com/>

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

Re: [openstack-dev] [devstack] [vitrage] install vitrage by devstack failed

[Eyal B]

Hi,

I understood from Ifat that now everything works :-)
Let us know if you have more questions

Eyal

On Fri, Apr 22, 2016 at 10:19 AM,  wrote:

>
> Hi folks,
> While installing vitrage by devstack with a fresh clone I am hitting
> following error.
> What could be the problems here? Is there any configures i missed?
> Thank you for help~
>
> ++./stack.sh:echo_summary:385   echo -e Initializing Vitrage
> 2016-04-22 07:38:02.311 | Initializing Vitrage
> ++/opt/stack/vitrage/devstack/plugin.sh:source:255  init_vitrage
> ++/opt/stack/vitrage/devstack/plugin.sh:init_vitrage:179
>  _vitrage_create_accounts
> ++/opt/stack/vitrage/devstack/plugin.sh:_vitrage_create_accounts:69
>  is_service_enabled vitrage-api
> ++functions-common:is_service_enabled:2047  local xtrace
> +++functions-common:is_service_enabled:2048  set +o
> +++functions-common:is_service_enabled:2048  grep xtrace
> ++functions-common:is_service_enabled:2048  xtrace='set -o xtrace'
> ++functions-common:is_service_enabled:2049  set +o xtrace
> ++functions-common:is_service_enabled:2077  return 0
> ++/opt/stack/vitrage/devstack/plugin.sh:_vitrage_create_accounts:71
>  create_service_user vitrage admin
> ++lib/keystone:create_service_user:449  local role=admin
> ++lib/keystone:create_service_user:451  get_or_create_user vitrage
> stack Default
> ++functions-common:get_or_create_user:798   local user_id
> ++functions-common:get_or_create_user:799   [[ ! -z '' ]]
> ++functions-common:get_or_create_user:802   local email=
> +++functions-common:get_or_create_user:816   openstack user create
> vitrage --password stack --domain=Default --or-show -f value -c id
> Discovering versions from the identity service failed when creating the
> password plugin. Attempting to determine version from URL.
> Could not determine a suitable URL for the plugin
> ++functions-common:get_or_create_user:814   user_id=
> +functions-common:get_or_create_user:1 exit_trap
> +./stack.sh:exit_trap:474  local r=1
> ++./stack.sh:exit_trap:475  jobs -p
> +./stack.sh:exit_trap:475  jobs=
>
>
> Here is my local.conf file:
>
> [[local|localrc]]
> ADMIN_PASSWORD=stack
> DATABASE_PASSWORD=stack
> RABBIT_PASSWORD=stack
> SERVICE_PASSWORD=stack
>
> enable_service heat h-api h-api-cfn h-api-cw h-eng
> disable_service tempest
> enable_plugin vitrage https://github.com/openstack/vitrage
> enable_plugin vitrage-dashboard
> https://github.com/openstack/vitrage-dashboard
> enable_plugin ceilometer https://github.com/openstack/ceilometer
> enable_plugin aodh https://github.com/openstack/aodh
>
> GIT_DEPTH=1
>
> [[post-config|$NOVA_CONF]]
> [DEFAULT]
> notification_topics = notifications,vitrage_notifications
> notification_driver=messagingv2
>
>
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is privileged and confidential and is 
> intended for the exclusive use of the addressee(s).  If you are not an 
> intended recipient, any disclosure, reproduction, distribution or other 
> dissemination or use of the information contained is strictly prohibited.  If 
> you have received this mail in error, please delete it and notify us 
> immediately.
>
>
>
>
> __
> OpenStack Development Mailing 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] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[Eli Qiao]

hi Mike
One questions:
Currently, we can specify --master-count --node-count when creating a 
bay, so how will that work if you have defined the nodes count in baymodel?


I think we need some rethinking here.

Eli.

On 2016年04月26日 15:00, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) wrote:

Hi Hongbin, Ricardo
This is mike, I am working with Gary now.
Thanks for Ricardo's good suggestion. I have tried the "map/index"  method ,  
we can use it to passed the minion_flavor_map and the index into the minion cluster 
stack. It does work well.
I think we can update magnum baymodel-create to set the N minion flavors in the 
minion_flavor_map and assign minion counts for each flavor.
For example :
magnum baymodel-create --name k8s-bay-model  --flavor-id 
minion-flavor-0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types 
flavor minion node and total minion nodes  count is 10. The magnum baymode.py 
will parse  this  dictionary and pass them to the heat template parameters 
minion_flavor_map, minion_flavor_count_map. Then the heat stack will work well.

kubecluster-fedora-ironic.yaml
parameters:
   minion_flavor_map:
 type: json
 default:
   '0': minion-flavor-0
   '1': minion-flavor-1
   '2': minion-flavor-2
  
   minion_flavor_count_map:

 type: json
 default:
   '0': 3
   '1': 5
   '2': 2
  
resources:

kube_minions_flavors:
 type: OS::Heat::ResourceGroup
 properties:
   count: { get_param: minion_flavors_counts }
   resource_def:
 type: kubecluster-minion-fedora-ironic.yaml
 properties:
   minion_flavor_map: {get_param: minion_flavor_map}
   minion_flavor_count_map: {get_param: minion_flavor_count_map}
   minion_flavor_index: '%index%'

How do you think about this interface in magnum baymodel to support N falvor to 
provision minion nodes? Do you have any comments about this design for this 
feature?

Thanks && Regards
Mike Ma
HP Servers Core Platform Software China Email wentao...@hpe.com

-Original Message-
From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Sent: Monday, April 25, 2016 3:37 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) 
Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes

Hi Ricardo,

This is really good suggestion. I'd like to see whether we can use 
"foreach"/"repeat" in ResourceGroup in Heat.

Regards,
Gary Duan

-Original Message-
From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
Sent: Thursday, April 21, 2016 3:49 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes

Hi Hongbin.

On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu  wrote:




From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
[mailto:li-gong.d...@hpe.com]
Sent: April-20-16 3:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
provision minion nodes



Hi Folks,



We are considering whether Magnum can supports 2 Nova flavors to
provision Kubernetes and other COE minion nodes.

This requirement comes from the below use cases:

-  There are 2 kind of baremetal machines in customer site: one is
legacy machines which doesn’t support UEFI secure boot and others are
new machines which support UEFI secure boot. User want to use Magnum
to provisions a Magnum bay of Kubernetes from these 2 kind of
baremetal machines and for the machines supporting secure boot, user
wants to use UEFI secure boot to boot them up. And 2 Kubernetes
label(secure-booted and
non-secure-booted) are created and User can deploy their
data-senstive/cirtical workload/containers/pods on the baremetal
machines which are secure-booted.



This requirement requires Magnum to supports 2 Nova flavors(one is
“extra_spec: secure_boot=True” and the other doesn’t specify it) based
on the Ironic
feature(https://specs.openstack.org/openstack/ironic-specs/specs/kilo-
implemented/uefi-secure-boot.html
).



Could you kindly give me some comments on these requirement or whether
it is reasonable from your point? If you agree, we can write design
spec and implement this feature?



I think the requirement is reasonable, but I would like to solve the
problem in a generic way. In particular, there could be another user
who might ask for N nova flavors to provision COE nodes in the future.
A challenge to support N groups of Nova instances is how to express
arbitrary number of resource groups (with different flavors) in a Heat
template (Magnum uses Heat template to provision COE clusters). Heat
doesn’t seem to support the logic of looping from 1 to N. There could
be other challenges/complexities along the way. If the proposed design
can address all the 

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)]

Hi Hongbin, Ricardo
This is mike, I am working with Gary now. 
Thanks for Ricardo's good suggestion. I have tried the "map/index"  method ,  
we can use it to passed the minion_flavor_map and the index into the minion 
cluster stack. It does work well.
I think we can update magnum baymodel-create to set the N minion flavors in the 
minion_flavor_map and assign minion counts for each flavor. 
For example :
magnum baymodel-create --name k8s-bay-model  --flavor-id 
minion-flavor-0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types 
flavor minion node and total minion nodes  count is 10. The magnum baymode.py 
will parse  this  dictionary and pass them to the heat template parameters 
minion_flavor_map, minion_flavor_count_map. Then the heat stack will work well.

kubecluster-fedora-ironic.yaml
parameters:
  minion_flavor_map:
type: json
default:
  '0': minion-flavor-0
  '1': minion-flavor-1
  '2': minion-flavor-2
 
  minion_flavor_count_map:
type: json
default:
  '0': 3 
  '1': 5
  '2': 2
 
resources:
kube_minions_flavors:
type: OS::Heat::ResourceGroup
properties:
  count: { get_param: minion_flavors_counts }
  resource_def:
type: kubecluster-minion-fedora-ironic.yaml
properties:
  minion_flavor_map: {get_param: minion_flavor_map}
  minion_flavor_count_map: {get_param: minion_flavor_count_map}
  minion_flavor_index: '%index%'

How do you think about this interface in magnum baymodel to support N falvor to 
provision minion nodes? Do you have any comments about this design for this 
feature?

Thanks && Regards
Mike Ma
HP Servers Core Platform Software China Email wentao...@hpe.com

-Original Message-
From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
Sent: Monday, April 25, 2016 3:37 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) 
Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes

Hi Ricardo,

This is really good suggestion. I'd like to see whether we can use 
"foreach"/"repeat" in ResourceGroup in Heat.

Regards,
Gary Duan

-Original Message-
From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
Sent: Thursday, April 21, 2016 3:49 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes

Hi Hongbin.

On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu  wrote:
>
>
>
>
> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> [mailto:li-gong.d...@hpe.com]
> Sent: April-20-16 3:39 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
> provision minion nodes
>
>
>
> Hi Folks,
>
>
>
> We are considering whether Magnum can supports 2 Nova flavors to 
> provision Kubernetes and other COE minion nodes.
>
> This requirement comes from the below use cases:
>
> -  There are 2 kind of baremetal machines in customer site: one is
> legacy machines which doesn’t support UEFI secure boot and others are 
> new machines which support UEFI secure boot. User want to use Magnum 
> to provisions a Magnum bay of Kubernetes from these 2 kind of 
> baremetal machines and for the machines supporting secure boot, user 
> wants to use UEFI secure boot to boot them up. And 2 Kubernetes 
> label(secure-booted and
> non-secure-booted) are created and User can deploy their 
> data-senstive/cirtical workload/containers/pods on the baremetal 
> machines which are secure-booted.
>
>
>
> This requirement requires Magnum to supports 2 Nova flavors(one is
> “extra_spec: secure_boot=True” and the other doesn’t specify it) based 
> on the Ironic
> feature(https://specs.openstack.org/openstack/ironic-specs/specs/kilo-
> implemented/uefi-secure-boot.html
> ).
>
>
>
> Could you kindly give me some comments on these requirement or whether 
> it is reasonable from your point? If you agree, we can write design 
> spec and implement this feature?
>
>
>
> I think the requirement is reasonable, but I would like to solve the 
> problem in a generic way. In particular, there could be another user 
> who might ask for N nova flavors to provision COE nodes in the future.
> A challenge to support N groups of Nova instances is how to express 
> arbitrary number of resource groups (with different flavors) in a Heat 
> template (Magnum uses Heat template to provision COE clusters). Heat 
> doesn’t seem to support the logic of looping from 1 to N. There could 
> be other challenges/complexities along the way. If the proposed design 
> can address all the challenges and the implementation is clean, I am 
> OK to add support for this feature. Thoughts from others?

This looks similar to the way we looked at passing a list of availability 

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

[Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)]

Hi Folks
This is mike, I am working with Gary. 
Thanks for Ricardo's good suggestion. I have tried the "map/index"  method ,  
we can use it to passed the minion_flavor_map and the index into the minion 
cluster stack. It does work well.
I think we can update magnum baymodel-create to set the N minion flavors in the 
minion_flavor_map and assign minion counts for each flavor. 
For example :
magnum baymodel-create --name k8s-bay-model  --flavor-id 
minion-flavor-0:3,minion-flavor-1:5, minion-flavor-2:2
It will create 3 types flavor minion node and total minion nodes  count is 10. 
The magnum baymode.py will parse  this  dictionary and pass them to the heat 
template parameters minion_flavor_map, minion_flavor_count_map. Then the heat 
stack will work well.

kubecluster-fedora-ironic.yaml
parameters:
  minion_flavor_map:
type: json
default:
  '0': minion-flavor-0
  '1': minion-flavor-1
  '2': minion-flavor-2
 
  minion_flavor_count_map:
type: json
default:
  '0': 3 
  '1': 5
  '2': 2
 
resources:
kube_minions_flavors:
type: OS::Heat::ResourceGroup
properties:
  count: { get_param: minion_flavors_counts }
  resource_def:
type: kubecluster-minion-fedora-ironic.yaml
properties:
  minion_flavor_map: {get_param: minion_flavor_map}
  minion_flavor_count_map: {get_param: minion_flavor_count_map}
  minion_flavor_index: '%index%'

How do you think about this interface in magnum baymodel to support N falvor to 
provision minion nodes? Do you have any comments about this design for this 
feature?

Thanks && Regards
Mike Ma
HP Servers Core Platform Software China 
Email wentao...@hpe.com



-Original Message-
From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
Sent: Monday, April 25, 2016 3:37 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) 
Subject: RE: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes

Hi Ricardo,

This is really good suggestion. I'd like to see whether we can use 
"foreach"/"repeat" in ResourceGroup in Heat.

Regards,
Gary Duan

-Original Message-
From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
Sent: Thursday, April 21, 2016 3:49 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
provision minion nodes

Hi Hongbin.

On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu  wrote:
>
>
>
>
> From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> [mailto:li-gong.d...@hpe.com]
> Sent: April-20-16 3:39 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to 
> provision minion nodes
>
>
>
> Hi Folks,
>
>
>
> We are considering whether Magnum can supports 2 Nova flavors to 
> provision Kubernetes and other COE minion nodes.
>
> This requirement comes from the below use cases:
>
> -  There are 2 kind of baremetal machines in customer site: one is
> legacy machines which doesn’t support UEFI secure boot and others are 
> new machines which support UEFI secure boot. User want to use Magnum 
> to provisions a Magnum bay of Kubernetes from these 2 kind of 
> baremetal machines and for the machines supporting secure boot, user 
> wants to use UEFI secure boot to boot them up. And 2 Kubernetes 
> label(secure-booted and
> non-secure-booted) are created and User can deploy their 
> data-senstive/cirtical workload/containers/pods on the baremetal 
> machines which are secure-booted.
>
>
>
> This requirement requires Magnum to supports 2 Nova flavors(one is
> “extra_spec: secure_boot=True” and the other doesn’t specify it) based 
> on the Ironic
> feature(https://specs.openstack.org/openstack/ironic-specs/specs/kilo-
> implemented/uefi-secure-boot.html
> ).
>
>
>
> Could you kindly give me some comments on these requirement or whether 
> it is reasonable from your point? If you agree, we can write design 
> spec and implement this feature?
>
>
>
> I think the requirement is reasonable, but I would like to solve the 
> problem in a generic way. In particular, there could be another user 
> who might ask for N nova flavors to provision COE nodes in the future.
> A challenge to support N groups of Nova instances is how to express 
> arbitrary number of resource groups (with different flavors) in a Heat 
> template (Magnum uses Heat template to provision COE clusters). Heat 
> doesn’t seem to support the logic of looping from 1 to N. There could 
> be other challenges/complexities along the way. If the proposed design 
> can address all the challenges and the implementation is clean, I am 
> OK to add support for this feature. Thoughts from others?

This looks similar to the way we looked at passing a list of availability 
zones. Mathieu