date:20160201

Re: [openstack-dev] [Magnum] New Core Reviewers

2016-02-01 Thread Vilobh Meshram

+1 from me for both.

On Mon, Feb 1, 2016 at 10:00 AM, Gal Sagie  wrote:

> Not part of Magnum team, but Egor is a great help for Kuryr as well and is
> a great addition in my eyes
>
> On Mon, Feb 1, 2016 at 7:00 PM, Davanum Srinivas 
> wrote:
>
>> +1 from me!
>>
>> On Mon, Feb 1, 2016 at 9:58 AM, Adrian Otto 
>> wrote:
>> > Magnum Core Team,
>> >
>> > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core
>> Reviewers. Please respond with your votes.
>> >
>> > Thanks,
>> >
>> > Adrian Otto
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>
>
__
OpenStack Development Mailing 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] [Cinder] the spec of Add-ServiceGroup-using-Tooz

2016-02-01 Thread Michał Dulko

On 01/31/2016 10:43 PM, dong.wenj...@zte.com.cn wrote:
>
> Hi all,
>
> I proposed the spec of Add-ServiceGroup-using-Tooz in Ciner[1].
>
> Project doctor[2] in OPNFV community is its upstream.
> The goal of this project is to build fault management and
> maintenance framework for high availability of Network Services on top
> of virtualized infrastructure.
> The key feature is immediate notification of unavailability of
> virtualized resources from VIM, to process recovery of VNFs on them.
>
> But in Cinder, the service reports it's status with a delay. So I
> proposed adding Tooz as cinder ServiceGroup driver to report the
> service states without a dely.
>
> I'm a new in Cinder. :) So I wants to invite some Cinder exports
> to discuss the spec in the doctor's weekly meeting at 14:00 on Tuesday
> this week. Is anyone interested in it? Thanks~
>
> [1]https://review.openstack.org/#/c/258968/
> [2]https://wiki.opnfv.org/doctor
>

So basically doctor wants to know state of Cinder services as soon as
possible, right? Why use cinder to inform of its own services then? What
if cinder-api service is down?

If your use case is monitoring of services state, then what prevents you
from using some external monitoring tools for that purpose? Or even a
combination of both external monitoring tool and Cinder service-group API?

__
OpenStack Development Mailing 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] Announcing Ekko -- Scalable block-based backup for OpenStack

2016-02-01 Thread Preston L. Bannister

Hi Fausto,

To be clear, I am not in any way critical of Freezer and the folk putting
in work. (Please, I want to be *entirely* clear on this point! Also, saw
your presentation in Vancouver.)

That said, Freezer is a bit of a Swiss-Army-Knife set of combined backup
functions. Sometimes it is better to focus on a single aspect (or few). The
new features landing in QEMU present an opportunity. A project focused
solely on that opportunity, to work through initial set of issues, makes a
lot of sense to me. (Something like how KVM forked QEMU for a time, to
build faster x86 emulation.)

I do not see these as competing projects, and more as cooperative. The Ekko
work should be able to plug into Freezer, cleanly.

Aspects of the problem, as I see:

   1. Extracting efficient instance backups from OpenStack (via new QEMU
   function).
   2. Storing backups in efficient form (general implementation, and
   vendor-specific supersets).
   3. Offering an OpenStack backup-service API, with core and
   vendor-specific extensions.


Vendors (like my employer, EMC) might be somewhat opinionated about (2),
and for reason. :)

The huge missing piece is (1), and a focused project seems to make a lot of
sense.

As to (3), that looks like a good topic for further discussion. :)


My $.02.




On Sat, Jan 30, 2016 at 5:36 PM, Fausto Marzi 
wrote:

