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

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

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

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

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

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

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

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

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

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

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: 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: 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: /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: /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

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

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

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

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/

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

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

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

Re: alpha features

They're usually enabled by default. Only certain alpha security features are disabled. On Wed, Jul 27, 2016 at 4:48 PM, Luke Meyer wrote: > How do I turn on alpha features in Origin? E.g. dynamic provisioning, auto > service cert generation... > > ___

OpenShift Origin v1.3.0-alpha.3 released

v1.3.0-alpha.3 is now up on GitHub and the DockerHub, and available via `oc cluster up --version=v1.3.0-alpha.3`. There will likely be one more alpha release in the next week or so before we begin cutting rc candidates. Thanks to e

Re: Router Defaut Timeout

Is this a new variable in 1.3? Can we rename it to be more descriptive? ROUTER_HTTP_REQUEST_TIMEOUT would be more accurate. On Aug 9, 2016, at 4:02 PM, Ram Ranganathan wrote: That default for the haproxy router can be set via an environment variable in your deployment. $ oc env dc/$router_dc_n

Re: few questions on quotas and limits

On Wed, Aug 10, 2016 at 2:26 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: > Need some clarity on quotas and limits > > As a platform team, we want control quotas on cpu and memory and put upper > bounds and same time provide more flexibility to app team to control or > decide wha

Re: few questions on quotas and limits

On Wed, Aug 10, 2016 at 2:41 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: > > > > -- > *Srinivas Kotaru* > > From: "ccole...@redhat.com" > Date: Wednesday, August 10, 2016 at 11:33 AM > To: skotaru > Cc: dev > Subject: Re: few questions on quotas and limits > > > > On Wed, Aug

Re: Openshift and infrastructure as code

To briefly summarize - all Openshift API objects are designed to be "config" - declarative representation of end objects. Just updating an existing object should be enough to transform the actual config. We do have "imperative" style concepts in the APIs - for instance, deployment triggers and bu

Re: Openshift and infrastructure as code

On Tue, Aug 30, 2016 at 7:33 AM, Pieter Nagel wrote: > Thanks all for the helpful feedback. > > On Thu, Aug 25, 2016 at 4:42 PM, Clayton Coleman > wrote: > >> Please provide any feedback about limitations in export that you can - we >> intend "create, twea

Origin 1.3.0-rc1 has been released

The GitHub release page has been updated for v1.3.0-rc1 and Docker images have been pushed. Thanks to everyone for the hard work over the last few months to continue to stabilize and improve Kubernetes and OpenShift. We expect to make

Feedback needed: Automating Kubernetes / OpenShift integrations - i.e. building your own controllers

TL:DR If you've wanted to write a custom controller, try this out and give feedback! Controllers are a fundamental part of Kubernetes (they're the logic loops that ensure all the declarative APIs make it into reality) but for a long time they have been very difficult to write. We want to start ta

Re: Feedback needed: Automating Kubernetes / OpenShift integrations - i.e. building your own controllers

Thanks for the feedback - some comments inline > On Sep 8, 2016, at 3:44 AM, Tobias Florek wrote: > > Hi! > > I did not play with it yet but did find the docs: > https://github.com/openshift/origin/blob/master/docs/man/man1/oc-observe.1 > > I wrote a few simple kubernetes/openshift controllers in

Origin v1.3.0 released

Images have been pushed to the hub and release binaries are up on GitHub under release v1.3.0 . RPMs will take a few days to show up in the existing channels. v1.3.0 was a huge release - thanks to everyone who contributed to make it possibl

Re: Origin v1.3.0 released

And of course I almost forget - the *fastest* way to get v1.3.0 is: $ oc cluster up --version=v1.3.0 Enjoy! On Fri, Sep 16, 2016 at 12:51 AM, Clayton Coleman wrote: > Images have been pushed to the hub and release binaries are up on GitHub > under release v1.3.0 > <https:

OpenAPI schema (swagger 2.0), generated protobufs, and updated Swagger 1.2 docs

PR #10983 has merged to master and will be in v1.4.0-alpha.1. It contains the following: * Updated Swagger 1.2 API specs in https://github.com/openshift/origin/tree/master/api/swagger-spec that now have correctly updated unique names (fixing the pr

Re: Possible integration of a new Python library (kubeshift) to the Github repo

Hey Charlie, very interesting. Having a well maintained library would be very valuable for the community, so I'm in favor. How important is the name to you if we made it more generic (for more search mojo)? Jason, Michal, any thoughts on this? On Oct 6, 2016, at 6:19 AM, Charlie Drage wrote:

Re: Possible integration of a new Python library (kubeshift) to the Github repo

ass citizens would be best. If there are any (better!) names that anyone could think of please speak up! Love to hear your thoughts on it. Charlie Drage PGP - 4096R/C037D617 http://pgp.mit.edu/pks/lookup?op=get&search=0xDA227403C037D617 On Thu, Oct 6, 2016 at 12:24 PM, Clayton Coleman wrote:

Re: NetworkCIDR for big cluster

On Oct 6, 2016, at 1:23 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: Hi We ‘re building 3 big clusters, 1 specific to each data center. growth expected to 1000 nodes each cluster over the time. Questions: 1. # egrep 'clusterNetworkCIDR|serviceNetworkCIDR' /etc/origin/m

Re: NetworkCIDR for big cluster

Pod limits are now directly settable, so no longer hard coded. It sounds like you would plan for 100k pods which a 15 or 14 cidr for pods would cover. I would recommend leaving some headroom there. 14 might be safer if in the future you want to continue to grow the cluster - our target max clust

Re: NetworkCIDR for big cluster

gth 8 (256 pods) or put the cidr mask at 13. For a cidr mask of 12, and a hostSubnetLength of 9, you will get 512 pods on each of 2048 nodes. /Rajat On Oct 7, 2016 4:08 PM, "Clayton Coleman" wrote: > > Pod limits are now directly settable, so no longer hard coded. > > It

Re: OpenShift go client library

Once it settles, yes. > On Oct 11, 2016, at 9:34 AM, Jimmi Dyson wrote: > >> On 11 October 2016 at 17:23, Tomas Kral wrote: >>> On Tue, Oct 11, 2016 at 3:26 PM, Dan Mace wrote: On Tue, Oct 11, 2016 at 9:12 AM, Andy Goldstein wrote: We don't currently have a standalone go c

Re: Container UUID

This should be possible from the downward API as an env var (get the pod uuid as env var) but isn't supported yet. If you file an issue we can make sure it's exposed, and if important enough we could consider backporting it. On Oct 11, 2016, at 10:12 AM, Srinivas Naga Kotaru (skotaru) < skot...@c

Origin v1.2.2 and v1.3.1 released

They contain a security fix that we recommend applying to all v1.2.x versions. v1.3.1 contains a number of bug fixes discovered post release. ___ dev mailing list dev@lists.openshift.redhat.com ht

Re: deploymentconfigs and deployments

The goal is to make Kube capable of expressing all of the things deployment configs do: Hooks Permanent failure (don't deploy bad code) Custom deployments Test deployment Image change triggers That's likely to stretch into mid or late 2017. We will support deployment configs for a very long time

Re: deploying to cluster with no persistent volumes

We kind of have said the opposite - that it should almost always be possible to get a PV bound unless you ask for something weird. Ie allowing local pvc, precreating pv in cluster up and the installer, and better dynamic provisioners like the nfs tools. That doesn't mean that API would be a bad i

Re: Quota Policies

On Tue, Oct 25, 2016 at 3:55 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: > Hi > > > > I’m trying to frame a policy for best usage of compute resources for our > environment. I stared reading documentation on this topic. Although > documentation is pretty limited on this topic wi

Origin v1.4.0-alpha.1 released

As you may have noticed (if you were looking at the repos) v1.4.0-alpha.1 was tagged and released last week. Please see https://github.com/openshift/origin/releases/tag/v1.4.0-alpha.1 for a list of changes. This will be the final alpha - the next release will be the first release candidate. Than

Master has branched for release 1.4

The branch release-1.4 has been set up to track changes destined for the 1.4 release. Master is now open for 1.5 changes. Please ensure your fixes are in master and then cherry pick back to release-1.4. I'll be cutting a release candidate 0 build soon. __

Release v1.4.0-rc1 and v1.5.0-alpha.0 created

v1.4.0-rc1 is the first release candidate for Origin v1.4.0. Please report any issues you encounter. Fixes go to the release-1.4 branch and to master. As noted earlier master is open for changes for 1.5, and v1.5.0-alpha.0 was seeded

Re: feedback

On Dec 6, 2016, at 3:13 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: we are continuously hearing 2 complaints from our users not much verbose info to troubleshott/narrow down 2 commonf failures . 1. Pod unable to come up. Why it failed, what caused? 2.

Re: web socket support

It's fully supported and has been since 3.0 On Tue, Dec 6, 2016 at 5:55 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: > What is OpenShift strategy or plans to support web socket support at > router layer? Our clients asking web socket support since Openshift 2 days > onwards. I k

Re: web socket support

You would just listen on whatever port is exposed by the route (the target port). You can create multiple routes if necessary. Router allows Connection: Upgrade headers seamlessly. Connection timeouts on the router matter, of course. The router documentation briefly describes it, mostly because

Re: web socket support

Tunnel mode default timeout is 1h: https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template I would recommend setting it lower in high density environments. On Dec 6, 2016, at 7:16 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: Ok will t

Re: Linux on s390x release binaries for OpenShift Origin

Probably the easiest integration would be to set up a Jenkins Job that can use a Z instance on linuxone as a worker and build from latest master. Alternatively, if you have a Jenkins instance under your control you could do your own setup and builds and we can link those in to the release process.

Re: 1.3.2 Release

We're currently waiting for another backport. Hoping to have it out soon. On Mon, Dec 19, 2016 at 12:01 PM, Patrick Tescher wrote: > v1.3.2 has been available for a week on Github but I don’t see any builds > yet. Will there be a 1.3.2 rpm package? Is there anything the community can > do to ge

Re: OC client - Multi cluster

You can use different KUBECONFIG environment variables per tab. It has been suggested to add more environment variables but that can complicate scripting. On Dec 21, 2016, at 1:43 AM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: Is it normal behavior to switch to each cluster and l

Re: OC client - Multi cluster

I would recommend keeping login and use of the config file separate - for CI, using a pre-built kubeconfig that you control separately from the thing using it. In general, for scripting I recommend --config and for users with multiple shells I recommend KUBECONFIG. Since a single kubeconfig file

Re: Upstream PRs to Origin are on hold pending the rebase

Origin 1.5 is in alpha right now - we trail Kube specifically to catch these issues and also to ensure all security policies for multi-tenancy are adapted / enforced. On Jan 3, 2017, at 2:11 PM, Andy Goldstein wrote: We will pull in Kubernetes 1.5.1 prior to releasing Origin 1.5. As soon as http

Re: What is the current status of the branches

1.3.3 will be released before the end of the week. 1.4 is simply soaking waiting for new bugs Rebase may still take a while. I cut 1.5.0-alpha.1 as the pre rebase point. On Wed, Jan 4, 2017 at 12:00 PM, Troy Dawson wrote: > Hi, > For downstream purposes I'm asking for a status of the origin br

Re: Binding Persistent Volumes by Labels

In 1.4 quota of persistent volume claims per storage class will be available, but you have to define all of your classes up front in the quota. A whitelist approach is coming later (where adding new storage classes would not require you to change everyone's quota for that new type to be zero) On

Any other PRs for 1.4?

We're getting close to end of 1.4 - if there are any other high severity issues against 1.4 please ensure a PR is opened or an issue is appropriately flagged. Otherwise, after the current PRs in the 1.4 queue merge I'll go ahead and cut 1.4 Thanks! ___

Re: storage labels

Yes On Jan 12, 2017, at 4:23 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: How to represent TB storage in PV? Is it Ti , similar to Gi? -- *Srinivas Kotaru* *From: * on behalf of Srinivas Naga Kotaru *Date: *Wednesday, January 11, 2017 at 11:33 AM *To: *dev *Subject: *s

Re: storage labels

Brad, can you comment? On Jan 13, 2017, at 1:59 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: Perfect, that answer and clarify. Thank you, Nakayama, I was able to bound a PV which has label selectors using a PVC which doesn’t have any selectors. This behavior completely make

Re: openshift audit logs

I believe that feature is coming in 3.4 - copying Maciej who did the impl and updates. On Jan 17, 2017, at 5:23 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: We turned on audit in our platform. Currently Openshift writing audit logs to /var/log/messages log file. Is anyway we can

ANN: New pull request test job added to Origin for deploying a cluster on GCE

A new test job is being added (experimentally) to test_pr_origin (which runs on all Origin merge and test) that deploys a full Origin GCE cluster from your PR. The job test_pull_requests_origin_gce builds and deploys your

OpenShift Origin v1.4.0, v1.3.3, and v1.5.0-alpha.2 released

Thanks to everyone for their hard work in getting OpenShift v1.4.0 out the door. Images have been pushed and RPMs will be available in a few days. See the release notes on GitHub: https://github.com/openshift/origin/releases/tag/v1.4.0 In addition, we've released v1.3.3 with a security fix,

Re: Registry Access Denied

On Tue, Jan 24, 2017 at 9:40 AM, Clayton Coleman wrote: > Sounds like a race in the build controller. Ben might remember if we > fixed anything there or what master logs to look for. > > On Jan 23, 2017, at 3:48 PM, Mateus Caruccio com> wrote: > > CCing list again. >

Re: App is not able to talk with a third party app (installed on another infrastructure).

Usually those are firewall rules blocking your access to the cluster. Have you verified that each node is able to ping your other cluster? > On Jan 30, 2017, at 11:41 AM, Francesco D'Andria wrote: > > Hi all, > > I've just installed an instance of OpenShift Origin on my infrastructure. > I deploy

Re: service discover - always confuse

Including the list correctly. On Tue, Jan 31, 2017 at 4:06 PM, Clayton Coleman wrote: > > > On Jan 30, 2017, at 1:51 AM, Srinivas Naga Kotaru (skotaru) < > skot...@cisco.com> wrote: > > Hi > > > > Observed 2 different behaviors in my platform. not sure thi

Deprecation of OpenShift CLI features in 1.5

There are two features in the OpenShift CLI that we are considering deprecating because more full featured alternatives exist elsewhere. 1. oc import docker-compose - Kompose ( https://github.com/kubernetes-incubator/kompose) supports everything in this feature and has added many more features sin

Re: `oc import docker-compose` with kompose as backend

Hey Suraj, sorry for the delay responding On Fri, Feb 10, 2017 at 12:59 AM, Suraj Deshmukh wrote: > Hi Clayton, > > > This is new thread in support of `oc import docker-compose` with > kompose as backend. > > (I tried repying to your earlier mail thread but had few issues with > the ML, excuse m

Changing release numbers for 1.6 and beyond

There has been some discussion recently about changing the release numbers of Origin so that they line up with the "actual" OpenShift release history. When we reset the numbers to 1.0 for OpenShift 3 on top of Kubernetes, we did so to ensure we clearly identified for the open source community whic

OpenShift Origin v1.5.0-alpha.3 released

Alpha 3 is out on GitHub. This will be the last alpha for 1.5.0 - the next tag will be the release candidate. https://github.com/openshift/origin/releases/tag/v1.5.0-alpha.3 We plan to branch master soon and create a release-1.5 branch that will lead to v1.5.0. ___

Re: metrics

Resending to dev list. On Thu, Feb 23, 2017 at 5:31 PM, Clayton Coleman wrote: > Yes, the apiserver, the controllers, and the nodes all expose metrics on > their serving port. The controllers listen on localhost only today. > > You can view the api server metrics as a suitably pri

Re: Unable to mount GCE Persistent Disks

Resending to whole list, sorry Erik. On Mon, Mar 13, 2017 at 6:49 PM, Clayton Coleman wrote: > I think your node names in 1.4.1 need to match the GCE instance name, and > not be fully qualified domain names. I hit this in origin-gce and we don't > have a fix for this until Kube

Re: Introducing Origin API Groups

> On Mar 17, 2017, at 8:44 AM, Michal Fojtik wrote: > > Hi all, > > As this[1] PR landed today the Origin API resources are now placed > into following API groups[2]: > > * authorization.openshift.io > * build.openshift.io > * apps.openshift.io > * template.openshift.io > * image.openshift.io > *

Extended test binaries now include the yaml files and scripts they depend on

https://github.com/openshift/origin/pull/13361 has just merged and makes it so that running `extended.test` (generated via RPM or the normal build) no longer requires a copy of the Git repository checked out for the tests to run - instead, the files the tests depend on are part of the generated bin

OpenShift Origin v1.5.0-rc.0 and v3.6.0-alpha.0 released

The releases page and tags for OpenShift v1.5.0-rc.0 (first release candidate) and OpenShift v3.6.0-alpha.0 have been updated. * v1.5.0-rc.0 * v3.6.0-alpha.0 Note that

New experimental image build optimizations - reduce build times by 50+%

In https://github.com/openshift/origin/pull/13178 we have introduced a new experimental docker build strategy that avoids creating layers for each statement in your dockerfile, which is a lot faster and gives you a single layer in your image which avoids inefficient temporary copies of data. On a

Re: Question on DNS when running Master/Node on same node

Can you run: $ dig @MASTER_IP -p 53 kubernetes.default.svc.cluster.local from the host and verify it works? And if so, then try $ dig @MASTER_IP -p 53 www.google.com On Thu, Mar 23, 2017 at 12:35 PM, Rishi Misra wrote: > Hi there, > > I am having difficulty getting DNS to work on OpenShift

Re: Question on DNS when running Master/Node on same node

4.google.com. > google.com. 30110 IN NS ns3.google.com. > google.com. 30110 IN NS ns1.google.com. > google.com. 30110 IN NS ns2.google.com. > > ;; Query time: 1 msec > ;; SERVER:

Re: Question on DNS when running Master/Node on same node

er found) ;; global options: +cmd ;; connection timed out; no servers could be reached root@vote-1-7acnx-debug:/app# /========/ On Thu, Mar 23, 2017 at 12:49 PM, Clayton Coleman wrote: > Ok, can you create a running container (oc debug pod/NAME_OF_POD) and > i

Re: Question on DNS when running Master/Node on same node

.5-9+deb8u10-Debian <<>> @MASTER_IP -p 53 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached root@vote-1-7acnx-debug:/app# /========/ On Thu, Mar 23, 2017 at 12:49 PM, Clayton Coleman wrote: > Ok, c

Re: Question on DNS when running Master/Node on same node

paths": [ "/api", "/api/v1", "/apis", "/controllers", "/healthz", "/healthz/ping", "/healthz/ready", "/metrics", "/oapi", "/oapi/v1", "/swaggerapi/&quo

Re: projects join

Not at my laptop but should be an annotation on the project/namespace On Mar 29, 2017, at 12:28 AM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: Is there anyway or how to find out 2 projects are joined together? I joined few projects for inter project communication but didn’t find a

Re: List routes from Routershards

Right now you'd want to list routes and filter them clientside. We could add a field path selector at some point in the future, but the syntax is deliberately limited and I don't think we can guarantee something stable anytime soon. On Apr 4, 2017, at 9:04 PM, Srinivas Naga Kotaru (skotaru) < sko

Re: List routes from Routershards

Each router registers itself on the route status with its unique name - that would tel you which routers have observed it On Apr 4, 2017, at 10:05 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: U mean oc get routes –all-namespaces and filter? I don’t see any way to filter routes b

Re: Why are most openshift/origin releases on github tagged pre-release?

Just because we waited a bit longer for 1.5 to stabilize. > On Apr 13, 2017, at 9:05 AM, Colin Walters wrote: > > Under https://github.com/openshift/origin/releases > it looks like there was never a "non-prerelease" 1.5. Now we're > on the train to 3.6 (which makes sense to me). > > Currently in

Re: Backport requests?

I am surprised that hasn't already been backported. Copying some folks who may know. On Apr 13, 2017, at 9:48 PM, Andrew Lau wrote: Hi, What are the chances for having something like this backported to 1.5? https://github.com/kubernetes/kubernetes/commit/9992bd23c2aa12db432696fd324e900770251dc

OpenShift Origin v1.5.0 has been released

https://github.com/openshift/origin/releases/tag/v1.5.0 contains the fixes since v1.5.0-rc.0. A big thanks to everyone who contributed fixes, helped test, and wrote documentation for 1.5.0! ___ dev mailing list dev@lists.openshift.redhat.com http://lists

<    1   2   3   4   >