Re: [Container-tools] VDI + CDK

[Aaron Weitekamp]

On Wed, Aug 3, 2016 at 7:52 AM, Pete Muir  wrote:

> Do we have any recommendations for how to run the CDK in a VDI
> (
> https://en.wikipedia.org/wiki/Desktop_virtualization#Virtual_desktop_infrastructure
> )
> set up - where thousands of developers connect to servers and run
> virtual desktops. In particular, I'm thinking about the nested
> virtualization performance hit.
>
> Thoughts?
>
> Honestly, my recommendation for this use case would be not to use the CDK
at all. Rather, deploy a quota limited openshift dev cluster with
self-provisioning enabled. The goal for these orgs is managed, efficient,
centralized environments so a container cluster fits into this quite well.

If we have CDK features that do not meet the requirements maybe these can
run as services in the cluster. Don't know. Just putting it out there.

​

> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] [Devtools] openshift is way too permissive in the CDK/ADB

[Aaron Weitekamp]

On Wed, May 18, 2016 at 8:30 AM, Dusty Mabe  wrote:

>
>
> On 05/18/2016 07:18 AM, Aslak Knutsen wrote:
> > I think most teams at the Brno F2F were struggling with this. It works
> locally, but semi-obscure failures when pushed 'live'. And out of the 30 RH
> engineers there, none knew 100% or was able to dig up a doc that explained
> why and how to fix it...
> >
> > This is/will be a massive pain point moving from Dev to Production. The
> very least we need some very clear, simple guides on how to make it work.
>
> Yeah, I think a lot of people are going to be very frustrated by this.
> It took me over an hour to track down and that's only because I know a
> lot about how the CDK is set up. Others would probably never be able
> to figure it out.
>
> ​
For the "eval" use case we made the right choice. Dusty's question is about
the CDK use case. To my mind the CDK should add value to a
​n openshift eval environment. This is a great opportunity for the CDK to
provide tooling to address this ubiquitous problem. Mitch Harpur's ideas
around this months ago were spot-on: walk devs through a journey, educate
them, etc.

___
> Devtools mailing list
> devto...@redhat.com
> https://www.redhat.com/mailman/listinfo/devtools
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

[Container-tools] Parameter hinting labels

[Aaron Weitekamp]

I proposed[1] a method for enabling tools to generate parameterization
based on Dockerfile labels. The idea is that tools like the openshift CLI
could generated a parameterized template based on these values. It's a
simple approach. Please comment there.

[1]
https://github.com/projectatomic/ContainerApplicationGenericLabels/pull/69
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] oc export

[Aaron Weitekamp]

On Tue, Mar 15, 2016 at 9:50 AM, Tomas Kral <tk...@redhat.com> wrote:

