This is a message for people who have self-nominated for the Fedora Cloud Product Working Group (FCPWG?). As the FESCo coordinator for the group, it's my job to narrow down the list to the initial 9 voting members. I was going to send this individually, but then I thought, eh, let's do it in public. If you want to send me other thoughts off-line too, go for it. And if you're not in the list of nominees I'd still value your input into some of the concepts.
I've been the defacto maintainer of the Fedora cloud image kickstart for the past year or so (I have commit access, and I use it!), and I think that's gotten into fairly decent shape. This WG will be about going beyond decent and into something that's actually both very useful and well-used. I have some ideas for what that'd look like, but I'd like to hear yours too. And, I'm interested in hearing where you'd like to contribute in specific. I didn't see anyone mention QA on the nomination list, for example, and we'll need to find someone to take ownership of that.
Our actual deliverables are listed here: https://fedoraproject.org/wiki/Fedora.next/boardproposal#Product_Working_Gro... and they start with:
* Governance plan and documents * A product definition -- target audience and so on * A list of changes from existing procedures * Actually doing things
You may notice that "actually doing things" is kind of far down the list, and there's some degree of.... procedural overhead. If you really hate that kind of thing, speak up now, because maybe this isn't the best use of your time. Although the voting membership is going to be limited, and focused on these things, we actually also need a broader, involved community, so not being on the WG doesn't mean you can't be involved in a meaningful way.
I posted a few weeks ago about possible directions for the cloud product. I am, by the way, pretty sure that we are talking about a cloud _guest_, and that being a base for cloud infrastructure systems like OpenStack or Eucalyptus is in the realm of the Server product (or possibly new, secondary products focused specifically on those use-cases).
I've also heard a few comments suggesting that the cloud guest should basically just be the server product in image form, with cloud-init. This is a model where cloud computing is basically seen as providing "servers in the sky"; I think there's a place for that, but again, I don't think it's what we should be aiming at. The point of having this product as something different is so we can actually better address the different needs.
What that actually looks like is to be determined. The current target is basically "as minimal as possible, but not so minimal that we break stuff or make people's life harder". In the absence of better idea about what we're doing or what we're providing this image _for_, that's a fine, generic base. We have the opportunity now to write the better story, though... so, what are your ideas?
On 18/10/13 19:59, Matthew Miller wrote:
- Governance plan and documents
- A product definition -- target audience and so on
- A list of changes from existing procedures
- Actually doing things
...
I've also heard a few comments suggesting that the cloud guest should basically just be the server product in image form, with cloud-init. This is a model where cloud computing is basically seen as providing "servers in the sky"; I think there's a place for that, but again, I don't think it's what we should be aiming at. The point of having this product as something different is so we can actually better address the different needs.
Matt, thank you for driving this further!
During the last weekend, I was thinking about the definition of cloud working group and what we should achieve.
When thinking about what will be the role of images in the cloud, let's say in 3-5 years, I believe, allmost every server image will be executed in a virtual environment, i.e. in a cloud environment. Thus, I think, we (as the cloud working group) should target this. Every image in the cloud will be used as "server" image, to serve something.
That would mean switched roles/targets between the server wg and the cloud wg (in "their" target and in "cloud image" aim).
So in terms of product definition:
* we strive to provide cloud INFRASTRUCTURE to primarily execute server images provided by the server wg, target audience will be people running Fedora to provide infrastructure.
Speaking of live cycles: Fedora is supported for about a year. Since infrastructure is deployed for longer cycles, we'd need to take care, that UPGRADING works well. This is something, we're not very good right now (compared to others).
* Change from existing procedures: Provide an easy install of a cloud infrastructure on a (bare metal) system. For OpenStack, we'd already have such a solution: packstack. Still we might need to re-validate this, when OpenStack upstream might came up with a different solution. I can't say, if there is something like an installer for OpenNebula or Eukalyptus as well.
When looking at the cloud image produced mainly by Matt, it's very useful to test and to make sure, Fedora runs well on other cloud platforms. On the other hand, I don't see this single product as the main outcome of this group.
Matthias
On Mon, Oct 21, 2013 at 10:32 AM, Matthias Runge mrunge@matthias-runge.dewrote:
On 18/10/13 19:59, Matthew Miller wrote:
- Governance plan and documents
- A product definition -- target audience and so on
- A list of changes from existing procedures
- Actually doing things
...
I've also heard a few comments suggesting that the cloud guest should basically just be the server product in image form, with cloud-init. This is a model where cloud computing is basically seen as providing "servers in the sky"; I think there's a place for that, but again, I don't think it's what we should be aiming at. The point of having this product as something different is so we can actually better address the different needs.
Matt, thank you for driving this further!
During the last weekend, I was thinking about the definition of cloud working group and what we should achieve.
When thinking about what will be the role of images in the cloud, let's say in 3-5 years, I believe, allmost every server image will be executed in a virtual environment, i.e. in a cloud environment. Thus, I think, we (as the cloud working group) should target this. Every image in the cloud will be used as "server" image, to serve something.
Am I right in assuming that we are looking into cloud images for the short term as a starting point? I know the group says cloud but I feel like we need to look more into other spaces that directly/indirectly affect us.
That would mean switched roles/targets between the server wg and the cloud wg (in "their" target and in "cloud image" aim).
So in terms of product definition:
- we strive to provide cloud INFRASTRUCTURE to primarily execute server
images provided by the server wg, target audience will be people running Fedora to provide infrastructure.
Speaking of live cycles: Fedora is supported for about a year. Since infrastructure is deployed for longer cycles, we'd need to take care, that UPGRADING works well. This is something, we're not very good right now (compared to others).
- Change from existing procedures: Provide an easy install of a cloud
infrastructure on a (bare metal) system. For OpenStack, we'd already have such a solution: packstack. Still we might need to re-validate this, when OpenStack upstream might came up with a different solution. I can't say, if there is something like an installer for OpenNebula or Eukalyptus as well.
I totally agree on this.
I can take up its work on the cloudstack platform. At least my boss allows me to abuse some of the resources we have a little. :-)
When looking at the cloud image produced mainly by Matt, it's very useful to test and to make sure, Fedora runs well on other cloud platforms. On the other hand, I don't see this single product as the main outcome of this group.
My opinion is we need to set up what our goals(both long and short term)
are . We also need to have frameworks set up to support this. As long as we have this it will work out well. I am supporting your point here. :-)
Matthias
Matthias Runge mrunge@matthias-runge.de _______________________________________________ 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 21, 2013 at 09:32:55AM +0200, Matthias Runge wrote:
On 18/10/13 19:59, Matthew Miller wrote:
- Governance plan and documents
- A product definition -- target audience and so on
- A list of changes from existing procedures
- Actually doing things
...
I've also heard a few comments suggesting that the cloud guest should basically just be the server product in image form, with cloud-init. This is a model where cloud computing is basically seen as providing "servers in the sky"; I think there's a place for that, but again, I don't think it's what we should be aiming at. The point of having this product as something different is so we can actually better address the different needs.
Matt, thank you for driving this further!
During the last weekend, I was thinking about the definition of cloud working group and what we should achieve.
When thinking about what will be the role of images in the cloud, let's say in 3-5 years, I believe, allmost every server image will be executed in a virtual environment, i.e. in a cloud environment. Thus, I think, we (as the cloud working group) should target this. Every image in the cloud will be used as "server" image, to serve something.
Images are currently used to 'serve' something, what we're talking about here is the difference between pets and cattle, really. How I see the difference here:
- server == pet == a system that is running on the bare hardware and may run the IaaS or PaaS that is running instances/applications. I care a lot if this goes down because it's infrastructure. - instance/image == cattle == a system that has the libraries/apps I need *right now* and is being used as part of scale out applications, and if it dies, I don't care as much because I have an automated system that can spin up a new image with the application data.
(Being *very* general here).
That would mean switched roles/targets between the server wg and the cloud wg (in "their" target and in "cloud image" aim).
So in terms of product definition:
- we strive to provide cloud INFRASTRUCTURE to primarily execute server
images provided by the server wg, target audience will be people running Fedora to provide infrastructure.
I think this is the reverse of how we should be structuring the cloud/server groups.
Best,
jzb
On Mon, Oct 21, 2013 at 11:21 AM, Joe Brockmeier jzb@redhat.com wrote:
On Mon, Oct 21, 2013 at 09:32:55AM +0200, Matthias Runge wrote:
On 18/10/13 19:59, Matthew Miller wrote:
- Governance plan and documents
- A product definition -- target audience and so on
- A list of changes from existing procedures
- Actually doing things
...
I've also heard a few comments suggesting that the cloud guest should basically just be the server product in image form, with cloud-init. This is a model where cloud computing is basically seen as providing "servers in the sky"; I think there's a place for that, but again, I don't think it's what we should be aiming at. The point of having this product as something different is so we can actually better address the different needs.
Matt, thank you for driving this further!
During the last weekend, I was thinking about the definition of cloud working group and what we should achieve.
When thinking about what will be the role of images in the cloud, let's say in 3-5 years, I believe, allmost every server image will be executed in a virtual environment, i.e. in a cloud environment. Thus, I think, we (as the cloud working group) should target this. Every image in the cloud will be used as "server" image, to serve something.
Images are currently used to 'serve' something, what we're talking about here is the difference between pets and cattle, really. How I see the difference here:
- server == pet == a system that is running on the bare hardware and may run the IaaS or PaaS that is running instances/applications. I care a lot if this goes down because it's infrastructure.
- instance/image == cattle == a system that has the libraries/apps I need *right now* and is being used as part of scale out applications, and if it dies, I don't care as much because I have an automated system that can spin up a new image with the application data.
(Being *very* general here).
I very much like this approach to say the Server Product is for pets and the Cloud Product is for cattle. But I do think both pets and cattle can be run both on bare metal or virtualized.
For those who don't know the pet/cattle analogy yet, you want to look at slide 20 of this presentation: http://www.slideshare.net/randybias/architectures-for-open-and-scalable-clou...
...or also at slide 17 in this one: http://www.slideshare.net/gmccance/cern-data-centre-evolution
That would mean switched roles/targets between the server wg and the cloud wg (in "their" target and in "cloud image" aim).
So in terms of product definition:
- we strive to provide cloud INFRASTRUCTURE to primarily execute server
images provided by the server wg, target audience will be people running Fedora to provide infrastructure.
I think this is the reverse of how we should be structuring the cloud/server groups.
Best,
jzb
Joe Brockmeier | Open Source and Standards, Red Hat jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ _______________________________________________ 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 21, 2013 at 11:57:57AM +0200, Sandro "red" Mathys wrote:
On Mon, Oct 21, 2013 at 11:21 AM, Joe Brockmeier jzb@redhat.com wrote:
- server == pet == a system that is running on the bare hardware and may run the IaaS or PaaS that is running instances/applications. I care a lot if this goes down because it's infrastructure.
- instance/image == cattle == a system that has the libraries/apps I need *right now* and is being used as part of scale out applications, and if it dies, I don't care as much because I have an automated system that can spin up a new image with the application data.
(Being *very* general here).
I very much like this approach to say the Server Product is for pets and the Cloud Product is for cattle. But I do think both pets and cattle can be run both on bare metal or virtualized.
Sure. As I said, I was being *very* general... and we would want to provide a cloud image that can be spun up on bare metal, in addition to the images for AWS and KVM, Xen and/or the major open source IaaSes.
Best,
jzb
On Mon, Oct 21, 2013 at 12:12 PM, Joe Brockmeier jzb@redhat.com wrote:
On Mon, Oct 21, 2013 at 11:57:57AM +0200, Sandro "red" Mathys wrote:
On Mon, Oct 21, 2013 at 11:21 AM, Joe Brockmeier jzb@redhat.com wrote:
- server == pet == a system that is running on the bare hardware and may run the IaaS or PaaS that is running instances/applications. I care a lot if this goes down because it's infrastructure.
- instance/image == cattle == a system that has the libraries/apps I need *right now* and is being used as part of scale out applications, and if it dies, I don't care as much because I have an automated system that can spin up a new image with the application data.
(Being *very* general here).
I very much like this approach to say the Server Product is for pets and the Cloud Product is for cattle. But I do think both pets and cattle can be run both on bare metal or virtualized.
Sure. As I said, I was being *very* general... and we would want to provide a cloud image that can be spun up on bare metal, in addition to the images for AWS and KVM, Xen and/or the major open source IaaSes.
I don't think we need a different image that can be spun up on bare metal. We simply provide a cloud image (or several that are tailored more specifically to the underlying solution) and that's it. But whether the IaaS solution uses hypervisors, containers or bare metal shouldn't matter to us. With OpenStack for example, all three are possible and the image doesn't even need to know. And for the Server Product, i.e. Pet, it shouldn't matter either. After all, Server Product kind of OSes have been used for ages both on bare metal and in hypervisors before Cloud Images came into existence sp nothing needs to change here.
It should just matter to the sysadmin / devops, as he needs to know what kind of OS he is running and what kind of OS is right for what kind of use case.
-- Sandro
On 21/10/13 11:21, Joe Brockmeier wrote:
Images are currently used to 'serve' something, what we're talking about here is the difference between pets and cattle, really. How I see the difference here:
- server == pet == a system that is running on the bare hardware and may run the IaaS or PaaS that is running instances/applications. I care a lot if this goes down because it's infrastructure.
Agreed. A server provides infrastructure. What happens, when you need to scale your infrastructure? Is this something for Cloud WG or for Server WG? Usually you'd set up a infrastructure, a monitoring and would define actions, what to do, if event e is triggered. That could imply to spawn up other servers.
- instance/image == cattle == a system that has the libraries/apps I need *right now* and is being used as part of scale out applications, and if it dies, I don't care as much because I have an automated system that can spin up a new image with the application data.
(Being *very* general here).
Yes, still that doesn't explain, why the target of this WG shouldn't be directly targeted to provide infrastructure and the server images should be executed in the infrastructure e.g provided by a cloud.
(Or I might be blind, and I really don't see your point here)
That would mean switched roles/targets between the server wg and the cloud wg (in "their" target and in "cloud image" aim).
So in terms of product definition:
- we strive to provide cloud INFRASTRUCTURE to primarily execute server
images provided by the server wg, target audience will be people running Fedora to provide infrastructure.
I think this is the reverse of how we should be structuring the cloud/server groups.
I see, as it's the opposite of how server wg (and also cloud wg) would see themselves.
Matthias
On Mon, Oct 21, 2013 at 09:32:55AM +0200, Matthias Runge wrote:
- we strive to provide cloud INFRASTRUCTURE to primarily execute server
images provided by the server wg, target audience will be people running Fedora to provide infrastructure.
Hmmm. I don't think that's the original intent of the three-product proposal -- I was thinking more in line with the pets-vs-cattle distinction Joe brings up. Under that idea, there may actually end up being some overlap in that both products are "serving" something, but the distinction is in the approach. The server product would likely be more traditional/conservative and ours more exploratory.
It may be that as we develop the product definitions, the idea you're suggesting comes out to make the most sense. But, if the majority of the group thinks the other way, would you still be interested in working in this direction? (No hard feelings either way!)
Also I was kind of hoping that we'd never have to worry about running on bare metal, but maybe that's fantasy. :)
On Mon, Oct 21, 2013 at 08:56:50AM -0400, Matthew Miller wrote:
Also I was kind of hoping that we'd never have to worry about running on bare metal, but maybe that's fantasy. :)
FWIW, I know that some folks have been using CloudStack/CloudPlatform to manage images running on bare metal for $reasons to do with performance, etc. I'm not sure what percentage of users want to manage cloudy workloads on bare metal, but that use case does exist.
Best,
jzb
On Mon, Oct 21, 2013 at 4:00 PM, Joe Brockmeier jzb@redhat.com wrote:
On Mon, Oct 21, 2013 at 08:56:50AM -0400, Matthew Miller wrote:
Also I was kind of hoping that we'd never have to worry about running on bare metal, but maybe that's fantasy. :)
Do we have to care about bare metal? As long as we use the same kernel as the Server Product does, we should have all the necessary drivers and that should be enough care. Except for the missing abstraction layer between hardware and instance, the behavior should be just the same and therefore not matter to us. And the HW stuff should really be covered by Server and Desktop Products already.
FWIW, I know that some folks have been using CloudStack/CloudPlatform to manage images running on bare metal for $reasons to do with performance, etc. I'm not sure what percentage of users want to manage cloudy workloads on bare metal, but that use case does exist.
Well, one use case is really performance. Particularly in research, many are looking to move from HPC Clusters to (HPC) Clouds. Currently, HPC Clusters are still notably more performant but that's going to change rather earlier than later and a lot of research institutions are very eager to adopt clouds once that's changed.
Another (upcoming but already being used by the big players) OpenStack-specific use case is TripleO which stands for "OpenStack on OpenStack". So there's really one OpenStack deploying another OpenStack on Bare Metal. The aim is to ease operation of the overlying (productive) infrastructure. See also https://wiki.openstack.org/wiki/TripleO
Not sure if I'd classify the underlying OpenStack's bare metal instances as Pet or Cattle, TBH. But either way I don't think our cloud image needs to cover this use case as you really want to use tailored images (with the desired services already prepared, etc). So really just listing the use case FYI.
On 21/10/13 14:56, Matthew Miller wrote:
Also I was kind of hoping that we'd never have to worry about running on bare metal, but maybe that's fantasy. :)
Well, I was more thinking, if we're (as opposite to the server product) the only ones running on bare metal, and of course, the desktop group (most probable) too.
Because desktop is running on bare metal, I would expect, we don't need to worry about bare metal issues first/at all.
pet-vs-cattle: I'd expect every server to be a cattle: made of a description how to produce the service and a system image. I'd only expect a few underlying "servers" below the infrastructure to be pets at all. Especially compute nodes should be cattle here, the same applies to storage nodes.
I'd expect, not so many people would agree here, since it aggressively breaks with very traditional installs.
On Fri, Oct 18, 2013 at 01:59:30PM -0400, Matthew Miller wrote:
This is a message for people who have self-nominated for the Fedora Cloud Product Working Group (FCPWG?). As the FESCo coordinator for the group, it's my job to narrow down the list to the initial 9 voting members. I was going to send this individually, but then I thought, eh, let's do it in public. If you want to send me other thoughts off-line too, go for it. And if you're not in the list of nominees I'd still value your input into some of the concepts.
I've been the defacto maintainer of the Fedora cloud image kickstart for the past year or so (I have commit access, and I use it!), and I think that's gotten into fairly decent shape. This WG will be about going beyond decent and into something that's actually both very useful and well-used. I have some ideas for what that'd look like, but I'd like to hear yours too. And, I'm interested in hearing where you'd like to contribute in specific. I didn't see anyone mention QA on the nomination list, for example, and we'll need to find someone to take ownership of that.
In specific:
Would like to help with governance plan and documents, product definition, defining the target audience, and helping to promote the project to developers in the communities that are consuming cloud instances: e.g. AWS, CloudStack, Euca, OpenStack...
Part of that includes surveying and talking to folks who are consuming cloud images now and asking "where's the gap between what you use now and Fedora? What changes would make you interested in using Fedora and contributing to the project to sustain the instance images you need?"
Best,
jzb
On Fri, Oct 18, 2013 at 7:59 PM, Matthew Miller mattdm@fedoraproject.org wrote:
This is a message for people who have self-nominated for the Fedora Cloud Product Working Group (FCPWG?). As the FESCo coordinator for the group, it's my job to narrow down the list to the initial 9 voting members. I was going to send this individually, but then I thought, eh, let's do it in public. If you want to send me other thoughts off-line too, go for it. And if you're not in the list of nominees I'd still value your input into some of the concepts.
I've been the defacto maintainer of the Fedora cloud image kickstart for the past year or so (I have commit access, and I use it!), and I think that's gotten into fairly decent shape. This WG will be about going beyond decent and into something that's actually both very useful and well-used. I have some ideas for what that'd look like, but I'd like to hear yours too. And, I'm interested in hearing where you'd like to contribute in specific. I didn't see anyone mention QA on the nomination list, for example, and we'll need to find someone to take ownership of that.
Actually, I did mention QA on the nomination wiki page. I used to be part of the Fedora QA team (you can ask Adam or Tim if you want) back when I was heavily using Fedora as a Desktop OS (until about 1 year ago). My focus then changed to OpenStack and I'm interested in doing QA for the cloud image. Whenever I get the chance, I already give the Fedora Cloud Image (candidates) a quick spin. I usually get that done at least for the final Alpha / Beta / Gold and for most release candidates.
So, I'm experiences with Fedora QA and interested in Cloud QA. I can take ownership of QA in the FCPWG if desired.
Our actual deliverables are listed here: https://fedoraproject.org/wiki/Fedora.next/boardproposal#Product_Working_Gro... and they start with:
- Governance plan and documents
- A product definition -- target audience and so on
- A list of changes from existing procedures
- Actually doing things
You may notice that "actually doing things" is kind of far down the list, and there's some degree of.... procedural overhead. If you really hate that kind of thing, speak up now, because maybe this isn't the best use of your time. Although the voting membership is going to be limited, and focused on these things, we actually also need a broader, involved community, so not being on the WG doesn't mean you can't be involved in a meaningful way.
Since I also was a (appointed) founding member of the Community Working Group (CWG) which also started with a lot of not-actually-doing-things (mostly working out the code of conduct). I enjoyed the work there just as much as I enjoy actually getting things done. As long as it's constructive.
I posted a few weeks ago about possible directions for the cloud product. I am, by the way, pretty sure that we are talking about a cloud _guest_, and that being a base for cloud infrastructure systems like OpenStack or Eucalyptus is in the realm of the Server product (or possibly new, secondary products focused specifically on those use-cases).
Fair enough.
I've also heard a few comments suggesting that the cloud guest should basically just be the server product in image form, with cloud-init. This is a model where cloud computing is basically seen as providing "servers in the sky"; I think there's a place for that, but again, I don't think it's what we should be aiming at. The point of having this product as something different is so we can actually better address the different needs.
IMHO, there's a lot of similarities but yes, there are differences that should be treated as such. Still, there should probably be some exchange to keep the similarities as equal as possible so the experience keeps the same wherever it makes sense (sometimes, the cloud image should rather behave like all the other cloud images instead of like Fedora Server).
What that actually looks like is to be determined. The current target is basically "as minimal as possible, but not so minimal that we break stuff or make people's life harder". In the absence of better idea about what we're doing or what we're providing this image _for_, that's a fine, generic base. We have the opportunity now to write the better story, though... so, what are your ideas?
I follow up with comments to the ongoing discussion in this regard.
-- Sandro
On Mon, Oct 21, 2013 at 11:47:32AM +0200, Sandro red Mathys wrote:
Actually, I did mention QA on the nomination wiki page. I used to be part of the Fedora QA team (you can ask Adam or Tim if you want) back
Why so you did. Awesome. :)
On 18/10/13 19:59, Matthew Miller wrote:
This is a message for people who have self-nominated for the Fedora Cloud Product Working Group (FCPWG?). As the FESCo coordinator for the group, it's my job to narrow down the list to the initial 9 voting members. I was going to send this individually, but then I thought, eh, let's do it in public. If you want to send me other thoughts off-line too, go for it. And if you're not in the list of nominees I'd still value your input into some of the concepts.
Hey Matt,
first of all, I need to apologize for being so disruptive and bring up my thoughts so late.
Compared cloud SIG/WG to Fedora base/core or how you're calling it, one could compare it like RDO to RHEL (with way more QE both produce RHOS).
My personal background is, I'm working upsream/downstream on OpenStack for Red Hat (as you might know/have already guessed).
From product perspective, we have a major issue in system upgrades. It
gets harder, when you'd like to upgrade your infrastructure during production or with minimal disruption. This is something, Ubuntu/Debian does a lot better than us, but customers are asking for this and will ask for in the future.
I'm not sure, if this is something we can or even if we should try to solve in Fedora-land.
Count me in for the WG for all todo-items; I'm a packager, sponsor and proven packager in fedora, and a proven tester as well (although this doesn't count anything anymore)
Best regards, Matthias