Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Ed Leafe
On Jul 18, 2016, at 12:39 PM, Fox, Kevin M  wrote:

> I'm arguing the opposite. It should be a requirement to use the OpenStack 
> Secret Store.
> 
> Instead, we're trying to make it optional and either reimplementing large 
> swaths of it in individual projects to make it optional, or skip security all 
> together.
> 
> If it wasn't optional, then:
> * Keystone could rely on it being there for password hashing
> * Magnum can rely on it for security.
> * lbaas can rely on it
> * App developers can rely on it being there
> * ...
> 
> Same with Zaqar. It was a requirement then,
> * Guest agents of heat, sahara, mangum, trove, etc could all rely on it being 
> there and wouldn't have to deal with workarounds
> * Horizon could rely on it being there for dynamic ui
> * App developers can rely on it being there.
> 
> Yes, it seems like more work for an operator to have to install "one more 
> thing", but the savings it provides by not having to do that "one more thing" 
> in 7 different projects pays for it.

There is a lot to be said for code simplification. When Glance split out of 
Nova, the knowledge that Glance would be required to be there meant the the 
code in Nova for interacting with it didn’t have to contain tons of ‘if :  else ”. Knowing that that code was 
unnecessary made writing the interaction much simpler (and less tedious to 
read). So if we added, say, Barbican as a requirement, all of the other 
projects that need to handle secrets (a lot of them!) could simply program to 
the Barbican interface, and be done with it.

The discussion of whether project X should be required is a whole ‘nother 
topic. But I want to emphasize that often the utility of having a standard is 
grossly underestimated.

In this discussion, the issue that seems to be arising is that the Big Tent 
doesn’t provide for a path for a project to be reconsidered as an OpenStack 
standard, in the way that Nova and Glance and Swift are. The Small Tent 
“incubation” process designed to identify which projects were mature enough to 
be considered “one of us”, when “us” was the group of core projects. This was 
unnecessarily harsh, and pushed away many worthy efforts. In an attempt to 
improve this, the definition of “one of us” was broadened so that lots of 
interesting projects could be part of the community.

What I think is causing some confusion (and friction) is that OpenStack needs 
two “us”s: what projects are part of our ecosystem and build software in the 
same open way (the Big Tent concept), and which are a fundamental component of 
the overall OpenStack software, which all other projects can assume are 
available (the Small Tent concept). 

To that end, it seems necessary to define a migration path for a project to 
become required. Of course, most will never need to be required, but I think a 
case could be made that several projects (Barbican and Zaqar are the obvious 
ones here) have matured to the point where it makes sense to standardize on 
them. They are mature, and no other projects have come along to challenge their 
designs. At some point, it makes sense to stop pretending that there are 
options, and establish a standard instead.


-- Ed Leafe






__
OpenStack Development Mailing 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] [mistal] Mistral logo ideas?

2016-07-18 Thread Renat Akhmerov


> On 18 Jul 2016, at 19:54, Ryan Brady  wrote:
> 
> On Mon, Jul 18, 2016 at 12:44 AM, Renat Akhmerov  > wrote:
> On choosing a mascot for Mistral. Let’s choose one till next Monday.
> 
> To start this discussion I’d like to propose a couple of ideas:
> 
> Octopus (kind of symbolic to me). How do you like this beauty? 
> http://nashaplaneta.su/_bl/158/78285238.jpg 
> 
> 
>  +1.  Intelligence, dexterity, tool-use - many good qualitites to associate 
> with.
> 

Yep :)


Renat Akhmerov
@Nokia

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


Re: [openstack-dev] [glance] selecting project mascot

2016-07-18 Thread Nikhil Komawar
The etherpad poll has been closed and the votes and the top 3 candidates
in the preferential order have been sent for further evaluation. We will
most likely be selecting one of the 3 candidates mentioned at the near
bottom of the etherpad. More to come once selection has been made.


On 7/12/16 11:24 AM, Nikhil Komawar wrote:
> Hi,
>
>
> Please find this etherpad [1] for helping collaboratively choose Glance
> project mascot. All the information needed to help understand the
> process is in the etherpad.
>
>
> There are quite a few proposals already. Please note the poll closes
> Monday July 18th so please cast your votes as soon as possible.
>
>
> [1] https://etherpad.openstack.org/p/glance-project-mascot
>
>

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing 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] 答复: [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

2016-07-18 Thread zhou . ya
+1
周亚   Zhou Ya
虚拟化南京一部NIV Nanjing Dept.Ⅰ



R Building, ZTE Plaza, #6 Huashen Ave. 
Yuhuatai District, Nanjing, P.R.China, 210012
T: +86 13951010061  M: +86 13772010248
E: zhou...@zte.com.cn
www.zte.com.cn




发件人: 胡智江180967/user/zte_ltd
收件人: openstack-dev@lists.openstack.org, huzhiji...@gmail.com, 
lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn, 
kong.w...@zte.com.cn, janonymous.codevult...@gmail.com, 
WuWei10166727/user/zte_ltd@ZTE_LTD, HuZhiJiang180967/user/zte_ltd@ZTE_LTD, 

日期:   2016/07/19 10:21
主题:   [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core 
project


Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.



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-dev] 答复: [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

2016-07-18 Thread sun . jing22
+1
 
孙静  Sun Jing
虚拟化南京一部/无线研究院  NIV Nanjing dept.I / Wireless Product R 
Institute



南京市花神大道6号中兴通讯二期5楼
ZTE Corporation, No6, Huashendadao Road
Yuhuatai District, Nanjing, P.R.China, 210012
T:+86 M: +86 18551731425
E: sun.jin...@zte.com.cn
www.zte.com.cn




胡智江180967/user/zte_ltd
2016/07/19 10:21

收件人
openstack-dev@lists.openstack.org, huzhiji...@gmail.com, 
lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn, 
kong.w...@zte.com.cn, janonymous.codevult...@gmail.com, 
WuWei10166727/user/zte_ltd@ZTE_LTD, HuZhiJiang180967/user/zte_ltd@ZTE_LTD, 

抄送

主题
[daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project





Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.



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-dev] [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

2016-07-18 Thread hu . zhijiang
Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.


B.R.,
Zhijiang



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-dev] [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

2016-07-18 Thread hu . zhijiang
Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.


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-dev] OpenStack: Happy 6th Birthday:)

2016-07-18 Thread Wang, Shane


__
OpenStack Development Mailing 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] Applying for stable-follows tag

2016-07-18 Thread Jeffrey Zhang
+1 to apply
I'd like to be the volunteer.

On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
 wrote:
> On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke  wrote:
>> Hi Steve,
>>
>> +1 to applying. I'll volunteer for the backport team also.
>>
>> -Paul
>>
>>
>> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>>>
>>> Hey Koalians,
>>>
>>> I'd like us to consider applying  for the stable follows policy tag.
>>>   Full details are here:
>>>
>>>
>>> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>>>
>>> Because of the magic work we did to make liberty functional, it is
>>> possible that we may not be able to apply for this tag until Liberty
>>> falls into EOL.  Still I personally believe intent matters most, and our
>>> intent has always been for these to be stable low-rate-of-change
>>> no-feature-backport branches.  There are some exceptions I think we
>>> would fit under for the Liberty case, so I think it is worth a shot.
>>>
>>> I'd need 2-4 people to commit to joining the stable backport team for
>>> Kolla reviews specifically.  These folks would be the only folks that
>>> could ACK patches in the stable branch maintenance queue.  Anyone could
>>> continue to submit backport patches as they desire.
>>>
>>> I'll leave voting open for 1 week or until there I a majority (6 core
>>> reviewers) or until there is a unanimous vote.  If there is not, then we
>>> won't apply.  The deadline for this vote is July 25th.
>>>
>>> Thanks!
>>> -steve
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
> +1 to apply for stable follows policy.
> I would like to volunteer for the backport team.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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


Re: [openstack-dev] [glance][nova] Globally disabling hw_qemu_guest_agent support

2016-07-18 Thread Daniel Russell
Hi Erno,

For the size of team I am in I think it would work well but it feels like I am 
putting the security of Nova in the hands of Glance.

What I was more after was a setting in Nova that says 'this hypervisor does not 
allow guest sockets and will ignore any attempt to create them', 'this 
hypervisor always creates guest sockets regardless of your choice', 'this 
hypervisor will respect whatever you throw in hw_qemu_guest_agent with a 
default of no', or 'this hypervisor will respect whatever you throw in 
hw_qemu_guest_agent with a default of yes'.  It feels like a more appropriate 
place to control and manage that kind of configuration.

Thanks for the pointer, and I will implement it in our environment, but I guess 
it opens up a larger question of '*should* I manage that kind of config in that 
manner?'

Regards,
Daniel.

-Original Message-
From: Erno Kuvaja [mailto:ekuv...@redhat.com] 
Sent: Tuesday, 19 July 2016 10:09 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance][nova] Globally disabling 
hw_qemu_guest_agent support

Hi Daniel,

You might want to have look on the Glance Property Protections [0].
I'd assume that would do it for you?

[0] http://docs.openstack.org/developer/glance/property-protections.html

Best,
Erno

On Tue, Jul 19, 2016 at 12:43 AM, Daniel Russell  
wrote:
> Hi,
>
>
>
> We are running a public cloud and allow customers to upload their own 
> images.  A concern we have is that a customer could set 
> hw_qemu_guest_agent=yes in the image metadata and then get a socket to 
> the hypervisor created when running.  For us, this is a bit of a 
> security concern and I’m not aware of any way to globally disable this 
> feature at the moment.
>
>
>
> Is there any work going on to add the ability to enable/disable the 
> feature globally?  Would it be of interest to the project(s) to add that?
>
>
>
> I am happy to look into it and am keen to start contributing if it’s 
> deemed low enough hanging fruit for a new guy!
>
>
>
> Regards,
>
> DANIEL RUSSELL
> Solution Architect
>
>
>
>
> __
>  OpenStack Development Mailing 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] [glance][nova] Globally disabling hw_qemu_guest_agent support

2016-07-18 Thread Erno Kuvaja
Hi Daniel,

You might want to have look on the Glance Property Protections [0].
I'd assume that would do it for you?

[0] http://docs.openstack.org/developer/glance/property-protections.html

Best,
Erno

On Tue, Jul 19, 2016 at 12:43 AM, Daniel Russell
 wrote:
> Hi,
>
>
>
> We are running a public cloud and allow customers to upload their own
> images.  A concern we have is that a customer could set
> hw_qemu_guest_agent=yes in the image metadata and then get a socket to the
> hypervisor created when running.  For us, this is a bit of a security
> concern and I’m not aware of any way to globally disable this feature at the
> moment.
>
>
>
> Is there any work going on to add the ability to enable/disable the feature
> globally?  Would it be of interest to the project(s) to add that?
>
>
>
> I am happy to look into it and am keen to start contributing if it’s deemed
> low enough hanging fruit for a new guy!
>
>
>
> Regards,
>
> DANIEL RUSSELL
> Solution Architect
> 340 Findon Road, KIDMAN PARK, SA 5025
> T: +61 8 8461 4841 F: +61 8 8461 4899
> E: dani...@hostworks.com.au
> W: www.hostworks.com.au
>
>
>
>
> __
> OpenStack Development Mailing 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] [glance][nova] Globally disabling hw_qemu_guest_agent support

2016-07-18 Thread Kris G. Lindgren
I also happened to be looking at this today and was wondering about this as 
well.  From the multi-places that talk about how to enable the qemu guest agent 
for quiescing drives during snapshots, they all have a warning that this should 
be enabled on trusted guests only. [1] [2] [3]  So, I am wondering has anyone 
actually solved any of the security issues called out in the tail end of [3]? 
It seems interesting that we would would make it so where the only flag that’s 
needed to enabled/disable this is done on the image metadata – which any users 
that is given permission to upload images can set.  Since this opens up a 
communication channel directly between the Untrusted (for most people running a 
cloud) vm and libvirt running on the HV.

[1] - 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/chap-QEMU_Guest_Agent.html#idp9487712
 (see the warning directly the title)
[2] - http://wiki.libvirt.org/page/Qemu_guest_agent (see the last sentence)
[3] - http://wiki.qemu.org/Features/QAPI/GuestAgent (See the Security section)
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
__
OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Joshua Harlow
I applaud this (since I know this kind of question and work is really 
really hard). So thanks for starting and keeping 'hard' questions going 
because without someone pushing the limit here (and/or raising the 
questions) I too fear what u fear and that we may be obsoleting 
ourselves by continuing down the path we are on (death by a thousand 
cuts anyone?)


In general I'd also like to know how cross-project things will be any 
different with the TC work, tags, release goals or other? I have a glass 
is half full feeling that those kind of things are 'to soft' or 'to 
late' but maybe I should just think more positive, but then I'm sort of 
in the camp that much *much* more aggressive action must be taken here.


Thus why I think the starting of the architecture working group is a 
good thing; because I have a believe that people are forgetting among 
all of this that such a group holds a lot of the keys to the kingdom 
(whether u, the reader, want to admit that or not is well the readers 
problem) in openstack (sorry and no disrespect to independent folks & 
contributors), but most of us work for large companies that have 
architects (and leads) and if those architects (and leads) can get 
together cross-company to aggregate and (agree on) and solve actual 
problems then that really is IMHO the only way to keep our projects 
healthy (assuming we can even do that at this stage).


Sadly I'm not sure if it's already to late for an architecture working 
group of which one of its goals (IMHO) is to do said analysis & 
aggregation of 'worker bees' to actually make fixes and solutions 
appear; but I'll remain hopefully on that (for now).


Fox, Kevin M wrote:

I feel like I'm just the messenger here. Please don't shoot me. I'm generally 
trying to provide good, though hard feedback to better a perceived problem. 
Many others would just stay silent or leave rather then have the difficult 
discussion.


__
OpenStack Development Mailing 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] [grenade] upgrades vs rootwrap

2016-07-18 Thread Sean Dague

On 07/04/2016 05:36 AM, Sean McGinnis wrote:

On Mon, Jul 04, 2016 at 01:59:09PM +0200, Thierry Carrez wrote:
[...]

The issue here is that oslo.rootwrap uses config files to determine
what to allow, but those are not really configuration files as far
as the application using them is concerned. Those must match the
code being executed.

So from Grenade perspective, those should really not be considered
configuration files, but application files.

[...]

+1

I have to agree with this perspective. They are config files, but they
are a special type of config file that is closely tied in to the code. I
think we should treat them as application files.

I say we allow these changes for grenade and move forward on this. I
think we all agree we want to move to privsep. As long as we document
this very clearly that these changes need to be made for upgrades, I'm
OK with that.

I would really like to be able to decided on this and move forward. I'm
afraid sticking with rootwrap for another cycle with just confuse things
and compound our issues.


So, can we just put them in python code inline then and abandon etc?

Special config files that we don't want anyone to touch, but we put in 
/etc, aren't really a thing. You really can't have it both ways. Either 
these are in the part of the filesystem where ops expect to change them, 
or they are not.


-Sean

--
Sean Dague
http://dague.net

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


Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

2016-07-18 Thread Sean Dague

On 07/07/2016 01:12 PM, Davanum Srinivas wrote:

Folks,

The nova-docker project[1] is barely alive[2]. So i'll kick off the
process of retiring the project [3]

Thanks,
Dims

[1] http://git.openstack.org/cgit/openstack/nova-docker/
[2] http://stackalytics.com/report/contribution/nova-docker/30
[3] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project


It seems prudent.

Thanks Dims for keeping this effort alive so long. It's unfortunate that 
no one else was up for maintaining this driver.


-Sean

--
Sean Dague
http://dague.net

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


[openstack-dev] [glance][nova] Globally disabling hw_qemu_guest_agent support

2016-07-18 Thread Daniel Russell
Hi,

We are running a public cloud and allow customers to upload their own images.  
A concern we have is that a customer could set hw_qemu_guest_agent=yes in the 
image metadata and then get a socket to the hypervisor created when running.  
For us, this is a bit of a security concern and I'm not aware of any way to 
globally disable this feature at the moment.

Is there any work going on to add the ability to enable/disable the feature 
globally?  Would it be of interest to the project(s) to add that?

I am happy to look into it and am keen to start contributing if it's deemed low 
enough hanging fruit for a new guy!

Regards,
DANIEL RUSSELL
Solution Architect
340 Findon Road, KIDMAN PARK, SA 5025
T: +61 8 8461 4841 F: +61 8 8461 4899
E: dani...@hostworks.com.au
W: www.hostworks.com.au

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


Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

2016-07-18 Thread Joshua Harlow
Also to go further into a little mini-retrospective we did during our 
meeting. This got released and passed through the periodic jobs we run 
before releasing in oslo due to primarily a timing glitch. When the 
patch[0] was proposed to the release repo the nova periodic jobs were 
fine and releasing looked ok, but what was noticed is that the commit 
that got merged into oslo.context[1] was with-in the 24 hour period of 
those periodic jobs[2] and hadn't been put through the 'wringer' just 
yet, thus how it got released.


So to help that process going forward (and to make it more visible) I 
made a 'oslobot' which has as one of its main commands the ability to 
easily check the failed jobs and report them back into IRC (code and 
review for this is at https://review.openstack.org/#/c/343857/).


That should help mitigate this kind of situation going forward although 
I also agree with what ronald says below in that some of the tests being 
performed are reaching a little to far into oslo.context to do that 
testing (ie knowing what to_dict outputs starts to cross a API boundary 
IMHO).


[0]: https://review.openstack.org/#/c/340578/
[1]: https://review.openstack.org/#/c/331916/
[2]: https://wiki.openstack.org/wiki/Oslo#Periodic

Ronald Bradford wrote:

Hi All,

For Oslo libraries we ensure that API's are backward compatible for 1+ releases.
When an Oslo API adds a new class attribute (as in this example of
is_admin_project and 4 other attributes) added to Oslo Context in
2.6.0,  these are added to ensure this API is also forward compatible
with existing project code for any contract with the base class
instantiation or manipulation.

The issue seen is presently Nova specific (as other projects can
utilize 2.6.0) and it is related to projects that sub-class
oslo.context, and how unit tests are written for using class
parameters.  Ideally, to implement using oslo.context correctly
OpenStack projects should:

* Not perform direct dictionary to dictionary comparisons with the
to_dict() method as this does not support when new attributes at
added. Two patches (one to nova) address this in offending projects
[5][6]
* Unit tests should focus on attributes specific to the sub-classed
signature, e.g. [7].  Oslo context provides an extensive set of unit
tests for base class functionality. This is a wish list item for
projects to implement.

The to_dict() method exists as a convenience method only and is not an
API contract. The resulting set of keys should be used accordingly.
This is why there is no major release version.
There is a note from our discussion in Oslo to improve our
documentation to describe the API use of to_dict() better and state we
will not remove to_dict() keys within a release, but that may happen
between releases.

There is a subsequent problem with how Nova performs a warning test
[8]. Additional reviews are looking at addressing this sub-class usage
of from_dict() and to_dict().

Regards

Ronald


[5] https://review.openstack.org/#/c/343694/,
[6] https://review.openstack.org/#/c/342367/
[7] https://review.openstack.org/#/c/342869/
[8] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144

On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
  wrote:

On 7/18/2016 9:42 AM, Matt Riedemann wrote:

On 7/18/2016 9:09 AM, Markus Zoeller wrote:

Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
Portland and won't be available for the next 2h or so.
If you can have a look at it and merge it, that would be great.

References:
[1]

https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1

[2] https://review.openstack.org/#/c/342604/1
[3] https://bugs.launchpad.net/nova/+bug/1603979
[4] logstash: http://goo.gl/79yFb9


This is an API change for oslo.context, why wasn't it released as 3.0.0?

Seems we should revert the upper-constraints bump and blacklist 2.6.0,
then get that released as 3.0.0.


Here is the blacklist:

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


--

Thanks,

Matt Riedemann


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


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

Re: [openstack-dev] [nova] Let's kill quota classes (again)

2016-07-18 Thread Sean Dague

On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:

The original concept of quota classes was to allow the default quotas
applied to a tenant to be a function of the type of tenant.  That is,
say you have a tiered setup, where you have gold-, silver-, and
bronze-level customers, with gold having lots of free quota and bronze
having a small amount of quota.  Rather than having to set the quotas
individually for each tenant you created, the idea is that you set the
_class_ of the tenant, and have quotas associated with the classes.
This also has the advantage that, if someone levels up (or down) to
another class of service, all you do is change the tenant's class, and
the new quotas apply immediately.

(By the way, the turnstile integration was not part of turnstile itself;
there's a turnstile plugin to allow it to integrate with nova that's
quota_class-aware, so you could also apply rate limits this way.)

Personally, it wouldn't break my heart if quota classes went away; I
think this level of functionality, if it seems reasonable to include,
should become part of a more unified quota API (which we're still
struggling to come up with anyway) so that everyone gets the benefit…or
perhaps shares the pain? ;)  Anyway, I'm not aware of anyone using this
functionality, though it might be worth asking about on the operators
list—for curiosity's sake, if nothing else.  It would be interesting to
see if anyone would be interested in the original idea, even if the
current implementation doesn't make sense :)


