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

Re: Some thoughts on shared access to applications



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.

----- 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]