Fwd: metering services in openshift v3

[Pri]

Hi everybody,

I came across this link
https://blog.openshift.com/metering-microservices-on-openshift-with-6fusions-delano-seymour-commons-briefing-13/



wanted to understand if this is available to use with openshift v3, if yes
how users can use this to charge services ?

Thankyou so much!
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: When can we expect the next official release?

[Clayton Coleman]

In a few days - we're still finding and poking the last bugs in 1.1.1.

> On Jan 18, 2016, at 6:19 AM, André Dietisheim  wrote:
>
> Hi all
>
> Official binaries were release in the beginning of December. oc rsync has a 
> few fixes and enhancement we'd love to get officially released.
> When is the next one scheduled?
>
> https://github.com/openshift/origin/releases
>
> Thanks
> André
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: metering services in openshift v3

[Chris Morgan]

Hi Pri,

I brought this to the attention of the partner — they should reach out to you 
soon.

Cheers,
Chris

> On Jan 18, 2016, at 2:04 AM, Pri  wrote:
> 
> Hi everybody,
> 
> I came across this link 
> https://blog.openshift.com/metering-microservices-on-openshift-with-6fusions-delano-seymour-commons-briefing-13/
>  
> 
>  
> 
> 
> wanted to understand if this is available to use with openshift v3, if yes 
> how users can use this to charge services ?
> 
> Thankyou so much!
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Upcoming image related features

[Vincent Behar]

Hi,

that’s great news!

On our side, we were mainly waiting for the automatic scheduled images import.
We have some private base images in external registries, that are either 
automatically built (dockerhub), or manually (artifactoryonline), so yes, 
having a scheduled import is a huge win for us because it allows for automatic 
rebuilds.

Vincent

> On 18 Jan 2016, at 06:06, Clayton Coleman  wrote:
> 
> In 1.2 we plan to land a number of improvements to how image streams
> work that deliver on the original design goals of centralizing and
> abstracting how users deal with images in multiple docker registries
> in a predictable way.  I wanted to provide an abstract on those
> changes so people could give feedback based on their use cases today,
> and see if there's additional opportunities to streamline workflows on
> OpenShift.
> 
> 
> ## Importing images from V2 Docker registries with authentication
> 
> This feature enables importing images based on the secrets that exist
> in the current namespace. If you create an image stream that points to
> a remote registry that requires auth, the pull secrets in the current
> namespace will be used to authenticate you (you can create a pull
> secret with 'oc secrets new-dockercfg NAME ...').  It also streamlines
> the API that we use to import images, so you'll see some additional
> info show up in your imported images like the size, layer info, and
> the ability to selectively import specific tags with the 'oc tag'
> command.  It prioritizes importing tags from remote repositories based
> on semantic versioning - i.e., a tag like "v5" will be imported in
> preference to "v5.3.6", and improves the performance of importing in
> general.
> 
> Authentication is not currently enabled for V1 Docker registries given
> the upcoming removal of support for V1 registries in the Docker
> daemon.
> 
> 
> ## Allow the OpenShift integrated registry to automatically proxy pull
> requests to any tagged image
> 
> This feature allows you to 'docker pull' any image that is tagged into
> an OpenShift repository and resides in a V2 docker registry.  This
> leverages the authentication support described above, so as long as
> you can authenticate to the OpenShift registry you do *not* need to
> have authentication keys to remote repositories. An example:
> 
>oc tag --source=docker mysql:5.6 mysql:latest
>docker pull //mysql:latest
>... downloads mysql:5.6
> 
> This pull-through mechanism leverages content-offload, so if you have
> S3 or Swift URL downloads (where the registry creates a temporary URL
> that downloads directly from S3 or Swift) the OpenShift registry is
> only invoked to get the manifest, and the local Docker daemon will
> pull directly from your content store.
> 
> This should open the door for centrally managing and referencing
> images across the cluster - any instance of OpenShift can pull
> metadata centrally but leverage content locally.
> 
> 
> ## Automatically import images on a scheduled basis
> 
> This feature lets you enable background importing of upstream Docker
> image metadata into an image stream.  Every X minutes OpenShift will
> check to see if your upstream registry tags changed, and then
> automatically import the latest metadata from the server, triggering
> deployments or builds automatically.  This also leverages the
> improvements above, allowing you to authenticate to any V2 Docker
> registry for import.
> 
> You will be able to enable scheduled import with the tag command:
> 
>oc tag --source=docker mysql:5.6 mysql:latest --schedule
> 
> This will import the image immediately (making the current unique
> image reference available for deployments), and then every 15 minutes
> by default the Docker Hub will be checked to see if the tag has been
> changed.  As an administrator, you can change the frequency of these
> imports and the rate at which images can be imported to limit the
> impact that imports have your other registries.
> 
> Every time OpenShift finds a new tag, the image stream will trigger
> any builds or deployments that depend on the tag, which means you can
> enable scheduling for your base images (things like RHEL, base images
> on the DockerHub, or images built in external systems), and those
> images will automatically flow into your OpenShift deployment on a
> schedule.  This allows production clusters to import and track images
> from development clusters automatically.
> 
> 
> ## Image Policy Control
> 
> In order to give administrators more control about what runs on their
> cluster, we plan to introduce policy controls as an admission
> controller, with some (or all) of the following options available:
> 
> * Control which images can be used in pods and builds
>  * Specify a partial match on registry, namespace, or name in either
> a blacklist or a whitelist to prevent images from unknown registries
> from being used in pods
>  * Require the image to be fully qualified to an image ID 

Origin v1.1.1 is now available

[Clayton Coleman]

On GitHub at https://github.com/openshift/origin/releases/tag/v1.1.1

The merge queue for master will reopen shortly.

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: metering services in openshift v3

[Pri]

Hi Chris,

thanks a lot , looking forward to use the same for billing.


Thanks,
Pri

On Mon, Jan 18, 2016 at 8:57 PM, Chris Morgan  wrote:

> Hi Pri,
>
> I brought this to the attention of the partner — they should reach out to
> you soon.
>
> Cheers,
> Chris
>
> On Jan 18, 2016, at 2:04 AM, Pri  wrote:
>
> Hi everybody,
>
> I came across this link
> https://blog.openshift.com/metering-microservices-on-openshift-with-6fusions-delano-seymour-commons-briefing-13/
>
>
>
> wanted to understand if this is available to use with openshift v3, if yes
> how users can use this to charge services ?
>
> Thankyou so much!
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev