First cut - Cloud PRD outline

[Alek Paunov]

On 30.10.2013 19:01, Matthew Miller wrote:
> On Wed, Oct 30, 2013 at 11:16:06AM -0500, Joe Brockmeier wrote:
>> Indeed. So, as I've gotten approval to attend AWS re:Invent, I'm going
>> to be spending some time asking these questions. Well, not "why are you
>> avoiding Fedora like the plague" but "what do you want out of a cloud
>> image, and how can we get there?"
>
> I did exactly this last year at re:Invent. The consistent answer I got was
> "Oh, I don't really care. That layer is boring."
>
> Other answers I get routinely are:
>
>   1. Doesn't provide any help with what I need -- my language stack with
>      the version I want.
>   2. Lifecycle too short (not per instance, but want to deploy to consistent
>      target)
>   3. Every else is using the other thing, so it's easier
>   4. Snowball effects of #3: documentation, QA, tools
>

    2b. "Fedora is fragile, unacceptable for anything serious. The stable
        product in that family is called CentOS ... but it is too old
        (see #1), so the right thing is the other thing".

This meme has been constantly spread recent few years, mainly across
sysadmins with little-to-zero knowledge or first-hand experience with
Fedora as server platform. Or by frustrated devops, because new Fedoras
bring never versions of the stacks, which are incompatible with their
already deployed (but not so properly supported) applications (which is
again #1 but in reverse direction).

Personally, I am using only Fedora for all roles: KVM hosts, Physical
WSs, VMs(Server/Desktop), exactly because it is very stable and unique
combination between smooth (yum) upgradeability and both recent (means
saving hundreds of hours) and compatible with the rest of the system
versions of the things (and also because bunch of other superior
characteristics, but they are less relevant here). But ... because urban
legends, once established, are hard thing to fight ...

... IMHO, besides solution/education related to #1, with Fedora.next we
need to deliver something *easily distinguishable* (from both F20 and
the "other thing") to put in the mouth of "old-school" sysadmins,
journalists, php/nodejs-only class coders and all other kinds of "very
well informed" experts ;-)

One shot in the dark (possibly out of the Cloud WG scope):

Imagine a Hyper-formula designer/Image factory appliance (+ hosted
version at fp.o - like github for formulas).

The user (devop, sysadmin) starts on her current hardware and VM
instances an agent - system analyzer tool (something highly portable,
even with non Linux versions) which uploads to the running appliance the
profile of the analyzed instance: hardware (equivalent of lshw report or
better), running services, etc. - everything detectable by a program.

The profiles are added to the blank (so far) drawing of her
hyper-formula (sexy browser IDE). She finishes the drawing (actually her
deployment documentation) specifying:

  * Machine/role (KVM node/WS/Bare metal server) how many, VMs/role
    capabilities, containers persistent/ephemeral, etc.

  * Desired infrastructure level services: Distributed storage,
    Management solution (OpenLMI, Puppet, Chef, Salt, or lack-of).

  * Existing/planned applications and their stack requirements. Instance
    class formulas (something equivalent of full salt/puppet definition
    for the class). Private bits for the instance: IP addreses, users,
    etc.

  * etc, etc ...

If all the specs are resolvable, the factory provides initially test
(PXE bootable served by the appliance) images intended to be unobtrusive
tested alongside current OSes plus production images (for example
deployable on the physical hosts from the running test images). Next she
is asked whether she wants to upload the formula (without the quantities
and private bits of course) to the fp.o hosted version for future
personal reuse/tracking/cloning and/or inclusion in the public
formula/solution gallery.

If some requirements of the design are not (yet) resolvable, due to
missing packages in Fedora repos and existing SCLs, unsupported hardware
or just by lack of rules (knowledge) in the resolver, she is asked to
upload too and register as "unresolved" to eventually receive further
help from the community.

Besides initial images generation, the appliance provides the recipes
for the chosen management solution (e.g. salt states) or alternatively
offers joining the instance to the "native" (included in the appliance)
management solution.

I.e. post-kickstarts-era integrated solution, an extensible IDE for
infrastructure design compiling to ready for use pre-provisioned
Host/VM/Container images.

Or something even more "cool" to start people talking about ...

Kind Regards,
Alek

PS. BTW, I am occasionally reading ceph-users list - half of the mails
are description of the hardware/setup (context) + question. The same can
be seen in ovirt-users and probably in other places too. I think - if we
start an effort for replacing these endless raw text
descriptions/supplementary questions limbos with pointers to the
drawings (specs) on the web ... they probably will benefit/be interested
too, ... and they also need a gallery for recommended setups.