User namespace as you would expect it to work. (Container Isolation)
does not work yet. User Namespace can be used with docker-1.10, but
only for protecting the host from the container. All containers would
run with the same "DockerRoot".
We are working on the ability to run each container
Hi,
On Wed, 18-May-2016 07:10, Clayton Coleman wrote:
> It was a deliberate choice, predicated on other changes coming to
> Docker (user namespaces) plus the desire to ensure demos run.
>
> Ultimately, the CDK is a playground. Putting up chain link fences
> around the playground sends the wrong
Mostly that it's still experimental, will probably be enabled but not
considered "secure" in OpenShift 3.3 on Docker 1.10, and we're still
working to add the right controls and get soak time so that by the
time we get to Docker 1.12/1.13 we can say "it's actually secure".
On Wed, May 18, 2016 at
Opened https://github.com/openshift/origin/pull/8929 to make:
oc debug dc/thing_that_works_in_cdk --as-user=1
possible, which should catch 90% of real user problems.
On Wed, May 18, 2016 at 10:46 AM, Clayton Coleman wrote:
> Ideally a build would continue into
Ideally a build would continue into deployment, but there are some
challenges. We definitely need to brainstorm and implement better guide
rails around this in the near term.
On May 18, 2016, at 10:33 AM, Burr Sutter wrote:
On Wed, May 18, 2016 at 10:14 AM, Clayton Coleman
On Wed, May 18, 2016 at 10:14 AM, Clayton Coleman
wrote:
> start build has no idea what your destination runtime environment is,
> unfortunately.
>
Interesting...from an end-user perspective, it causes a "redeployment" but
I guess that is Openshift picking up the image
Actually I was thinking we need the warning on "oc start-build" since that
is how we are primarily re-deploying to OpenShift for Helloworld MSA.
On Wed, May 18, 2016 at 9:46 AM, Clayton Coleman
wrote:
> Yes, this is an openshift problem (really, it's container platform,
>
On Wed, May 18, 2016 at 8:34 AM, Aaron Weitekamp
wrote:
> On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote:
>
>>
>>
>> On 05/18/2016 07:18 AM, Aslak Knutsen wrote:
>> > I think most teams at the Brno F2F were struggling with this. It works
>> locally,
- Original Message -
| From: "Clayton Coleman"
| To: "Dusty Mabe"
| Cc: devto...@redhat.com, "Aslak Knutsen" ,
"container-tools"
| Sent: Wednesday, May 18, 2016 6:04:05 PM
| Subject: Re:
On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe wrote:
>
>
> On 05/18/2016 07:18 AM, Aslak Knutsen wrote:
> > I think most teams at the Brno F2F were struggling with this. It works
> locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH
> engineers there,
It's surprising to you because you know that there *should* be
protections and then try to reduce them. For the vast majority of
users, there is no surprise, because they have no expectation.
Explaining that expectation, helping users transition, and educating
them via example is something we
This is a usecase "oc debug" was designed to solve.
1. Set your app up normally (as root)
2. Get it working
3. Run "oc debug dc/foo --as-user=xxx"
4. See that it works or not
I'll add that flag, although it will be a while before it makes it into an
origin release.
On May 18, 2016, at 7:55 AM,
An index.openshift.org with proper images similar to 'index.docker.org'
would be a start :)
On Wed, May 18, 2016 at 1:31 PM, Max Rydahl Andersen
wrote:
> Yeah, if CDK was running with this enabled I would not be able to run
> anything
> in any meaningful timeframe on
Yeah, if CDK was running with this enabled I would not be able to run
anything
in any meaningful timeframe on openshift.
I wish there was a better way though.
i.e. that I could set a flag for a specific deployment wether
it should be allowed to run as root or not without making this a fully
14 matches
Mail list logo