> Hi Preston,
> No need to apologize. They are aspect of the same problem.
> However, VMs backup is one of the many aspects that we are approaching
> here, such as:
>
> - VM backups
> - Volumes backups
> - Specific applications consistent data backup (i.e. MySQL, Mongo, file
> system, etc)
> - Provide capabilities to restore data even if keystone and swift are not
> available
> - Upload data during backup to multiple media storage in parallel
> - Web Interface
> - Provide capability to synchronize backups for sharded data on multiple
> nodes
> - Encryption
> - File based incremental
> - Block based incremental
> - Tenant related data backup and restore
> - Multi platform OS support (i.e. Linux, BSD, OSX, Windows, iOS, Android,
> etc)
> - Everything is upstreamed.
>
> This looks like a list of features... and actually it is.
>
> Block based and some multi platform OS aside, all the mentioned features
> are provided to the date. Most of them are available since Kilo.
>
> I agree with the multi API, room for vendors and to provide different
> approaches, but please let me say something (*not referring specifically
> to you or Sam or anyone*)
>
> All the time people say you have to do this and that, but the facts are
> that at the end of the day, always the same 6 engineers (not even full
> time) are working on it since 2 years, investing professional and personal
> time on it.
>
> We try to be open, to accept everybody (even the most arrogant), to
> implement features for whoever needs it, but the facts are that the only
> Companies that invested on it are HP, a bit Ericsson and Orange (apologize
> if I forgot anyone). We never said no to anyone about anything, never
> focused only to a single Company influence, never blocked a thing... and
> never will.
>
> Wouldn't be better to join efforts if companies need a backup solution and
> have their own requirements implemented by a common public Team, rather
> then start creating many tools to solve the same set of problems? How can
> ever competition benefit this? How can ever fragmenting projects help to
> provide a better solution?
>
> I'm sorry, but unless the TC or many people from the Community, tell us to
> do something different (in that case we'll do it straight away), we'll keep
> doing what we are doing, focusing on delivering what we think is the most
> advanced solution, according the resources and time we have.
>
> We need to understand that here the most important thing is to work in
> Team, to provide great tools to the Community, rather then thinking to be
> PTL or maintain independence just for the sake of it or focusing only on
> what's the best for a single Company. If this vision is not shared, then,
> unfortunately, good luck competing, while if the vision is shared... let's
> do together unprecedented things.
>
> Many thanks,
> Fausto
>
>
> On Sun, Jan 31, 2016 at 1:01 AM, Preston L. Bannister <
> pres...@bannister.us> wrote:
>
>> Seems to me there are three threads here.
>>
>> The Freezer folk were given a task, and did the best possible to support
>> backup given what OpenStack allowed. To date, OpenStack is simply not very
>> good at supporting backup as a service. (Apologies to the Freezer folk if I
>> misinterpreted.)
>>
>> The patches (finally) landing in QEMU in support of incremental backup
>> could be the basis for efficient backup services in OpenStack. This is all
>> fairly high risk, in the short term. The bits that landed in QEMU 2.4 may
>> not be sufficient (there are more QEMU patches trying to land). When put
>> into production, we may find faults. For use in OpenStack, we may

[openstack-dev] [nova][virt] rebuild action not in support-matrix

2016-02-01 Thread Chen CH Ji

 Hi   We have been trying to enablement of our CI work for our nova virt layer code ,so we need to configure the tempest cases based on our nova driver capability  I found that rebuild action is not listed in [1] (only talk about rebuild in evacuate), but code [2] seems support virt layer abstraction   can someone point the rebuild action in [1] or it's missing on purpose ? Thanks[1]http://docs.openstack.org/developer/nova/support-matrix.html[2]https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2920


__
OpenStack Development Mailing 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][API]what's the purpose of fping in nova API?

2016-02-01 Thread Chen CH Ji

ok, a potential work for N release, thanks-Sean Dague  wrote: -To: openstack-dev@lists.openstack.orgFrom: Sean Dague Date: 02/01/2016 11:07AMSubject: Re: [openstack-dev] [nova][API]what's the purpose of fping in nova API?On 01/29/2016 09:18 AM, Chen CH Ji wrote:> In doing some API work on> http://developer.openstack.org/api-ref-compute-v2.1.html> noticed that fping was [1] and try to ping the instance to check whether> it's pingable or not..> but this is running on API service host which mostly have no access to> instance with private IP?> Just curious about it ...> > > [1]> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/fping.py#L53fping is probably an API we should deprecate, as you've seen, it'shighly foulable and requires a network topology that people may not have.-Sean-- Sean Daguehttp://dague.net__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[attachment "signature.asc" removed by Chen CH Ji/China/IBM]


__
OpenStack Development Mailing 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] Recent integration tests failures

2016-02-01 Thread Richard Jones

Ugh, dependencies with breaking API changes in minor point releases :/

On 2 February 2016 at 04:53, Timur Sufiev  wrote:

> Maintainers of outside dependencies continue to break our stuff :(. New
> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
> currently being checked by Jenkins
>
> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev  wrote:
>
>> Problematic Selenium versions have been successfully excluded from
>> Horizon test-requirements, if you still experiencing the error described
>> above, rebase your patch onto the latest master.
>> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
>> wrote:
>>
>>> Can confirm, had the same issue locally, was fixed after a downgrade to
>>> selenium 2.48.
>>>
>>>
>>> Good catch!
>>>
>>> Itxaka
>>>
>>> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
>>> > According to the results at
>>> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
>>> > greater than 2.49 fixes broken tests. Patch to global-requirements is
>>> > here: https://review.openstack.org/#/c/273750/
>>> >
>>> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev >> > > wrote:
>>> >
>>> > Hello, Horizoneers
>>> >
>>> > You may have noticed recent integration tests failures seemingly
>>> > unrelated to you patches, with a stacktrace like:
>>> > http://paste2.org/2Hk9138U I've already filed a bug for that,
>>> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
>>> > Selenium issue, currently investigating it.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][nova][cinder][horizon] Projects acting as a domain at the top of the project hierarchy

2016-02-01 Thread Michał Dulko

On 01/30/2016 07:02 PM, Henry Nash wrote:
> Hi
>
> One of the things the keystone team was planning to merge ahead of 
> milestone-3 of Mitaka, was “projects acting as a domain”. Up until now, 
> domains in keystone have been stored totally separately from projects, even 
> though all projects must be owned by a domain (even tenants created via the 
> keystone v2 APIs will be owned by a domain, in this case the ‘default’ 
> domain). All projects in a project hierarchy are always owned by the same 
> domain. Keystone supports a number of duplicate concepts (e.g. domain 
> assignments, domain tokens) similar to their project equivalents.
>
> 
>
> I’ve got a couple of questions about the impact of the above:
>
> 1) I already know that if we do exactly as described above, the cinder gets 
> confused with how it does quotas today - since suddenly there is a new parent 
> to what it thought was a top level project (and the permission rules it 
> encodes requires the caller to be cloud admin, or admin of the root project 
> of a hierarchy).

These problems are there because our nested quotas code is really buggy
right now. Once Keystone merges a fix allowing non-admin users to fetch
his own project hierarchy - we should be able to fix it.

> 2) I’m not sure of the state of nova quotas - and whether it would suffer a 
> similar problem?

As far as I know Nova haven't had merged nested quotas code and will not
do that in Mitaka due to feature freeze.

> 3) Will Horizon get confused by this at all?
>
> Depending on the answers to the above, we can go in a couple of directions. 
> The cinder issues looks easy to fix (having had a quick look at the code) - 
> and if that was the only issue, then that may be fine. If we think there may 
> be problems in multiple services, we could, for Mitaka, still create the 
> projects acting as domains, but not set the parent_id of the current top 
> level projects to point at the new project acting as a domain - that way 
> those projects acting as domains remain isolated from the hierarchy for now 
> (and essentially invisible to any calling service). Then as part of Newton we 
> can provide patches to those services that need changing, and then wire up 
> the projects acting as a domain to their children.
>
> Interested in feedback to the questions above.

__
OpenStack Development Mailing 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] [Cinder] Nominating Patrick East to Cinder Core

2016-02-01 Thread Mike Perez

On 01:04 Jan 30, Sean McGinnis wrote:
> Patrick has been a strong contributor to Cinder over the last few releases,
> both with great code submissions and useful reviews. He also participates
> regularly on IRC helping answer questions and providing valuable feedback.
> 
> I would like to add Patrick to the core reviewers for Cinder. Per our
> governance process [1], existing core reviewers please respond with any
> feedback within the next five days. Unless there are no objections, I will
> add Patrick to the group by February 3rd.

+1 good job Patrick!

-- 
Mike Perez

__
OpenStack Development Mailing 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] Kuryr-Magnm integration spec

2016-02-01 Thread Hongbin Lu

Hi Magnum team,

FYI, you might interest to review the Magnum integration spec from Kuryr team: 
https://review.openstack.org/#/c/269039/