We've already dropped the hook turnstile was using, so I don't see any 
reason not to drop this bit as well. I don't think it will work for 
anyone with the current code.


I agree that this probably makes way more sense in common quota code 
then buried inside of Nova.


-Sean

--
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

2016-07-18 Thread Steve Martinelli
You can create a new ocata directory if one is not present

On Jul 18, 2016 7:24 PM, "Adrian Turjak"  wrote:

>
>
> On 19/07/16 03:31, Steve Martinelli wrote:
> > I think the change you posted could very much just
> > replace the existing password plugin in keystone (
> > https://review.openstack.org/#/c/343422/) and not be it's own plugin.
> >
> > How about a specification instead?
> > https://github.com/openstack/keystone-specs :)
> > It's unlikely to land in Newton, but would be a candidate for O.
> >
>
> Will do. I'll edit my patch/blueprint to be clear that this is a
> replacement for password that does not affect normal username/password
> functionality, just adds MFA support, and write a spec for the O release.
> :)
>
> Although looking at that repo, since there isn't a folder yet for O,
> should I just throw it in ongoing?
>
> As for your gerrit comments:
> > Is there a reason you created totp_password plugin and not just added
> to the existing password plugin?"
>
> Mainly I wasn't sure if this was something people wanted and I didn't
> want to propose replacing the default password auth module as I thought
> an optional second plugin would be easier to get people to approve.
> Turns out I was wrong!
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] About deleting keypairs

2016-07-18 Thread Sean Dague

On 07/18/2016 08:14 AM, Matt Riedemann wrote:


Nova doesn't actually validate the user_id passed into the keypairs API
is valid, does it? Like flavor access and quotas, Nova is given an ID
but doesn't validate it with Keystone. So we don't actually need
Keystone to find these do we?

I'm not saying that's great, we already had a spec approved for Newton
to check the provided user/project ID with keystone for the flavor
access and quotas APIs, we could do the same for keypairs.

You could, however, write a script that deletes keypairs for user_ids
that don't exist in Keystone...


A user can be in more than one project, so delete of users in projects 
automatically has some edge conditions, enough so that I'm not sure we'd 
ever want that automatically.


My suggestion would be a periodic purge of your local records by looking 
up the userids in keystone. The dead keys are doing very little other 
than taking up space, so it's mostly just about compaction, which could 
be run on a weekly basis.


-Sean

--
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

2016-07-18 Thread Adrian Turjak


On 19/07/16 03:31, Steve Martinelli wrote:
> I think the change you posted could very much just
> replace the existing password plugin in keystone (
> https://review.openstack.org/#/c/343422/) and not be it's own plugin.
> 
> How about a specification instead?
> https://github.com/openstack/keystone-specs :)
> It's unlikely to land in Newton, but would be a candidate for O.
> 

Will do. I'll edit my patch/blueprint to be clear that this is a
replacement for password that does not affect normal username/password
functionality, just adds MFA support, and write a spec for the O release. :)

Although looking at that repo, since there isn't a folder yet for O,
should I just throw it in ongoing?

As for your gerrit comments:
> Is there a reason you created totp_password plugin and not just added
to the existing password plugin?"

Mainly I wasn't sure if this was something people wanted and I didn't
want to propose replacing the default password auth module as I thought
an optional second plugin would be easier to get people to approve.
Turns out I was wrong!






__
OpenStack Development Mailing 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] [keystone] project mascot -- turtle!

2016-07-18 Thread Steve Martinelli
We have decided it will be a turtle. (hard shell, security, get it!)

A poll was created, anyone who had 2 or more commits in a keystone project
during the Mitaka or Newton release had a vote. The options were made by
active keystone developers during a meeting. Poll results are here [1], in
case there is a conflict/copyright issue/etc. we can go with #2 (or #3 or
...) on the list.

[1] http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_3b96ec71a39af395
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Angular action services and initScope

2016-07-18 Thread Richard Jones
On 18 July 2016 at 11:49, Rob Cresswell 
wrote:

> Maybe I'm missing the point, but the schema stuff just defines a model and
> passes it to the schema directive via ctrl; doesn't that remove any issues
> with workflows? ui-bootstraps modal and modalinstance already provides a
> way to pass that data back to the initial location (table etc) again
>

In a nutshell, yes this is the goal I'm aiming for, though some of the
details might vary.


  Richard
__
OpenStack Development Mailing 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] [Keystone] Multi-factor Auth with Keystone and TOTP

2016-07-18 Thread Adrian Turjak


On 19/07/16 01:49, David Stanek wrote:
> On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak  
> wrote:
>> We need an MFA solution, and this doesn't seem like too terrible an option.
> 
> 
> One thing to note here is that the credentials for TOTP stored in the
> keystone credentials backend are not encrypted. So a breach of your
> database could expose those to an attacker. This is a review[1] to fix
> this issue that is close to merging.
> 
> 1. https://review.openstack.org/#/c/317169/
> 

Have noticed this, and we are looking at a few options to do something
about this by protecting our Keystone database. This review is ideal and
something I will keep and eye on!

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


Re: [openstack-dev] [Horizon] Angular action services and initScope

2016-07-18 Thread Richard Jones
On 18 July 2016 at 11:34, Tripp, Travis S  wrote:

> TL;DR, I’ll be quite happy to get rid of the need for initScope and like
> exploring a common way to share model other than events.
>
>  |From: Richard Jones 
> | Date: Sunday, July 17, 2016 at 6:55 PM
>
> | I think this is a bad idea because in the angular world "factory" means
> singleton
> | (which is totally opposite to what everyone else in the programming
> world [and the rest]
> | thinks "factory" means but hey, angular gonna angular) and we'd be
> changing that, and
> | the potential for confusion would be very high.
>
> | Controllers are already not singletons - I see no reason why mutable
> state shouldn't be |
> | contained in *them*. We don't need to invent something new to hold that
> mutable state.
>
> As FYI, the way I mentioned for factories is *not* inventing something new
> and is how they were intended and even used in angular in that way.  A
> factory is a singleton object whose job is to create instances of objects.
> It is even used that way in angular code. See $cacheFactory [0]
>
> [0]
> https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js
>
> The differentiation of .factory vs .service is still obtuse since they are
> both singletons, but the concept of a factory object whether .service or
> .factory still remains.
>

Ah, yep, sorry for the confusion there - what I was getting at is that the
data for doing things is already handled by controllers, so let's use
those, rather than create something new to do it. My grumpiness about
"factory" was a distraction ;-)



> |From: Richard Jones 
> | Date: Sunday, July 17, 2016 at 6:55 PM
>
> | But the workflow implementation has no concept of an over-arching model
> for
> | the workflow. If that was changed, I believe all the current $scope
> shenanigans
> |(which are basically about short-circuiting the workflow not doing its
> job ;-) would
> | go away.
>
> The event based mechanism was an attempt originally proposed by Thai to
> get around the essentially hard coded shared model service in launch
> instance where the steps are tightly bound to that model service. There was
> also some idea that some steps could be reusable / recomposable across work
> flows (such as update metadata) if you didn’t tightly bind things.
>

I'd like to call YAGNI here :-)



> |From: Richard Jones 
> | Date: Sunday, July 17, 2016 at 6:55 PM
>
> | So, here's my rough thought: workflow.model is an object with properties
> named for
> | each of the workflow steps - using the step formName as the name (hell,
> schema
> | form could probably make this a doddle). The workflow model is passed to
> the
> | controller for each step, which uses its own named model to store the
> data captured
> | by the step - and as a side effect it can poke at (and watch) the data
> captured by other
> | steps, which is often useful. Workflow $modal resolution supplies the
> workflow model
> | for the consumer of the workflow to then to something with all that data.
>
> We’ve roughly talked about a need for something like this for sometime and
> I think it would be great to explore it. It is similar to some of the
> Django workflow concepts.  Effectively, this boils down to steps declaring
> with data they require and which data they provide.  I’d prefer it if we
> can disassociate the step name from the data name.


Quite reasonable to have the data model be named more after the data being
captured in the panel than the step of the panel, yep, but...



> We want to keep the steps from being tightly coupled to each other, but
> rather be declarative about the data they use.  For example, if we later
> want to split out steps (see History of Launch Instance, Chapter 1: Source
> and Details) or want to combine steps (See History of Launch Instance:
> Chapter Boy it would be nice if we could have a quick launch step as the
> first step), it will be easier to do if we don’t couple the model to the
> current presentation.
>

Yeah, this is especially tricky, and I think Launch Instance Quick Launch
is a special snowflake and we shouldn't necessarily make everything else
have to work around it. If we could just define pages of workflows which
have their own model (with SchemaForm models once that lands, but manually
for now) that would solve 80-90% of workflow cases while being much simpler
to implement (not needing a whole separate model definition aside the form
definition).


By the way, yes the ability to watch the data or react to changes in the
> data is definitely useful. For example, in Launch Instance if you increase
> the number of instances, this may mean that the flavor you’ve chosen will
> now go over your quota (select smaller), which is a different step.


Completely agreed.


 Richard
__
OpenStack Development Mailing List (not for 

Re: [openstack-dev] [DIB] [TripleO] Should we have a DIB meeting?

2016-07-18 Thread Gregory Haynes
 
> I'm glad to see some interest. I've proposed a time slot for the new
> meeting here:
>
> https://review.openstack.org/#/c/343871/
>
> which is currently Thursdays, 2000 UTC. I realize the timing isn't
> ideal, but given how widely distributed regular contributors are it's
> not easy to pick a good time. I welcome input here or on the review
> proposal.
 
This works for me, but I am PST so that might be obvious. It'll be
early for the AU folk / late for the EU folk but I am not sure we can
do any better...
 
>
> Thanks,
> Stephane
>
 
Thanks a ton for organizing this!
-Greg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

2016-07-18 Thread Ronald Bradford
Hi All,

For Oslo libraries we ensure that API's are backward compatible for 1+ releases.
When an Oslo API adds a new class attribute (as in this example of
is_admin_project and 4 other attributes) added to Oslo Context in
2.6.0,  these are added to ensure this API is also forward compatible
with existing project code for any contract with the base class
instantiation or manipulation.

The issue seen is presently Nova specific (as other projects can
utilize 2.6.0) and it is related to projects that sub-class
oslo.context, and how unit tests are written for using class
parameters.  Ideally, to implement using oslo.context correctly
OpenStack projects should:

* Not perform direct dictionary to dictionary comparisons with the
to_dict() method as this does not support when new attributes at
added. Two patches (one to nova) address this in offending projects
[5][6]
* Unit tests should focus on attributes specific to the sub-classed
signature, e.g. [7].  Oslo context provides an extensive set of unit
tests for base class functionality. This is a wish list item for
projects to implement.

The to_dict() method exists as a convenience method only and is not an
API contract. The resulting set of keys should be used accordingly.
This is why there is no major release version.
There is a note from our discussion in Oslo to improve our
documentation to describe the API use of to_dict() better and state we
will not remove to_dict() keys within a release, but that may happen
between releases.

There is a subsequent problem with how Nova performs a warning test
[8]. Additional reviews are looking at addressing this sub-class usage
of from_dict() and to_dict().

Regards

Ronald


[5] https://review.openstack.org/#/c/343694/,
[6] https://review.openstack.org/#/c/342367/
[7] https://review.openstack.org/#/c/342869/
[8] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144

On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
 wrote:
> On 7/18/2016 9:42 AM, Matt Riedemann wrote:
>>
>> On 7/18/2016 9:09 AM, Markus Zoeller wrote:
>>>
>>> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
>>> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
>>> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
>>> Portland and won't be available for the next 2h or so.
>>> If you can have a look at it and merge it, that would be great.
>>>
>>> References:
>>> [1]
>>>
>>> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
>>>
>>> [2] https://review.openstack.org/#/c/342604/1
>>> [3] https://bugs.launchpad.net/nova/+bug/1603979
>>> [4] logstash: http://goo.gl/79yFb9
>>>
>>
>> This is an API change for oslo.context, why wasn't it released as 3.0.0?
>>
>> Seems we should revert the upper-constraints bump and blacklist 2.6.0,
>> then get that released as 3.0.0.
>>
>
> Here is the blacklist:
>
> https://review.openstack.org/#/c/343683/
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


[openstack-dev] [Infra] Meeting Tuesday July 19th at 19:00 UTC

2016-07-18 Thread Elizabeth K. Joseph
Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday July 19th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-12-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-12-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-12-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] Reviewing coverage jobs set up

2016-07-18 Thread Diana Clarke
On Mon, Jul 18, 2016 at 4:11 PM, Andreas Jaeger  wrote:
> You're welcome to send a patch for openstack-infra/project-config repo
> and update zuul/layout.yaml to add the job to the check queue of nova.

Done, thanks for pointing me in the right direction!

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

I've added Matt Riedemann to the review since it's not really my call to make.

Thanks again,

--diana

__
OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Thierry Carrez

Fox, Kevin M wrote:

[...]
I feel like I'm just the messenger here. Please don't shoot me. I'm generally 
trying to provide good, though hard feedback to better a perceived problem. 
Many others would just stay silent or leave rather then have the difficult 
discussion.


And I think we all appreciate that :)


[...]
The openness of the big tent has allowed more choice in the ecosystem, which 
seems good, but I think it has also stalled development on the sorts of cross 
project issues that were important to our users and are now looking elsewhere 
for solutions.


As others have mentioned, we are always adapting and continuously 
improving. Now that we completed the community-centric redefinition of 
OpenStack (the "big tent"), we are I think in a better position to push 
the sort of cross-project initiatives and normalization that you are 
looking for. For example, we talked recently about having the Technical 
Committee set "release goals" to drive simple coherence and visible 
improvements across all the components of the stack.


--
Thierry Carrez (ttx)

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


[openstack-dev] [tacker] Mascot for Tacker

2016-07-18 Thread Sridhar Ramaswamy
Tackers:

Please provide your inputs to select a Mascot for Tacker in the
etherpad. This is based on the recent initiative from OpenStack
marketing team, see http://www.openstack.org/project-mascots for more
details. There is already an exciting logo proposal in the etherpad
below :)

https://etherpad.openstack.org/p/tacker-mascot

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


Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

2016-07-18 Thread Matt Riedemann

On 7/15/2016 8:06 PM, Alex Xu wrote:


Actually I still think aggregates isn't good for Manage Caps, just as I
said in previous reply about Aggregates. One of reason is just same with
#2 you said :) And It's totally not managable. User is even no way to
query a specific host in which host-aggregate. And there isn't a
interface to query what metadata was related to the host by
host-aggregate. I prefer just keep the Aggregate as tool to group the
hosts. But yes, user still can use host-aggregate to manage host with
old way, let's user decide what is more convenient.



+1 to Alex's point. I just read through this thread and had the same 
thought. If the point is to reduce complexity in the system and surface 
capabilities to the end user, let's do that with resource provider tags, 
not a mix of host aggregate metadata and resource provider tags so that 
an operator has to set both, but also know in what situations he/she has 
to set it and where.


I'm hoping Jay or someone channeling Jay can hold my hand and walk me 
safely through the evil forest that is image properties / flavor extra 
specs / scheduler hints / host aggregates / resource providers / and the 
plethora of scheduler filters that use them to build a concrete 
picture/story tying this all together. I'm thinking like use cases, what 
does the operator need to do, what does the end user of the cloud need 
to do, etc. I think if we're going to do resource providers tags for 
capabilities we also need to think about what we're replacing. Maybe 
that's just host aggregate metadata, but what's the deprecation plan for 
that?


There is a ton to talk about here, so I'll leave that for the midcycle. 
But let's think about what, if anything, needs to land in Newton to 
enable us working on this in Ocata - but our priority for the midcycle 
is really going to be focused on what things we need to get done yet in 
Newton based on what we said we'd do in Austin.


Also, a final nit - can we please be specific about roles in this thread 
and any specs? I see 'user' thrown around a lot, but there are different 
kinds of users. Only admins can see host aggregates and their metadata. 
And when we're talking about how these tags will be used, let's be clear 
about who the actors are - admins or cloud users. It helps avoid some 
confusion.


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

2016-07-18 Thread Major Hayden
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/12/2016 01:33 PM, Truman, Travis wrote:
> Jean-Philippe has been providing great code reviews and patches for some 
> time. His recent commitment to running bug triage every week shows his 
> willingness to step up and take responsibilities within the community. He’s 
> also found an opportunity to innovate by introducing an improved bug triage 
> process. He can often be found in #openstack-ansible as *evrardjp *providing 
> support to deployers in a welcoming and friendly manner.

Count me as a +1 for JP. He's doing excellent work.

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