>
> On 03/15/2016 02:04 PM, Aaron Weitekamp wrote:
> > On Tue, Mar 15, 2016 at 6:20 AM, Tomas Kral <tk...@redhat.com
> > <mailto:tk...@redhat.com>> wrote:
> >
> >
> >
> > On 03/14/2016 07:11 PM, Aaron Weitekamp wrote:
> > > On Mon, Mar 14, 2016 at 1:10 PM, Tomas Kral <tk...@redhat.com
> <mailto:tk...@redhat.com>
> > > <mailto:tk...@redhat.com <mailto:tk...@redhat.com>>> wrote:
> > >
> > > Thank you, that makes sense, but this is also what was afraid
> of :(
> > >
> > > We want to be able to export any arbitrary application that we
> know
> > > nothing about :(
> > > Now we need to figure out which object were generated by
> OpenShift
> > > internally and which one were created by developer.
> > >
> > >
> > > ​You're introducing an additional requirement. :) Can you confirm
> the
> > > initial problem is resolved?
> > >
> >
> > Not really, because I don't know how application was deployed.
> > My initial assumption that `oc export all` will somehow magically
> solve
> > this for every application was wrong :(
> > If I'm the one who deployed application than yes, I know what
> objects to
> > export. But if someone else created application it is hard for me to
> > figure out what to export.
> >
> >
> > ​I think we need to understand the full use case. Maybe there's
> > something that can be done to help you achieve what you're looking for.
> > Right now it's hard to understand why the person who did the original
> > deployment​
> > ​ isn't involved in the export or migration. Can you spell out what
> > you're trying to do?
> > ​
>
> Sure.
>
> (BTW: I'm CC'ing container-tools because we are starting to touch
> subjects that might be interesting for people there)
>
> We are trying to build tool that will allow users to export application
> from OpenShift as Nulecule application.
> Result should be Nulecule application with Kubernetes and OpenShift
> artifacts.
>
> We have following users stories in mind:
>
> 1.
> I create an application in OpenShift.
> Now I want to export it so it can be placed in any registry and then
> redeployed into Kubernetes or OpenShift.
>
>
It's a good convention to add a label to every object created together,
something like app=
Then all of those things deployed together can be referenced, such as:

oc export all -l app= -n  --as-template=

​If you control the deployment you can pass this label in (web ui, oc
new-app, API).
​


>
> 2.
> I created a new application from a bunch of 'container mirco-sevices'
> and components (i.e. a set of nested Nulecules, or templates)
>  - for example, added management, added a DB etc etc.
>
> Now I want to export the new composite definition and ->Retain<- the
> granularity  and nesting of my service definitions.
>

I
​ would recommend unique labels so you can reference things separately.
​


> Result would be set of Nulecule apps (some probably nested) and
> corresponding images that can be again placed in registry.
>
>
> 3.
> I want to create a new mirco service using OpenShift
> I want to export it for OTHER to use.
>
>
>
> Right now I'm focusing mainly on number one.
>
> >
> >
> >
> >
> > > If you're comfortable with exporting everything in a project then
> > > replace "all" with the set of resources Clayton listed.
> >
> > You and Clayton suggested doing `oc export dc,svc,route,is` but what
> if
> > application also includes ReplicationControllers that were created
> > directly without DeploymentConfig?
> > For example I have RC that was created "directly by user" and other
> RC
> > that was created by DC. Now I need to export only first RC and
> instead
> > of second one I should export DC.
> >
> > It looks like, that for our use case, we need to export 'all' and
> than
> > do some filtering.
> > This is was what my followup question was about.
> >
> > Is there a way how to figure out what objects 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 only one "application" in a
> > > project. You may 

Re: [Container-tools] Rethinking Nulecule

[Aaron Weitekamp]

On Thu, Mar 10, 2016 at 4:29 AM, Ratnadeep Debnath  wrote:

> Hi all,
>
> Till now, Nulecule's focus has been to be a spec to package and ship
> nested, composable multi container applications. Well, it helps us to
> focus on a smaller problem and solve it well. This also keeps
> implementation of Nulecule, e.g., atomicapp, lean and simple.
>
> However, is it enough?
>
>
> I will try to highlight a few shortcomings of the current Nulecule spec:
>
> - the spec file does not fully describe the architecture of the
> applications
> - it's difficult to get started with Nulecule as it requires knowledge
> of underlying providers
> - it's not possible to use the same Nulecule spec to deploy a Nulecule
> application across providers without writing artifacts for each
> provider
>
>
> So, we are thinking in the lines of extending Nulecule SPEC to
> describe a multi container application completely in the SPEC file,
> similar to Docker compose file. This will enable us to:
>
> - to automatically generate artifact files for underlying providers
> from the SPEC file
> - to override the generated artifact files, if needed
>
>
> The advantages of such a change would be:
>
> - zero barrier entry for developers
> - package once, in one language, and deploy anywhere
>
>
> This move will be beneficial to:
>
> - developers, with little knowledge about openshift, k8s, marathon, etc.
>

​I disagree that we can shoulder the burden of making openshift or
kubernetes or anything else easier to use. We haven't been successful
making our own tooling easy to use and adopt. The platform has to do this
work.
​


> - ISVs to package apps to run across multiple providers
>
- switch seamlessly to another provider
>

>
> We're keen to hear your feedback on the above proposed changes. Will
> this help to make Nulecule more awesome and user friendly? Let us know
> what you think.
>
>
> Thanks,
> rtnpro
> --
> Ratnadeep Debnath,
> https://www.waartaa.com
> GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02  B785 2119 5486 F245 DFD6
>
> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] Rethinking Nulecule

[Aaron Weitekamp]

On Thu, Mar 10, 2016 at 7:18 AM, Burr Sutter  wrote:

> I like the proposal! :-)
>
>
I agree we should encourage adoption, zero barriers, etc, but I think we
should go in the other ​direction with the spec:
- focus on the high-level definition of the application and service
discovery, e.g. I want to deploy and connect 2 services
- we push artifact generation AND parameterization[1] AND application
lifecycle down to the platform, e.g. kubernetes and openshift.

With this approach we add value to the platform without duplicating. We
stop chasing low-level platform artifact/api changes. We help people
compose and distribute applications.

[1] by parameterization I mean the platform should have its own mechanism
for parameterization that we simply hook into.


> On Thursday, March 10, 2016, Ratnadeep Debnath  wrote:
>
>> Hi all,
>>
>> Till now, Nulecule's focus has been to be a spec to package and ship
>> nested, composable multi container applications. Well, it helps us to
>> focus on a smaller problem and solve it well. This also keeps
>> implementation of Nulecule, e.g., atomicapp, lean and simple.
>>
>> However, is it enough?
>>
>>
>> I will try to highlight a few shortcomings of the current Nulecule spec:
>>
>> - the spec file does not fully describe the architecture of the
>> applications
>> - it's difficult to get started with Nulecule as it requires knowledge
>> of underlying providers
>> - it's not possible to use the same Nulecule spec to deploy a Nulecule
>> application across providers without writing artifacts for each
>> provider
>>
>>
>> So, we are thinking in the lines of extending Nulecule SPEC to
>> describe a multi container application completely in the SPEC file,
>> similar to Docker compose file. This will enable us to:
>>
>> - to automatically generate artifact files for underlying providers
>> from the SPEC file
>> - to override the generated artifact files, if needed
>>
>>
>> The advantages of such a change would be:
>>
>> - zero barrier entry for developers
>> - package once, in one language, and deploy anywhere
>>
>>
>> This move will be beneficial to:
>>
>> - developers, with little knowledge about openshift, k8s, marathon, etc.
>> - ISVs to package apps to run across multiple providers
>> - switch seamlessly to another provider
>>
>>
>> We're keen to hear your feedback on the above proposed changes. Will
>> this help to make Nulecule more awesome and user friendly? Let us know
>> what you think.
>>
>>
>> Thanks,
>> rtnpro
>> --
>> Ratnadeep Debnath,
>> https://www.waartaa.com
>> GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02  B785 2119 5486 F245 DFD6
>>
>> ___
>> Container-tools mailing list
>> Container-tools@redhat.com
>> https://www.redhat.com/mailman/listinfo/container-tools
>>
>
> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] Namespace for demo images

