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

Re: rhc commands targetting individual gears/nodes



Thx.
On the rhc side support for the focused target sooner is desirable. A command that outputs the gear dns endpoints [haproxy gear registry] is also helpful. I think the rest api outputs the gear UUIDs for an app but not the end point. This stops someone manually ssh'ing to haproxy gear to read the registry for end points. One less reason to explicitly ssh.


From: Clayton Coleman <ccoleman redhat com>
To: meghdoot bhattacharya <meghdoot_b yahoo com>
Cc: dev lists openshift redhat com
Sent: Monday, March 4, 2013 2:30 PM
Subject: Re: rhc commands targetting individual gears/nodes

Also one note - we've toyed with the idea of a pull-request for apps, where you say "deploy the same level of code that is on app X to app Y", where app X might be your staging app and app Y might be your production app.  This would then allow the admins to control when the production app is updated without having to access Git directly.  We'd also like to be able to do "start a copy of app Y for development purposes but without the data/ENV vars".  Both of these are somewhat further out because they require a really clear distinction about what deployment means.  Hopefully we'll be able to clarify that over the next few months and get something concrete onto the roadmap.

----- Original Message -----
>
> Thx Clayton. Good to know you guys are also thinking about those.
> Fairly important.
> The whole trust thing is always subjective. Even today developers
> deliver code [without PaaS] and still can do damage but there is a
> super approval process to get direct access to live boxes. And
> though empowering the developers is welcome there are certain doors
> still very difficult to get open. This is unfortunately a reality
> not only in our company but elsewhere [non startup companies]. So,
> some sort of segmentation/balance is needed.
>
> Thx
>
>
>
>
>
>
>
>
> From: Clayton Coleman <ccoleman redhat com>
> To: meghdoot bhattacharya <meghdoot_b yahoo com>
> Cc: dev lists openshift redhat com
> Sent: Monday, March 4, 2013 12:40 PM
> Subject: Re: rhc commands targetting individual gears/nodes
>
>
>
> ----- Original Message -----
> >
> >
> >
> >
> >
> > Hi,
> > Over the years spending my time in application teams, the situation
> > would often arise that a funky behavior is happening only in few
> > instances in a large pool or maybe Ops have configured honeypot to
> > observe behavior in few instances for app troubleshooting.
> >
> >
> > Do we have plans where rhc can be used for targeting individual
> > gear
> > or maybe all gears in a node but not the entire app itself?
>
> Yes, today it's fairly limited.
>
> >
> >
> > I just noticed in Openshift Online [have to try it in origin] that
> > rhc threaddump not supported for scaled apps.
>
> That is correct, it's a limitation that needs to be corrected.
>
> > Does rhc tail aggregate logs from N gear instances. That would be
> > waste.
>
> It does not, it uses the head gear. We would like to make rhc target
> individual gears if a user so chooses.
>
> >
> > It would be nice to have specific targets for these commands to
> > provide more value. Same goes for app start/stop commands also
> > having option to have specific targets.
>
> Start/stop gears has been discussed, but the user case is usually
> that we would start stopped gears. Stopping started gears was
> something that hasn't been brought up before.
>
> >
> >
> > This may open up a question why not ssh into those gears and
> > execute
> > it locally. As I am explaining the power of Openshift to our app
> > teams, the initial consensus though dev has power to push code and
> > execute commands remotely, nobody feels comfortable giving them ssh
> > access to gears [even with selinux protections]. Requiring regular
> > ssh access to LIVE boxes requires very special approval in our
> > current organization.
>
> We have discussed splitting SSH access to gears into 3 levels:
>
> read code
> shell access with read only permissions
> shell access
>
> The caveat here is that certain commands require read access to data
> today (tail, threaddump, snapshot) and that a solution would need to
> be put into place. Also, we haven't really dug into what it would
> mean to have no shell access but the ability to push code, but the
> problem is that code that is pushed can do ANYTHING to the gear, so
> you're not gaining much security by allowing push without shell.
> Remember too that anyone who can get shell access can view
> environment variables, so that's a trust level thing.
>
> >
> >
> > So, the second question is right now anybody having git access
> > means
> > they have access to all gears in a scaled app [the way ssh keys are
> > copied]. It would be nice to separate git operations permission vs
> > access to gears. Is there a way to do it currently?
>
> No way to do it today, but it is in the roadmap.
>
> >
> >
> > Thx
> >
> > _______________________________________________
> > 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]