Best regards,
Hongbin

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: January-31-16 2:57 AM
To: OpenStack Development Mailing List (not for usage questions); Antoni Segura 
Puimedon; Kyle Mestery; Irena Berezovsky; Taku Fukushima; Mohammad Banikazemi; 
Fawad Khaliq; Vikas Choudhary; Eran Gampel; Adrian Otto; Daneyon Hansen
Subject: [openstack-dev] [Kuryr] IRC Meeting - Monday (2/1) 1500 UTC 
(#openstack-meeting-4)


Hello All,

We are going to have an IRC Meeting tomorrow (2/1) at 1500 UTC
in #openstack-meeting-4

The meeting agenda can be seen here [1].
We are going to focus most of the meeting on the Kubernetes-Kuryr integration.
You can view the logs from our specific Kuryr-Kubernetes integration IRC 
meeting [2]

Please come with some modeling ideas, i think this topic will take most of the 
time.

I would also like us to discuss about Fawad spec about Magnum-Kuryr 
integration. [3]
and nested containers support.

I have CCed Adrian/Danyeon from the Magnum team here, hopefully you guys
can provide some feedback as well.

Thanks and see you there!
Gal.

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2] 
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html
[3] https://review.openstack.org/#/c/269039/3

__
OpenStack Development Mailing 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] [ironic] weekly subteam status report

2016-02-01 Thread Ruby Loo

Hi,


We are elated to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

- Stats (diff with 25.01.2016):

- Ironic: 151 bugs (-1) + 171 wishlist items (+7). 14 new (-1), 111 in
progress (+3), 0 critical, 19 high (-1) and 9 incomplete

- Inspector: 14 bugs + 17 wishlist items. 0 new, 10 in progress (+1), 0
critical, 6 high and 0 incomplete

- Nova bugs with Ironic tag: 23. 0 new, 0 critical, 0 high

- January summary (diff with 04.01):

- Ironic: bugs +0, wishlist items +22, in progress +12


Network isolation (Neutron/Ironic work) (jroll)

===

- please review :D

- nova patch for portgroups will be delayed until Newton, due to length of
time it will take to land -sigh-

- Garbutt said a client API version bump to make it usable will likely
be okay, but it will also need to wait for client/api patches


RAID (lucasagomes)

==

- still waiting for manual cleaning to land (needs reviews)


Parallel tasks with futurist (dtantsur)

===

- futurist 0.10 released with my changes, we should be good to continue as
soon as we get our gate back :)


Node filter API and claims endpoint (jroll, devananda, lucasagomes)

===

- no update; deprioritized in favor of neutron work, manual cleaning

- (rloo, could you leave this note until it changes? :) sure :D


Testing/Quality (jlvillal/lekha/krtaylor)

=

- krtaylor sent out reminder about 3rd Party CI for M-2

- having trouble getting drivers paired up with test systems listed
(krtaylor)

- https://wiki.openstack.org/wiki/ThirdPartySystems - please make sure
your system account is created and registered here

-  https://etherpad.openstack.org/p/IronicCI - list the link from the
above wiki here

- jlvillal continues to work on Grenade testing. Investigating if we need
to have 3 bare- metal VMs to run tempest and do we have enough memory to do
that.


Inspector (dtansur)

===

- Our gates use IPA by default now (except for -dib check job on inspector
itself)


webclient (krotscheck / betherly)

=

- plugin wrapper almost merged upstream

- panel being separated out into sections for upstreaming into the plugin

- node details showing locally and being tested now


.


Until next week,

--ruby
__
OpenStack Development Mailing 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] Google Sumer of Code 2016 - Call for ideas and mentors (deadline 19/02/2016)

2016-02-01 Thread Victoria Martínez de la Cruz

Hi all,

Google Summer of Code (GSoC) is a program that matches mentoring
organizations with college and university student developers who are paid
to write open source code. It has been around 2005 and we had been accepted
as a mentor organization in only one opportunity (2014) having a great
outcome for both interns and for our community. We expect to be able to
join this year again, but for that, we will need your help.

Mentors

We need to submit our application as a mentoring organization, but for
that, we need to have a clear outline of what different projects we have
for interns to work on.

*** The deadline for mentoring organizations applications is 19/02/2016. ***

If you are interested in mentoring but you have doubts about it, please
feel free to reach us here or on #openstack-gsoc. We will be happy to reply
any doubt you may have about mentoring for this internship. Also, you can
check out this guide [0].

If you are already convinced that you want to join us as a mentor for this
round, add your name in the OpenStack Google Summer of Code 2016 wiki page
[1] and add your project ideas in [2]. Make sure you leave your contact
information in the OpenStack GSoC 2016 wiki and that you add all the
important details about the project idea. Also reach us if there is
something you are not certain about.

Interns

Whereas we don't know yet if we are going to make it as a mentoring
organization for this round, if you want to join us as an intern and you
want to help OpenStack to get selected as a mentoring organization, you can
help us proposing different tasks for the various projects we have in our
ecosystem.

For your inspiration, you can check out past projects in [3] and [4].

Looking forward to see GSoC happening again in our community!

Thanks,

Victoria

[0] http://en.flossmanuals.net/gsocmentoring/
[1] https://wiki.openstack.org/wiki/GSoC2016
[2] https://wiki.openstack.org/wiki/Internship_ideas
[3] https://wiki.openstack.org/wiki/GSoC2014
[4] https://wiki.openstack.org/wiki/GSoC2015
__
OpenStack Development Mailing 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] Announcing Ekko -- Scalable block-based backup for OpenStack

2016-02-01 Thread Fausto Marzi

Hi Preston,
Thank you. You saw Fabrizio in Vancouver, I'm Fausto, but it's allright, : P

The challenge is interesting. If we want to build a dedicated backup API
service (which is always what we wanted to do), probably we need to:


   - Place out of Nova and Cinder the backup features, as it wouldn't make
   much sense to me to have a Backup service and also have backups managed
   independently by Nova and Cinder.


That said, I'm not a big fan of the following:

   - Interacting with the hypervisors and the volumes directly without
   passing through the Nova and Cinder API.
   - Adding any additional workload on the compute nodes or block storage
   nodes.
   - Computing incremental, compression, encryption is expensive. Have many
   simultaneous process doing that may lead  to bad behaviours on core
   services.


Some open questions:

   - Are we going to implement in Nova and Cinder, the features we need
   from the hypervisor for the backups i.e.:
  - http://wiki.qemu.org/Features/Snapshots2
  - http://wiki.qemu.org/Features/Livebackup


   - Are we going to talk directly with the hypervisors without passing
   through the services API?
   - Are we going to provide a backup service using the feature from Nova
   and Cinder API currently implemented, and improve it over time as long as
   more related advanced features are available?
   - No other service touch directly volumes and hypervisors for reasons.
   We would need to make a diamond case to get an exception for backups.
   - There's any requirement from vendors and any of them will allocate
   resources to make a backup service, as a Team?


My (flexible) thoughts are:

   - The feature is needed and is brilliant.
   - We should probably implement the newest feature provided by the
   hypervisor in Nova and export them from the Nova API.
   - Create a plugin that is integrated with Freezer to leverage that new
   features.
   - Same apply for Cinder.
   - The VMs and Volumes backup feature is already available by Nova,
   Cinder and Freezer. It needs to be improved for sure a lot, but do we need
   to create a new project for a feature that needs to be improved, rather
   than work with the existing Teams?
   - No one wants to block others, Sam proposed solution is indeed
   remarkable, but this is OpenStack, we work in Teams, why we cannot do that
   and be less fragmented.


Thanks,
Fausto


On Mon, Feb 1, 2016 at 9:23 PM, Preston L. Bannister 
wrote:

> Hi Fausto,
>
> To be clear, I am not in any way critical of Freezer and the folk putting
> in work. (Please, I want to be *entirely* clear on this point! Also, saw
> your presentation in Vancouver.)
>
> That said, Freezer is a bit of a Swiss-Army-Knife set of combined backup
> functions. Sometimes it is better to focus on a single aspect (or few). The
> new features landing in QEMU present an opportunity. A project focused
> solely on that opportunity, to work through initial set of issues, makes a
> lot of sense to me. (Something like how KVM forked QEMU for a time, to
> build faster x86 emulation.)
>
> I do not see these as competing projects, and more as cooperative. The
> Ekko work should be able to plug into Freezer, cleanly.
>
> Aspects of the problem, as I see:
>
>1. Extracting efficient instance backups from OpenStack (via new QEMU
>function).
>2. Storing backups in efficient form (general implementation, and
>vendor-specific supersets).
>3. Offering an OpenStack backup-service API, with core and
>vendor-specific extensions.
>
>
> Vendors (like my employer, EMC) might be somewhat opinionated about (2),
> and for reason. :)
>
> The huge missing piece is (1), and a focused project seems to make a lot
> of sense.
>
> As to (3), that looks like a good topic for further discussion. :)
>
>
> My $.02.
>
>
>
>
> On Sat, Jan 30, 2016 at 5:36 PM, Fausto Marzi 
> wrote:
>
>> Hi Preston,
>> No need to apologize. They are aspect of the same problem.
>> However, VMs backup is one of the many aspects that we are approaching
>> here, such as:
>>
>> - VM backups
>> - Volumes backups
>> - Specific applications consistent data backup (i.e. MySQL, Mongo, file
>> system, etc)
>> - Provide capabilities to restore data even if keystone and swift are not
>> available
>> - Upload data during backup to multiple media storage in parallel
>> - Web Interface
>> - Provide capability to synchronize backups for sharded data on multiple
>> nodes
>> - Encryption
>> - File based incremental
>> - Block based incremental
>> - Tenant related data backup and restore
>> - Multi platform OS support (i.e. Linux, BSD, OSX, Windows, iOS, Android,
>> etc)
>> - Everything is upstreamed.
>>
>> This looks like a list of features... and actually it is.
>>
>> Block based and some multi platform OS aside, all the mentioned features
>> are provided to the date. Most of them are available since Kilo.
>>
>> I agree with the multi API, room for vendors and

[openstack-dev] [keystone] Domain Specific Roles vs Local Groups

2016-02-01 Thread Henry Nash

During the recent keystone midcycle, it was suggested than an alternative
domain specific roles (see spec:
https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/domain-specific-roles.rst

and code patches starting at: https://review.openstack.org/#/c/261846/
) might be to somehow re-use the
group concept. This was actually something we had discussed in previous
proposals for this functionality. As I mentioned during the last day, while
this is a seductive approach, it doesn’t actually scale well (or in fact
provide the right abstraction). The best way to illustrate this is with an
example:

Let’s say a customer is being hosted by a cloud provider. The customer has
their own domain containing their own users and groups, to keep them segregated
from other customers. The cloud provider, wanting to attract as many different
types of customer as possible, has created a set of fine-grained global roles
tied to APIs via the policy files. The domain admin of the customer wants to
create a collection of 10 such fine-grained roles that represent some function
that is meaningful to their setup (perhaps it’s job that allows you to monitor
resources and fix a subset of problems).

With domain specific roles (DSR) , the domain admin creates a DSR (which is
just a role with a domain_id attribute), and then adds the 10 global policy
roles required using the implied roles API. They can then assign this DSR to
all the projects they need to, probably as a group assignment (where the groups
could be local, federated or LDAP). One assignment per project is required, so
if there were, over time, 100 projects, then that’s 100 assignments. Further,
if they want to add another global role (maybe to allow access to a new API) to
that DSR, then it’s a single API call to do it.

The proposal to use groups instead would work something like this: We would
support a concept of “local groups” in keystone, that would be independent of
whatever groups the identity backend was mapped to. In order to represent the
DSR, a local group would be created (perhaps with the name of the functional
job members of the group could carry out). User who could carry out this
function would be added to this group (presumably we might also have to support
“remote” groups being members of such local groups, a concept we don’t really
support today, but not too much of a stretch). This group would then need to be
assigned to each project in turn, but for each of the 10 global roles that this
“DSR equivalent” provided in turn (so an immediate increase by a factor of N
API calls, where N is the number of roles per DSR) - so 1000 assignments in our
example. If the domain admin wanted to add a new role to (or remove a role
from) the “DSR”, they would have to do another assignment to each project that
this “DSR” was being used (100 new assignments in our example). Again, I would
suggest, much less convenient.

Given the above, I believe the current DSR proposal does provide the right
abstraction and scalability, and we should continue to review and merge it as
planned. Obviously this is still dependant on Implied Roles (either in its
current form, or a modified version). Alternative code of doing a
one-level-only inference part of DSRs does exist (from an earlier attempt), but
I don’t think we want to do that if we are going to have any kind of implied
roles.

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

1 - 100 of 107 matches

Mail list logo