iQIcBAEBCAAGBQJXjT6hAAoJEHNwUeDBAR+xeDMP/2Q0SGZFaLmrI1tQ6KJjmp7F
yzxg1KTpc27sI1yPsAfAxk6kjCIyPAxEkY0rzS0QrOM1mBbrn1PvxEzoVqF6UWD0
4VPS20Gy256pF0BBBLEdmGsctIELvO36AAmmQjMq8PQIismvjHezePhiE16MzSol
urWOOrIJP5WFxDjDvXBoeXpHEPSgmS+fD3+2rd1IkYHj5L2YS5lJvWoOBzqIowlg
bLvry8bXD5krc5VR4W8bDWC4RiFur86OdIBpegH77mSIziveMJRsmRtM9Ut0mFVZ
JBG8OtKZatianSL1Rcb1ofyL7V0DU0actQ2WZ/bRBShZ7FuSPMfJZF1PaFH3zM2H
/yuUPFMPbd/yWk4O/KRHFBkP++QU4gIsicKyQ48ELEpaW4iGwhJAlwM3lZEyiTfd
oVn+amgQEQqnZVzcl2tMwX8Y+8j43zewhWdEDdJ6s3VUhhfYABdGgBoYnKMSvJsx
dHTDHkA8O+tDNVYnwoi+JMTN2NyC2qy6+VxqsIfWegTzQlw9I9Tz7vj5yKuFQIem
3H8ZmbfaJ1aXc7Fva2qbyKwV7jUAQWA04IbCkPkKuGi9Zbju8jE+GWn6A50h7Igx
hPtOaeitt/zTUv/zSYdHzT+cZFbb3BlYNeSuJrqp1mHizmst7b4wCL1Lo9nN2lR2
nlfR7ls3wpAcjfvvVX5d
=5aKT
-END PGP SIGNATURE-

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


Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Fox, Kevin M
The current incarnation of the Instance User spec: 
https://review.openstack.org/#/c/93/

Thanks,
Kevin

From: Michael Still [mi...@stillhq.com]
Sent: Monday, July 18, 2016 10:13 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)


On 16 Jul 2016 1:27 PM, "Thomas Herve" 
> wrote:
>
> On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M 
> > wrote:
> > Some specific things:
> >
> > Magnum trying to not use Barbican as it adds an addition dependency. See 
> > the discussion on the devel mailing list for details.
> >
> > Horizon discussions at the summit around wanting to use Zaqar for dynamic 
> > ui updates instead of polling, but couldn't depend on a non widely deployed 
> > subsystem.
> >
> > Each Advanced OpenStack Service implementing a guest controller 
> > communication channel that are incompatible with each other and work around 
> > communications issues differently. This makes a lot more pain for Ops to 
> > debug or architect a viable solution. For example:
> >  * Sahara uses ssh from the controllers to the vms. This does not play well 
> > with tenant networks. They have tried to work around this several ways:
> > * require every vm to have a floating ip. (Unnecessary attack surface)
> > * require the controller to be on the one and only network node (Uses 
> > ip netns exec to tunnel. Doesn't work for large clouds)
> > * Double tunnel ssh via the controller vm's. so some vms have fips, 
> > some don't. Better then all, but still not good.
> >   * Trove uses Rabbit for the guest agent to talk back to the controllers. 
> > This has traffic going the right direction to work well with tenant 
> > networks.
> > * But Rabbit is not multitenant so a security risk if any user can get 
> > into any one of the database vm's.
> > Really, I believe the right solution is to use a multitenant aware message 
> > queue so that the guest agent can pull in the right direction for tenant 
> > networks, and not have the security risk. We have such a system already, 
> > Zaqar, but its not widely deployed and projects don't want to depend on 
> > other projects that aren't widely deployed.
>
> While I agree using Barbican/Zaqar for those would be fantastic, this
> is easily solved: just optionally depend on it. Heat provides features
> that use Zaqar, which are not just present when Zaqar is not there.
> For example, if people in the Trove project were convinced that Zaqar
> was the best solution to their problem, I think they would find a way
> to provide an implementation using it. I don't think they are, though.
> Whatever the reasons may be.
>
> > The lack of Instance Users has caused lots of projects to try and work 
> > around the lack thereof. I know for sure, Mangum, Heat, and Trove work 
> > around the lack. I'm positive others have too. As an operator, it makes me 
> > have to very carefully consider all the tradeoffs each project made, and 
> > decide if I can accept the same risk they assumed. Since each is different, 
> > thats much harder.
>
> Instance users would be nice. Nobody just provided a good solution. I
> know you tried, but I don't think you succeeded. We need a good
> implementation, easy to understand, and maybe this will move forward.

I think I need a more complete definition of instance users to know what you're 
talking about here. Is this the instance locking stuff Bruno proposed a while 
ago?

> > I'm sure there are more examples. but I hope you get I'm not just trying to 
> > troll.
> >
> > The TC did apply inconsistant rules on letting projects in. That was for 
> > sure a negative before the big tent. But it also provided a way to apply 
> > pressure to projects to fix some of the issues that multiple projects face, 
> > and that plague user/operators and raise the whole community up, and that 
> > has fallen to the wayside since. Which is a big negative now. Maybe that 
> > could be bolted on top of the Big Tent I don't know.
>
> So I think that's the root of the issue here. You assume we can
> "pressure" people do something you think is right. But that's not how
> opensource works. You either implement the solution to your problem,
> or convince someone else, but you don't force anybody. I think that's
> what the TC recognized and changed, to the correct path. Could project
> be better integrated, so that we have a more coherent "product"? Sure.
> But you don't achieve that with more governance and processes.
>
> --
> Thomas
>
> __
> OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Fox, Kevin M
Kfox> Responding to this inline. Sorry, its outlook. Not my choice. :/

-Original Message-
From: Thomas Herve [mailto:the...@redhat.com] 
Sent: Saturday, July 16, 2016 1:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M  wrote:
> Some specific things:
>
> Magnum trying to not use Barbican as it adds an addition dependency. See the 
> discussion on the devel mailing list for details.
>
> Horizon discussions at the summit around wanting to use Zaqar for dynamic ui 
> updates instead of polling, but couldn't depend on a non widely deployed 
> subsystem.
>
> Each Advanced OpenStack Service implementing a guest controller communication 
> channel that are incompatible with each other and work around communications 
> issues differently. This makes a lot more pain for Ops to debug or architect 
> a viable solution. For example:
>  * Sahara uses ssh from the controllers to the vms. This does not play well 
> with tenant networks. They have tried to work around this several ways:
> * require every vm to have a floating ip. (Unnecessary attack surface)
> * require the controller to be on the one and only network node (Uses ip 
> netns exec to tunnel. Doesn't work for large clouds)
> * Double tunnel ssh via the controller vm's. so some vms have fips, some 
> don't. Better then all, but still not good.
>   * Trove uses Rabbit for the guest agent to talk back to the controllers. 
> This has traffic going the right direction to work well with tenant networks.
> * But Rabbit is not multitenant so a security risk if any user can get 
> into any one of the database vm's.
> Really, I believe the right solution is to use a multitenant aware message 
> queue so that the guest agent can pull in the right direction for tenant 
> networks, and not have the security risk. We have such a system already, 
> Zaqar, but its not widely deployed and projects don't want to depend on other 
> projects that aren't widely deployed.

While I agree using Barbican/Zaqar for those would be fantastic, this is easily 
solved: just optionally depend on it. Heat provides features that use Zaqar, 
which are not just present when Zaqar is not there.
For example, if people in the Trove project were convinced that Zaqar was the 
best solution to their problem, I think they would find a way to provide an 
implementation using it. I don't think they are, though.
Whatever the reasons may be.

kfox> The problem with making it optional, is it's a chicken and the egg 
problem. Everyone makes it optional, so they all have to implement fallback 
code. Operators see its optional, so they don't deploy the optional stuff as 
that's "more work". Users can't depend on it, since its not there on most 
systems. They don't tend to ask for it to be installed. Then the new project 
never gains any traction. It's a vicious cycle.

> The lack of Instance Users has caused lots of projects to try and work around 
> the lack thereof. I know for sure, Mangum, Heat, and Trove work around the 
> lack. I'm positive others have too. As an operator, it makes me have to very 
> carefully consider all the tradeoffs each project made, and decide if I can 
> accept the same risk they assumed. Since each is different, thats much harder.

Instance users would be nice. Nobody just provided a good solution. I know you 
tried, but I don't think you succeeded. We need a good implementation, easy to 
understand, and maybe this will move forward.

kfox> The problem is, it's a hard thing to solve, and I believe the current 
organization of OpenStack provides significant barrier to solving it.  I've 
tried for years to solve it, and have basically given up. This is part of the 
big tent issue. I'm moving more and more stuff that requires Instance Users to 
non OpenStack systems, which will be a majority of my workload at some point if 
things continue. This is the kind of thing OpenStack is really suffering from 
right now, and will only get worse as it continues to be swept under the rug.

> I'm sure there are more examples. but I hope you get I'm not just trying to 
> troll.
>
> The TC did apply inconsistant rules on letting projects in. That was for sure 
> a negative before the big tent. But it also provided a way to apply pressure 
> to projects to fix some of the issues that multiple projects face, and that 
> plague user/operators and raise the whole community up, and that has fallen 
> to the wayside since. Which is a big negative now. Maybe that could be bolted 
> on top of the Big Tent I don't know.

So I think that's the root of the issue here. You assume we can "pressure" 
people do something you think is right. But that's not how opensource works. 
You either implement the solution to your problem, or convince someone else, 
but you don't force anybody. I think that's what the TC recognized 

Re: [openstack-dev] [all] Reviewing coverage jobs set up

2016-07-18 Thread Andreas Jaeger
On 07/18/2016 10:03 PM, Diana Clarke wrote:
> On Mon, Jul 18, 2016 at 2:09 PM, Andreas Jaeger  wrote:
>> In general, I think coverage jobs should be run as check job so
>> that you know how the coverage changes. Running them only in the post
>> job means that in practice nobody sees the output of the job.
> 
> I look at the post queue coverage output for nova, and have often
> wished I could see the check queue coverage results. +1 for moving it
> to the check queue.

You're welcome to send a patch for openstack-infra/project-config repo
and update zuul/layout.yaml to add the job to the check queue of nova.


>> Here're the failures (including some that run successful but coverage
>>
>> nova:
>> http://logs.openstack.org/3f/3f700b5a5a498ba08e77378d34f059c3fa6845d8/post/nova-coverage-db/2bdabf8/
> 
> I suspect you can cross nova off your list of failures soon. I believe
> those errors were addressed by the following:
> 
> https://bugs.launchpad.net/nova/+bug/1603979
> 
> Here's a recent passing coverage run for nova (from before those
> errors were introduced):
> 
> 
> http://logs.openstack.org/1a/1a074a72845d812666a904b9c17289a43bb32062/post/nova-coverage-db/2fe5506/cover/

Glad to see! I didn't dig deeper, just looked at today's status,

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


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


Re: [openstack-dev] [all] Reviewing coverage jobs set up

2016-07-18 Thread Diana Clarke
On Mon, Jul 18, 2016 at 2:09 PM, Andreas Jaeger  wrote:
> In general, I think coverage jobs should be run as check job so
> that you know how the coverage changes. Running them only in the post
> job means that in practice nobody sees the output of the job.

I look at the post queue coverage output for nova, and have often
wished I could see the check queue coverage results. +1 for moving it
to the check queue.

> Here're the failures (including some that run successful but coverage
>
> nova:
> http://logs.openstack.org/3f/3f700b5a5a498ba08e77378d34f059c3fa6845d8/post/nova-coverage-db/2bdabf8/

I suspect you can cross nova off your list of failures soon. I believe
those errors were addressed by the following:

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

Here's a recent passing coverage run for nova (from before those
errors were introduced):


http://logs.openstack.org/1a/1a074a72845d812666a904b9c17289a43bb32062/post/nova-coverage-db/2fe5506/cover/

Much appreciated,

--diana

__
OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Thomas Herve
On Mon, Jul 18, 2016 at 7:13 PM, Michael Still  wrote:
> On 16 Jul 2016 1:27 PM, "Thomas Herve"  wrote:
>>
>> On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M  wrote:
>> > The lack of Instance Users has caused lots of projects to try and work
>> > around the lack thereof. I know for sure, Mangum, Heat, and Trove work
>> > around the lack. I'm positive others have too. As an operator, it makes me
>> > have to very carefully consider all the tradeoffs each project made, and
>> > decide if I can accept the same risk they assumed. Since each is different,
>> > thats much harder.
>>
>> Instance users would be nice. Nobody just provided a good solution. I
>> know you tried, but I don't think you succeeded. We need a good
>> implementation, easy to understand, and maybe this will move forward.
>
> I think I need a more complete definition of instance users to know what
> you're talking about here. Is this the instance locking stuff Bruno proposed
> a while ago?

I believe this is what's Kevin talks about:
https://review.openstack.org/#/c/93/

-- 
Thomas

__
OpenStack Development Mailing 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] [DIB] [TripleO] Should we have a DIB meeting?

2016-07-18 Thread Stephane Miller
I'm glad to see some interest. I've proposed a time slot for the new
meeting here:

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

which is currently Thursdays, 2000 UTC. I realize the timing isn't ideal,
but given how widely distributed regular contributors are it's not easy to
pick a good time. I welcome input here or on the review proposal.

Thanks,
Stephane

On Mon, Jul 18, 2016 at 3:31 AM, Steven Hardy  wrote:

> On Fri, Jul 15, 2016 at 04:20:35PM -0700, Stephane Miller wrote:
> >There are a lot of interesting and complex changes going on with DIB
> at
> >the moment. This is a good thing, but it also means that we have more
> >complex decisions to make for the project. We've already taken one
> step to
> >address this in proposing a specs process
> >(https://review.openstack.org/#/c/336109/). However, I'm thinking we
> could
> >also use some higher-bandwidth communication.
> >I'm proposing that we have a regular, IRC-based meeting for the
> project.
> >This could be done on its own, or as part of the TripleO meeting. I
> don't
> >think we necessarily need to do this every week, but a fortnightly
> chance
> >to get together to chat about big changes, design, etc would be great.
> >DIB and TripleO DIB community, what are your thoughts?
>
> I'm happy for folks to discuss DIB related topics in the TripleO meeting,
> but it may make more sense for this to be a separate meeting, given that
> the overlap between DIB users/contributors/reviewers and those involved
> with TripleO isn't as great as it once was?
>
> Thanks for raising this, big +1 on anything that enables a better feedback
> loop and communication channel for DIB.
>
> Steve
>
> __
> OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Fox, Kevin M
I'm arguing the opposite. It should be a requirement to use the OpenStack 
Secret Store.

Instead, we're trying to make it optional and either reimplementing large 
swaths of it in individual projects to make it optional, or skip security all 
together.

If it wasn't optional, then:
 * Keystone could rely on it being there for password hashing
 * Magnum can rely on it for security.
 * lbaas can rely on it
 * App developers can rely on it being there
 * ...

Same with Zaqar. It was a requirement then,
 * Guest agents of heat, sahara, mangum, trove, etc could all rely on it being 
there and wouldn't have to deal with workarounds
 * Horizon could rely on it being there for dynamic ui
 * App developers can rely on it being there.

Yes, it seems like more work for an operator to have to install "one more 
thing", but the savings it provides by not having to do that "one more thing" 
in 7 different projects pays for it.

Rather then focus on sharing code by adding required project dependencies, 
we're just implementing things in each project to workaround the lack thereof 
in a general project and then everyone suffers for it.

Thanks,
Kevin


From: Hongbin Lu [hongbin...@huawei.com]
Sent: Friday, July 15, 2016 10:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

No, Magnum still uses Barbican as an optional dependency, and I believe nobody 
has proposed to remove Barbican entirely. I have no position about big tent but 
using Magnum as an example of "projects are not working together" is 
inappropriate.

Best regards,
Hongbin

> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: July-15-16 2:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
>
> Some specific things:
>
> Magnum trying to not use Barbican as it adds an addition dependency.
> See the discussion on the devel mailing list for details.
>
> Horizon discussions at the summit around wanting to use Zaqar for
> dynamic ui updates instead of polling, but couldn't depend on a non
> widely deployed subsystem.
>
> Each Advanced OpenStack Service implementing a guest controller
> communication channel that are incompatible with each other and work
> around communications issues differently. This makes a lot more pain
> for Ops to debug or architect a viable solution. For example:
>  * Sahara uses ssh from the controllers to the vms. This does not play
> well with tenant networks. They have tried to work around this several
> ways:
> * require every vm to have a floating ip. (Unnecessary attack
> surface)
> * require the controller to be on the one and only network node
> (Uses ip netns exec to tunnel. Doesn't work for large clouds)
> * Double tunnel ssh via the controller vm's. so some vms have fips,
> some don't. Better then all, but still not good.
>   * Trove uses Rabbit for the guest agent to talk back to the
> controllers. This has traffic going the right direction to work well
> with tenant networks.
> * But Rabbit is not multitenant so a security risk if any user can
> get into any one of the database vm's.
> Really, I believe the right solution is to use a multitenant aware
> message queue so that the guest agent can pull in the right direction
> for tenant networks, and not have the security risk. We have such a
> system already, Zaqar, but its not widely deployed and projects don't
> want to depend on other projects that aren't widely deployed.
>
> The lack of Instance Users has caused lots of projects to try and work
> around the lack thereof. I know for sure, Mangum, Heat, and Trove work
> around the lack. I'm positive others have too. As an operator, it makes
> me have to very carefully consider all the tradeoffs each project made,
> and decide if I can accept the same risk they assumed. Since each is
> different, thats much harder.
>
> I'm sure there are more examples. but I hope you get I'm not just
> trying to troll.
>
> The TC did apply inconsistant rules on letting projects in. That was
> for sure a negative before the big tent. But it also provided a way to
> apply pressure to projects to fix some of the issues that multiple
> projects face, and that plague user/operators and raise the whole
> community up, and that has fallen to the wayside since. Which is a big
> negative now. Maybe that could be bolted on top of the Big Tent I don't
> know.
>
> I could write a very long description about the state of being an
> OpenStack App developer too that touches on all the problems with
> getting a consistent target and all the cross project communication
> issues there of. But thats probably for some other time.
>
> Thanks,
> Kevin
>
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Friday, July 15, 2016 8:17 AM
> To: 

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Fox, Kevin M
I don't object to the need of an OpenStack controller and a vm need to 
communicate. I object to every project coming up with their own solution for 
that communication channel, when there really is no benefit to them being 
different. It is one thing amongst many that has made being an Operator's life 
very difficult as the individual OpenStack projects don't consider all the 
stuff they are asking an op to do, in aggregate.

This has parallels with, say, college professors. They often do not talk to 
each other, and will give out a fair amount of homework, which, by itself 
doesn't sound unreasonable, but when you have a lot of classes, they can add up 
sometimes to periods of time where you have an unreasonable workload. Its not 
such a problem in academia, as students are usually kind of a captive audience. 
Operators can choose to move on though.

Other then the specific messages being sent (payload) between heat and vm, 
trove and vm, sahara and vm, etc, are the needs of the base communication 
channel any different between the projects? I don't think there are. But today 
each projects workarounds/solutions/monitoring are all different.

I feel like I'm just the messenger here. Please don't shoot me. I'm generally 
trying to provide good, though hard feedback to better a perceived problem. 
Many others would just stay silent or leave rather then have the difficult 
discussion.

For reference, have a look here:
https://www.google.com/trends/explore#q=%2Fm%2F0cm87w_=q=Etc%2FGMT%2B7

The slope of the line has dramatically changed. I'm sure there are many reasons 
for it, but the difficulty of being an OpenStack operator or app developer in a 
world where there are increasing numbers of alternatives I'm sure plays a part. 
(Some other things, docker and docker COE's staring to gain traction, the 
introduction of the big tent)

The openness of the big tent has allowed more choice in the ecosystem, which 
seems good, but I think it has also stalled development on the sorts of cross 
project issues that were important to our users and are now looking elsewhere 
for solutions. I have to admit, I've gotten frustrated after years of waiting, 
and trying to fix things, I'm starting to switch some systems away from 
OpenStack to things that are easier to deal with. Again, please understand, 
there is no malice here, just stating the way things are. We should try and fix 
it so this is not the case.

As for the specific  Trove security risk mentioned below, you can have a zaqar 
queue per vm, not per tenant, and compromising the vm only compromise control 
of that one vm. Thats much preferable to the current situation. But again, this 
is in no way Trove specific. We should be talking this issue through with all 
the related projects.

Service tenants are not an option for us today, as we have users that buy 
hardware that gets dedicated to them. they use flavors with permissions to land 
vm's onto their hardware pools. Service tenants don't have access to those 
flavors. Again, this is a solution that was thought up and provided by a single 
project (Trove) but should be considered at the general OpenStack level. It 
isn't specific to Trove, but affects Sahara, Magnum, etc too. There isn't 
anything Trove specific about the issue or the solution.

There needs to be a general place... technical committee? that helps design 
these sorts of solutions that deal with the needs of multiple OpenStack 
projects and operators and pushes through features (like nova service vm's) 
that fills in the current implementation gaps to get good solutions. This, 
everyone for themselves way of solving things isn't working so good.
 
Thanks,
Kevin


From: Amrith Kumar [amr...@tesora.com]
Sent: Saturday, July 16, 2016 8:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: Friday, July 15, 2016 2:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for
> all)
>
> Some specific things:
>
> Magnum trying to not use Barbican as it adds an addition dependency. See
> the discussion on the devel mailing list for details.
>
> Horizon discussions at the summit around wanting to use Zaqar for dynamic
> ui updates instead of polling, but couldn't depend on a non widely
> deployed subsystem.
>
> Each Advanced OpenStack Service implementing a guest controller
> communication channel that are incompatible with each other and work
> around communications issues differently. This makes a lot more pain for
> Ops to debug or architect a viable solution. For example:
>  * Sahara uses ssh from the controllers to the vms. This does not play
> well with tenant networks. They have tried to work around this 

Re: [openstack-dev] [all] Reviewing coverage jobs set up

2016-07-18 Thread Steve Martinelli
see inline comment

On Mon, Jul 18, 2016 at 2:09 PM, Andreas Jaeger  wrote:

> While looking at coverage jobs to enable them to allow use of
> constraints in post jobs (something which has just been introduced and
> needs some more testing before we take on the other jobs), I noticed
> that we have quite a few coverage
> jobs that are failing.
>
> In general, I think coverage jobs should be run as check job so
> that you know how the coverage changes. Running them only in the post
> job means that in practice nobody sees the output of the job.
>

Yes please! I never understood why they were run as post jobs. In keystone
we've had it running as a check/gate job for a while without hiccups.
__
OpenStack Development Mailing 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] Reviewing coverage jobs set up

2016-07-18 Thread Jeremy Stanley
On 2016-07-18 20:09:54 +0200 (+0200), Andreas Jaeger wrote:
[...]
> Btw. if you want to get the output of the post job, check the git SHA.
> logs are found at ``http://logs.openstack.org/ commit SHA>/``. For example, if a change is committed with
> the sha 'deadbeef123456', the logs will be found at
> ``http://logs.openstack.org/de/deadbeef123456``.
[...]

Note that this will only be true if the change's parent commit in
Gerrit was the branch tip at the time it landed. Otherwise (and
quite frequently in fact) you will need to identify the SHA of the
merge commit which was created at the time it merged and use that
instead to find the post job.
-- 
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] [nova][glance] snapshots are broken by default with newton and glance v2

