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

Re: Some thoughts on shared access to applications




----- Original Message -----
> ----- Original Message -----
> 
> > From: "Clayton Coleman" <ccoleman redhat com>
> > To: "Luke Meyer" <lmeyer redhat com>
> > Cc: dev lists openshift redhat com
> > Sent: Tuesday, July 9, 2013 1:36:30 PM
> > Subject: 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?
> 
> Specify each grouping that an app belongs in as a tag on the app. To
> illustrate the point with speculative functionality:
> 
> If you (a developer) want to allow developers on team A to access a set of
> apps, you tag all those apps with "access_group: team_A" and somewhere you
> define who is in team A and what role(s) they get (perhaps this is in LDAP),
> and that is applied to whatever apps you give that tag.
> 
> If you want to compose a set of apps into one meta-app and have them find
> each other according to rules you define, then you tag them as
> "composed_app: app_A" and the broker connects them with the necessary env
> vars (something like domain variables today, with Jenkins as the "build
> layer").
> 
> If you want to specify a set of env vars that will be used by multiple apps
> (say, to access a DB) then you tag all those apps as "resource_group: db_A"
> and something like "rhc set-env db_password=foo --tagged db_A" sets the var
> for all those apps.
> 
> And just in case a domain (as we know it today) actually does correspond to
> something they want to group by (e.g. dev/qa/prod domains with different
> versions of the same apps may correspond with a resource they all use), it
> could be an implicit tag ("rhc set-env foo=bar --tagged domain_A"), or there
> could just be a way to associate all current and future members of a domain
> explicitly with a tag.
> 
> The same app could be in multiple groupings, which is what makes me think of
> tags. So, apps in multiple domains or groupings could use with the same
> Jenkins builder just by tagging it multiple times, but it would still be
> easy to have a separate Jenkins for say dev apps and prod apps.

That just sounds much more complex than "you get to group things in a domain".  Aliases are the vehicle for real app interacitons anyway - the domain name we assign as part of the default app creation code is a convenience, and I wouldn't depend on it in a complex multiapp SOA 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]