Le 30/10/2013 21:30, Joe Brockmeier a écrit :
Hi all,
(For those who weren't in today's IRC meeting, I sorta apologize for the
subject line. Sorta.)
As we were discussing today - we need to decide what we are building,
and (almost as importantly) what we're not building. We've agreed that
we want to be cooperating with the server SIG, but don't necessarily
plan to build a foundation for an IaaS ourselves.
Some of the questions that were raised during the meeting:
- Should we drop 32-bit?
Not yet, it's still widely used on low-end instances.
- Should we be targeting ARM?
Definitively, many server manufacturers are investing on ARM hardware
like Dell, HP ...
I'm more worried about QA since we don't have much ARM hardware.
- Do we worry about supporting ALL THE METHODS of building the image, or
no? (I recommend we focus on One True Way so as not to confuse
everyone with 80 different ways they *could* do it.)
Ideally, we should at least support a "portable" way to build images (at
least on other GNU/Linux systems). It's convenient for our users and
ease integration with cloud platforms like OpenStack (it has been done
with Horizon and Image Factory:
http://blog.aeolusproject.org/building-openstack-images-with-image-factory/)
Other questions, thoughts, comments, flames?
I also want to recommend that we think hard about not just what we
build, but accompanying it with appropriate amounts of documentation for
the developers/users we expect to be consuming the image. I'm sure it
goes without saying that we would document what we do, but I would like
to see this thought about each step of the way so that when we get to a
finished product, it's dead easy to adopt.
Let's say, that an user come to our landing page, what should she find ?
* a clear mission statement
* description of various use cases each of them linking to a short
tutorial (ie: deploy my node.js app in 5 minutes in openstack, build and
deploy my infrastructure using puppet/ansible/whatever)
* how to participate in the Cloud SIG
* user documentation (both narrative and references) <= we need to
collaborate with the documentation team
* users & partners testimonials (yes, if we want to build a product, we
have to collaborate with industrial partners, neglecting them or the
community won't do us any good)
* external ressources
Best,
jzb
Thanks,
H.
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