2016-07-18 Thread Nikhil Komawar
For those needing this release soon, watch out for the announcement.
Ref: https://review.openstack.org/#/c/343708


On 7/18/16 12:19 AM, Nikhil Komawar wrote:
> Thanks Matt. I've scheduled for a release of the client this week.
>
> On 7/16/16 4:09 AM, Matt Riedemann wrote:
>> This is more of a heads up than anything.
>>
>> Our internal CI is running Tempest with images that don't have
>> kernel_id or ramdisk_id properties set.
>>
>> We're running from master so nova defaults to use_glance_v1=False.
>>
>> Because of this:
>>
>> https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/compute/api.py#L867-L868
>>
>>
>> and this:
>>
>> https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/image/glance.py#L835
>>
>>
>> The snapshot image properties get kernel_id and ramdisk_id set to None
>> since that's what the glance v2 schema requires.
>>
>> However, python-glanceclient has it's own outdated copy of the schema
>> which doesn't allow null values for those properties, see bug:
>>
>> https://bugs.launchpad.net/python-glanceclient/+bug/1596602
>>
>> We don't hit this in the community CI because the image that Tempest
>> uses from devstack has the kernel_id and ramdisk_id properties set:
>>
>> http://logs.openstack.org/52/335152/1/check/gate-tempest-dsvm-neutron-src-python-glanceclient/d393db9/logs/devstacklog.txt.gz#_2016-06-28_18_40_12_429
>>
>>
>> But for anyone else upgrading to Newton that has images without those
>> properties set and doesn't have use_glance_v1=True in nova.conf is
>> going to be broken.
>>
>> Since we really want to get people off glance v1 and move to
>> deprecation in Ocata, we need to get this merged and released:
>>
>> https://review.openstack.org/#/c/335152/
>>
>> And bump the minimum required python-glanceclient in
>> global-requirements for Newton.
>>
>> I'm not really sure why python-glanceclient even has it's own copy of
>> the image schema, that seems redundant and error prone given the
>> glance API already validates that, but it's kind of beside the point
>> right now.
>>

-- 

Thanks,
Nikhil


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


Re: [openstack-dev] [Horizon] Angular action services and initScope

2016-07-18 Thread Rob Cresswell
Maybe I'm missing the point, but the schema stuff just defines a model and 
passes it to the schema directive via ctrl; doesn't that remove any issues with 
workflows? ui-bootstraps modal and modalinstance already provides a way to pass 
that data back to the initial location (table etc) again

Rob

On 18 July 2016 at 19:34, Tripp, Travis S 
> wrote:
TL;DR, I’ll be quite happy to get rid of the need for initScope and like 
exploring a common way to share model other than events.

 |From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM

| I think this is a bad idea because in the angular world "factory" means 
singleton
| (which is totally opposite to what everyone else in the programming world 
[and the rest]
| thinks "factory" means but hey, angular gonna angular) and we'd be changing 
that, and
| the potential for confusion would be very high.

| Controllers are already not singletons - I see no reason why mutable state 
shouldn't be |
| contained in *them*. We don't need to invent something new to hold that 
mutable state.

As FYI, the way I mentioned for factories is *not* inventing something new and 
is how they were intended and even used in angular in that way.  A factory is a 
singleton object whose job is to create instances of objects.  It is even used 
that way in angular code. See $cacheFactory [0]

[0] https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js

The differentiation of .factory vs .service is still obtuse since they are both 
singletons, but the concept of a factory object whether .service or .factory 
still remains.

|From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM
|Thus the controller and action service, which are quite independent pieces of 
code,
| must have intimate knowledge of each  other's internal operation. I'm not so 
keen on that ;-)

That is yuck!

|From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM

| But the workflow implementation has no concept of an over-arching model for
| the workflow. If that was changed, I believe all the current $scope 
shenanigans
|(which are basically about short-circuiting the workflow not doing its job ;-) 
would
| go away.

The event based mechanism was an attempt originally proposed by Thai to get 
around the essentially hard coded shared model service in launch instance where 
the steps are tightly bound to that model service. There was also some idea 
that some steps could be reusable / recomposable across work flows (such as 
update metadata) if you didn’t tightly bind things.

|From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM

| So, here's my rough thought: workflow.model is an object with properties 
named for
| each of the workflow steps - using the step formName as the name (hell, schema
| form could probably make this a doddle). The workflow model is passed to the
| controller for each step, which uses its own named model to store the data 
captured
| by the step - and as a side effect it can poke at (and watch) the data 
captured by other
| steps, which is often useful. Workflow $modal resolution supplies the 
workflow model
| for the consumer of the workflow to then to something with all that data.

We’ve roughly talked about a need for something like this for sometime and I 
think it would be great to explore it. It is similar to some of the Django 
workflow concepts.  Effectively, this boils down to steps declaring with data 
they require and which data they provide.  I’d prefer it if we can disassociate 
the step name from the data name. We want to keep the steps from being tightly 
coupled to each other, but rather be declarative about the data they use.  For 
example, if we later want to split out steps (see History of Launch Instance, 
Chapter 1: Source and Details) or want to combine steps (See History of Launch 
Instance: Chapter Boy it would be nice if we could have a quick launch step as 
the first step), it will be easier to do if we don’t couple the model to the 
current presentation.

By the way, yes the ability to watch the data or react to changes in the data 
is definitely useful. For example, in Launch Instance if you increase the 
number of instances, this may mean that the flavor you’ve chosen will now go 
over your quota (select smaller), which is a different step.


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


Re: [openstack-dev] [Horizon] Angular action services and initScope

2016-07-18 Thread Tripp, Travis S
TL;DR, I’ll be quite happy to get rid of the need for initScope and like 
exploring a common way to share model other than events.

 |From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM

| I think this is a bad idea because in the angular world "factory" means 
singleton 
| (which is totally opposite to what everyone else in the programming world 
[and the rest]
| thinks "factory" means but hey, angular gonna angular) and we'd be changing 
that, and
| the potential for confusion would be very high.

| Controllers are already not singletons - I see no reason why mutable state 
shouldn't be |
| contained in *them*. We don't need to invent something new to hold that 
mutable state.

As FYI, the way I mentioned for factories is *not* inventing something new and 
is how they were intended and even used in angular in that way.  A factory is a 
singleton object whose job is to create instances of objects.  It is even used 
that way in angular code. See $cacheFactory [0]

[0] https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js

The differentiation of .factory vs .service is still obtuse since they are both 
singletons, but the concept of a factory object whether .service or .factory 
still remains.

|From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM
|Thus the controller and action service, which are quite independent pieces of 
code,
| must have intimate knowledge of each  other's internal operation. I'm not so 
keen on that ;-)

That is yuck!

|From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM

| But the workflow implementation has no concept of an over-arching model for
| the workflow. If that was changed, I believe all the current $scope 
shenanigans
|(which are basically about short-circuiting the workflow not doing its job ;-) 
would
| go away.

The event based mechanism was an attempt originally proposed by Thai to get 
around the essentially hard coded shared model service in launch instance where 
the steps are tightly bound to that model service. There was also some idea 
that some steps could be reusable / recomposable across work flows (such as 
update metadata) if you didn’t tightly bind things.

|From: Richard Jones 
| Date: Sunday, July 17, 2016 at 6:55 PM

| So, here's my rough thought: workflow.model is an object with properties 
named for
| each of the workflow steps - using the step formName as the name (hell, schema
| form could probably make this a doddle). The workflow model is passed to the
| controller for each step, which uses its own named model to store the data 
captured
| by the step - and as a side effect it can poke at (and watch) the data 
captured by other
| steps, which is often useful. Workflow $modal resolution supplies the 
workflow model
| for the consumer of the workflow to then to something with all that data.

We’ve roughly talked about a need for something like this for sometime and I 
think it would be great to explore it. It is similar to some of the Django 
workflow concepts.  Effectively, this boils down to steps declaring with data 
they require and which data they provide.  I’d prefer it if we can disassociate 
the step name from the data name. We want to keep the steps from being tightly 
coupled to each other, but rather be declarative about the data they use.  For 
example, if we later want to split out steps (see History of Launch Instance, 
Chapter 1: Source and Details) or want to combine steps (See History of Launch 
Instance: Chapter Boy it would be nice if we could have a quick launch step as 
the first step), it will be easier to do if we don’t couple the model to the 
current presentation. 

By the way, yes the ability to watch the data or react to changes in the data 
is definitely useful. For example, in Launch Instance if you increase the 
number of instances, this may mean that the flavor you’ve chosen will now go 
over your quota (select smaller), which is a different step. 


__
OpenStack Development Mailing 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] Reviewing coverage jobs set up

2016-07-18 Thread Andreas Jaeger
While looking at coverage jobs to enable them to allow use of
constraints in post jobs (something which has just been introduced and
needs some more testing before we take on the other jobs), I noticed
that we have quite a few coverage
jobs that are failing.

In general, I think coverage jobs should be run as check job so
that you know how the coverage changes. Running them only in the post
job means that in practice nobody sees the output of the job.

Out of 83 jobs having a post coverage job, 19 failed. See
below for list of failures and a list of all repos that have a coverage
post job setup.

I suggest that projects review their coverage setup and decide whether
they want to run it as part of the check queue, fix it, or remove it.

Btw. if you want to get the output of the post job, check the git SHA.
logs are found at ``http://logs.openstack.org//``. For example, if a change is committed with
the sha 'deadbeef123456', the logs will be found at
``http://logs.openstack.org/de/deadbeef123456``.

Here're the failures (including some that run successful but coverage
did not collect any data):

cloudkitty-dashboard:
http://logs.openstack.org/11/113209883e3e9131602f35593bc0cb8880db19b9/post/cloudkitty-dashboard-coverage/c390a24/

designate-dashboard:
http://logs.openstack.org/56/5627ddb4a6eedb751fecced56d277961aac92436/post/designate-dashboard-coverage/73650dc/

horizon:
http://logs.openstack.org/8f/8f35c43bc5b4182d6e82a67cdc2beccd2364da8a/post/horizon-coverage/5535457/

monasca-ui:
http://logs.openstack.org/f0/f05e4992fb6ce722ac00c4aa6ad30ff89b453476/post/monasca-ui-coverage/af5105e/

murano-agent:
http://logs.openstack.org/14/1450eb39fb9f6dcbe1b70167d23d16e74f28dbd5/post/murano-agent-coverage/ee9c33a/

nodepool:
http://logs.openstack.org/e3/e345107476a82ddad82ea99e184398e0d0e7e85a/post/nodepool-coverage-db/8a0ee23/

nova:
http://logs.openstack.org/3f/3f700b5a5a498ba08e77378d34f059c3fa6845d8/post/nova-coverage-db/2bdabf8/

nova-docker:
http://logs.openstack.org/03/034a4842fc1ebba5912e02cff8cd197ae81eb0c3/post/nova-docker-coverage/879d790/

os-net-config:
http://logs.openstack.org/6b/6bb8412ef3d3f163d91f2884081b743f07a78f18/post/os-net-config-coverage/cba622a/

poppy:
http://logs.openstack.org/09/0948c854e4b8543f01d909437f09cfb23e71a5b0/post/poppy-coverage/ccbc8ad/

python-aodhclient:
http://logs.openstack.org/65/65d2e625ee3b359bae154a5da3931f48b48fe720/post/python-aodhclient-coverage/2d8a169/

python-gnocchiclient:
http://logs.openstack.org/81/81e1b91beb3d85760e574951e240a381d6a4d008/post/python-gnocchiclient-coverage/2d9a414/

python-monascaclient (this should be fixed with the enabling of
constraints):
http://logs.openstack.org/17/17b9eaa1ede715344ac9cb2049c63e25604476cb/post/python-monascaclient-coverage/2b44b1b/

sahara-dashboard:
http://logs.openstack.org/bc/bcf8e2938d7085799a3754a9ff6d245d73ec33ff/post/sahara-dashboard-coverage/7807a4e/console.html.gz

sahara-tests:
http://logs.openstack.org/91/914bf0646f4de85107324f0aa05e856961bb0ee6/post/sahara-tests-coverage/b65352b/

solum-dashboard:
http://logs.openstack.org/82/8235df5a5ab0d48a6b407931c1d998102050b1b9/post/solum-dashboard-coverage/8d23679/

trove:
http://logs.openstack.org/4a/4ad0dfe88c6362356c8083d167f43ab495da661d/post/trove-coverage-db/990fd71/

trove-dashboard:
http://logs.openstack.org/01/01815715539fad40e06e974d6fdf840957051b69/post/trove-dashboard-coverage/908f8df/

turbo-hipster:
http://logs.openstack.org/7e/7ef12b758020176fb3e13e5bb0154084b1456797/post/turbo-hipster-coverage/ab2d17a/


Full list of repos with coverage job defined:

openstack-dev/hacking hacking-coverage
openstack-dev/pbr pbr-coverage
openstack-infra/bindep bindep-coverage
openstack-infra/grafyaml grafyaml-coverage
openstack-infra/jenkins-job-builder jenkins-job-builder-coverage
openstack-infra/nodepool nodepool-coverage-db
openstack-infra/python-storyboardclient python-storyboardclient-coverage
openstack-infra/shade shade-coverage
openstack-infra/storyboard storyboard-coverage-db
openstack-infra/zuul zuul-coverage-db
openstack/ara ara-coverage
openstack/ceilometermiddleware ceilometermiddleware-coverage
openstack/cloudbase-init cloudbase-init-coverage
openstack/cloudkitty cloudkitty-coverage
openstack/cloudkitty-dashboard cloudkitty-dashboard-coverage
openstack/designate designate-coverage-db
openstack/designate-dashboard designate-dashboard-coverage
openstack/heat heat-coverage-db
openstack/heat-translator heat-translator-coverage
openstack/horizon horizon-coverage
openstack/ironic ironic-coverage-db
openstack/ironic-lib ironic-lib-coverage
openstack/keystonemiddleware keystonemiddleware-coverage
openstack/kiloeyes kiloeyes-coverage
openstack/manila manila-coverage-db
openstack/monasca-ui monasca-ui-coverage
openstack/murano murano-coverage-db
openstack/murano-agent murano-agent-coverage
openstack/neutron neutron-coverage
openstack/neutron-dynamic-routing neutron-dynamic-routing-coverage
openstack/neutron-fwaas neutron-fwaas-coverage
openstack/neutron-vpnaas 

[openstack-dev] [fuel documentation] new cores in fuel-docs-core

2016-07-18 Thread Evgeny Konstantinov
Hey everyone,

We've added new cores to the Fuel documentation project:

https://review.openstack.org/#/admin/groups/657,members

Thew new cores are:

Olena Logvinova
Mariia Zlatkova

Over the past ~1,5 years they've contributed a lot of quality docs pieces
to various openstack projects, including Fuel docs.

We've also removed inactive members.

Please let me know if you have concerns etc.

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


Re: [openstack-dev] [tc][all] Plugins for all

2016-07-18 Thread Hayes, Graham
On 18/07/2016 17:57, Thierry Carrez wrote:
> Hayes, Graham wrote:
>> [...]
>> The point is that we were supposed to be a level field as a community
>> but if we have examples like this, there is not a level playing field.
>
> While I generally agree on your goals here (avoid special-casing some
> projects in generic support projects like Tempest), I want to clarify
> what we meant by "level playing field" in a recent resolution.


