Hi folks,
I took an initial cut at the framework/outline for a PRD, and started filling in... some bits of it, mostly in an "example" type format so people can get an idea of context, other parts in a more "this is a description of what should be here," etc.
https://fedoraproject.org/wiki/Cloud_PRD
This is about as "traditional" of a PRD as I have gotten it to at this point - given that typically, in a proprietary-type company setting, one group might do a MRD (marketing), then product managers would do a PRD, and then engineers might dive in and do a more detailed requirements document, and then Dilbert-type things start happening (Engineers inform the product managers that they are living in a dream world, the product managers tell them that is nice but it needs to be finished by next week, etc.. http://garbuz.com/blog/wp-content/uploads/2013/02/dilbert-agile-user-stories... :D ) And we're trying to cover most of those bases in one document, and also be realistic (i hope) in the process.
There is still plenty of basic explanatory stuff that can be filled in here, so I hope that people can bear with the fact that more is coming along that might give them better context, but I wanted to get this out for a few reasons:
* Validate that this is even remotely on the right track - I wanted basic framework but... at some point release early/often kicks in.
...hmm, okay, maybe there aren't any more reasons. There are clearly some sections where I'm questioning which way might be the better way to do things (user stories vs. primary use cases, for example), feedback welcome on that or anything else, obv.
Other things I'd just like to put on the table as food for thought:
* There are likely a lot of cases for overlap with the other working groups. I would still prefer to list them out explicitly, just so we can track / ensure that any dependencies are being coordinated / worked through (with our help, or not, or whatever) with the other teams, and also so people don't come along and say "OMG YOU FORGOT XYZ" and we don't have to explain that we already thought through this and decided it would be best passed on to another team. * In line with that, it would probably be useful to explicitly describe somewhere towards the beginning of the document what we expect is *within* our scope, vs. outside of it, particularly when it comes to server WG / cloud WG things; and also ensure that we have mutual agreement with the other WGs on that, so that we don't get into some situation of questioning whose call it is, or worse, just assuming that another working group has those bases covered. (Johann's mail that he sent just a bit ago to the list, https://lists.fedoraproject.org/pipermail/cloud/2013-October/002837.html more or less illustrates the need for this, IMO.)
Also: I realize that there is often times a desire to just think about all the cool things we could add in in terms of packages but I do think it is useful for us to actually think through the use cases or user profiles, to ensure we have something that is useful in a variety of environments, for multiple purposes, user types, etc. If you're a sysadmin or developer, or know people who are, by all means, share what would make a cloud "product" useful for you in your day to day work, or ask people what would make it useful. If you know people who are explicitly avoiding Fedora like the plague for cloud usage, ask them why. This is the kind of stuff that helps us ensure that we are not just talking to ourselves, more or less ;)
Anyway: I know some folks are going to want to dive in and start filling things out - and perhaps I should have maybe put this in a separate file as a "template" and then have the actual filled-out thing on in the Cloud_PRD spot, but ... maybe we can take a snapshot of it at some point soon and save that as the template. In any case: I'd like to make sure that we make sure that this is an effective way to format a PRD that will allow us to produce useful results before we go filling it all in, so that we don't wind up making a bunch of folks all sadfaced that they spent a bunch of time writing stuff before we decided that this sucks and we should do it some other way. :)
Finally (I'm wordy today, sorry) - I have no idea what the other WGs are planning offhand for their PRDs. I don't know if it would be useful for everyone to standardize on one template, or have each WG decide what works best for them, and I'm not going to try and sort that out here :) but it might be useful to keep an eye on what the other teams are putting together so that we can make sure anything that does need cross-coordination can be captured appropriately.
-robyn
Top Post actually makes sense this time.
PRD == Product Requirements Document MRD == Marketing Requirements Document.
On 28 October 2013 07:19, Robyn Bergeron rbergero@redhat.com wrote:
Hi folks,
I took an initial cut at the framework/outline for a PRD, and started filling in... some bits of it, mostly in an "example" type format so people can get an idea of context, other parts in a more "this is a description of what should be here," etc.
https://fedoraproject.org/wiki/Cloud_PRD
This is about as "traditional" of a PRD as I have gotten it to at this point - given that typically, in a proprietary-type company setting, one group might do a MRD (marketing), then product managers would do a PRD, and then engineers might dive in and do a more detailed requirements document, and then Dilbert-type things start happening (Engineers inform the product managers that they are living in a dream world, the product managers tell them that is nice but it needs to be finished by next week, etc.. http://garbuz.com/blog/wp-content/uploads/2013/02/dilbert-agile-user-stories... ) And we're trying to cover most of those bases in one document, and also be realistic (i hope) in the process.
There is still plenty of basic explanatory stuff that can be filled in here, so I hope that people can bear with the fact that more is coming along that might give them better context, but I wanted to get this out for a few reasons:
- Validate that this is even remotely on the right track - I wanted basic
framework but... at some point release early/often kicks in.
...hmm, okay, maybe there aren't any more reasons. There are clearly some sections where I'm questioning which way might be the better way to do things (user stories vs. primary use cases, for example), feedback welcome on that or anything else, obv.
Other things I'd just like to put on the table as food for thought:
- There are likely a lot of cases for overlap with the other working
groups. I would still prefer to list them out explicitly, just so we can track / ensure that any dependencies are being coordinated / worked through (with our help, or not, or whatever) with the other teams, and also so people don't come along and say "OMG YOU FORGOT XYZ" and we don't have to explain that we already thought through this and decided it would be best passed on to another team.
- In line with that, it would probably be useful to explicitly describe
somewhere towards the beginning of the document what we expect is *within* our scope, vs. outside of it, particularly when it comes to server WG / cloud WG things; and also ensure that we have mutual agreement with the other WGs on that, so that we don't get into some situation of questioning whose call it is, or worse, just assuming that another working group has those bases covered. (Johann's mail that he sent just a bit ago to the list, https://lists.fedoraproject.org/pipermail/cloud/2013-October/002837.htmlmore or less illustrates the need for this, IMO.)
Also: I realize that there is often times a desire to just think about all the cool things we could add in in terms of packages but I do think it is useful for us to actually think through the use cases or user profiles, to ensure we have something that is useful in a variety of environments, for multiple purposes, user types, etc. If you're a sysadmin or developer, or know people who are, by all means, share what would make a cloud "product" useful for you in your day to day work, or ask people what would make it useful. If you know people who are explicitly avoiding Fedora like the plague for cloud usage, ask them why. This is the kind of stuff that helps us ensure that we are not just talking to ourselves, more or less ;)
Anyway: I know some folks are going to want to dive in and start filling things out - and perhaps I should have maybe put this in a separate file as a "template" and then have the actual filled-out thing on in the Cloud_PRD spot, but ... maybe we can take a snapshot of it at some point soon and save that as the template. In any case: I'd like to make sure that we make sure that this is an effective way to format a PRD that will allow us to produce useful results before we go filling it all in, so that we don't wind up making a bunch of folks all sadfaced that they spent a bunch of time writing stuff before we decided that this sucks and we should do it some other way. :)
Finally (I'm wordy today, sorry) - I have no idea what the other WGs are planning offhand for their PRDs. I don't know if it would be useful for everyone to standardize on one template, or have each WG decide what works best for them, and I'm not going to try and sort that out here :) but it might be useful to keep an eye on what the other teams are putting together so that we can make sure anything that does need cross-coordination can be captured appropriately.
-robyn
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, Oct 28, 2013 at 09:19:30AM -0400, Robyn Bergeron wrote:
Hi folks,
I took an initial cut at the framework/outline for a PRD, and started filling in... some bits of it, mostly in an "example" type format so people can get an idea of context, other parts in a more "this is a description of what should be here," etc.
Thanks for doing that. I'm taking a crack at a few of the sections. I'm assuming since it's a wiki we'd rather just have a go there rather than hashing out all the specifics on the list?
- Validate that this is even remotely on the right track - I wanted
basic framework but... at some point release early/often kicks in.
Yeah, I think this is on the right track.
- There are likely a lot of cases for overlap with the other working
groups. I would still prefer to list them out explicitly, just so we can track / ensure that any dependencies are being coordinated / worked through (with our help, or not, or whatever) with the other teams, and also so people don't come along and say "OMG YOU FORGOT XYZ" and we don't have to explain that we already thought through this and decided it would be best passed on to another team.
I think that the IaaS environments section falls in the "overlap" if not outright "belongs in other group" category.
If you know people who are explicitly avoiding Fedora like the plague for cloud usage, ask them why. This is the kind of stuff that helps us ensure that we are not just talking to ourselves, more or less ;)
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'm also a believer in "skate where the puck is going," so we should be asking not only "why aren't you using it today?" but "what gaps are there in what you are using today?"
maybe we can take a snapshot of it at some point soon and save that as the template. In any case: I'd like to make sure that we make sure that this is an effective way to format a PRD that will allow us to produce useful results before we go filling it all in, so that we don't wind up making a bunch of folks all sadfaced that they spent a bunch of time writing stuff before we decided that this sucks and we should do it some other way. :)
Ah, well, we'll always have:
https://fedoraproject.org/w/index.php?title=Cloud_PRD&direction=prev&...
Best,
jzb
On Wed, Oct 30, 2013 at 11:16:06AM -0500, Joe Brockmeier wrote:
Thanks for doing that. I'm taking a crack at a few of the sections. I'm assuming since it's a wiki we'd rather just have a go there rather than hashing out all the specifics on the list?
Wikis are good at many things, but discussion isn't one of them. I'd say you're adding to blank areas, or just making wording changes, go for it, but if there's any bigger changes at least summarize them here. From the rest of your message I think that's what you're actually doing. :)
- There are likely a lot of cases for overlap with the other working
groups. I would still prefer to list them out explicitly, just so
[...]
I think that the IaaS environments section falls in the "overlap" if not outright "belongs in other group" category.
There's two parts to this. One is use case as part of an iaas platform (eg openstack note), and for that I agree that it's at least potentially in the overlap section. The second is "environments that guest image will run in", though, and that's not overlap.
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
Not necessarily in that order.
I'm also a believer in "skate where the puck is going," so we should be asking not only "why aren't you using it today?" but "what gaps are there in what you are using today?"
So this is why I'm interested in SCLs, or anything which does what SCLs promise better -- the item #1 above isn't well-covered by _anyone_.
On Wed, Oct 30, 2013 at 01:01:18PM -0400, Matthew Miller wrote:
On Wed, Oct 30, 2013 at 11:16:06AM -0500, Joe Brockmeier wrote:
Thanks for doing that. I'm taking a crack at a few of the sections. I'm assuming since it's a wiki we'd rather just have a go there rather than hashing out all the specifics on the list?
Wikis are good at many things, but discussion isn't one of them. I'd say you're adding to blank areas, or just making wording changes, go for it, but if there's any bigger changes at least summarize them here. From the rest of your message I think that's what you're actually doing. :)
Yeah, if there's a big divergence in ideas / how we should do it, then I'd bring it right here.
So this is why I'm interested in SCLs, or anything which does what SCLs promise better -- the item #1 above isn't well-covered by _anyone_.
Good to know. Thanks!
Best,
jzb
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.
-
Alek Paunov -
Joe Brockmeier -
Matthew Miller -
Robyn Bergeron -
Stephen John Smoogen