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

Re: Contribute to OpenShift 3!




> On Sep 7, 2014, at 2:52 PM, Jakob Praher <jakob praher info> wrote:
> 
> Dear Clayton,
> 
> Am 07.09.2014 20:04, schrieb Clayton Coleman:
>> 3 separates git from runtime - the build flows will generate images, and the git input for builds can come from  anywhere.
>> 
>> Running more than just web apps as primary components (no distinction between DBs, message buses, tcp servers like IRC, or http servers) is very important to us - we believe that paas is about standardizing patterns for many types of network software.  Two key pieces of that are the abstractions for interconnection (links in the os3 pep, services and portals in the current kube proposals) and the ability to easily leverage persistent storage (volumes in Kubernetes).  It's still pretty early but those are very clear objectives for us.
> Sounds interesting. Thanks for mentioning the openshift-pep-013-openshift-3.md - was not aware of that. Not sure I understand everything.  So application is replaced by composition of services.  Is then an instantiated project the concept that describes an end-to-end application (having e.g. an external address?).

In general a "project" in 3 will feel more like an app does today - I suspect the project overview page will look more like the app overview in 2.x.  If you're working with multiple projects we'll probably let you group and display projects by label query, which means you should be able to look at multiple at a time.

> I would especially be interested in the details of the stateful services design.

Stateful services is somewhat under specified today - how you attach and track volumes against a service (and how volumes get reattached when a pod goes away) is dependent on some upstream discussions (see durable containers issue on Kube github).

> Links sound interesting - are these merely dependencies?

They're directed relationships between two sets of pods - they'll probably blend the concept of Kubernetes services with direct relationships (see services v2 design issue on Kube github)

> Do you think high level control API (REST-ful like etcd) is a way to perform operations on dependent services (e.g. a database abstraction layer that can create, destroy, backup, or restore databases transparently).

Maybe - I expect there will be higher level API abstractions around domain specific lifecycles (DBs, message queues, camel routes) but it's still early.

> 
> To make implementing stateful services easier, the availability/liveness properties could be provided by the container/pod.  Also +1 on the image immutability  - I am not a docker user as of now - I guess statelessness is important for updating the images composing many services a smaller set of images.
> 
> Best,
> Jakob
> 
>> 
>>> Best,
>>> Jakob
>>> 
>>> 
>>> 
>>> Am 06.09.2014 15:29, schrieb N. Harrison Ripps:
>>>> Hey all--
>>>> Just wanted to let you know that we've put up a contributing guide for our next-generation OpenShift system. You can read all about it here:
>>>> 
>>>> https://github.com/openshift/origin/blob/master/CONTRIBUTING.adoc
>>>> 
>>>> There you can see how to get set up with an OpenShift 3 development environment, where to find our roadmap, and which tasks are in the pipeline.
>>>> 
>>>> If you have any questions or comments about the guide, feel free to follow up on this thread.
>>>> 
>>>> Cheers,
>>>> Harrison
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
> 


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