[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Some thoughts on shared access to applications




----- Original Message -----
> I can think of at least three reasons why people may want to group apps.
> 
> 1. Access control - I want to collaborate with group X on this set of apps,
> but not another.
> 2. Grouping layers of a composed app, allowing them to use each other as
> resources while possibly scaling separately - for instance, a messaging
> layer, an API layer, a UI layer that are all separate apps.
> 3. Access to / specification of shared resources; a Jenkins app is a good
> example, but also external DB definitions or other resources.
> 
> Not trying to list everything here, but it shouldn't be hard to see that the
> different purposes are likely to be orthogonal, and it would probably be bad
> to use the domain as the scope for all of them. What is a domain really,
> anyway? Right now it's nothing but a device for keeping app names unique on
> the cloud domain. Does it need to be anything more than that? It seems to me
> that group membership for other purposes should be more of a tagging system.

Elaborate?  Define tagging?

> 
> ----- Original Message -----
> From: "Clayton Coleman" <ccoleman redhat com>
> To: "meghdoot bhattacharya" <meghdoot_b yahoo com>
> Cc: dev lists openshift redhat com
> Sent: Monday, July 8, 2013 5:15:45 PM
> Subject: Re: Some thoughts on shared access to applications
> 
> One of the biggest challenges, as we move from the single-domain per account
> model, is to adapt how we think about domain-wide concepts like Jenkins
> today.  The simple path we've started on is a domain-wide application.
> E.g.:
> 
>   I have a domain A
>   When I add Jenkins in A, all other applications have access to it
>   Jenkins contributes "domain" environment variables that all other apps have
>   access to.
>   Once Jenkins exists, I can add the jenkins client cart to other apps in A
>   The Jenkins client cart uses the domain wide environment variable to check
>   whether it's installable
>   If Jenkins is removed, it removes the jenkis client cart from other apps in
>   A
> 
> If we start to use domains to scope sets of users, how does Jenkins react?  I
> personally would be frustrated having to have one Jenkins per domain,
> because Jenkins either costs me money or provisioning space (Online vs
> Enterprise).  Hypothetically, what sorts of changes are required to support
> concepts like a shared Jenkins across domains:
> 
>   Each user may have different access to different domains
>   - adding the Jenkins Client and pointing it to a Jenkins server domain B
>   may mean that some users in domain A can't see the server
>   - the info the client needs is from variables (url, user, and password) so
>   the broker access is redundant
> 
>   The Jenkins server needs to know which Jenkins clients are connected to it
>   so it can disable the client carts if it's removed
>   - because that could be every domain in the server, we'd need to track the
>   "connection" between the server and client differently
>  
>   The Jenkins client won't have access to the domain wide environment
>   variables
>   - instead, the Jenkins client needs to be able to get access to the info
>   about the jenkins server on install
>   - the broker could pass it, but then the broker has to know about specifics
>   of environment variables
>   - The env var would have to be removed on deletion
> 
> Thinking through the problem, it seems like what we would be trying to do is
> register a "connection" between a jenkins server and client.  The server
> needs to expose a set of arbitrary info that the client must consume.  That
> connection seems to be very similar to cartridge hooks, just between apps.
> One possible approach might be to allow client cartridges to indicate they
> have an external dependency that must be satisfied (app with component X) on
> creation, and then allow the client and server to expose an "external"
> connection hook that the broker could resolve prior to creation.
> 
> For example:
> 
>   1) User attempts to add jenkins-client to an app
>   2) Broker sees that jenkins-client declares a "jenkins-server" dependency
>   that is cross-application
>   3) Broker looks in the domain for an app that can satisfy that component
>   dependency
>      a) if it finds multiple, or none, the user will have to specify the
>      appropriate app
>      b) when adding a cart, user would have to tell the REST API what app
>      should satisfy the dependency, including any app they have access to
>      c) some thought must be given to backwards compatibility with clients
>   4) The broker checks for an external subscribe connection hook on the
>   client cart and attempts to match that to an external publish hook in the
>   server cart
>   5) If it succeeds, it runs the server publish hook, then includes that
>   output on the cartridge creation (or triggers the hook as part of config)
>   6) Cart configure succeeds or fails based on whether the input from #5 is
>   acceptable, broker reports that back
> 
> Obviously speculative, and is not the first problem we would go solve... but
> there are some interesting parallels there to app<->app connection hooks and
> how we would track and manage that.
> 
> ----- Original Message -----
> > Much needed and highly anticipated feature. Not only for practical
> > considerations where different groups: dev, release engineers, 24X7 Ops
> > would want to operate on the same application for different aspects of
> > management, the simplest case during feature development where a dev asks
> > the teammate to debug an app in their gear independently can be easily
> > supported without the need of sharing explicitly ssh keys and rhc tokens.
> > Something like multiple domains per User can be used to have isolated mesh
> > of
> > interconnected apps/topology.
> > Personally from my view point I like the role classification described.
> > Thx
> > 
> > 
> > 
> > From: "dev-request lists openshift redhat com"
> > <dev-request lists openshift redhat com>
> > To: dev lists openshift redhat com
> > Sent: Saturday, July 6, 2013 9:00 AM
> > Subject: dev Digest, Vol 16, Issue 23
> > 
> > Send dev mailing list submissions to
> > dev lists openshift redhat com
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> > or, via email, send a message with subject or body 'help' to
> > dev-request lists openshift redhat com
> > 
> > You can reach the person managing the list at
> > dev-owner lists openshift redhat com
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of dev digest..."
> > 
> > 
> > Today's Topics:
> > 
> > 1. Some thoughts on shared access to applications (Clayton Coleman)
> > 2. Munin plugins for OpenShift (Tim Bielawa)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Fri, 5 Jul 2013 16:27:48 -0400 (EDT)
> > From: Clayton Coleman < ccoleman redhat com >
> > To: Openshift Dev < dev lists openshift redhat com >
> > Subject: Some thoughts on shared access to applications
> > Message-ID:
> > < 2128282006 24947482 1373056068712 JavaMail root redhat com >
> > Content-Type: text/plain; charset=utf-8
> > 
> > There's been discussion recently about how multiple users could access an
> > individual application. There have been various comments on it over time -
> > I
> > wanted to summarize the latest thinking and start a discussion about the
> > various features/behavior.
> > 
> > Current model:
> > 
> > A CloudUser *owns* a Domain, which *contains* zero or more Application
> > A Domain is a logical grouping of Applications
> > 
> > Application
> > -> domain (contains)
> > Domain
> > -> owner (owns)
> > CloudUser
> > 
> > Application has SSH keys from its owner (app.domain.owner.ssh_keys)
> > The usage and limitations of the application reflect the capabilities of
> > the
> > owner domain (the ability to upload client certificates, etc)
> > 
> > 
> > Possible changes:
> > 
> > A CloudUser may own many Domains
> > A Domain has one or more Members
> > An Application has one or more Members
> > All Members of a Domain are Members of the contained Applications
> > A Member has a Role within an Application or Domain
> > A Member who has a Role on a Domain, has an equivalent Role on the
> > contained
> > Applications
> > Members have *view* access on the resource and any contained resources
> > Applications receive SSH keys from all Members with sufficient access
> > A CloudUser has *view* rights on CloudUsers on the Domains they are a
> > Member
> > of
> > (i.e. you can only see users you collaborate with)
> > A configuration setting would allow CloudUsers to view all other CloudUsers
> > Otherwise, adding a user would require sharing an Invitation via a unique
> > secret
> > 
> > Possible future additions:
> > 
> > A Team has one or more Members
> > A Team has *access* to one or more Domains
> > A Team has a Role, that is assigned to all Members when they are added to
> > domains
> > A Member may be assigned a more limited Role on a specific application
> > 
> > 
> > Here are some proposed Roles (roles inherit the permissions of lesser
> > roles).
> > Multiple names are suggested as examples
> > 
> > read/view
> > - can view the application or domain in the REST API
> > - no access to viewing environment variables or SSL certificates
> > 
> > control/ops/monitor
> > - can stop/start/restart individual gears or the entire application
> > - can change scale factors
> > - can read and set environment variables
> > - can view and set aliases, including SSL certificates
> > 
> > developer/deployer
> > - can add/remove cartridges
> > - can trigger builds or deployments
> > - can create applications in a domain (and delete apps they created?)
> > 
> > manager/admin
> > - can add/remove users, change roles, delete applications, delete domains
> > 
> > owner
> > - can transfer ownership of a domain
> > 
> > 
> > We've discussed splitting SSH access off into a separate variable - a Gear
> > Role:
> > 
> > none
> > - the Member's SSH keys are not transferred to the gear, and so has no SSH
> > or
> > Git access
> > 
> > edit/write/push/ssh
> > - can SSH to the gear
> > - can push changes to Git
> > 
> > * In the future, it might be nice to have a role in between none and
> > edit/write where the user has only read access to the gear. This is a
> > fairly
> > complex implementation though and needs more thought.
> > 
> > * All owners and admin/managers are implicitly edit/write/push/ssh enabled
> > (since they can change their own roles).
> > 
> > 
> > Some simplifying assumptions we've discussed:
> > 
> > All access to applications is implicit by virtue of Domain membership
> > 
> > - You are granted access to an application by virtue of being a Member of
> > the
> > containing domain
> > - The point of a Domain is to group applications. Since grouped
> > applications
> > often have security interconnections, it's natural to make the assumption
> > that access to one is implicitly granting access to all. Multiple domains
> > can be used to partition applications.
> > - This also simplifies the access control protection on domains - many
> > clients may need to access only a single app, but want to use the existing
> > API to navigate to the app. Backwards compatibility is pretty important
> > here
> > 
> > Team membership would be denormalized to the Applications
> > 
> > - Allows fast read access control patterns for showing a list of
> > applications
> > you have access to and checking membership
> > - Has the possibility to introduce "membership storms" where adding a user
> > to
> > a team triggers jobs on hundreds of applications. Team membership changes
> > might be queued centrally to avoid this
> > - The "team" would also be a member on the app
> > - Denormalization has to be handled cleanly so that removing a user from
> > the
> > domain doesn't remove the Member entry for a user from the team
> > 
> > Any sort of external group integration would map to a Team
> > 
> > - For instance, to map an LDAP group to a Team, you would store a bit of
> > metadata with the Team and then when the user logs in you could do an
> > initial LDAP groups -> team check to provision the user. A background
> > process would manage LDAP removal. Only active OpenShift users would be
> > materialized into the Team (prevents excessive group operations)
> > 
> > Inheritance of roles
> > 
> > - Rather than do complex permission bits, it's conceptually simpler to have
> > a
> > set of nested roles where each level lets you do more things. If we can get
> > the roles right, that makes the modelling and behavior a lot easier to
> > control.
> > - A lot of operations on the app are destructive (i.e. stopping an app
> > means
> > the app is useless). So most of the higher roles are ordered from least to
> > most destructiveness
> > 
> > 
> > Queries that have to be fast:
> > 
> > - List of applications I have access to
> > - List of domains that I have access to
> > - Do I have access to this domain/application?
> > 
> > The most efficient model for those queries is going to be a list of members
> > on each application object, with an index on the nested member ids. We are
> > explicitly assuming high hundreds of users on each application, which means
> > the index selectivity will be high. Also, given that the list of
> > applications may span tens or hundreds of domains, the info needed for
> > generating a REST API response needs to be denormalized from the domain
> > onto
> > the application (probably just domain_namespace).
> > 
> > I'm sure I've left some stuff out - please ask if something fundamental is
> > missing.
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Fri, 05 Jul 2013 17:11:40 -0400
> > From: Tim Bielawa < tbielawa redhat com >
> > To: "Openshift Dev" < dev lists openshift redhat com >
> > Subject: Munin plugins for OpenShift
> > Message-ID: < 87wqp4k8z7 fsf deepfryer rdu redhat com >
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > 
> > I wrote a simple munin plugin for charting gears present/idle on nodes
> > [0]. All the relevant bits are available on GitHub [1].
> > 
> > Does anyone else have any useful plugins written for Munin+OpenShift? I
> > couldn't find any in a standard 5-second Google search for "munin
> > openshift".
> > 
> > Obligatory pretty pictures (fancier ones are in references):
> > 
> > https://raw.github.com/tbielawa/openshift-munin-plugins/master/gears_present.png
> > 
> > https://raw.github.com/tbielawa/openshift-munin-plugins/master/charts/openshift_gears_present-node01.ose-poc.png
> > 
> > 
> > I'd love to collaborate if there's any interest in this beyond what I've
> > done already (pull requests accepted).
> > 
> > 
> > Enjoy!
> > 
> > [0] http://blog.lnx.cx/2013/07/05/a-munin-plugin-for-openshift/
> > [1] https://github.com/tbielawa/openshift-munin-plugins
> > 
> > --
> > Tim Bielawa, Software Engineer/Scribe
> > We are all cloud
> > GCA - Production Control Team (RDU)
> > 919.332.6411 Cell | IRC: tbielawa (#gca)
> > 1BA0 4FAB 4C13 FBA0 A036 4958 AD05 E75E 0333 AE37
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: not available
> > Type: application/pgp-signature
> > Size: 162 bytes
> > Desc: not available
> > URL: <
> > http://lists.openshift.redhat.com/openshift-archives/dev/attachments/20130705/d9b99466/attachment.bin
> > >
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > dev mailing list
> > dev lists openshift redhat com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> > 
> > 
> > End of dev Digest, Vol 16, Issue 23
> > ***********************************
> > 
> > 
> > 
> > _______________________________________________
> > dev mailing list
> > dev lists openshift redhat com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> > 
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]