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:
- Doesn't provide any help with what I need -- my language stack with the version I want.
- Lifecycle too short (not per instance, but want to deploy to consistent target)
- Every else is using the other thing, so it's easier
- 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.