Re: [openstack-dev] [mistral][yaql] Addressing task result using YAQL function

2015-09-05 Thread Dmitri Zimine 
Yes meant to ask for consistency of referencing to task results. So it’s 
task(task_name) regardless of where. 

One use case in favor of this is tooling: I refactor workflow with an automated 
tool which wants to automatically rename the task name EVERYWHERE. You guys 
know well by now that renaming the task is a source of too many frustrating 
errors :)

What other think? 

DZ. 

On Sep 3, 2015, at 4:23 AM, Renat Akhmerov  wrote:

> 
>> On 02 Sep 2015, at 21:01, Dmitri Zimine  wrote:
>> 
>> Agree, 
>> 
>> with one detail: make it explicit -  task(task_name). 
> 
> So do you suggest we just replace res() with task() and it looks like
> 
> task() - get task result when we are in “publish”
> task(task_name) - get task result from anywhere
> 
> ?
> 
> Is that correct you mean we must always specify a task name? The reason I’d 
> like to have a simplified form (w/o task name) is that I see a lot of 
> workflows that we have to repeat task name in publish so that it just look 
> too verbose to me. Especially in case of very long task name.
> 
> Consider something like this:
> 
> tasks:
>   get_volumes_by_names:
> with-items: name in <% $.vol_names %>
> workflow: get_volume_by_name name=<% $.name %>
> publish:
>   volumes: <% $.get_volumes_by_names %>
> 
> So in publish we have to repeat a task name, there’s no other way now. I’d 
> like to soften this requirement, but if you still want to use task names 
> you’ll be able to.
> 
> 
>> res - we often see folks confused by result of what (action, task, workflow) 
>> although we cleaned up our lingo: action-output, task-result, 
>> workflow-output…. but still worth being explicit.
>> 
>> And full result is being thought as the root context $.
>> 
>> Publishing to global context may be ok for now, IMO.
> 
> Not sure what you meant by "Publishing to global context”. Can you clarify 
> please?
> 
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> __
> OpenStack Development Mailing 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] [security][bandit] Looking to the future

2015-09-05 Thread Kelsey, Timothy John 
Hey Bandit Folks,
Thanks for all the great work done during the recent security mid cycle, we 
have made some really solid progress on key areas like documentation, testing, 
and code quality. It was also great to see people in person! This email follows 
on from various conversations with the hope of keeping our momentum and 
planning out our next steps.

Key Focus Areas

Documentation
We made good progress here getting our docs layout and initial content down. 
The next steps now are to keep pushing to bring our docs up to scratch across 
the board, covering all testing and report plugins we have available today. As 
cores, I would suggest we don’t accept any new tests without accompanying 
documentation. Work will now be done to integrate our sphinx build with infra 
to get our stuff available online, much in the same way as Anchor has done 
here: http://docs.openstack.org/developer/anchor/

Testing
We had a strong push to add unit tests to supplement our existing functional 
tests. Going forward we should continue to focus on bringing our coverage up 
and bug fixing as we go. Cores should be mindful of coverage when reviewing new 
patches and significant blocks of new work should of course be accompanied with 
unit tests. To help with this, coverage reporting will be added to the current 
tox output report.

Code Quality
Bandit is growing fast, new and interesting stuff is being added all the time, 
but its worth keeping in mind that there is a lot of code that was hastily 
written for the original prototype and still persists in the code base today. 
This is a source of potential bugs and unnecessary complexity, any effort 
directed in improving this situation would be a good thing. Refactoring is also 
a perfect opportunity to bring up our test coverage as well.

Releases
Up to this point bandit has had a fairly add-hoc release schedule, with new 
releases being pushed once a significant number of new features/bug fixes have 
been accumulated. Going forward we should review this strategy and determine if 
it is still appropriate. We should also consider how our releases could best 
tie into the overarching OpenStack release cadence. I would very much like to 
hear peoples thoughts on this matter.

Anyway, please let me know what people think of this, or anything else that I 
haven’t covered here.

Thanks again for all your hard work

--
Tim Kelsey
Cloud Security Engineer
HP Hellion

__
OpenStack Development Mailing 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] This is what disabled-by-policy should look like to the user

2015-09-05 Thread John Griffith 
On Fri, Sep 4, 2015 at 8:04 AM, Monty Taylor  wrote:

> mordred@camelot:~$ neutron net-create test-net-mt
> Policy doesn't allow create_network to be performed.
>
> Thank you neutron. Excellent job.
>
> Here's what that looks like at the REST layer:
>
> DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 13:55:47
> GMT connection: close content-type: application/json; charset=UTF-8
> content-length: 130 x-openstack-request-id:
> req-ba05b555-82f4-4aaf-91b2-bae37916498d
> RESP BODY: {"NeutronError": {"message": "Policy doesn't allow
> create_network to be performed.", "type": "PolicyNotAuthorized", "detail":
> ""}}
>
> As a user, I am not confused. I do not think that maybe I made a mistake
> with my credentials. The cloud in question simply does not allow user
> creation of networks. I'm fine with that. (as a user, that might make this
> cloud unusable to me - but that's a choice I can now make with solid
> information easily. Turns out, I don't need to create networks for my
> application, so this actually makes it easier for me personally)
>
> In any case- rather than complaining and being a whiny brat about
> something that annoys me - I thought I'd say something nice about something
> that the neutron team has done that especially pleases me. I would love it
> if this became the experience across the board in OpenStack for times when
> a feature of the API is disabled by local policy. It's possible it already
> is and I just haven't directly experienced it - so please don't take this
> as a backhanded condemnation of anyone else.
>

​By the way, I think feedback is good and pointing out positive feedback
for something isn't as frequent as it probably should be.  So before the
sentiment gets completely lost...

"Cool, thanks for pointing it out and yeah; maybe we can look at some
improvements in Cinder and other projects".
​


>
> 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
>
__
OpenStack Development Mailing 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-scheduler] Scheduler sub-group meeting - Cancel for 9/8?

2015-09-05 Thread Dugger, Donald D 
It belatedly occurred to me that it's a US holiday this week (Labor Day) so 
most of us will gone so we should probably cancel the meeting this week.  The 
IRC channel will be there but many of us won't.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

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

2015-09-05 Thread Germy Lure 
Hi, Gal

Thank you for bringing this up. But I have some suggestions for the API.

An operator or some other component wants to reach several VMs related NOT
only one or one by one. Here, RELATED means that the VMs are in one subnet
or network or a host(similar to reaching dockers on a host).

Via the API you mentioned, user must ssh one VM and update even delete and
add PF to ssh another. To a VPC(with 20 subnets?) admin, it's totally a
nightmare.

Germy


On Wed, Sep 2, 2015 at 1:59 PM, Gal Sagie  wrote:

> Hello All,
>
> I have searched and found many past efforts to implement port forwarding
> in Neutron.
> I have found two incomplete blueprints [1], [2] and an abandoned patch [3].
>
> There is even a project in Stackforge [4], [5] that claims
> to implement this, but the L3 parts in it seems older then current master.
>
> I have recently came across this requirement for various use cases, one of
> them is
> providing feature compliance with Docker port-mapping feature (for Kuryr),
> and saving floating
> IP's space.
> There has been many discussions in the past that require this feature, so
> i assume
> there is a demand to make this formal, just a small examples [6], [7],
> [8], [9]
>
> The idea in a nutshell is to support port forwarding (TCP/UDP ports) on
> the external router
> leg from the public network to internal ports, so user can use one
> Floating IP (the external
> gateway router interface IP) and reach different internal ports depending
> on the port numbers.
> This should happen on the network node (and can also be leveraged for
> security reasons).
>
> I think that the POC implementation in the Stackforge project shows that
> this needs to be
> implemented inside the L3 parts of the current reference implementation,
> it will be hard
> to maintain something like that in an external repository.
> (I also think that the API/DB extensions should be close to the current L3
> reference
> implementation)
>
> I would like to renew the efforts on this feature and propose a RFE and a
> spec for this to the
> next release, any comments/ideas/thoughts are welcome.
> And of course if any of the people interested or any of the people that
> worked on this before
> want to join the effort, you are more then welcome to join and comment.
>
> Thanks
> Gal.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
> [2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding
> [3] https://review.openstack.org/#/c/60512/
> [4] https://github.com/stackforge/networking-portforwarding
> [5] https://review.openstack.org/#/q/port+forwarding,n,z
>
> [6]
> https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
> [7] http://www.gossamer-threads.com/lists/openstack/dev/34307
> [8]
> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
> [9]
> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] Oslo meeting - Cancel for Sept 7th, 2015

2015-09-05 Thread Davanum Srinivas 
Team,

Just realized that 9/8 is a holiday for some of us. Let's meet again the
next week.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing 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]keystone version

