Re: Protobuf support merged

On Mon, Jul 25, 2016 at 2:22 PM, Andy Goldstein wrote: > > > On Mon, Jul 25, 2016 at 2:15 PM, Clayton Coleman > wrote: > >> Protobuf support has been merged to origin, which has an impact on dev >> workflows. >> >> If you are changing the API, you'll

Protobuf support merged

Protobuf support has been merged to origin, which has an impact on dev workflows. If you are changing the API, you'll need to run hack/update-generated-protobuf.sh to generate the IDL for your changes, and those changes will be checked in. You need protoc 3.0.0-beta1 or newer installed. A

Re: Building oc binary for Windows

You have to build as sudo to compile the std library correctly, *or* install the Windows cross compile rpm package for go (golang-*-windows something) You can also run hack/env hack/build-cross.sh to use the release container build, which has the correct tools already installed On Jul 23, 2016, a

Re: v1.3.0-alpha.3 is coming soon, waiting for a Kube 1.3 performance regression to be fixed

commended upgrade paths between these alpha/beta versions? > I have a test install running alpha.2 > > On Fri, 15 Jul 2016 at 08:59 Clayton Coleman wrote: > >> We intend to cut a new tag for 1.3.0 once the Kube 1.3 pod startup issue >> is fixed (pods in the same nam

v1.3.0-alpha.3 is coming soon, waiting for a Kube 1.3 performance regression to be fixed

We intend to cut a new tag for 1.3.0 once the Kube 1.3 pod startup issue is fixed (pods in the same namespace are serializing on startup). Probably sometime next week. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/

Origin v1.2.1 released

Origin v1.2.1 has been released, containing a security hot fix to the server components to prevent some users from escalating privileges via the API. Releases older than v1.2.0 are not affected, but all v1.2.0 deployments should update. https://github.com/openshift/origin/releases/tag/v1.2.1

Rebase of Origin to Kube 1.3.0 was merged

Be aware that we have moved from Godeps/_workspace/src GOPATH for building to using the vendor/ directory. Builds have been changed to take this into account, but some scripts may be broken if I didn't catch them. There are additional steps required to make Godep restore work now (you'll need to

Re: /etc/localtime

lot more than just logs to consider... as mentioned, > scheduled/cron-type jobs are actually what inspired this question. > > You don't know that the user's timezone will match the server, but it's a > good default guess. > > > On Fri, Jul 8, 2016 at 12:10 PM, Clayton Col

Re: /etc/localtime

on-like > jobs being more readable with an assumed timezone. > > > > *Brandon Richins* > > > > *From: *Clayton Coleman > *Date: *Friday, July 8, 2016 at 8:56 AM > *To: *Luke Meyer > *Cc: *Brandon Richins , dev < > dev@lists.openshift.redhat.com> > *

Re: /etc/localtime

Shouldn't logs be written to UTC and the UI of the caller be used for that? I would expect all the stored data to be normalized correctly when shown. On Jul 8, 2016, at 10:49 AM, Luke Meyer wrote: If you can docker run as shown, sure, you can mount in the appropriate thing for your container di

Re: packaging

The spec file checked in to the repo is the same one that is used to build those RPMs, isn't it? On Jun 29, 2016, at 8:12 AM, Luke Meyer wrote: The origin project itself doesn't maintain spec files. However you might find the Fedora and EPEL source rpms interesting: Fedora - https://kojipkgs.fe

Re: use of third_party directory for libcompose

That's great, we'll help navigate the godep process (it can be tricky). > On Jun 28, 2016, at 9:52 AM, Tomas Kral wrote: > >> On Tue, Jun 28, 2016 at 5:32 PM, Clayton Coleman wrote: >> Mostly because I had to make extensive changes to use it the way we >> need

Re: use of third_party directory for libcompose

Mostly because I had to make extensive changes to use it the way we needed (as a parsing library to get at the structs), and an incompatibility with the yaml library used by Kube. We mostly need it to parse the files and resolve the env bindings. At the time, it was the easiest way to make progre

Re: OpenShift Origin v1.3.0-alpha.2 has been released

last few weeks as it was brought into git as a submodule; perhaps an older script version was used in those releases? There haven't been actual changes to the image, it just needs the tag. On Wed, Jun 22, 2016 at 10:42 PM, Clayton Coleman wrote: > The release notes are up on GitHub

OpenShift Origin v1.3.0-alpha.2 has been released

The release notes are up on GitHub https://github.com/openshift/origin/releases/tag/v1.3.0-alpha.2 along with binaries. Improvements to the console UI have been the primary focus. Please report any issues you encounter! ___ dev mailing list dev@lists.op

Re: Commit ID during build

s not currently a way to access it, unfortunately. On Tue, Jun 21, 2016 at 7:25 PM, Clayton Coleman wrote: > It is not, however it's very reasonable to want. > > On Tue, Jun 21, 2016 at 7:01 PM, Mateus Caruccio > wrote: > > Hi. > > > > Is it possible to re

Re: Commit ID during build

It is not, however it's very reasonable to want. On Tue, Jun 21, 2016 at 7:01 PM, Mateus Caruccio wrote: > Hi. > > Is it possible to read the git commit id from repo during source build? > > -- > Mateus Caruccio / Master of Puppets > GetupCloud.com - Eliminamos a Gravidade > > ___

Re: building rpm packages to build rpm-ostree-based containers

The registry is an interesting question. We've had a lot of discussion about other types of registries (mostly Artifactory and Nexus) and those are multi-content type registries that can also store RPMs, as well as docker images. I'm not opposed to an RPM registry, but a first class integration w

Re: Request for a new generic release image tag on Docker hub

What you describe sounds very reasonable - I don't think building clusters off latest should ever be a default. On Thu, Jun 16, 2016 at 3:37 PM, Devan Goodwin wrote: > On Thu, Jun 16, 2016 at 4:07 PM, Clayton Coleman wrote: >>> On Jun 16, 2016, at 3:01 PM, Devan Goodwin wrote

Re: Using openshift Go client library from outside

The client suffers from many of the same limitations of the Kube client. As part of the 1.3 work we're actively working on versioned clients that would be much easier to consume from outside of Kube/OpenShift. See Michal's PR here https://github.com/openshift/origin/pull/9372 On Thu, Jun 16, 201

Re: Request for a new generic release image tag on Docker hub

> On Jun 16, 2016, at 3:01 PM, Devan Goodwin wrote: > >> On Thu, Jun 16, 2016 at 3:48 PM, Clayton Coleman wrote: >> Generally we always pin tags to the previous version (so that we know >> exactly what we'd get). If we tagged them as v1.3.0, when we pushed &g

Re: Request for a new generic release image tag on Docker hub

prevent us from being able to guarantee the right update is delivered. On Thu, Jun 16, 2016 at 2:09 PM, Devan Goodwin wrote: > On Thu, Jun 16, 2016 at 3:01 PM, Clayton Coleman wrote: >> Can you explain #2 in more detail (why you want to be using 1.3.0 >> image tags, which you shoul

Re: Request for a new generic release image tag on Docker hub

Can you explain #2 in more detail (why you want to be using 1.3.0 image tags, which you shouldn't be doing) On Thu, Jun 16, 2016 at 1:42 PM, Devan Goodwin wrote: > If I may add another request and summarize: > > (1) Add an additional v1.2 tag pointing to the latest released 1.2.x > image. Doing t

Please participate in the Kubernetes sig-apps app builder survey

As part of trying to define use cases and ensure we cover requirements for many different kinds of applications on Kubernetes and OpenShift, the Kubernetes app SIG (sig-apps) is going to do a survey of how people are looking to build applications on top of Kubernetes. So not just web apps and dbs,

Re: Upcoming image related features

Yes, for now you can only import 1.9 pushed images when using docker 1.9 On Jun 11, 2016, at 6:45 PM, Philippe Lafoucrière < philippe.lafoucri...@tech-angels.com> wrote: Sadly, it's not working for me :( I'm running into this: http://stackoverflow.com/questions/37709594/api-error-500-manifest-un

Re: Upcoming image related features

Looks like the docs page has not been added yet. It's described a bit in `oc tag --help` On Sat, Jun 11, 2016 at 5:07 PM, Philippe Lafoucrière wrote: > > On Sat, Jun 11, 2016 at 5:05 PM, Clayton Coleman > wrote: >> >> It was delivered and merged, I believe

Re: Upcoming image related features

It was delivered and merged, I believe before 1.1.6. On Sat, Jun 11, 2016 at 4:17 PM, Philippe Lafoucrière wrote: > > On Mon, Jan 18, 2016 at 12:06 AM, Clayton Coleman > wrote: >> >> ## Automatically import images on a scheduled basis >> >> This feature lets y

Re: Starting container fails with system error

There is a PR open to backport it to 1.9 https://github.com/projectatomic/docker/pull/168 On Thu, Jun 9, 2016 at 12:32 AM, Andrew Lau wrote: > Hi, > > Has anyone hit this issue where a pod is not able to start after it's been > successfully built: > > Starting container fails with "System error:

Re: Some s2i builds failing with "manifest unknown", also support for Origin for Docker versions

Also note that CI is failing due to this until the new reverted images are built. Will send an email when the queue is unblocked. On Wed, Jun 8, 2016 at 12:30 PM, Clayton Coleman wrote: > Users may have noticed a brief window between yesterday and today > where builds of our S2I based

Some s2i builds failing with "manifest unknown", also support for Origin for Docker versions

Users may have noticed a brief window between yesterday and today where builds of our S2I based images began to fail with "manifest unknown" if you were using Docker 1.9 and had pulled the latest images. We started building S2I images with Docker 1.10 and are now in the process of reverting. This

Re: "manifest unknown" test flakes

Graham's issue appears to be similar. On Wed, Jun 8, 2016 at 9:43 AM, Clayton Coleman wrote: > There is a flake issue open in origin > > On Jun 8, 2016, at 9:42 AM, Steve Kuznetsov wrote: > > Do we have an issue or BZ open to track this? > > On Wed, Jun 8, 2016 at

Re: "manifest unknown" test flakes

v AMI and it had docker 1.9. And FWIW it doesn't look like > Fedora 23 has shipped 1.10 yet either. > > On Tue, Jun 7, 2016 at 11:07 PM, Clayton Coleman > wrote: > >> Yes, but you do not need v2 metadata. >> >> I just saw this flake again on a PR. We need to

Re: "manifest unknown" test flakes

understand it correctly. Steve On Jun 7, 2016 10:27 PM, "Ben Parees" wrote: > > > On Tue, Jun 7, 2016 at 9:48 PM, Clayton Coleman > wrote: > >> We are building and pushing our images with Docker 1.10 for Origin (but >> possibly not in all AMIs, depending on the

Re: "manifest unknown" test flakes

We are building and pushing our images with Docker 1.10 for Origin (but possibly not in all AMIs, depending on the test job). The last set of pushed images (alpha.1) was pushed from Docker 1.9. This might just be docker flaking, but we'd probably need more info from the Docker logs. On Tue, Jun

Re: S3 docker registry performance

In general, S3 should be as efficient for the registry than EBS, and far more operationally easy (it also scales out horizontally). I don't know whether the encrypt option is done on the registry side - have you compared running with or without? It's currently fairly difficult to move between bac

Re: setting kubelet --allow-privileged ?

Nodes come preconfigured with allow-privileged because SCC already protects the cluster. > On Jun 3, 2016, at 6:56 PM, Alan Jones wrote: > > Friends, > I had a privileged container running under under an OpenShift 3.2 master with > a sock k8s kubelet. > To get that to work, I added the security

Re: OpenShift Origin v1.2.0 released, along with the development drop of v1.3.0-alpha.1

Is it just the ipfailover image that you see impacted? On May 29, 2016, at 11:26 AM, Philippe Lafoucrière < philippe.lafoucri...@tech-angels.com> wrote: FYI, v1.3.0-alpha.1 installation is broken: https://github.com/openshift/origin/issues/9077​ ___ de

OpenShift Origin v1.2.0 released, along with the development drop of v1.3.0-alpha.1

We've cut the final v1.2.0 release and published it to the DockerHub - see https://github.com/openshift/origin/releases/tag/v1.2.0 for the release notes. A few security issues were encountered that we recommend upgrading. Development towards OpenShift Origin 1.3 (which will be based on top of Kub

Re: Support for Kubernetes metadata when using docker --log-driver=journald?

Or per node, rather. On Fri, May 20, 2016 at 12:47 PM, Clayton Coleman wrote: > Per cluster. > > On Fri, May 20, 2016 at 12:46 PM, Rich Megginson wrote: >> On 05/20/2016 10:39 AM, Clayton Coleman wrote: >>> >>> Actually, there may be an issue for this already.

Re: Support for Kubernetes metadata when using docker --log-driver=journald?

Per cluster. On Fri, May 20, 2016 at 12:46 PM, Rich Megginson wrote: > On 05/20/2016 10:39 AM, Clayton Coleman wrote: >> >> Actually, there may be an issue for this already. >> https://github.com/kubernetes/kubernetes/issues/15478 > > > I created a new issue:

Re: Support for Kubernetes metadata when using docker --log-driver=journald?

We could support setting that on the Kubelet when we launch the containers. I think it's reasonable - if you open a Kube issue Derek and I can chime in. On Fri, May 20, 2016 at 12:12 PM, Rich Megginson wrote: > When using OpenShift with the standard docker log driver, there are > container logs

Re: Support for Kubernetes metadata when using docker --log-driver=journald?

Actually, there may be an issue for this already. https://github.com/kubernetes/kubernetes/issues/15478 On Fri, May 20, 2016 at 12:38 PM, Clayton Coleman wrote: > We could support setting that on the Kubelet when we launch the > containers. I think it's reasonable - if you open a

Re: readiness probes and clustered discovery

We have the basic support for this today - endpoints also contain unready IPs. We are adding two constructs that will enable easy access - a DNS entry that returns all endpoints, no matter whether they are ready or not, and an annotation on a service that instructs the endpoints list to contain ev

Re: How to specify ImageStream as a source for container

> starts from image " " and fails again. You will be stuck in this loop > and never get it deployed this way! At least I did not. > > >> On Út, 2016-05-17 at 10:56 -0400, Clayton Coleman wrote: >> There is a work going on to ensure that you don't get a failure for

Re: 'oc cluster up' command

For now you'll need to build your own binary or download it from the Jenkins nightly, at least until we release 1.3.0-alpha.1 On May 17, 2016, at 8:48 PM, Cesar Wong wrote: PR #7675 introduces a new command 'oc cluster up' that allows you to start

Re: How to specify ImageStream as a source for container

)*)*\"\n" > > Failed to pull image " ": API error (500): repository name component > must match "[a-z0-9](?:-*[a-z0-9])*(?:[._][a-z0-9](?:-*[a-z0-9])*)*" > --- > > Is there some proper solution? > > On Út, 2016-05-17 at 10:04 -0400, Clayton Coleman

Re: How to specify ImageStream as a source for container

Set image to " " On Tue, May 17, 2016 at 9:54 AM, Tomas Nozicka wrote: > I am not able to specify ImageStream as source of what my container is > run from in my DeploymentConfig. I can only specify image there [1] but > not ImageStream. But when I setup triggers for DeploymentConfig I can > speci

Improvements to custom deployments

PR https://github.com/openshift/origin/pull/8787 added some improvements that make running your own custom deployments even easier than before. Custom deployments previously allowed you to provide your own image to handle the deployment logic, but it required you to duplicate a lot of the code in

Re: New experimental feature: import application from Docker Compose

https://github.com/openshift/origin/pull/8871 squashes a few bugs and supports the core schema 2. Separate volumes would be a nice to add thing, although will probably wait until we move to libcompose for that. On Thu, May 12, 2016 at 9:05 AM, Clayton Coleman wrote: > We decode the compo

Re: New experimental feature: import application from Docker Compose

We decode the compose1 format, have not yet added compose2 On Thu, May 12, 2016 at 4:43 AM, Tomas Tomecek wrote: > Quoting Clayton Coleman (2016-05-10 18:14:46) >> PR https://github.com/openshift/origin/pull/7690 introduces a new >> command in 'oc' to convert a Docker

New experimental feature: import application from Docker Compose

PR https://github.com/openshift/origin/pull/7690 introduces a new command in 'oc' to convert a Docker Compose application to a Kubernetes+OpenShift application (including build and deployment pipelines, so you have a reproducible app). This is currently experimental, and we'd love to get feedback

Re: Is 1.2 out?

We're just waiting for any final reports of issues to cut a 1.2.0 release. For 1.3 we will be moving to be more like Kubernetes, where features will be considered .alpha. and we will be releasing 1.3.0-alpha.0, 1.3.0-alpha.1, etc. On Tue, May 3, 2016 at 7:00 PM, Diego Spinola Castro wrote: > Hel

Help needed testing new docker build functionality

As part of looking to support faster and more flexibility image building under kubernetes, we've been prototyping a Docker compatible builder that is not innately tied to the Docker daemon in Origin (which would allow us to run a docker build inside a container launched by Kube). The utility code

Re: Excluding replacement pods from quota?

Or set maxUnavailable to 100% in your rolling deployment config. On Mon, May 2, 2016 at 10:59 AM, Luke Meyer wrote: > Use the Recreate deploy strategy rather than Rolling. > https://docs.openshift.org/latest/dev_guide/deployments.html#recreate-strategy > > On Sat, Apr 30, 2016 at 10:24 PM, Andrew

Merge queue for master is open

We're back to normal merge processes. Please note that API changes still require approval (you can ask @openshift/api-review and you can merge when you get api-approved label). Thanks for everyone's patience, and for the folks who have helped get the CI flakes knocked out. Remember, flakes are a

Origin v1.2.0-rc2 released

The second release candidate for 1.2.0 has been pushed to GitHub https://github.com/openshift/origin/releases/tag/v1.2.0-rc2 and to DockerHub ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Merge queue for post 1.2.x is still closed - BUT ...

For 1.2.x, master will reopen soon. The process is: 1. We'll cut for 1.2.0-rc2. 2. I'll cut a 1.3.0-alpha0 3. We'll merge a selected set of critical PRs (specifically, those related to the rebase and test flakes) 4. We'll open master for normal [merge] rights I'll send out an email after 3 has b

Origin extended test suite passed!

https://ci.openshift.redhat.com/jenkins/job/origin_extended/830/ is green, for the first time in a while :) Thanks to everyone over the last few months who chipped away at flakes, improved the e2e suite (over 150 new tests), and introduced / improved / hacked on new suites. Over the 1.3 release I

Re: OpenShift Origin v1.2.0-rc1

Working on a fix. On Fri, Apr 22, 2016 at 1:39 PM, Clayton Coleman wrote: > Yes, let me repro. > > On Apr 22, 2016, at 1:26 PM, Gabe Montero wrote: > > Would this be an example of such an issue: > > E0422 13:18:25.7715051184 manager.go:1858] Failed to create

Re: OpenShift Origin v1.2.0-rc1

mands. If I should open an issue, let me know whatever debug / info would be of use. thanks, gabe On Thu, Apr 21, 2016 at 6:17 PM, Clayton Coleman wrote: > The first release candidate for 1.2.0 has been pushed to GitHub > https://github.com/openshift/origin/releases/tag/v1.2.0-rc1 >

OpenShift Origin v1.2.0-rc1

The first release candidate for 1.2.0 has been pushed to GitHub https://github.com/openshift/origin/releases/tag/v1.2.0-rc1 Because this is the first official release we've done using a semantic version tag, it's possible that some images / code may break trying to pull "v1.2.0-rc1". If you encou

Re: Extended tests are now part of the test queue for Origin

b, though. > > On Wed, Apr 6, 2016 at 6:56 PM, Clayton Coleman wrote: >> The test job for Origin now runs a subset of extended tests in a third >> worker whenever you add [test] (it'll be the third job when you click >> through to Jenkins). The job won't block

Re: Project limits

The docs here: https://docs.openshift.org/latest/admin_guide/managing_projects.html#limit-projects-per-user Cover that. > On Apr 13, 2016, at 7:17 PM, Andrew Lau wrote: > > Hi, > > There seems to be documentation on project quotas and disabling self > provisioning, however is there a facility

Changes to test_pr_origin CI job and the [testonlyextended]

As you may have noticed, the test_pr_origin CI job on ci.openshift.redhat.com (which answers [test]) has now been split into three sub jobs: https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/ - test_pull_requests_origin_check - the unit and verification tests (equivalent to `make check`)

Re: Extended tests are now part of the test queue for Origin

Hopefully soon, still verifying we have all the changes we need. On Wed, Apr 6, 2016 at 10:31 PM, Ari LiVigni wrote: > Clayton when will these tests make it into OSE? > > On Wed, Apr 6, 2016 at 10:22 PM, Tim St. Clair wrote: >> >> HURRAY >> >> On Wed, Apr 6,

Re: Extended tests are now part of the test queue for Origin

the overall number of flakes, clicking through for every test would be a pain. On Wed, Apr 6, 2016 at 9:56 PM, Clayton Coleman wrote: > The test job for Origin now runs a subset of extended tests in a third > worker whenever you add [test] (it'll be the third job when you click > throug

Extended tests are now part of the test queue for Origin

The test job for Origin now runs a subset of extended tests in a third worker whenever you add [test] (it'll be the third job when you click through to Jenkins). The job won't block merge (yet) but please don't merge if there are failures. The tests that are run are a subset of the full extended

CI test-pull-requests-origin is being changed to enable e2e, you can ignore the JUnit publisher errors

Only the test is marked as failed. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

v1.1.6 released (this is v1.2.0-rc1)

Images have been pushed and GitHub has been updated https://github.com/openshift/origin/releases/tag/v1.1.6 ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Set UID/GID to the azure mount command

27;t get other ownership than default >> (uid,gid) underneath the mount point. >> As the root is mounting, so it owns the files, pods can write because >> file_mode and dir_mode are 0777 >> >> 2016-04-04 11:45 GMT-03:00 Clayton Coleman : >>> >>> At the m

Re: Set UID/GID to the azure mount command

At the mount point, or anywhere underneath the mount point? On Mon, Apr 4, 2016 at 9:39 AM, Diego Spinola Castro wrote: > Azure file plugin doesn't support Unix Permissions, so a pod can't manage > file ownership at a mountpoint. This is a issue for PostgreSQL images, which > complains if don't

Re: ImageStream loses tags when exported

Sounds like a bug, please file an issue with your scenario. We may not have correctly set export behavior for image streams. > On Mar 30, 2016, at 5:22 AM, Tomáš Nožička wrote: > > Hi, > > I am working on o2n and I am experiencing problem exporting and > importing ImageStreams. When I export Bui

Approvals required for merge to origin/master as we close out 1.2

Since we're getting into the final stretches of 1.2, we're now in approval mode for changes to be merged into master. Only high priority defects approved by leads / component owners should get the [merge] tag. Quick reminder: 1. Prioritize p0 and p1 changes over p2 and p3 - component leads use y

Release v1.1.5 has a serious bug preventing PVC use by normal users - a fix will be released soon as v1.1.6

In 1.1.5 regular users are no longer able to use PVCs due to an SCC constraint. You can relax the SCC constraint by editing your SCCs to set the `volumes` field with `*`. This allows users to continue to use PVCs. The bug is https://github.com/openshift/origin/issues/8297 Please hold off on upg

Origin updated to v1.1.5

Release notes are here https://github.com/openshift/origin/releases/tag/v1.1.5 Note that v1.1.5 resolves an issue with Docker 1.9.1-23 and cgroups and is a recommended upgrade for all users. ___ dev mailing list dev@lists.openshift.redhat.com http://lis

Re: oc export

jects were >> created by >> > user and >> > > what objects were generated by OpenShift? >> > > Can annotations that I have mentioned be used for this? >> > > >> > > > It is >> > > > dangerously presumptive that there's on

Re: Set https (tls) as default route

...` would default to tls if I knew the > right knob to turn. > > I looked up the `oc create route edge` command. That’s great. I think I’ll > use that. It appears to work against the OSE 3.1.1 too. > > Thanks for the tip. > > Brandon Richins > > > > > O

Re: Set https (tls) as default route

Hrm - the default termination *should* be edge if the router has been configured with a default certificate and you don't specify a destination CA cert. What version of the server are you running against? 'oc create route' is the new mechanism for creating routes where the parameters matter - you

origin_extended CI job on Jenkins is temporarily only running the core.sh suite

While we debug issues with the other suites. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Cgroup limits on builds are being temporarily disabled to allow the merge queue to proceed while we debug

https://github.com/openshift/origin/issues/7549 and https://github.com/openshift/origin/pull/8196 This should unblock the merge queue. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: oc export

>> > >> > This is deliberate simplification to make things little easier >> for us. >> > We are exporting whole project, because right now I don't have >> any idea >> > how we are going to decide what is

Merge queue experiencing high volume of flakes due to a Docker race

We're working on a resolution, but for now you will just have to retry your merges. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: --volumes-from

t use (an) empty volume(s) to which I would have to copy > these files upon startup. > > On Mon, Mar 21, 2016 at 10:12 PM, Clayton Coleman > wrote: >> >> The EmptyDir volume type handles that - you create a volume in your >> pod template and then specify where it sho

Re: --volumes-from

The EmptyDir volume type handles that - you create a volume in your pod template and then specify where it should be mounted into each container. The "oc volume" command can help add and remove volumes (see the examples) from deployment configs or replication controllers. > On Mar 21, 2016, at 10

Changes to Origin build for Go 1.6

Due to the removal of code in golint and govet that supported Go 1.4, we are in the process of transitioning the Origin build pipeline to Go 1.6. The first set of changes updates openshift/origin-release to use Go 1.6 to build release binaries. test-pull-request in CI will only use that for the e

Re: oc export

#x27;kubernetes.io/created-by: ...' >> >> Can we rely on those annotations to decide what to export and what to >> leave behind? Is this documented somewhere? >> >> >> >> >> On 03/14/2016 04:48 PM, Clayton Coleman wrote: >> > Export is a

v1.1.4 released

The latest release is up on GitHub at https://github.com/openshift/origin/releases/tag/v1.1.4 ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: oc export

Export is a lower level tool that does not *exactly* export an entire application, but rather tries to give you the tools to build it. I would suggest instead of running "oc export all", you try "oc export dc,svc,route,is". "all" includes pods, replication controllers, build configs, and builds,

Re: Hosting MySQL images in OpenShift Origin

There are several ways to accomplish external routing. 1. Expose your pod network directly to the rest of your infrastructure (make 10.0.X.X routable from other places) 2. Use a service that is of type NodePort and connect to the node(s) on the port you receive directly (if you need HA, you'll wan

Re: `oc project` as opposed to kubectl namespaces

Yes, but it's coupled to a few other discussions like changing/splitting/merging the config file, how to deal with multiple clusters, how to deal with login, etc. Maybe not for 1.3 but later. And you can always use oc against a Kube cluster (and if not, file bugs( > On Mar 1, 2016, at 11:35 AM, D

Re: Pod/docker logs limits

No, that's probably docker rolling over your logs (or fluentd, if you have that configured). You *can* specify limits via the logs command (oc logs -h) but they aren't applied by default. On Thu, Feb 25, 2016 at 2:13 PM, Mateus Caruccio wrote: > Hi. > > There any limits of lines/btyes for pod lo

Now that https://github.com/openshift/origin/pull/7015 has merged...

Do not add the description tag to any new API fields. All descriptions should follow the upstream conventions as Godoc on public API fields, i.e.: // Protocol for port. Must be UDP or TCP. // Defaults to "TCP". Protocol Protocol `json:"protocol,omitempty"` Note that the Godoc for api

Router command is updated to be more flexible

As a cluster administrator, you should no longer have to provide any arguments to creating a router. Simply invoke `oc adm router` or `oadm router` as a cluster administrator and a new router should be created with the proper permissions (you'll be prompted to grant access if you don't have it).

Router image v1.1.3 updated due to a backwards incompatible change.

Thanks to @wenskys for reporting https://github.com/openshift/origin/issues/7452 - in v1.1.3 the router began writing status for routes (when the route was accepted, or an error message if a duplicate route exists) which required the system:router role to have permission to update routes. However,

Back, by popular demand, building from an isolated GOPATH!

PR https://github.com/openshift/origin/pull/7477 allows you to define OS_OUTPUT_GOPATH=1 and get the old hack/build-go.sh behavior. Builds will not use this for now, but you can set it to have the same old flow. ___ dev mailing list dev@lists.openshift.

Anyone having problems with pkgs being rebuilt in GOPATH/pkg after the recent build changes ...

https://github.com/golang/go/issues/10509 was a bug in Go 1.4 - if you are building OpenShift, run a checkout to another branch, and then get package errors, you're getting this. You can upgrade to Go 1.5 (and thus get slow builds) or stay on 1.4 and remember to clean $GOPATH/pkg when changing bra

Re: Router: Readiness probe failed - connection refused

this content. (3 times in the last 20 seconds) On Wed, Feb 17, 2016 at 3:58 PM, Clayton Coleman wrote: > The readiness and liveness probes don't support authentication - the > health check, even if stats are enabled, should not require authorization. > > On Wed, Feb 17, 2016 at 3:1

Re: Router: Readiness probe failed - connection refused

The readiness and liveness probes don't support authentication - the health check, even if stats are enabled, should not require authorization. On Wed, Feb 17, 2016 at 3:16 PM, Rishi Misra wrote: > Thanks Ram - I was able to get around it using by removing Liveness and > Readiness probe entries

v1.1.3 released

https://github.com/openshift/origin/releases/tag/v1.1.3 contains another feature and bug fix as we approach Origin v1.2.0. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Changes to how hack/build-go.sh uses GOPATH

> I was getting an error about k8s deps which has changed upstream :/ > > Cleaning GOPATH/pkg helped, but that's way too problematic imho to > remember doing this with every make. > > Maciej > > >> On Mon, Feb 15, 2016 at 6:22 PM, Clayton Coleman >> wrote: &g

<    1   2   3   4   >