[Aaron Weitekamp]

On Wed, Mar 9, 2016 at 6:29 AM, Josh Berkus  wrote:

> > Indeed Scott. Just started and this might be more a mid-term feature.
> > First we need to fix some other items. Just wanted to mention that I'm
> > considering this as an RFE and have added to my planning board.
>

​We had a plan to deliver a Red Hat Labs registry for this very purpose. It
was a bit before it's time but we are much closer now with the atomic
registry. Dirk and I will work together on this.
​

>
> Well OK 
>
> In the meantime I have demo images to upload *right now*.  What's a
> reasonable way to namespace them on Docker Hub?  Do we want a Demo org, or
> is prefixing them with "demo-" better?
>

​I prefer just using tags for this purpose. It's quite useful to have an
image that does not have a :latest tag but only :wip (work in progress)

​


>
> --
> Josh Berkus
> Project Atomic
> Red Hat
>
> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] Atomic App / Nulecule Spec Readiness for 1.0.0: we still have some work to do

[Aaron Weitekamp]

On Tue, Mar 8, 2016 at 6:20 AM, Tomas Kral  wrote:

>
>
> On 03/08/2016 12:36 AM, Dusty Mabe wrote:
> >
> > We met earlier today to discuss the readiness of the Nulecule spec. This
> was
> > brought about because we were in motion to release a 1.0.0 release of
> Atomic App
> > because we have been in feature freeze/test mode for a while.
> >
> > Here are some important notes from the meeting:
> > - We have thusly concentrated on the deployment story and not enough on
> the
> >   developer story. We need to take a new look at the spec from a
> developer point
> >   of view.
> > - We would like to have more "users" attempt to create Apps so we can
> fully vet
> >   Atomic App and Nulecule Spec before we approach 1.0.0 status.
> > - We realize that soon we will need to make sure that we support (for
> some time)
> >   the existing Nulecule spec version that Atomic App supports. We have a
> short
> >   amount of time before that to change the spec, but even after that
> point we have
> >   freedom to change the spec as long as we support backwards compat.
> > - Development of Atomic App isn't tied to the ADB/CDK because Atomic App
> isn't
> >   baked into the ADB and is delivered via a registry. So we may be more
> free to
> >   iterate faster than previously thought.
> >
> > Conclusions:
> > - We will leave the current versioning scheme in place for now; continue
> on with
> >   0.4.x, 0.5.x and so on.. Before we make any large changes to
> versioning we
> >   should also discuss with marketing to make sure we have a good message.
> > - For the time being we will go back to heavy/fundamental development
> instead of
> >   just bug-fixing so we can attempt to address the issues with the spec
> and with
> >   the developer story.
> >
> > Open Questions:
> > - Do we need to continue to be generic and support all providers or
> should we tailor
> >   our solution to Kubernetes/OpenShift?
>
> I can see benefits of tailoring our solution to Kubernetes/OpenShift.
> But I'm also afraid that in this case we might end up with something
> only slightly different than OpenShift templates.
>