2015-09-05 Thread Adrian Otto 
Keystone v2 will soon be deprecated. It makes sense for Magnum to use v3.

--
Adrian

On Sep 5, 2015, at 6:57 PM, ?? 
> wrote:

any comments on this?

On Fri, Sep 4, 2015 at 9:43 AM, ?? 
> wrote:
Hi all,

Now the keystoneclient in magnum only support keystone v3. Is is necessary to 
support keystone v2? Keystone v2 don't support trust.

Regards,
Wanghua

__
OpenStack Development Mailing 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] [Congress] bugs for liberty release

2015-09-05 Thread Zhou, Zhenzan 
I have taken two, thanks.
https://bugs.launchpad.net/congress/+bug/1492308
https://bugs.launchpad.net/congress/+bug/1492354

BR
Zhou Zhenzan
From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Friday, September 4, 2015 23:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] bugs for liberty release

Hi all,

I've found a few bugs that we could/should fix by the liberty release.  I 
tagged them with "liberty-rc".  If we could all pitch in, that'd be great.  Let 
me know which ones you'd like to work on so I can assign them to you in 
launchpad.

https://bugs.launchpad.net/congress/+bugs/?field.tag=liberty-rc

Thanks,
Tim
__
OpenStack Development Mailing 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]keystone version

2015-09-05 Thread 王华 
any comments on this?

On Fri, Sep 4, 2015 at 9:43 AM, 王华  wrote:

> Hi all,
>
> Now the keystoneclient in magnum only support keystone v3. Is is necessary
> to support keystone v2? Keystone v2 don't support trust.
>
> Regards,
> Wanghua
>
__
OpenStack Development Mailing 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 support for Amazon Concepts - was Re: cloud-init IPv6 support

2015-09-05 Thread Sean M. Collins 
On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:
> Right, it depends on your perspective of who 'owns' the API. Is it
> cloud-init or EC2?
> 
> At this point I would argue that cloud-init is in control because it would
> be a large undertaking to switch all of the AMI's on Amazon to something
> else. However, I know Sean disagrees with me on this point so I'll let him
> reply here.


Here's my take:

Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API
in both the Neutron and Nova projects should all the details of the
Metadata API that is documented at:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

This means that this is a compatibility layer that OpenStack has
implemented so that users can use appliances, applications, and
operating system images in both Amazon EC2 and an OpenStack environment.

Yes, we can make changes to cloud-init. However, there is no guarantee
that all users of the Metadata API are exclusively using cloud-init as
their client. It is highly unlikely that people are rolling their own
Metadata API clients, but it's a contract we've made with users. This
includes transport level details like the IP address that the service
listens on. 

The Metadata API is an established API that Amazon introduced years ago,
and we shouldn't be "improving" APIs that we don't control. If Amazon
were to introduce IPv6 support the Metadata API tomorrow, we would
naturally implement it exactly the way they implemented it in EC2. We'd
honor the contract that Amazon made with its users, in our Metadata API,
since it is a compatibility layer.

However, since they haven't defined transport level details of the
Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a
solution. It is not our API.

The nice thing about config-drive is that we've created a new mechanism
for bootstrapping instances - by replacing the transport level details
of the API. Rather than being a link-local address that instances access
over HTTP, it's a device that guests can mount and read. The actual
contents of the drive may have a similar schema as the Metadata API, but
I think at this point we've made enough of a differentiation between the
EC2 Metadata API and config-drive that I believe the contents of the
actual drive that the instance mounts can be changed without breaking
user expectations - since config-drive was developed by the OpenStack
community. The point being that we call it "config-drive" in
conversation and our docs. Users understand that config-drive is a
different feature.

I've had this same conversation about the Security Group API that we
have. We've named it the same thing as the Amazon API, but then went and
made all the fields different, inexplicably. Thankfully, it's just the
names of the fields, rather than being huge conceptual changes.

http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html

Basically, I believe that OpenStack should create APIs that are
community driven and owned, and that we should only emulate
non-community APIs where appropriate, and explicitly state that we only
are emulating them. Putting improvements in APIs that came from
somewhere else, instead of creating new OpenStack branded APIs is a lost
opportunity to differentiate OpenStack from other projects, as well as
Amazon AWS.

Thanks for reading, and have a great holiday.

-- 
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] 9/4 state of the gate

2015-09-05 Thread Joe Gordon 
On Fri, Sep 4, 2015 at 6:43 PM, Matt Riedemann 
wrote:

>
>
> On 9/4/2015 3:13 PM, Matt Riedemann wrote:
>
>> There are a few things blowing up in the last 24 hours so might as well
>> make people aware.
>>
>> 1. gate-tempest-dsvm-large-ops was failing at a decent rate:
>>
>> https://bugs.launchpad.net/nova/+bug/1491949
>>
>> Turns out devstack was changed to run multihost=true and that doesn't
>> work so well with the large-ops job that's creating hundreds of fake
>> instances on a single node.  We reverted the devstack change so things
>> should be good there now.
>>
>>
>> 2. gate-tempest-dsvm-cells was regressed because nova has an in-tree
>> blacklist regex of tests that don't work with cells and renaming some of
>> those in tempest broke the regex.
>>
>> https://bugs.launchpad.net/nova/+bug/1492255
>>
>> There is a patch in the gate but it's getting bounced on #3.  Long-term
>> we want to bring that blacklist regex down to 0 and instead use feature
>> toggles in Tempest for the cells job, we just aren't there yet.  Help
>> wanted...
>>
>>
>> 3. gate-tempest-dsvm-full-ceph is broken with glance-store 0.9.0:
>>
>> https://bugs.launchpad.net/glance-store/+bug/1492432
>>
>> It looks like the gate-tempest-dsvm-full-ceph-src-glance_store job was
>> not actually testing trunk glance_store code because of a problem in the
>> upper-constraints.txt file in the requirements repo - pip was capping
>> glance_store at 0.8.0 in the src job so we actually haven't been testing
>> latest glance-store.  dhellmann posted a fix:
>>
>> https://review.openstack.org/#/c/220648/
>>
>> But I'm assuming glance-store 0.9.0 is still busted. I've posted a
>> change which I think might be related:
>>
>> https://review.openstack.org/#/c/220646/
>>
>> If ^ fixes the issue we'll need to blacklist 0.9.0 from
>> global-requirements.
>>
>> --
>>
>> As always, it's fun to hit this stuff right before the weekend,
>> especially a long US holiday weekend. :)
>>
>>
> I haven't seen the elastic-recheck bot comment on any changes in awhile
> either so I'm wondering if that's not running.
>

Looks like there was a suspicious 4 day gap in elastic-recheck, but it
appears to be running again?

$ ./lastcomment.py
Checking name: Elastic Recheck
[0] 2015-09-06 01:12:40 (0:35:54 old) https://review.openstack.org/220386
'Reject the cell name include '!', '.' and '@' for Nova API'
[1] 2015-09-02 00:54:54 (4 days, 0:53:40 old)
https://review.openstack.org/218781 'Remove the unnecassary
volume_api.get(context, volume_id)'


>
> Also, here is another new(ish) gate bug I'm just seeing tonight (bumped a
> fix for #3 above):
>
> https://bugs.launchpad.net/keystonemiddleware/+bug/1492508
>
>
> --
>
> 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

Re: [openstack-dev] [Neutron] Port forwarding

2015-09-05 Thread Gal Sagie 
Hi Germy,

I am not sure i understand what you mean, can you please explain it
further?

Thanks
Gal.

On Sun, Sep 6, 2015 at 5:39 AM, Germy Lure  wrote:

> Hi, Gal
>
> Thank you for bringing this up. But I have some suggestions for the API.
>
> An operator or some other component wants to reach several VMs related NOT
> only one or one by one. Here, RELATED means that the VMs are in one subnet
> or network or a host(similar to reaching dockers on a host).
>
> Via the API you mentioned, user must ssh one VM and update even delete and
> add PF to ssh another. To a VPC(with 20 subnets?) admin, it's totally a
> nightmare.
>
> Germy
>
>
> On Wed, Sep 2, 2015 at 1:59 PM, Gal Sagie  wrote:
>
>> Hello All,
>>
>> I have searched and found many past efforts to implement port forwarding
>> in Neutron.
>> I have found two incomplete blueprints [1], [2] and an abandoned patch
>> [3].
>>
>> There is even a project in Stackforge [4], [5] that claims
>> to implement this, but the L3 parts in it seems older then current master.
>>
>> I have recently came across this requirement for various use cases, one
>> of them is
>> providing feature compliance with Docker port-mapping feature (for
>> Kuryr), and saving floating
>> IP's space.
>> There has been many discussions in the past that require this feature, so
>> i assume
>> there is a demand to make this formal, just a small examples [6], [7],
>> [8], [9]
>>
>> The idea in a nutshell is to support port forwarding (TCP/UDP ports) on
>> the external router
>> leg from the public network to internal ports, so user can use one
>> Floating IP (the external
>> gateway router interface IP) and reach different internal ports depending
>> on the port numbers.
>> This should happen on the network node (and can also be leveraged for
>> security reasons).
>>
>> I think that the POC implementation in the Stackforge project shows that
>> this needs to be
>> implemented inside the L3 parts of the current reference implementation,
>> it will be hard
>> to maintain something like that in an external repository.
>> (I also think that the API/DB extensions should be close to the current
>> L3 reference
>> implementation)
>>
>> I would like to renew the efforts on this feature and propose a RFE and a
>> spec for this to the
>> next release, any comments/ideas/thoughts are welcome.
>> And of course if any of the people interested or any of the people that
>> worked on this before
>> want to join the effort, you are more then welcome to join and comment.
>>
>> Thanks
>> Gal.
>>
>> [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
>> [2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding
>> [3] https://review.openstack.org/#/c/60512/
>> [4] https://github.com/stackforge/networking-portforwarding
>> [5] https://review.openstack.org/#/q/port+forwarding,n,z
>>
>> [6]
>> https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
>> [7] http://www.gossamer-threads.com/lists/openstack/dev/34307
>> [8]
>> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
>> [9]
>> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html
>>
>>
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Best Regards ,

The G.
__
OpenStack Development Mailing 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] FFE Request for Reseller

2015-09-05 Thread Steve Martinelli 

I suspect we'll vote on this topic during the next meeting on Tuesday, but
this seems like a huge amount of code to land.

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Henrique Truta 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2015/09/04 12:12 PM
Subject:[openstack-dev] [keystone] FFE Request for Reseller



Hi Folks,



As you may know, the Reseller Blueprint was proposed and approved in Kilo (
https://review.openstack.org/#/c/139824/) with the developing postponed to
Liberty.

During this time, the 3 main patches of the chain were split into 8,
becoming smaller and easier to review. The first 2 of them were merged
before liberty-3 freeze, and some of the others have already received +2s.
The code is very mature, having a keystone core member support through the
whole release cycle.



I would like to request an FFE for the remaining 9 patches (reseller core)
which are already in review (starting from
https://review.openstack.org/#/c/213448/ to
https://review.openstack.org/#/c/161854/).



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


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

Re: [openstack-dev] [magnum]keystone version

2015-09-05 Thread Steve Martinelli 
+1, we're trying to deprecate the v2 API as soon as is sanely possible.
Plus, there's no reason to not use v3 since you can achieve everything you
could in v2, plus more goodness.

Thanks,

Steve Martinelli
OpenStack Keystone Core



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

Date:   2015/09/06 12:48 AM
Subject:Re: [openstack-dev] [magnum]keystone version



Keystone v2 will soon be deprecated. It makes sense for Magnum to use v3.

--
Adrian

On Sep 5, 2015, at 6:57 PM, 王华  wrote:

  any comments on this?

  On Fri, Sep 4, 2015 at 9:43 AM, 王华 
  wrote:
Hi all,

Now the keystoneclient in magnum only support keystone v3. Is is
necessary to support keystone v2? Keystone v2 don't support trust.

Regards,
Wanghua

  __

  OpenStack Development Mailing 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] [nova][i18n] Is there any point in using _() inpython-novaclient?

2015-09-05 Thread Steve Martinelli 

Isn't this just a matter of setting up novaclient for translation? IIRC
using _() is harmless if there's no translation bits set up for the
project.

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Matt Riedemann 
To: "OpenStack Development Mailing List (not for usage questions)"
,
openstack-i...@lists.openstack.org
Date:   2015/09/04 01:50 PM
Subject:[openstack-dev] [nova][i18n] Is there any point in using _() in
python-novaclient?



I noticed this today:

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

And it got me thinking about something I've wondered before - why do we
even use _() in python-novaclient?  It doesn't have any .po files for
babel message translation, it has no babel config, there is nothing in
setup.cfg about extracting messages and compiling them into .mo's, there
is nothing on Transifex for python-novaclient, etc.

Is there a way to change your locale and get translated output in nova
CLIs?  I didn't find anything in docs from a quick google search.

Comparing to python-openstackclient, that does have a babel config and
some locale po files in tree, at least for de and zh_TW.

So if this doesn't work in python-novaclient, do we need any of the i18n
code in there?  It doesn't really hurt, but it seems pointless to push
changes for it or try to keep user-facing messages in mind in the code.

--

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

Re: [openstack-dev] [Glance] Feature Freeze Exception proposal

2015-09-05 Thread Bhandaru, Malini K 
Thank you Nikhil and Glance team on the FFE consideration.
We are committed to making the revisions per suggestion and separately seek 
help from the Flavio, Sabari, and Harsh.
Regards
Malini, Kent, and Jakub 


-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: Friday, September 04, 2015 9:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception proposal

Hi Malini et.al.,

We had a sync up earlier today on this topic and a few items were discussed 
including new comments on the spec and existing code proposal.
You can find the logs of the conversation here [1].

There are 3 main outcomes of the discussion:
1. We hope to get a commitment on the feature (spec and the code) that the 
comments would be addressed and code would be ready by Sept 18th; after which 
the RC1 is planned to be cut [2]. Our hope is that the spec is merged way 
before and implementation to the very least is ready if not merged. The 
comments on the spec and merge proposal are currently implementation details 
specific so we were positive on this front.
2. The decision to grant FFE will be on Tuesday Sept 8th after the spec has 
newer patch sets with major concerns addressed.
3. We cannot commit to granting a backport to this feature so, we ask the 
implementors to consider using the plug-ability and modularity of the taskflow 
library. You may consult developers who have already worked on adopting this 
library in Glance (Flavio, Sabari and Harsh). Deployers can then use those 
scripts and put them back in their Liberty deployments even if it's not in the 
standard tarball.

Please let me know if you have more questions.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2015-09-04.log.html#t2015-09-04T14:29:47
[2] https://wiki.openstack.org/wiki/Liberty_Release_Schedule

On 9/3/15 1:13 PM, Bhandaru, Malini K wrote:
> Thank you Nikhil and Brian!
>
> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
> Sent: Thursday, September 03, 2015 9:42 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
> proposal
>
> We agreed to hold off on granting it a FFE until tomorrow.
>
> There's a sync up meeting on this topic tomorrow, Friday Sept 4th at
> 14:30 UTC ( #openstack-glance ). Please be there to voice your opinion and 
> cast your vote.
>
> On 9/3/15 9:15 AM, Brian Rosmaita wrote:
>> I added an agenda item for this for today's Glance meeting:
>>https://etherpad.openstack.org/p/glance-team-meeting-agenda
>>
>> I'd prefer to hold my vote until after the meeting.
>>
>> cheers,
>> brian
>>
>>
>> On 9/3/15, 6:14 AM, "Kuvaja, Erno"  wrote:
>>
>>> Malini, all,
>>>
>>> My current opinion is -1 for FFE based on the concerns in the spec 
>>> and implementation.
>>>
>>> I'm more than happy to realign my stand after we have updated spec 
>>> and a) it's agreed to be the approach as of now and b) we can 
>>> evaluate how much work the implementation needs to meet with the revisited 
>>> spec.
>>>
>>> If we end up to the unfortunate situation that this functionality 
>>> does not merge in time for Liberty, I'm confident that this is one 
>>> of the first things in Mitaka. I really don't think there is too 
>>> much to go, we just might run out of time.
>>>
>>> Thanks for your patience and endless effort to get this done.
>>>
>>> Best,
>>> Erno
>>>
 -Original Message-
 From: Bhandaru, Malini K [mailto:malini.k.bhand...@intel.com]
 Sent: Thursday, September 03, 2015 10:10 AM
 To: Flavio Percoco; OpenStack Development Mailing List (not for 
 usage
 questions)
 Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
 proposal

 Flavio, first thing in the morning Kent will upload a new BP that 
 addresses the comments. We would very much appreciate a +1 on the 
 FFE.

 Regards
 Malini



 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: Thursday, September 03, 2015 1:52 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
 proposal

 On 02/09/15 22:11 -0400, Nikhil Komawar wrote:
> Hi,
>
> I wanted to propose 'Single disk image OVA import' [1] feature 
> proposal for exception. This looks like a decently safe proposal 
> that should be able to adjust in the extended time period of 
> Liberty. It has been discussed at the Vancouver summit during a 
> work session and the proposal has been trimmed down as per the 
> suggestions then; has been overall accepted by those present 
> during the discussions (barring a few changes needed on the spec itself).
> It being a addition to already existing import task, doesn't 
> involve API change or change to any of the core