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

Re: V3 Administrator Tooling





On May 12, 2015, at 11:49 PM, Andrew Lau <andrew andrewklau com> wrote:

On 12 May 2015 at 09:02, Clayton Coleman <ccoleman redhat com> wrote:


----- Original Message -----
> Hi,
>
> I'm excited to get ready for openshift3. I've been looking through the docs
> but haven't been able to find much information about how we can migrate some
> of our tooling/middleware to the new platform.
>
> ie. exporting usage /usr/sbin/oo-admin-ctl-usage --list or auto idling (will
> that be part of v3?)

v3 will not have usage (as it was in v2) directly, and idling is looking like it will be post v3 because we need to sort out autoscaling in kubernetes.

Usage can be calculated today by watching the "ResourceQuota" API.  We need to add the official modification timestamp of limits into the stored value (although that relies on you having accurate clocks).  That resource will show you the counts of any quota tracked resource, of which pods are today.  As we evolve quota we'll be able to track when pods transitioned into start status (we're currently waiting for some new features to make it into etcd).

Idling will likely be implemented at the TCP level in services - it will be possible for the idler to scale a set of replication controllers down to zero, but record that on traffic to a particular service that RC should be woken up.  The service proxy, upon receiving a new incoming connection, would trigger a scale up to 1 and hold traffic until that pod is available.  Still working through the details, but https://github.com/GoogleCloudPlatform/kubernetes/pull/3247 tracks the current design.

​Thanks for the run down.

I'm getting lost in the scrambled docs a little, I'm understanding there'll be a hierarchy of users being attached to projects, but I'm not seeing anywhere that references to a "global" administrator who could potentially query ResourceQuota on each individual users. Would it potentially require an arbitrary admin user to create the projects on behalf of the users to be able to potentially track their resource usage?

The cluster-admin role, which the admin.kubeconfig file generated by Openshift start runs under, can do anything on the cluster.  You can create a user via cert or the API and give it only access to view resource limits and quota.


I was also curious about Source Code Management, will OpenShift still provide the private git repositories that it had in place for v2?

There will be simple integrations that allow local Git mirroring in workspaces, and examples for running full featured Git servers on Openshift.  That's likely to give you the equivalent functionality as V2 with more flexibility.  You can check out examples/gitserver in the source repo for more on the former, although there's still work to do on that before it's ready for day to day use.

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