[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>
> 
> > > 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.
> 
> It *is* a more complex implementation, but it doesn't *have* to look more
> complex to the developer user. If they just want to use domains for
> everything, then fine - just attach everything to domain tags you get for
> free. But when they start complaining about needing a separate Jenkins app
> for each domain then we have an answer for how to reuse one Jenkins app.

Today app->domain->user is an ownership relationship, and there is some overlap with who has access to something and the ownership.  Every app requires a namespace to exist before it can be created as well, which I think complicates apps being in multiple domains.  Ownership of an app transfer should be a conscious choice between two users (user A to user B), vs being something magically implicit.  When thinking about what a domain does, up till now we've called it a "generic container for apps".  The namespace is useful, but not critical to the functioning of the apps in the container.  Any sort of app interconnection that depends on the domain (today Jenkins, and there are arguments that that mapping isn't perfect) is a reason for a domain to exist independent of other concerns.  A tag flow might have advantages, but it is going to be a separate concept that will need its own explanations to users which increases the complexity of both experience and implementation. 

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