Yes - it has been pointed out the title is probably overloading a term
just used for a different purpose - I am more than willing to change it.

I wasn't sure where I got the name, and I realised that was probably in
my head from that resolution.

> This was meant as a level playing field for contributors within a
> project, not a level playing field between projects. The idea is that
> any contributor joining any OpenStack project should not be technically
> limited compared to other contributors on the same project. So, no
> "secret sauce" that only a subset of developers on a project have access to.

There is a correlation here - "special sauce" (not secret obviously)
that only a subset of projects have access to.

> I think I understand where you're gong when you say that all projects
> should have equal chances, but keep in mind that (1) projects should not
> really "compete" against each other (but rather all projects should
> contribute to the success of OpenStack as a whole) and (2) some
> OpenStack projects will always be more equal than others (for example we
> require that every project integrates with Keystone, and I don't see
> that changing).

Yes, I agree we should not be competing. But was should not be asking
the smaller projects to re-implement functionality, just because they
did not get integrated in time.

We require all projects to integrate with keystone for auth, as we
require all projects to integrate with neutron for network operations
and designate for DNS, I just see it as a requirement for using the
other components of OpenStack for their defined purpose.




__
OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Michael Still
On 16 Jul 2016 1:27 PM, "Thomas Herve"  wrote:
>
> On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M  wrote:
> > Some specific things:
> >
> > Magnum trying to not use Barbican as it adds an addition dependency.
See the discussion on the devel mailing list for details.
> >
> > Horizon discussions at the summit around wanting to use Zaqar for
dynamic ui updates instead of polling, but couldn't depend on a non widely
deployed subsystem.
> >
> > Each Advanced OpenStack Service implementing a guest controller
communication channel that are incompatible with each other and work around
communications issues differently. This makes a lot more pain for Ops to
debug or architect a viable solution. For example:
> >  * Sahara uses ssh from the controllers to the vms. This does not play
well with tenant networks. They have tried to work around this several ways:
> > * require every vm to have a floating ip. (Unnecessary attack
surface)
> > * require the controller to be on the one and only network node
(Uses ip netns exec to tunnel. Doesn't work for large clouds)
> > * Double tunnel ssh via the controller vm's. so some vms have fips,
some don't. Better then all, but still not good.
> >   * Trove uses Rabbit for the guest agent to talk back to the
controllers. This has traffic going the right direction to work well with
tenant networks.
> > * But Rabbit is not multitenant so a security risk if any user can
get into any one of the database vm's.
> > Really, I believe the right solution is to use a multitenant aware
message queue so that the guest agent can pull in the right direction for
tenant networks, and not have the security risk. We have such a system
already, Zaqar, but its not widely deployed and projects don't want to
depend on other projects that aren't widely deployed.
>
> While I agree using Barbican/Zaqar for those would be fantastic, this
> is easily solved: just optionally depend on it. Heat provides features
> that use Zaqar, which are not just present when Zaqar is not there.
> For example, if people in the Trove project were convinced that Zaqar
> was the best solution to their problem, I think they would find a way
> to provide an implementation using it. I don't think they are, though.
> Whatever the reasons may be.
>
> > The lack of Instance Users has caused lots of projects to try and work
around the lack thereof. I know for sure, Mangum, Heat, and Trove work
around the lack. I'm positive others have too. As an operator, it makes me
have to very carefully consider all the tradeoffs each project made, and
decide if I can accept the same risk they assumed. Since each is different,
thats much harder.
>
> Instance users would be nice. Nobody just provided a good solution. I
> know you tried, but I don't think you succeeded. We need a good
> implementation, easy to understand, and maybe this will move forward.

I think I need a more complete definition of instance users to know what
you're talking about here. Is this the instance locking stuff Bruno
proposed a while ago?

> > I'm sure there are more examples. but I hope you get I'm not just
trying to troll.
> >
> > The TC did apply inconsistant rules on letting projects in. That was
for sure a negative before the big tent. But it also provided a way to
apply pressure to projects to fix some of the issues that multiple projects
face, and that plague user/operators and raise the whole community up, and
that has fallen to the wayside since. Which is a big negative now. Maybe
that could be bolted on top of the Big Tent I don't know.
>
> So I think that's the root of the issue here. You assume we can
> "pressure" people do something you think is right. But that's not how
> opensource works. You either implement the solution to your problem,
> or convince someone else, but you don't force anybody. I think that's
> what the TC recognized and changed, to the correct path. Could project
> be better integrated, so that we have a more coherent "product"? Sure.
> But you don't achieve that with more governance and processes.
>
> --
> Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Michael
__
OpenStack Development Mailing 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][all] Plugins for all

2016-07-18 Thread Thierry Carrez

Hayes, Graham wrote:

[...]
The point is that we were supposed to be a level field as a community
but if we have examples like this, there is not a level playing field.


While I generally agree on your goals here (avoid special-casing some 
projects in generic support projects like Tempest), I want to clarify 
what we meant by "level playing field" in a recent resolution.


This was meant as a level playing field for contributors within a 
project, not a level playing field between projects. The idea is that 
any contributor joining any OpenStack project should not be technically 
limited compared to other contributors on the same project. So, no 
"secret sauce" that only a subset of developers on a project have access to.


I think I understand where you're gong when you say that all projects 
should have equal chances, but keep in mind that (1) projects should not 
really "compete" against each other (but rather all projects should 
contribute to the success of OpenStack as a whole) and (2) some 
OpenStack projects will always be more equal than others (for example we 
require that every project integrates with Keystone, and I don't see 
that changing).


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] [mistral] Team meeting minutes - 07/18/2016

2016-07-18 Thread Renat Akhmerov
Thanks for the great meeting today!

Meeting minutes and log:
http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-07-18-16.02.html
 

http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-07-18-16.02.log.html
 


The next meeting will be on Jul 25.

Renat Akhmerov
@Nokia

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


Re: [openstack-dev] [TripleO] Proposing Gabriele Cerami for tripleo-quickstart core

2016-07-18 Thread Lars Kellogg-Stedman
On Mon, Jul 18, 2016 at 11:06:53AM -0400, John Trowbridge wrote:
> I would like to propose Gabriele (panda on IRC), for tripleo-quickstart
> core. He has worked on some pretty major features for the project
> (explicit teardown, devmode), and has a good understanding of the code base.

+2 from me.  Gabriel has done some good work and he has put up with
my reviews :).

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/



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] [TripleO] tripleo-common bugs, bug tracking and launchpad tags

2016-07-18 Thread Ben Nemec
On 07/18/2016 06:28 AM, Julie Pichon wrote:
> Hi,
> 
> On Friday Dougal mentioned on IRC that he hadn't realised there was a
> separate project for tripleo-common bugs on Launchpad [1] and that he'd
> been using the TripleO main tracker [2] instead.
> 
> Since the TripleO tracker is also used for client bugs (as far as I can
> tell?), and there doesn't seem to be a huge amount of tripleo-common
> bugs perhaps it would make sense to also track those in the main
> tracker? If there is a previous conversation or document about bug
> triaging beyond [3] I apologise for missing it (and would love a
> URL!). At the moment it's a bit confusing.

+1.  Given the heavily interconnected nature of tripleo-common,
tripleoclient, t-h-t, puppet-triple, et al I think it would get a bit
crazy trying to track bugs with repo-specific trackers.

Rather than use the wiki, whose future is in doubt, I would like to
propose that this become a policy like
https://review.openstack.org/#/c/339236/

> 
> If we do encourage using the same bug tracker for multiple components,
> I think it would be useful to curate a list of official tags [4]. The
> main advantage of doing that is that the tags will auto-complete so
> it'd be easier to keep them consistent (and thus actually useful).
> 
> Personally, I wanted to look through open bugs against
> python-tripleoclient but people use different ways of marking them at
> the moment - e.g. [tripleoclient] or [python-tripleoclient] or
> tripleoclient (or nothing?) in the bug name. I tried my luck at adding
> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
> something shorter like 'cli', 'common' would make more sense. If there
> are other tags that come back regularly it'd probably be helpful to
> list them explicitly as well.
> 
> Julie
> 
> [1] https://bugs.launchpad.net/tripleo-common
> [2] https://bugs.launchpad.net/tripleo
> [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
> [4] https://wiki.openstack.org/wiki/Bug_Tags
> [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient
> 
> __
> OpenStack Development Mailing 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] Add an extension "btree_gist" to Postgresql

2016-07-18 Thread Sean M. Collins
Ihar Hrachyshka wrote:
> That’s an interesting precedent. I understand that since we gate on
> postgresql and mysql only, the solution is good enough to pass in the gate.
> But are we ok fixing a bug just for those two backends, knowing that it’s
> left exposed for other backends? Could you think of a solution that would be
> backend agnostic?


This is why during the review phase, I objected to using a stored
procedure for this logic, since it is tied very tightly to the database
implementation. 

I also have a lot of scars and recurring nightmares
about an old job where the majority of an application's logic was
embedded in huge stored procedures and database triggers - so I'm a bit
biased.

-- 
Sean M. Collins

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


Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

2016-07-18 Thread Steve Martinelli
More comments inline.

On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak 
wrote:

> Ok. So it sounds like I'm not entirely off track and this will probably be
> the road we go down for our deployment until we have a better option. We
> need an MFA solution, and this doesn't seem like too terrible an option.
>
> Basically after a bunch of digging this was the only solution I found that
> wouldn't break everything, still cover our requirements, maybe let us do
> something interesting with CLI tools.
>
> For the UX thing, we're likely going to edit our horizon login form to
> have an optional passcode field and have the form concatenate before
> passing it to the keystone client. Having a proper two-step login process
> with passcode entry on a second page didn't really seem to be viable with
> stock keystone and mostly stock horizon so this seemed easier and workable.
>
This was the disconnect I had, I initially envisioned this as a two-step
process, but I'm happy to be wrong. Didn't realize that appending the
passcode is a common practice.

> A side UX part that is good here though is that the CLI is still usable
> without any extra work. Just enter your password+passcode and it works.
> Although for the CLI and clients we are actually looking at options to
> allow a sort of wrapper script to connect to a Yubikey and ask for a
> passcode. I'm not sure how doable that is, but anything that let's us do
> MFA while still working as simply as using envvars is good. Would be
> interesting if we can get something working with a Yubikey.
>
Making sure we have CLI, python bindings (via a keystoneauth plugin) and
horizon support is of course the most important, but it seems like the
first two are freebies. I think the change you posted could very much just
replace the existing password plugin in keystone (
https://review.openstack.org/#/c/343422/) and not be it's own plugin.

As for the MFA on one project but not another... That doesn’t really work.
> MFA only makes sense on a per user basis. Plus if you need an account for
> API actions and automation, you make another user with limited roles, but
> trying to make something like MFA work on a per project basis is something
> we ruled out very early. For my testing I never actually bothered even
> setting or using the project field on the credentials construct as it
> seemed redundant
>
If you do push a specification forward, then I think this is a fine
limitation to state.

> The best way to think about it I've found  is: imagine the horizon UX. You
> are logged into one project without MFA and then you swap to another that
> somehow now magically does need MFA. How do you enforce that? How do you
> log the user out, and make them enter MFA to then move to the other
> project? You are logged in already, with a valid token, how could you even
> tag that token as not logged via MFA? There are so many problems, and so
> many questions.
>
> Good point.


> MFA on a per project basis might be doable, but with a lot of pain and
> refactoring it seems like, none of which is worth it, and most of which
> makes for awful UX.
>
++

> At any rate, I would love to help if I can in this area, as it is
> something that interests me and something that we are going to be doing for
> our deployment. If worth the effort, I can polish up and write tests for
> the plugin I've written. It may not be the best solution long term, but it
> is the only one that seemed workable with what is present in OpenStack and
> without considerable effort.
>
> At the very least, I'll do a full write up as to what we end up doing with
> our deployment, and how that went for us.
>
How about a specification instead?
https://github.com/openstack/keystone-specs :)
It's unlikely to land in Newton, but would be a candidate for O.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Proposing Gabriele Cerami for tripleo-quickstart core

2016-07-18 Thread Wesley Hayutin
On Mon, Jul 18, 2016 at 11:06 AM, John Trowbridge  wrote:

> Howdy,
>
> I would like to propose Gabriele (panda on IRC), for tripleo-quickstart
> core. He has worked on some pretty major features for the project
> (explicit teardown, devmode), and has a good understanding of the code
> base.
>
> This will bring us to three dedicated core reviewers for
> tripleo-quickstart (myself and larsks being the other two), so I would
> also like to implement a 2x +2 policy at this time. Note, that all cores
> of TripleO are also cores on tripleo-quickstart, and should feel free to
> +2 changes as they are comfortable.
>
> If there are no objections, I will put in a change at the end of the week.
>
> Thanks,
>

+1 from me :)


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


Re: [openstack-dev] [Nova] About deleting keypairs

2016-07-18 Thread Matt Riedemann

On 7/14/2016 3:04 AM, Zhenyu Zheng wrote:

Hi All,

We have meet some problems when trying to cleanup resources, keypairs in
particular.

The scenario is like this, we have several projects in our public cloud,
each project have their own admin, they can create and delete users, and
their users may create keypairs; As keypairs are only related to
users(user_id), when project admin delete it's users, they may forget to
delete the related keypairs and also they might tried to delete keypairs
but some thing happened and it didn't work.

Now, when we, as public cloud admin, we want to delete this project and
cleanup its' resources, we can't delete the keypairs because when delete
keypairs we have to provide the related user_id, if this user has
already been deleted(keystone uses hard delete and we cannot find
deleted users their), we won't able to delete the keypairs forever.

Does anyone have any comments or thoughts about the above problem?

Thanks

Kevin Zheng


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



Nova doesn't actually validate the user_id passed into the keypairs API 
is valid, does it? Like flavor access and quotas, Nova is given an ID 
but doesn't validate it with Keystone. So we don't actually need 
Keystone to find these do we?


I'm not saying that's great, we already had a spec approved for Newton 
to check the provided user/project ID with keystone for the flavor 
access and quotas APIs, we could do the same for keypairs.


You could, however, write a script that deletes keypairs for user_ids 
that don't exist in Keystone...


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

2016-07-18 Thread Matt Riedemann

On 7/18/2016 9:42 AM, Matt Riedemann wrote:

On 7/18/2016 9:09 AM, Markus Zoeller wrote:

Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
Portland and won't be available for the next 2h or so.
If you can have a look at it and merge it, that would be great.

References:
[1]
https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1

[2] https://review.openstack.org/#/c/342604/1
[3] https://bugs.launchpad.net/nova/+bug/1603979
[4] logstash: http://goo.gl/79yFb9



This is an API change for oslo.context, why wasn't it released as 3.0.0?

Seems we should revert the upper-constraints bump and blacklist 2.6.0,
then get that released as 3.0.0.



Here is the blacklist:

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

--

Thanks,

Matt Riedemann


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


[openstack-dev] [puppet] weekly meeting #87

2016-07-18 Thread Emilien Macchi
Hi Puppeteers!

We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4.

Here's a first agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160719

Feel free to add topics, and any outstanding bug and patch.

See you tomorrow!
Thanks,
-- 
Emilien Macchi

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


[openstack-dev] [TripleO] Proposing Gabriele Cerami for tripleo-quickstart core

2016-07-18 Thread John Trowbridge
Howdy,

I would like to propose Gabriele (panda on IRC), for tripleo-quickstart
core. He has worked on some pretty major features for the project
(explicit teardown, devmode), and has a good understanding of the code base.

This will bring us to three dedicated core reviewers for
tripleo-quickstart (myself and larsks being the other two), so I would
also like to implement a 2x +2 policy at this time. Note, that all cores
of TripleO are also cores on tripleo-quickstart, and should feel free to
+2 changes as they are comfortable.

If there are no objections, I will put in a change at the end of the week.

Thanks,

- trown

__
OpenStack Development Mailing 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] [docs][nova] config options help texts: reviews by technical writers?

2016-07-18 Thread Markus Zoeller
On 18.07.2016 16:03, Matt Kassawara wrote:
> I think we can help. Do you want us to submit patches for config option
> descriptions that benefit from rewording? Also, you might want to post to
> the -docs list.

Awesome, thanks! If you could submit the changes, that would be great.
Let me skim through our modules first and filter out those which aren't
yet ready for your rewording. I'll post a list of modules in this thread
in the next days.

In case you don't already know, we have all config options at:
https://github.com/openstack/nova/tree/master/nova/conf

-- 
Regards, Markus Zoeller (markus_z)


> On Mon, Jul 18, 2016 at 6:29 AM, Markus Zoeller > wrote:
> 
>> I'd like to ask the docs team if they see the possibility to have
>> reviews of the merged config options help texts Nova has updated in the
>> last months.
>>
>> Background: In Mitaka and Newton, Nova put a lot of effort in providing
>> valuable help texts for their config options. They are written from
>> developers for operators. My assumption is, that technical writers like
>> the docs team look at them differently. As these help texts get
>> extracted from the code and will be used directly in the "configuration
>> reference" manual, the text "by-passed" the writing expertise of the
>> docs team.
>>
>> Be aware, that this is still an ongoing effort in Nova (see [1],
>> especially "needs:fix_opt_description").
>>
>> References:
>> [1] http://45.55.105.55:8082/config-options.html
>>
>> --
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> __
> OpenStack Development Mailing 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][all] Big tent? (Related to Plugins for all)

2016-07-18 Thread Flavio Percoco

On 15/07/16 18:36 +, Fox, Kevin M wrote:

Some specific things:

Magnum trying to not use Barbican as it adds an addition dependency. See the 
discussion on the devel mailing list for details.

Horizon discussions at the summit around wanting to use Zaqar for dynamic ui 
updates instead of polling, but couldn't depend on a non widely deployed 
subsystem.



Are the two points above a big tent issue?

We did have that problem before the big tent because distributions wouldn't
package projects that weren't integrated and OPs wouldn't deploy projects that
weren't integrated. I do not think that's true anymore.

In fact, projects like TripleO and Heat are already using Zaqar, despite the
fact it's not widely deployed. As Thomas mentioned in his reply to this email,
optional dependencies are the answer here. Re-inventing the wheel to avoid
adding a new dependency is the wrong approach but that's not an issue originated
by the big tent itself.