​I agree on both counts. So how can we add value without duplication? Here
are some suggestions:

*Packaging*: this has yet to catch on. Have we considered playing with the
S2I pattern and create a "packaging service" hosted on openshift? We need
to somehow make this compelling and automated.

*Parameterization*: currently we ask the developer to choose which params
to expose during deployment. How can they choose? The dev doesn't actually
know the extent to which ops might want to customize the deployment. Ops
makes that determination. Shouldn't we allow ops to override ANY param and
enable/disable objects (services)? This would be in keeping with our
high-level view of the app and yet provide the flexibility ops should have.
It should also provide a "snapshot" of a deployment that can be duplicated.

*Portability:* The user is on a platform that they've chosen (or at least
try out). They are going to use the artifacts (templates, etc) and
deployment methods that the platform requires. Isn't our role just helping
them distribute these artifacts between environments? As an ISV I want to
give the end-user the artifacts they need to deploy. As a dev I want my
(automated) build environment to hand off to the ops team.


>
>
> >
> > ___
> > Container-tools mailing list
> > Container-tools@redhat.com
> > https://www.redhat.com/mailman/listinfo/container-tools
> >
>
> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] Start merging atomicapp features to master!

[Aaron Weitekamp]

Per Jez Humble [1] I would recommend PRs merge to master and direct users
to stable releases.

[1]
http://continuousdelivery.com/2011/07/on-dvcs-continuous-integration-and-feature-branches/

On Mon, Mar 7, 2016 at 10:15 AM, Charlie Drage  wrote:

> I'm fine with feature branches. But not dev/master workflow. We need
> to stick to the github style workflow as that is what the majority of
> OSS contributors use.
>
> But no problem by me. If you want to play with experimental features
> feel free to create a branch and create PR's that merge to it.
>
> As long as it's a feature branch I believe we can bypass the formality
> of having to have two maintainers :+1: or LGTM the PR's to them.
>
> In regards to new features, we'll merge them to master post-1.0.0, just
> one more
> week (let's try not to jinx it, haha)! Until then, feel free to create
> a feature branch.
>
> In regards to the issues, there's quite a few which have been opened
> recently, if any of the new hires would like help tackling them don't
> be afraid to ask. Personally, I'm still overwhelmed by docs, but
> I'll be focusing back on coding soon and closing some issues.
>
> On 03/04, Ratnadeep Debnath wrote:
> > Hi all,
> >
> > I think it's time we should start merging pending feature pull
> > requests to master branch of atomicapp and start closing issues. If
> > needed, we can cut out a branch for the upcoming stable release and
> > cherry pick changes into the release branch.
> >
> > Thanks,
> > rtnpro
> > --
> > Ratnadeep Debnath,
> > https://www.waartaa.com
> > GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02  B785 2119 5486 F245 DFD6
> >
> > ___
> > Container-tools mailing list
> > Container-tools@redhat.com
> > https://www.redhat.com/mailman/listinfo/container-tools
>
> --
>
> Charlie Drage
> Red Hat - OSAS Team / Project Atomic
> 4096R / 0x9B3B446C
> http://pgp.mit.edu/pks/lookup?op=get=0x622CDF119B3B446C
>
> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools