[Container-tools] Naming the "Container App Spec and Libraries" project

[Mark Lamourine]

----- Original Message -----
> 
> 
> To atomic or not to atomic is
> 
> pro: associates it with red hat project, shows our leadership
> 
> con: associates it with red hat project, getting other to join

con: it muddies what "atomic" is.  When I'm asked at conferences what atomic is, answering "well there's atomic host, which is this minimal OS thing, then there's
atomic the CLI, which is a tool to manage updates on atomic hosts but can really be run anywhere to run privileged containers because that part's just managing docker, oh and then there's this meta orchestration thing which can sit on top of any kubernetes or heat stack, but is called atomic... well... because that's what we call any container related stuff".

About half way through my admin friends have walked away smelling marketing and my non admin friends are going "wait, wait, what do these have to do with each other?"

- Mark
> 
> 
> I like the suggestion of Tomas' suggestions.
> 
> Carl.
> 
> 
> On 04/14/2015 01:21 PM, Daniel Riek wrote:
> 
> 
> 
> Atomic App
> 
> - Consistent with Project Atomic
> - Consistent with the atomic-run tool - which is the first half of this
> concept.
> - Makes sense because it implements the concept of immutable
> infrastucture and aggregate packaging that the 'Atomic' naming scheme is
> trying to convey
> - Gives some urgently needed content to Project Atomic
> 
> And not to forget: it's the original name I had in mind, when I started
> the project...
> 
> Cheers,
> 
> Daniel
> 
> On 04/14/2015 01:02 PM, John Mark Walker wrote:
> 
> 
> 
> Hey gang,
> 
> Because there's an obvious namespace collision between CoreOS' appc efforts
> and our own container app spec, I've been wondering what to name our thing.
> Here are some potential names. Vote on 1 or submit your own:
> 
> - supernetes - I originally liked this, but then realized it doesn't send a
> realistic message. Connotes some type of orchestration that sits "above"
> k8s. I don't think that's what we're creating. I include it here for
> completeness.
> 
> - intercon - short for "inter-container" - because what we're doing is about
> defining multi-container applications that can utilize a number of
> "providers" and host environments.
> 
> All the other names I'm thinking about are variations on this theme:
> 
> - interpod - same as above, except adopting the term "pod" from the k8s
> universe
> 
> - hyperpod, hypercon - same theme as above, just using a different term of
> art to connote "more than one pod"
> 
> 
> I kind of like intercon, although I could see arguments for something else.
> 
> Once we have a name, we need to figure out where it lives. I don't think it
> belongs under the Project Atomic org on github.
> 
> github.com/intercon is available :)
> 
> -JM
> 
> 
> -JM
> 
> 
> _______________________________________________
> Container-tools mailing list Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
> 
> 
> _______________________________________________
> Container-tools mailing list Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
> 
> 
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
> 

-- 
Mark Lamourine <mlamouri at redhat.com>
Sr. Software Developer, Cloud Strategy
Red Hat, 314 Littleton Road, Westford MA 01886
Voice: +1 978 392 1093
http://people.redhat.com/~mlamouri
markllama @ irc://irc.freenod.org*lopsa