Each Advanced OpenStack Service implementing a guest controller communication 
channel that are incompatible with each other and work around communications 
issues differently. This makes a lot more pain for Ops to debug or architect a 
viable solution. For example:
* Sahara uses ssh from the controllers to the vms. This does not play well with 
tenant networks. They have tried to work around this several ways:
   * require every vm to have a floating ip. (Unnecessary attack surface)
   * require the controller to be on the one and only network node (Uses ip 
netns exec to tunnel. Doesn't work for large clouds)
   * Double tunnel ssh via the controller vm's. so some vms have fips, some 
don't. Better then all, but still not good.
 * Trove uses Rabbit for the guest agent to talk back to the controllers. This 
has traffic going the right direction to work well with tenant networks.
   * But Rabbit is not multitenant so a security risk if any user can get into 
any one of the database vm's.
Really, I believe the right solution is to use a multitenant aware message 
queue so that the guest agent can pull in the right direction for tenant 
networks, and not have the security risk. We have such a system already, Zaqar, 
but its not widely deployed and projects don't want to depend on other projects 
that aren't widely deployed.


I believe what you're describing above is not really related to how widely
deployed Zaqar is, but I might be being too naive here. Even if it were, though,
I still don't think that issue was caused by the big tent change. If anything,
the big tent change alleviated part of the issue.


The lack of Instance Users has caused lots of projects to try and work around 
the lack thereof. I know for sure, Mangum, Heat, and Trove work around the 
lack. I'm positive others have too. As an operator, it makes me have to very 
carefully consider all the tradeoffs each project made, and decide if I can 
accept the same risk they assumed. Since each is different, thats much harder.



I'd really appreciate if you'd ellaborate on why this issue was caused by the
big tent.


I'm sure there are more examples. but I hope you get I'm not just trying to 
troll.



I don't think you are but I'm lacking of some context that I get the feeling you
have. Hopefully I'm not being short-minded.


The TC did apply inconsistant rules on letting projects in. That was for sure a 
negative before the big tent. But it also provided a way to apply pressure to 
projects to fix some of the issues that multiple projects face, and that plague 
user/operators and raise the whole community up, and that has fallen to the 
wayside since. Which is a big negative now. Maybe that could be bolted on top 
of the Big Tent I don't know.

I could write a very long description about the state of being an OpenStack App 
developer too that touches on all the problems with getting a consistent target 
and all the cross project communication issues there of. But thats probably for 
some other time.


TBH, I'd be interested in such email but I'd beg you to keep it in a separate
thread as I don't think such email relates entirely to this one.

I believe the things you're describing are side-effects caused by the growth of
our community, which I consider a good thing. As Graham said in one of his
replies, we've not seen the end of the big tent yet and I believe there are
still good and bad things to come. How fast we'll adapt/react to those will
determine the success of the big tent.

I agree there are things that need to be changed or reflected on already and
your email, Graham's and Clynt's are a good example of the community
trying/willing to keep up with the changes.

Looking forward to your reply,
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

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

2016-07-18 Thread Matt Riedemann

On 7/18/2016 9:09 AM, Markus Zoeller wrote:

Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
Portland and won't be available for the next 2h or so.
If you can have a look at it and merge it, that would be great.

References:
[1]
https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
[2] https://review.openstack.org/#/c/342604/1
[3] https://bugs.launchpad.net/nova/+bug/1603979
[4] logstash: http://goo.gl/79yFb9



This is an API change for oslo.context, why wasn't it released as 3.0.0?

Seems we should revert the upper-constraints bump and blacklist 2.6.0, 
then get that released as 3.0.0.


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [kolla] our mascot - input needed

2016-07-18 Thread Steven Dake (stdake)


On 7/18/16, 6:12 AM, "Michał Jastrzębski"  wrote:

>I refuse to be cut out of this thread. It is my right to freely say
>what's in my mind in this, very important for our glorious project,
>issue!
>
>So here it is:
>
>Koala that holds openstack square'y logo and makes docker whale jumps
>through it

that's actually pretty good but I'm sure OpenStack trademark folks would
mention "infringement!" of some type.  OR docker would :)

Regards
-steve
>
>See? No glue or any narcotics involved.
>Meanwhile I'll keep using my own logo which will be reserved for kolla
>inner circle. Also develop a secret handshake while I'm at it.
>
>On 17 July 2016 at 21:16, Jeffrey Zhang  wrote:
>> koala +1
>>
>> On Mon, Jul 18, 2016 at 9:07 AM, Ryan Hallisey 
>>wrote:
>>> koala bear
>>>
>>> -Ryan
>>>
>>> - Original Message -
>>> From: "Vikram Hosakote (vhosakot)" 
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>
>>> Sent: Saturday, July 16, 2016 1:24:08 PM
>>> Subject: Re: [openstack-dev] [kolla] our mascot - input needed
>>>
>>> Sorry, I missed the kolla mid-cycle summit as I was at a conference.
>>>
>>> I will review the mid-cycle etherpad.
>>>
>>> Yes for the koala bear!! :)
>>>
>>> Regards,
>>> Vikram Hosakote
>>> IRC: vhosakot
>>>
>>> From: "Steven Dake (stdake)" < std...@cisco.com >
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)" < openstack-dev@lists.openstack.org >
>>> Date: Thursday, July 14, 2016 at 1:08 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>>openstack-dev@lists.openstack.org >
>>> Subject: [openstack-dev] [kolla] our mascot - input needed
>>>
>>> Hey folks,
>>>
>>> The OpenStack foundation is putting together mascots for every project
>>>with a proper artist doing the work. The cool thing about this is we a)
>>>get stickers b) have consistent look and feel among mascots in
>>>OpenStack.
>>>
>>> The downside is we have to make a decision. The foundation wants 3-5
>>>choices.
>>>
>>> The mascot must be an animal and it can't involve glue or other inc007
>>>inspired ideas :)
>>>
>>> Obviously Koala bear is probably everyone's first choice since we have
>>>sort of been using that as a mascot since day one. Anyone else have
>>>anything else for me to provide the foundation with a choices 2-5?
>>>
>>> Please respond quickly, the foundation needs the information shortly.
>>>I'd like to offer up two alternatives just in case.
>>>
>>> Regards
>>> -steve
>>>
>>>
>>>
>>> 
>>>
>>>__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> 
>>>
>>>__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] [craton] branch clean up and other stuff

2016-07-18 Thread Jim Baker
Sean, sounds good.

Today, among other things, we will be discussing the branch cleanup, which
should be straightforward. We look forward to discussing more about OneOps,
and I will briefly mention our thoughts to date on how this could work.

https://etherpad.openstack.org/p/craton-meetings for the full agenda



On Mon, Jul 18, 2016 at 8:29 AM, sean roberts 
wrote:

> I'm going to have to miss this mornings meeting again. Here out my
> outstanding issues
> - project patch https://review.openstack.org/#/c/332470/9, is pending a
> request to clean up the branches in the craton repo. Once the repo is
> moved, branch cleanup is expensive time wise. Branches are typically minor
> and major releases only.
> - allocating devs to the project. I'm getting spun up around a few teams.
> After the watcher, nova mid cycle this week. I will have a better idea who
> is available.
> - forking OneOps CMS repos as code base start. We are definitely
> interested internally in doing this. I suggest I get my devs to propose how
> the fork would look and what the implications are. Then the craton team as
> whole can discuss the merits and modifications to the approach.
>
>
>
> --
> ~sean
>
> __
> OpenStack Development Mailing 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] [craton] branch clean up and other stuff

2016-07-18 Thread sean roberts
I'm going to have to miss this mornings meeting again. Here out my
outstanding issues
- project patch https://review.openstack.org/#/c/332470/9, is pending a
request to clean up the branches in the craton repo. Once the repo is
moved, branch cleanup is expensive time wise. Branches are typically minor
and major releases only.
- allocating devs to the project. I'm getting spun up around a few teams.
After the watcher, nova mid cycle this week. I will have a better idea who
is available.
- forking OneOps CMS repos as code base start. We are definitely interested
internally in doing this. I suggest I get my devs to propose how the fork
would look and what the implications are. Then the craton team as whole can
discuss the merits and modifications to the approach.



-- 
~sean
__
OpenStack Development Mailing 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] Is LBAAS mandatory for MAGNUM ?

2016-07-18 Thread Spyros Trigazis
Hi Greg,

lbaas *v1* is required for magnum mitaka.

Cheers,
Spyros

On 18 July 2016 at 16:16, Waines, Greg  wrote:

> Thanks Madhuri,
>
>
>
> This blueprint is ‘Accepted for Newton’.
>
> So in ‘Mitaka’ and before, LBAAS is required for Magnum ?
>
>
>
> Greg.
>
>
>
> *From: *"Kumari, Madhuri" 
> *Reply-To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Date: *Monday, July 18, 2016 at 10:07 AM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?
>
>
>
> Hi Greg,
>
>
>
> Now it is not mandatory to have lbaas in Magnum. Here is blueprint in
> Magnum that aims to decouple lbaas from  Magnum
> https://blueprints.launchpad.net/magnum/+spec/decouple-lbaas.
>
> You can use flag –master-lb-enabled in baymodel to specify whether you
> want lbaas or not. However it just allows you to disable lbaas when master
> count is 1.
>
>
>
> Regards,
>
> Madhuri
>
>
>
> *From:* Waines, Greg [mailto:greg.wai...@windriver.com]
> *Sent:* Monday, July 18, 2016 5:11 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?
>
>
>
> I’m relatively new to looking at Magnum.
>
> Just recently played with Magnum in devstack on Newton.
>
> I noticed that the HEAT Stack used by Magnum created Load Balancer Pool
> and Load Balancer HealthMonitor.
>
>
>
> QUESTION … Is LBAAS support mandatory for MAGNUM ?  or can it be used
> (configured) without it ?
>
>
>
> i.e. if the OpenStack distribution being used does NOT support LBAAS, will
> MAGNUM work ?   will it still be useful ?
>
>
>
> ( … thinking that it could still be used, although would not support the
> load balancing across scaled or multiple instances of a container … )
>
>
>
> Greg.
>
> __
> OpenStack Development Mailing 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] [murano] Mascot for murano

2016-07-18 Thread Kirill Zaitsev
Let’s hop on the mascot craze train and choose one for murano, shall we? For 
those out of loop, please see http://www.openstack.org/project-mascots =)

Feel free to add suggestions, leave +1/-1 votes here 
https://etherpad.openstack.org/p/murano-mascot 


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

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


Re: [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?

2016-07-18 Thread Waines, Greg
Thanks Madhuri,

This blueprint is ‘Accepted for Newton’.
So in ‘Mitaka’ and before, LBAAS is required for Magnum ?

Greg.

From: "Kumari, Madhuri" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, July 18, 2016 at 10:07 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?

Hi Greg,

Now it is not mandatory to have lbaas in Magnum. Here is blueprint in Magnum 
that aims to decouple lbaas from  Magnum 
https://blueprints.launchpad.net/magnum/+spec/decouple-lbaas.
You can use flag –master-lb-enabled in baymodel to specify whether you want 
lbaas or not. However it just allows you to disable lbaas when master count is 
1.

Regards,
Madhuri

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Monday, July 18, 2016 5:11 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?

I’m relatively new to looking at Magnum.
Just recently played with Magnum in devstack on Newton.
I noticed that the HEAT Stack used by Magnum created Load Balancer Pool and 
Load Balancer HealthMonitor.

QUESTION … Is LBAAS support mandatory for MAGNUM ?  or can it be used 
(configured) without it ?

i.e. if the OpenStack distribution being used does NOT support LBAAS, will 
MAGNUM work ?   will it still be useful ?

( … thinking that it could still be used, although would not support the load 
balancing across scaled or multiple instances of a container … )

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


[openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

2016-07-18 Thread Markus Zoeller
Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
Portland and won't be available for the next 2h or so.
If you can have a look at it and merge it, that would be great.

References:
[1]
https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
[2] https://review.openstack.org/#/c/342604/1
[3] https://bugs.launchpad.net/nova/+bug/1603979
[4] logstash: http://goo.gl/79yFb9

-- 
Regards, Markus Zoeller (markus_z)


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


Re: [openstack-dev] [Magnum] Following Magnum QuickStart page, how do i use Docker CLI directly to manage containers

2016-07-18 Thread Kumari, Madhuri
Hi Greg,

Yes we do have document that explains the steps to configure your docker client 
to to be able to interact to bays.
Please follow this link 
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay

Regards,
Madhuri

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Monday, July 18, 2016 6:53 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Following Magnum QuickStart page, how do i 
use Docker CLI directly to manage containers

Was trying out Magnum in Devstack, following the instructions at 
http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html

I successfully created a swarmbay.
test -f ~/.ssh/id_rsa.pub || ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
nova keypair-add --pub-key ~/.ssh/id_rsa.pub testkey
magnum baymodel-create --name swarmbaymodel \
   --image-id fedora-21-atomic-5 \
   --keypair-id testkey \
   --external-network-id public \
   --dns-nameserver 8.8.8.8 \
   --flavor-id m1.small \
   --docker-volume-size 5 \
   --coe swarm
magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 2

Given that the ‘magnum container-… …’ APIs are no longer supported,
I wanted to use the Docker CLI directly to manage containers.

Is there an updated dev-quickstart guide on how to do this ?

-  I tried ssh-ing to the swarm-master VM, using the key … but could 
not connect.

-  ???

Greg.
__
OpenStack Development Mailing 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] Naming polls - and some issues

2016-07-18 Thread Monty Taylor
On 07/12/2016 04:40 AM, Monty Taylor wrote:
> Hey all!
> 
> The poll emails for the P and Q naming have started to go out - and
> we're experiencing some difficulties. Not sure at the moment what's
> going on ... but we'll keep working on the issues and get ballots to
> everyone as soon as we can.
> 
> Sorry for any confusion.

Quick update:

Some of you should have received updated Q polls. If you did and they
worked, awesome. If you haven't gotten one yet, you should get one
within the next 5 hours (if my math is correct)

Once the Q have all sent out, I will run my new shiny script for the P
poll to re-send. If you have already voted for P, you can ignore the
additional email you get- it will not let you vote a second time. I
expect the P emails to be done sending by this time tomorrow morning.

Sorry again for the confusion. However, if it makes anybody feel better,
I have automation now ...

Monty


__
OpenStack Development Mailing 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] Is LBAAS mandatory for MAGNUM ?

2016-07-18 Thread Kumari, Madhuri
Hi Greg,

Now it is not mandatory to have lbaas in Magnum. Here is blueprint in Magnum 
that aims to decouple lbaas from  Magnum 
https://blueprints.launchpad.net/magnum/+spec/decouple-lbaas.
You can use flag –master-lb-enabled in baymodel to specify whether you want 
lbaas or not. However it just allows you to disable lbaas when master count is 
1.

Regards,
Madhuri

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Monday, July 18, 2016 5:11 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?

I’m relatively new to looking at Magnum.
Just recently played with Magnum in devstack on Newton.
I noticed that the HEAT Stack used by Magnum created Load Balancer Pool and 
Load Balancer HealthMonitor.

QUESTION … Is LBAAS support mandatory for MAGNUM ?  or can it be used 
(configured) without it ?

i.e. if the OpenStack distribution being used does NOT support LBAAS, will 
MAGNUM work ?   will it still be useful ?

( … thinking that it could still be used, although would not support the load 
balancing across scaled or multiple instances of a container … )

Greg.
__
OpenStack Development Mailing 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] [docs][nova] config options help texts: reviews by technical writers?

2016-07-18 Thread Matt Kassawara
I think we can help. Do you want us to submit patches for config option
descriptions that benefit from rewording? Also, you might want to post to
the -docs list.

On Mon, Jul 18, 2016 at 6:29 AM, Markus Zoeller  wrote:

> I'd like to ask the docs team if they see the possibility to have
> reviews of the merged config options help texts Nova has updated in the
> last months.
>
> Background: In Mitaka and Newton, Nova put a lot of effort in providing
> valuable help texts for their config options. They are written from
> developers for operators. My assumption is, that technical writers like
> the docs team look at them differently. As these help texts get
> extracted from the code and will be used directly in the "configuration
> reference" manual, the text "by-passed" the writing expertise of the
> docs team.
>
> Be aware, that this is still an ongoing effort in Nova (see [1],
> especially "needs:fix_opt_description").
>
> References:
> [1] http://45.55.105.55:8082/config-options.html
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [Keystone] Multi-factor Auth with Keystone and TOTP

2016-07-18 Thread David Stanek
On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak  wrote:
> We need an MFA solution, and this doesn't seem like too terrible an option.


One thing to note here is that the credentials for TOTP stored in the
keystone credentials backend are not encrypted. So a breach of your
database could expose those to an attacker. This is a review[1] to fix
this issue that is close to merging.

1. https://review.openstack.org/#/c/317169/

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.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] [tc][all] Plugins for all

2016-07-18 Thread Dmitry Tantsur

On 07/17/2016 11:04 PM, Jay Pipes wrote:

On 07/14/2016 12:21 PM, Hayes, Graham wrote:

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas.


There *is* no standard CLI or UI for setting quotas.


They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.


This has nothing to do with the big tent and everything to do with the
fact that the community at large has conflated quotas -- i.e. the limit
of a particular class of resource that a user or tenant can consume --
with the usage of a particular class of resource. The two things are not
the same nor do they need to be handled by the same service, IMHO.

I've proposed before that quotas -- i.e. the *limits* for different
resource classes that a consumer of those resources has -- be handled by
the Keystone API. This is the endpoint that I personally think makes the
most sense to house this information.

Usage information is necessarily the domain of the individual service
projects who must control allocation/consumption of resources under
their control. It would be *helpful* to have a set of best-practice
guidelines for projects to follow in safely accounting for consumption
of resources, but "the big tent" has nothing to do with our community
failing to do this. We've failed to do this from the beginning of
OpenStack, well before the big tent was just a spark in the minds of the
TC.


Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface.


What "resources" are you referring to above? What is the "unstable
interface" you are referring to? Tempest should only ever be validating
public REST APIs.


Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.


An example here would be super-useful, since as mentioned above, Tempest
should only be validating public HTTP/REST APIs.


Not entirely related example, but still in support of the original point 
(IMO): grenade currently does not catch smoke tests coming from tempest 
plugins when running after upgrade. It's just one missing call [1], and 
it probably would not go unnoticed if Nova tests did not run ;)


[1] https://review.openstack.org/337372




None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.


I guess I don't understand what you are referring to as a "plugin"
above. Are you referring to devstack libXXX things? Or are you referring
to *drivers* for things like the hypervisor in Nova or the ML2 mech
drivers in Neutron? Or something else entirely?

Best,
-jay

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



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


Re: [openstack-dev] [kolla] our mascot - input needed

2016-07-18 Thread Serguei Bezverkhi (sbezverk)
Another idea could me Koala  lie down his back and juggling with logo of 
OpenStack, Docker and Kubernetes. 

Serguei
 

-Original Message-
From: Michał Jastrzębski [mailto:inc...@gmail.com] 
Sent: Monday, July 18, 2016 9:12 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla] our mascot - input needed

I refuse to be cut out of this thread. It is my right to freely say what's in 
my mind in this, very important for our glorious project, issue!

So here it is:

Koala that holds openstack square'y logo and makes docker whale jumps through it

See? No glue or any narcotics involved.
Meanwhile I'll keep using my own logo which will be reserved for kolla inner 
circle. Also develop a secret handshake while I'm at it.

On 17 July 2016 at 21:16, Jeffrey Zhang  wrote:
> koala +1
>
> On Mon, Jul 18, 2016 at 9:07 AM, Ryan Hallisey  wrote:
>> koala bear
>>
>> -Ryan
>>
>> - Original Message -
>> From: "Vikram Hosakote (vhosakot)" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Sent: Saturday, July 16, 2016 1:24:08 PM
>> Subject: Re: [openstack-dev] [kolla] our mascot - input needed
>>
>> Sorry, I missed the kolla mid-cycle summit as I was at a conference.
>>
>> I will review the mid-cycle etherpad.
>>
>> Yes for the koala bear!! :)
>>
>> Regards,
>> Vikram Hosakote
>> IRC: vhosakot
>>
>> From: "Steven Dake (stdake)" < std...@cisco.com >
>> Reply-To: "OpenStack Development Mailing List (not for usage 
>> questions)" < openstack-dev@lists.openstack.org >
>> Date: Thursday, July 14, 2016 at 1:08 PM
>> To: "OpenStack Development Mailing List (not for usage questions)" < 
>> openstack-dev@lists.openstack.org >
>> Subject: [openstack-dev] [kolla] our mascot - input needed
>>
>> Hey folks,
>>
>> The OpenStack foundation is putting together mascots for every project with 
>> a proper artist doing the work. The cool thing about this is we a) get 
>> stickers b) have consistent look and feel among mascots in OpenStack.
>>
>> The downside is we have to make a decision. The foundation wants 3-5 choices.
>>
>> The mascot must be an animal and it can't involve glue or other 
>> inc007 inspired ideas :)
>>
>> Obviously Koala bear is probably everyone's first choice since we have sort 
>> of been using that as a mascot since day one. Anyone else have anything else 
>> for me to provide the foundation with a choices 2-5?
>>
>> Please respond quickly, the foundation needs the information shortly. I'd 
>> like to offer up two alternatives just in case.
>>
>> Regards
>> -steve
>>
>>
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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


[openstack-dev] [Magnum] Following Magnum QuickStart page, how do i use Docker CLI directly to manage containers

2016-07-18 Thread Waines, Greg
Was trying out Magnum in Devstack, following the instructions at 
http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html

I successfully created a swarmbay.
test -f ~/.ssh/id_rsa.pub || ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
nova keypair-add --pub-key ~/.ssh/id_rsa.pub testkey
magnum baymodel-create --name swarmbaymodel \
   --image-id fedora-21-atomic-5 \
   --keypair-id testkey \
   --external-network-id public \
   --dns-nameserver 8.8.8.8 \
   --flavor-id m1.small \
   --docker-volume-size 5 \
   --coe swarm
magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 2

Given that the ‘magnum container-… …’ APIs are no longer supported,
I wanted to use the Docker CLI directly to manage containers.

Is there an updated dev-quickstart guide on how to do this ?

-  I tried ssh-ing to the swarm-master VM, using the key … but could 
not connect.

-  ???

Greg.
__
OpenStack Development Mailing 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] [Keystone] Multi-factor Auth with Keystone and TOTP

2016-07-18 Thread Adrian Turjak
Ok. So it sounds like I'm not entirely off track and this will probably be the road we go down for our deployment until we have a better option. We need an MFA solution, and this doesn't seem like too terrible an option. 
Basically after a bunch of digging this was the only solution I found that wouldn't break everything, still cover our requirements, maybe let us do something interesting with CLI tools.
For the UX thing, we're likely going to edit our horizon login form to have an optional passcode field and have the form concatenate before passing it to the keystone client. Having a proper two-step login process with passcode entry on a second page didn't really seem to be viable with stock keystone and mostly stock horizon so this seemed easier and workable.
A side UX part that is good here though is that the CLI is still usable without any extra work. Just enter your password+passcode and it works. Although for the CLI and clients we are actually looking at options to allow a sort of wrapper script to connect to a Yubikey and ask for a passcode. I'm not sure how doable that is, but anything that let's us do MFA while still working as simply as using envvars is good. Would be interesting if we can get something working with a Yubikey.
As for the MFA on one project but not another... That doesn’t really work. MFA only makes sense on a per user basis. Plus if you need an account for API actions and automation, you make another user with limited roles, but trying to make something like MFA work on a per project basis is something we ruled out very early. For my testing I never actually bothered even setting or using the project field on the credentials construct as it seemed redundant.
The best way to think about it I've found  is: imagine the horizon UX. You are logged into one project without MFA and then you swap to another that somehow now magically does need MFA. How do you enforce that? How do you log the user out, and make them enter MFA to then move to the other project? You are logged in already, with a valid token, how could you even tag that token as not logged via MFA? There are so many problems, and so many questions.
MFA on a per project basis might be doable, but with a lot of pain and refactoring it seems like, none of which is worth it, and most of which makes for awful UX.
At any rate, I would love to help if I can in this area, as it is something that interests me and something that we are going to be doing for our deployment. If worth the effort, I can polish up and write tests for the plugin I've written. It may not be the best solution long term, but it is the only one that seemed workable with what is present in OpenStack and without considerable effort.
At the very least, I'll do a full write up as to what we end up doing with our deployment, and how that went for us.
On 18/07/2016 6:51 PM, Morgan Fainberg  wrote:On Sun, Jul 17, 2016 at 10:37 PM, Steve Martinelli  wrote:Several comments inlineOn Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak  wrote:Hello,

I've been looking at options for doing multi-factor auth (MFA) on our
infrastructure and I'm just wanting to know if the option I've decided
to go with seems sensible.

As context, we are running stock Keystone (to be backed by LDAP), we
wanted to be able to enable MFA on a per user basis, and a user with MFA
enabled should either be blocked from using the APIs or required MFA to
use the APIs.
We discussed adding MFA support in Newton at the Austin summit and didn't come to a happy conclusion (aside from "let federated users have MFA since it's built in"). Part of the trouble was deciding where to enforce MFA. Should a user *always* require MFA just because he has a TOTP credential? What if the user has multiple projects, and wants MFA to access projectA, but not projectB.  
I was looking at the current TOTP module in keystone, but seeing as that
simply adds another optional Auth method to keystone it seems fairly
useless for our needs. Unless I'm missing something, there seems to be
no way in Keystone to enforce "use these two auth methods together". Is
that the case? If not, it is something that has been considered? Or it
is assumed people will write their own auth plugins rather than
combining existing ones?It was definitely not assumed that folks would write there own auth plugins. The TOTP auth plugin was meant to be just be an alternative to password auth. We had hoped it would provide the building blocks for MFA, but see above comment.
From there I went toward writing our own Keystone Auth plugin and had a
lot of success with that. The current iteration is a combination of the
password and totp plugins where for users with TOTP credentials we
expect a 6 digit password appended to the password. In the config I then
replace the default password plugin with my own.I assume appending the TOTP password to the regular password is 

Re: [openstack-dev] [kolla] our mascot - input needed

2016-07-18 Thread Michał Jastrzębski
I refuse to be cut out of this thread. It is my right to freely say
what's in my mind in this, very important for our glorious project,
issue!

So here it is:

Koala that holds openstack square'y logo and makes docker whale jumps through it

See? No glue or any narcotics involved.
Meanwhile I'll keep using my own logo which will be reserved for kolla
inner circle. Also develop a secret handshake while I'm at it.

On 17 July 2016 at 21:16, Jeffrey Zhang  wrote:
> koala +1
>
> On Mon, Jul 18, 2016 at 9:07 AM, Ryan Hallisey  wrote:
>> koala bear
>>
>> -Ryan
>>
>> - Original Message -
>> From: "Vikram Hosakote (vhosakot)" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Sent: Saturday, July 16, 2016 1:24:08 PM
>> Subject: Re: [openstack-dev] [kolla] our mascot - input needed
>>
>> Sorry, I missed the kolla mid-cycle summit as I was at a conference.
>>
>> I will review the mid-cycle etherpad.
>>
>> Yes for the koala bear!! :)
>>
>> Regards,
>> Vikram Hosakote
>> IRC: vhosakot
>>
>> From: "Steven Dake (stdake)" < std...@cisco.com >
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" < 
>> openstack-dev@lists.openstack.org >
>> Date: Thursday, July 14, 2016 at 1:08 PM
>> To: "OpenStack Development Mailing List (not for usage questions)" < 
>> openstack-dev@lists.openstack.org >
>> Subject: [openstack-dev] [kolla] our mascot - input needed
>>
>> Hey folks,
>>
>> The OpenStack foundation is putting together mascots for every project with 
>> a proper artist doing the work. The cool thing about this is we a) get 
>> stickers b) have consistent look and feel among mascots in OpenStack.
>>
>> The downside is we have to make a decision. The foundation wants 3-5 choices.
>>
>> The mascot must be an animal and it can't involve glue or other inc007 
>> inspired ideas :)
>>
>> Obviously Koala bear is probably everyone's first choice since we have sort 
>> of been using that as a mascot since day one. Anyone else have anything else 
>> for me to provide the foundation with a choices 2-5?
>>
>> Please respond quickly, the foundation needs the information shortly. I'd 
>> like to offer up two alternatives just in case.
>>
>> Regards
>> -steve
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

2016-07-18 Thread Swapnil Kulkarni (coolsvap)
On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke  wrote:
> Hi Steve,
>
> +1 to applying. I'll volunteer for the backport team also.
>
> -Paul
>
>
> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>>
>> Hey Koalians,
>>
>> I'd like us to consider applying  for the stable follows policy tag.
>>   Full details are here:
>>
>>
>> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>>
>> Because of the magic work we did to make liberty functional, it is
>> possible that we may not be able to apply for this tag until Liberty
>> falls into EOL.  Still I personally believe intent matters most, and our
>> intent has always been for these to be stable low-rate-of-change
>> no-feature-backport branches.  There are some exceptions I think we
>> would fit under for the Liberty case, so I think it is worth a shot.
>>
>> I'd need 2-4 people to commit to joining the stable backport team for
>> Kolla reviews specifically.  These folks would be the only folks that
>> could ACK patches in the stable branch maintenance queue.  Anyone could
>> continue to submit backport patches as they desire.
>>
>> I'll leave voting open for 1 week or until there I a majority (6 core
>> reviewers) or until there is a unanimous vote.  If there is not, then we
>> won't apply.  The deadline for this vote is July 25th.
>>
>> Thanks!
>> -steve
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing 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

+1 to apply for stable follows policy.
I would like to volunteer for the backport team.

__
OpenStack Development Mailing 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] Applying for stable-follows tag

2016-07-18 Thread Paul Bourke

Hi Steve,

+1 to applying. I'll volunteer for the backport team also.

-Paul

On 18/07/16 13:07, Steven Dake (stdake) wrote:

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.
  Full details are here:

http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is
possible that we may not be able to apply for this tag until Liberty
falls into EOL.  Still I personally believe intent matters most, and our
intent has always been for these to be stable low-rate-of-change
no-feature-backport branches.  There are some exceptions I think we
would fit under for the Liberty case, so I think it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for
Kolla reviews specifically.  These folks would be the only folks that
could ACK patches in the stable branch maintenance queue.  Anyone could
continue to submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core
reviewers) or until there is a unanimous vote.  If there is not, then we
won't apply.  The deadline for this vote is July 25th.

Thanks!
-steve




__
OpenStack Development Mailing 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] [mistal] Mistral logo ideas?

2016-07-18 Thread Ryan Brady
On Mon, Jul 18, 2016 at 12:44 AM, Renat Akhmerov 
wrote:

> On choosing a mascot for Mistral. Let’s choose one till next Monday.
>
> To start this discussion I’d like to propose a couple of ideas:
>
>
>- *Octopus* (kind of symbolic to me). How do you like this beauty?
>http://nashaplaneta.su/_bl/158/78285238.jpg
>
>
 +1.  Intelligence, dexterity, tool-use - many good qualitites to associate
with.


>- *Dandelion*:
>
> http://cdn1.smartvectorpics.com/images/imagesbase/veezy/misc/Flower-Dandelion-Flower_31992.jpg
>
>

> Please feel free to propose any crazy ideas, I think we will choose one
> easily. Btw, if we as a team don’t like what Foundation creates for us we
> won’t have to use it. But I like the idea of following the same style
> across OpenStack projects.
>
> Renat Akhmerov
> @Nokia
>
> On 14 Jul 2016, at 13:24, Renat Akhmerov  wrote:
>
> Hi,
>
> Please take a look at this thread:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
>
> The idea is to choose a mascot from the natural world (animal, fish,
> plant, mountain etc.) and let OpenStack kindly do illustration work for us.
>
> What do you think?
>
> Renat Akhmerov
> @Nokia
>
> On 30 Jun 2016, at 12:03, Renat Akhmerov  wrote:
>
>
> On 30 Jun 2016, at 00:12, Jason Rist  wrote:
> I was thinking of a tornado with eyes or a tasmanian devil.  Both are wind
> related.  Thoughts?
>
>
> Jason, that would be cool to see :) Something like this IMO would be
> awesome, but as always in such cases, a particular illustration matters the
> most.
>
>
> Renat Akhmerov
> @Nokia
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
OpenStack Development Mailing 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][all] Plugins for all

2016-07-18 Thread Hayes, Graham
On 17/07/2016 22:08, Jay Pipes wrote:
> On 07/14/2016 12:21 PM, Hayes, Graham wrote:
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas.
>
> There *is* no standard CLI or UI for setting quotas.

Well if you are nova, neutron or cinder there is.

http://docs.openstack.org/admin-guide/cli_set_quotas.html
http://docs.openstack.org/admin-guide/dashboard_set_quotas.html


>  > They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>
> This has nothing to do with the big tent and everything to do with the
> fact that the community at large has conflated quotas -- i.e. the limit
> of a particular class of resource that a user or tenant can consume --
> with the usage of a particular class of resource. The two things are not
> the same nor do they need to be handled by the same service, IMHO.
>
> I've proposed before that quotas -- i.e. the *limits* for different
> resource classes that a consumer of those resources has -- be handled by
> the Keystone API. This is the endpoint that I personally think makes the
> most sense to house this information.

As have I, but the reality is that *currently* limits are set by quotas.

(As a side note, keystone is the only place that this makes any sense,
but we needed quotas a few years ago, and we had to do what everyone
else had done at the time)

> Usage information is necessarily the domain of the individual service
> projects who must control allocation/consumption of resources under
> their control. It would be *helpful* to have a set of best-practice
> guidelines for projects to follow in safely accounting for consumption
> of resources, but "the big tent" has nothing to do with our community
> failing to do this. We've failed to do this from the beginning of
> OpenStack, well before the big tent was just a spark in the minds of the TC.
>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface.
>
> What "resources" are you referring to above? What is the "unstable
> interface" you are referring to? Tempest should only ever be validating
> public REST APIs.

The resources in tempest - thinks like setting up users / projects for
running the tests, cleaning up resources post testing, checking if
services are enabled / disabled in the cloud being tested, tagging tests
(smoke, slow, etc)

The are all used by projects using tempest for testing, and all of the
above are only available to projects not using the plugin interface
(the in tree tempest tests, in the openstack/tempest repository)

>> Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> An example here would be super-useful, since as mentioned above, Tempest
> should only be validating public HTTP/REST APIs.
>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>
> I guess I don't understand what you are referring to as a "plugin"
> above. Are you referring to devstack libXXX things? Or are you referring
> to *drivers* for things like the hypervisor in Nova or the ML2 mech
> drivers in Neutron? Or something else entirely?
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing 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] [docs][nova] config options help texts: reviews by technical writers?

2016-07-18 Thread Markus Zoeller
I'd like to ask the docs team if they see the possibility to have
reviews of the merged config options help texts Nova has updated in the
last months.

Background: In Mitaka and Newton, Nova put a lot of effort in providing
valuable help texts for their config options. They are written from
developers for operators. My assumption is, that technical writers like
the docs team look at them differently. As these help texts get
extracted from the code and will be used directly in the "configuration
reference" manual, the text "by-passed" the writing expertise of the
docs team.

Be aware, that this is still an ongoing effort in Nova (see [1],
especially "needs:fix_opt_description").

References:
[1] http://45.55.105.55:8082/config-options.html

-- 
Regards, Markus Zoeller (markus_z)


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


Re: [openstack-dev] [api] testing openstackdocstheme and os-api-ref for API reference info

2016-07-18 Thread Hayes, Graham
On 15/07/2016 22:58, Anne Gentle wrote:
> Hi -dev and -doc lists, and awesome devs Karen and Graham specifically -
>
> I want to figure out the best way to coordinate a release of both the
> theme and the sphinx extension so that we can test and publish and
> iterate on the new API reference information display and navigation.
>
> I think these patches are relevant and need to be merged:
>
> openstackdocstheme
> https://review.openstack.org/326668 (Actually include custom JS files)

This one is very important.

This would need to be merged, and then a release created so we could
use it

> https://review.openstack.org/329508 (API References dropdown menu)

I have not fully testes this one yet - I will do that this week

> os-api-ref
> https://review.openstack.org/324805 (Tests for invalid parameter files)
> https://review.openstack.org/327309 (microversion selector - dropdown)

There seems to be some rendering problems on Chrome for this one - I 
need to investigate it.

> https://review.openstack.org/318281 (HTTP Response Code Table)

Good to go, afaik.

> https://review.openstack.org/#/c/322430/ (openstackdocstheme integration)

When this merges, and is part of an os-api-ref release, all the api-ref
jobs will break. We need to find a way of putting a section in the
conf.py of each api-ref code base to flip to openstackdocstheme when it
is at the right version.

>
> I think these patches are irrelevant or will keep us from the priority
> task at hand, and it would be best not to merge them until we have
> merged and then test these after getting the above patches released:
> openstackdocstheme
> https://review.openstack.org/269297 (Remove duplicate search field
> from left sidebar)
> https://review.openstack.org/339747 (Removed more reliance on CDNs)
> https://review.openstack.org/333573 (Removed minimized files)
> https://review.openstack.org/339314 (Fix the incorrect CSS values,
> does something to headings I want more testing on)
>
> I'm asking about timing and next steps. Are these the basic steps, and
> am I missing any?

https://review.openstack.org/#/c/322453/ (Change Layout of Path + Sub
Title) needs to merge before https://review.openstack.org/#/c/322430/

This is to allow for longer URLs that Nova and Keystone have.


> 1. Review and merge the relevant patches in both os-api-ref and
> openstackdocstheme.
> 2. Release new versions of  os-api-ref and openstackdocstheme.
> 3. Publish test content with the new versions.
> 4. Update relevant tox.ini and requirements.txt files.
> 5. Rebuild all api-ref source to implement the new navigation.
>
> What I need to know:
> Is there an order we should follow in merging so that testing across
> browsers makes sense?
>
> What is the scope of testing: is testing with the Compute content
> enough or should we also test with Identity and other projects?

I *think* the URLs in identity are longer, we should use that as well.

> What timing should we attempt for steps 1 and 2 above? I'd like to aim
> for August for 1 and 2, is that do-able?

It should be, if we can get quick reviewer feedback on the patches.
For the changes to the projects conf.py, we might need to ping PTLs /
doc liaisons to make sure it gets the required attention.

> Do we need to wait for all the migrated content to be ready for steps
> 4 and 5 above? I think the answer is no, but I might be missing
> relevant info about how the navigation will work. I can also set up a
> meeting for next week if that's easier than email, let me know.
>
> Thanks,
> Anne
>


__
OpenStack Development Mailing 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] [keystone] meeting canceled this week (7/19/2015)

2016-07-18 Thread Steve Martinelli
Many of us are traveling that day to get to the midcycle, so cancelling the
meeting this week. Enjoy your time back!

stevemar
__
OpenStack Development Mailing 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] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

2016-07-18 Thread Dmitry Tyzhnenko
+1

On Fri, Jul 15, 2016 at 4:41 PM, Artem Panchenko 
wrote:

> +1
>
>
> On 15.07.16 16:25, Tatyana Leontovich wrote:
>
> +1
>
> On Fri, Jul 15, 2016 at 4:08 PM, Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> +1
>>
>> On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy <
>> asledzins...@mirantis.com> wrote:
>>
>>> Hi,
>>> I'd like to nominate Alexey Stepanov for fuel-qa [0] and fuel-devops
>>> [1] core.
>>>
>>> Alexey is doing great job improving fuel-qa and fuel-devops projects.
>>> He's become an expert in code base in very short terms so I think he
>>> deserves to be a part of fuel-qa/fuel-devops core team.
>>>
>>> Please, vote for Alexey!
>>>
>>> [0]
>>> http://stackalytics.com/?release=all=fuel-qa_id=astepanov-m=marks
>>> [1]
>>> http://stackalytics.com/?release=all=fuel-devops_id=astepanov-m=marks
>>>
>>> --
>>> Thanks,
>>> Andrey Sledzinskiy
>>> QA Engineer,
>>> Mirantis, Kharkiv
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Artem Panchenko
> QA Engineer
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
WBR,
Dmitry T.
Fuel QA Engineer
http://www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [kolla][vote] Applying for stable-follows tag

2016-07-18 Thread Steven Dake (stdake)
Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.  Full 
details are here:

http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is possible 
that we may not be able to apply for this tag until Liberty falls into EOL.  
Still I personally believe intent matters most, and our intent has always been 
for these to be stable low-rate-of-change no-feature-backport branches.  There 
are some exceptions I think we would fit under for the Liberty case, so I think 
it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for Kolla 
reviews specifically.  These folks would be the only folks that could ACK 
patches in the stable branch maintenance queue.  Anyone could continue to 
submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core 
reviewers) or until there is a unanimous vote.  If there is not, then we won't 
apply.  The deadline for this vote is July 25th.

Thanks!
-steve


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


Re: [openstack-dev] [nova][glance] snapshots are broken by default with newton and glance v2

2016-07-18 Thread Erno Kuvaja
On Mon, Jul 18, 2016 at 5:19 AM, Nikhil Komawar  wrote:
> Thanks Matt. I've scheduled for a release of the client this week.
>
> On 7/16/16 4:09 AM, Matt Riedemann wrote:
>> This is more of a heads up than anything.
>>
>> Our internal CI is running Tempest with images that don't have
>> kernel_id or ramdisk_id properties set.
>>
>> We're running from master so nova defaults to use_glance_v1=False.
>>
>> Because of this:
>>
>> https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/compute/api.py#L867-L868
>>
>>
>> and this:
>>
>> https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/image/glance.py#L835
>>
>>
>> The snapshot image properties get kernel_id and ramdisk_id set to None
>> since that's what the glance v2 schema requires.
>>
>> However, python-glanceclient has it's own outdated copy of the schema
>> which doesn't allow null values for those properties, see bug:
>>
>> https://bugs.launchpad.net/python-glanceclient/+bug/1596602
>>
>> We don't hit this in the community CI because the image that Tempest
>> uses from devstack has the kernel_id and ramdisk_id properties set:
>>
>> http://logs.openstack.org/52/335152/1/check/gate-tempest-dsvm-neutron-src-python-glanceclient/d393db9/logs/devstacklog.txt.gz#_2016-06-28_18_40_12_429
>>
>>
>> But for anyone else upgrading to Newton that has images without those
>> properties set and doesn't have use_glance_v1=True in nova.conf is
>> going to be broken.
>>
>> Since we really want to get people off glance v1 and move to
>> deprecation in Ocata, we need to get this merged and released:
>>
>> https://review.openstack.org/#/c/335152/
>>
>> And bump the minimum required python-glanceclient in
>> global-requirements for Newton.
>>
>> I'm not really sure why python-glanceclient even has it's own copy of
>> the image schema, that seems redundant and error prone given the
>> glance API already validates that, but it's kind of beside the point
>> right now.
>>
>
> --
>
> Thanks,
> Nikhil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi Matt,

Something has broken on the way if that shipped schema actually affect
your operation. That should be used _only_ when the client is called
without connection to the Glance API (for example in a case you have
no env set and you call `glance help`), this is btw the reason why we
have that schema shipped with the client.

As soon as you execute a call that actually interacts with Glance API
we should be pulling the schema from there. So if this is not the
case, we've broken somewhere on the way. I'll try to find time to have
a look.

- Erno

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


[openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?

2016-07-18 Thread Waines, Greg
I’m relatively new to looking at Magnum.
Just recently played with Magnum in devstack on Newton.
I noticed that the HEAT Stack used by Magnum created Load Balancer Pool and 
Load Balancer HealthMonitor.

QUESTION … Is LBAAS support mandatory for MAGNUM ?  or can it be used 
(configured) without it ?

i.e. if the OpenStack distribution being used does NOT support LBAAS, will 
MAGNUM work ?   will it still be useful ?

( … thinking that it could still be used, although would not support the load 
balancing across scaled or multiple instances of a container … )

Greg.
__
OpenStack Development Mailing 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][all] Plugins for all

2016-07-18 Thread Hayes, Graham
On 18/07/2016 01:59, Matt Riedemann wrote:
> On 7/17/2016 4:13 PM, Jay Pipes wrote:
>> On 07/15/2016 08:36 AM, Hayes, Graham wrote:
>>> On 14/07/2016 21:20, Matt Riedemann wrote:
 And does this also include plugins within projects, like storage
 backends in cinder and hypervisor drivers in nova?
>>>
>>> This is aimed at cross project interaction. So, if there is a project in
>>> projects.yaml that is a backend, or a hypervisor driver, it should.
>>>
>>> However, in the proposal, there is a choice that projects can make -
>>> all in tree, or all plugins. The point of the proposal is equality of
>>> access for the community.
>>>
>>> What would that mean in practice for Nova? Nothing would really change
>>> - they have decided to do in tree.
>>>
>>> 99% of deliverables tagged type:service will have no impact from this,
>>> the change will be in projects that are used by  teams across the
>>> community (CLI, Docs, UI etc), and provide a way for these projects
>>> to integrate with them.
>>>
>>> These integration points should be the same for *all* projects.
>>
>> What integration points exactly are you referring to? Can you provide a
>> specific example that Designate has run into issues with?
>>
 Nova has been pushing for a few releases now on getting rid of plug
 points since they are barriers to interoperability.
>>>
>>> Well, nova's plugins were barriers to interoperability, for other
>>> projects they are the only mechanism for interoperability.
>>
>> Perhaps there is some terminology problem here, but plugins absolutely
>> do NOT enable interoperability between clouds. They are the antithesis
>> of interoperability points.
>>
>> The REST APIs (and for projects that support it, the versioned
>> notifications payloads) should be the *only* interoperability and
>> integration points that projects should rely on.
>>
>> Best,
>> -jay
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I think I'm getting the point. Rather than devstack, tempest,
> openstack-manuals and horizon have stuff baked in for certain projects,
> e.g. nova, cinder, keystone, neutron, etc, every project has to plug in
> the same way, which would force all projects to experience any pain
> associated with dealing with plugging into those projects - and help
> drive making the plugin API better for everyone.
>

That is it - put much more concisely than I managed to.


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


[openstack-dev] [TripleO] tripleo-common bugs, bug tracking and launchpad tags

2016-07-18 Thread Julie Pichon
Hi,

On Friday Dougal mentioned on IRC that he hadn't realised there was a
separate project for tripleo-common bugs on Launchpad [1] and that he'd
been using the TripleO main tracker [2] instead.

Since the TripleO tracker is also used for client bugs (as far as I can
tell?), and there doesn't seem to be a huge amount of tripleo-common
bugs perhaps it would make sense to also track those in the main
tracker? If there is a previous conversation or document about bug
triaging beyond [3] I apologise for missing it (and would love a
URL!). At the moment it's a bit confusing.

If we do encourage using the same bug tracker for multiple components,
I think it would be useful to curate a list of official tags [4]. The
main advantage of doing that is that the tags will auto-complete so
it'd be easier to keep them consistent (and thus actually useful).

Personally, I wanted to look through open bugs against
python-tripleoclient but people use different ways of marking them at
the moment - e.g. [tripleoclient] or [python-tripleoclient] or
tripleoclient (or nothing?) in the bug name. I tried my luck at adding
a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
something shorter like 'cli', 'common' would make more sense. If there
are other tags that come back regularly it'd probably be helpful to
list them explicitly as well.

Julie

[1] https://bugs.launchpad.net/tripleo-common
[2] https://bugs.launchpad.net/tripleo
[3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
[4] https://wiki.openstack.org/wiki/Bug_Tags
[5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient

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


[openstack-dev] [Magnum] Discussing approaches to build `Discovery options for bay types`

2016-07-18 Thread Vipul Nayyar
Hey All,

Wanted to discuss integration of locally hosted discovery mechanisms, as
proposed in the following blueprint
https://blueprints.launchpad.net/magnum/+spec/bay-type-discovery-options.

As suggested by Hongbin, taking inspiration from the etcd approach is good
https://coreos.com/etcd/docs/latest/clustering.html. Although, there are
multiple ways to implement this including passing static config or using an
etcd discovery service. I believe as a first step, I should work on a
static discovery option for a pre-defined cluster with similar arguments as
passed to etcd.

Thoughts and suggestions from the community would be great.

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


[openstack-dev] [new][oslo] futurist 0.16.0 release (newton)

2016-07-18 Thread no-reply
We are enthusiastic to announce the release of:

futurist 0.16.0: Useful additions to futures, from the future.

This release is part of the newton release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/futurist

Please report issues through launchpad:

http://bugs.launchpad.net/futurist

For more details, please see below.

Changes in futurist 0.15.0..0.16.0
--

6d4e15a Remove 'smart' idleness check
4edd530 Add Python 3.5 classifier and venv


Diffstat (except docs and test files)
-

futurist/_futures.py | 6 +++---
setup.cfg| 1 +
tox.ini  | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)




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


Re: [openstack-dev] [Openstack] Openstack Mitaka Neutron LBaaS Question

2016-07-18 Thread Jose Manuel Ferrer Mosteiro
 

There are lbaas packages in Ubuntu 16.04 so you don't need to pipinstall
anything. 

I tried to install lbaasv2 but horizon does not manage it so I finally
installed lbaasv1. 

I use OpenVSwitch. Look for "lbaas" in this file:
https://github.com/paradigmadigital/ansible-openstack-vcenter/blob/mitaka-lbaas/etc_ansible/roles/networking-compute-controller/tasks/main.yml
[4] 

This is the agent config:
https://github.com/paradigmadigital/ansible-openstack-vcenter/blob/mitaka-lbaas/etc_ansible/roles/networking-compute-controller/templates/neutron_lbaas.conf.j2
[5] 

On 2016-07-02 00:24, zhihao wang wrote: 

> Dear OpenStack Dev member: 
> 
> May I ask you some question about neutron lbaaS? 
> 
> How to install the neutron LBaaS with Octavia in Mitaka? 
> I followed these two guide ,but which one I should use? (My openstack is 
> Mitaka , 1 controller, 2 compute nodes) 
> 
> https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun [1] -- Ubuntu Packages 
> Setup 
> http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html [2] 
> -- Configuring LBaaS v2 with Octavia 
> 
> Here is what I did: 
> 
> pip install octavia 
> 
> and then : 
> vim /etc/neutron/neutron.conf
> 
> service_plugins = 
> router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2 
> 
> [service_providers] 
> service_provider = 
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
>  
> 
> /etc/openstack-dashboard/local_settings.py
> 
> OPENSTACK_NEUTRON_NETWORK = {
> 'enable_lb': True
> }
> 
> And then I restart all the neutron service and apache server 
> 
> service neutron-server restart 
> service neutron-dhcp-agent restart 
> service neutron-metadata-agent restart 
> service neutron-l3-agent restart 
> but and then i ran the command neutron agent-list, it return this. I am 
> wondering what is wrong with this? how can I install Neutron LaaS? 
> 
> root@controller:~# neutron agent-list 
> Unable to establish connection to http://controller:9696/v2.0/agents.json 
> 
> Please help 
> 
> Thanks so much 
> 
> Thanks 
> Wally 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
> [3]
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
> [3]
 

Links:
--
[1] https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun
[2]
http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
[3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[4]
https://github.com/paradigmadigital/ansible-openstack-vcenter/blob/mitaka-lbaas/etc_ansible/roles/networking-compute-controller/tasks/main.yml
[5]
https://github.com/paradigmadigital/ansible-openstack-vcenter/blob/mitaka-lbaas/etc_ansible/roles/networking-compute-controller/templates/neutron_lbaas.conf.j2__
OpenStack Development Mailing 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][qos] Egress minimum bandwidth assurance

2016-07-18 Thread Ihar Hrachyshka

Rodolfo  wrote:


Hello:

I’m working in the egress minimum bandwidth assurance qos policy rule.

I made a POC using the following architecture:
-  Every time a new rule is created and assigned to a port:
o   A new queue is created in OVS.
o   Create/update the qos policy (OVS database) in all other ports in  
br-int (assigned to the same vlan), br-tun and br-phy, updating the queue  
value.

o   Set the queue id to the incoming traffic to the OVS.
-  Every time rule is updated:
o   The values are updated in the ovs database.
-  Every time a rule is unassigned to a port:
o   The queue is removed from the qos policies. (OVS database)
o   The OVS rule to set the queue id is removed.

The problem is, based on the neutron extensions API, I can’t make any  
updates in other ports affected by this rule. That means, for example: if  
I create a new port, this port must have also a qos assigned (OVS  
database) using the existing queue. But because the Neutron qos rule  
doesn’t apply to this port, no qos agent function is called and this port  
is not correctly configured.


I am sorry if the question is trivial, but just for my understanding, does  
it mean you want to set some queues on ports that have no qos policy  
attached? Why is it the case?


Because if the policy IS attached to a port, then qos l2 agent driver will  
be triggered for all supported rules, including your new rule, on every  
relevant policy/rule change.


I am sure I miss something, so please enlighten me.

Ihar

__
OpenStack Development Mailing 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] Naming polls - and some issues

2016-07-18 Thread Ian Y. Choi

Thank you, Joshua and Serguei!

Yep. I might have missed his mentions in this thread.
I am now anticipating his new e-mails for P and Q votes.


With many thanks,

/Ian



Joshua Hesketh wrote on 7/18/2016 1:03 PM:

Hello Ian,

My understanding of it is that you need to receive a new link. Monty 
is slowly sending those out in batches and he hasn't finished. I 
expect he'll email the list once he has finished to confirm so I'd 
suggest holding off until then to check.


Cheers,
Josh

On Mon, Jul 18, 2016 at 1:58 PM, Ian Y. Choi > wrote:


Hello,

Today I tried to vote the naming polls for P and Q releases,
however, unfortunately I am experiencing some issues.

I used the link for P release in the e-mail titled "Poll:
OpenStack P Release Naming" on July 11 22:42 UTC.
When I click my URL, the poll site says:
"Error / Your voter key is invalid. You should have received a
correct URL by email."
, and the poll is not ended yet. However I have not received any
other correct URLs by e-mail.

For Q release, I followed the link in the e-mail: "Poll: OpenStack
Q Release Naming" on July 12 02:15 UTC.
When I go to my vote URL, the site says "Poll already ended".
But strangely, when I see the poll result (
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_06e681ae091ad657 ),
all the poll candidates are 'tied'.

So my questions are:

1) Does anybody have troubles on voting P and Q release naming
like me?

2) Has the Q release naming poll already finished?
I think it can be finished although the original due date is July
20th. However It is so strange that the result I am seeing now is
"tied".


With many thanks,

/Ian


Monty Taylor wrote on 7/18/2016 10:03 AM:

Any time is a good time.

On 07/17/2016 04:54 PM, Michael Still wrote:

So, is now a good time to mention that "Quamby" is the
name of a local
prison?

Michael



On Fri, Jul 15, 2016 at 7:50 PM, Eoghan Glynn

>> wrote:



 > (top posting on purpose)
 >
 > I have re-started the Q poll and am slowly adding
all of you fine folks
 > to it. Let's keep our fingers crossed that it works
this time.
 >
 > I also removed Quay. Somehow my brain didn't
process the "it would be
 > like naming the S release "Street"" when reading
the original names.
 > Based on the naming critera, "Circular Quay" would
be a great option for
 > "Circular" - but sadly we already named the C
release Cactus. It's
 > possible this choice will make someone unhappy, and
if it does, I'm
 > certainly sorry. On the other hand, there are _so_
many awesome names
 > possible in this list, I don't think we'll miss it.

 Excellent, thanks Monty for fixing this ... agreed
that the remaining
 Q* choices are more than enough.

 Cheers,
 Eoghan

 > I'll fire out new emails for P once Q is up and going.
 >
 > On 07/15/2016 11:02 AM, Jamie Lennox wrote:
 > > Partially because its name is Circular Quay, so
it would be like
 calling
 > > the S release Street for  Street.
 > >
 > > Having said that there are not that many of them
and Sydney
 people know
 > > what you mean when you are going to the Quay.
 > >
 > >
 > > On 14 July 2016 at 21:35, Neil Jerram

 >
 > > 
 >
 > > Not sure what the problem would be with
'Quay' or 'Street' -
 they
 > > both sound like good options to me.
 > >
 > >
 > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn
 
>
 > >   >
 > >
 > >
 > > 

[openstack-dev] [new][congress] python-congressclient 1.4.0 release (newton)

2016-07-18 Thread no-reply
We are exuberant to announce the release of:

python-congressclient 1.4.0: Client for Congress

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/python-congressclient

Please report issues through launchpad:

http://bugs.launchpad.net/python-congressclient

For more details, please see below.

Changes in python-congressclient 1.3.0..1.4.0
-

bc34c56 Updated from global requirements
c0a33d0 Remove white space between print and ()
9d5db5d Updated from global requirements
0c6e93a Replace keystoneclient with keystoneauth1
fc1fbe0 Updated from global requirements
4bb1d6f Updated from global requirements


Diffstat (except docs and test files)
-

congressclient/osc/v1/policy.py |  4 ++--
congressclient/v1/client.py | 15 +++
requirements.txt|  3 ++-
test-requirements.txt   |  4 ++--
4 files changed, 13 insertions(+), 13 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 88459db..c71b15b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6,0 +7 @@ cliff!=1.16.0,!=1.17.0,>=1.15.0 # Apache-2.0
+keystoneauth1>=2.7.0 # Apache-2.0
@@ -10 +11 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.9.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 74436a3..2527b05 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ discover # BSD
-fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
+fixtures>=3.0.0 # Apache-2.0/BSD
@@ -10 +10 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD



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


  1   2   >