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? - Should we be targeting ARM? - 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.)
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.
Best,
jzb
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
- 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.)
So, from a person that doesn't use cloud stuff but might actually want to try and create an image to make sure I don't break things (kernel maintenance is fun!), I'd really like one way to make images. Knowing all of the images are made one way makes it easier to spin my own to recreate and then test fixes, etc. If I have to worry about person X building one way and something breaking, but person Y building another way and it works, it's going to drive me crazy.
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.
Please! I really want to use more virt/cloudy things myself, but I'm lost in a sea of acronyms and ever-changing tools. Probably the nature of the ecosystem at the moment, but having clear documentation that a dumb kernel maintainer can read to make shiny things would be good.
josh
From the peanut gallery, feel free to treat accordingly.
On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
From a Cloud perspective, I don't know of a single public cloud using ARM.
There are tons of benefits to using ARM, but I am not seeing deployments personally. This is a nice to have IMO at this stage, though we shouldn't ignore it, I think the power savings will make it prominent in very short order, but not sure that it's in the purview of
- 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.)
So, from a person that doesn't use cloud stuff but might actually want to try and create an image to make sure I don't break things (kernel maintenance is fun!), I'd really like one way to make images. Knowing all of the images are made one way makes it easier to spin my own to recreate and then test fixes, etc. If I have to worry about person X building one way and something breaking, but person Y building another way and it works, it's going to drive me crazy.
So Fedora should have a way of building images - and that way should also be easily consumable by others. (e.g. Koji is probably not the best answer). Image Factory, Boxgrinder, Vagrant. Bonus points if we don't reinvent a tool and adopt something that the rest of the world is already consuming and familiar with.
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.
Please! I really want to use more virt/cloudy things myself, but I'm lost in a sea of acronyms and ever-changing tools. Probably the nature of the ecosystem at the moment, but having clear documentation that a dumb kernel maintainer can read to make shiny things would be good.
josh _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
----- Original Message -----
From: "David Nalley" david@gnsa.us To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Thursday, October 31, 2013 10:02:17 AM Subject: Re: ZOMG WHAT ARE WE BUILDING?!
From the peanut gallery, feel free to treat accordingly.
On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
From a Cloud perspective, I don't know of a single public cloud using ARM. There are tons of benefits to using ARM, but I am not seeing deployments personally. This is a nice to have IMO at this stage, though we shouldn't ignore it, I think the power savings will make it prominent in very short order, but not sure that it's in the purview of
- 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.)
So, from a person that doesn't use cloud stuff but might actually want to try and create an image to make sure I don't break things (kernel maintenance is fun!), I'd really like one way to make images. Knowing all of the images are made one way makes it easier to spin my own to recreate and then test fixes, etc. If I have to worry about person X building one way and something breaking, but person Y building another way and it works, it's going to drive me crazy.
So Fedora should have a way of building images - and that way should also be easily consumable by others. (e.g. Koji is probably not the best answer). Image Factory, Boxgrinder, Vagrant. Bonus points if we don't reinvent a tool and adopt something that the rest of the world is already consuming and familiar with.
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.
Please! I really want to use more virt/cloudy things myself, but I'm lost in a sea of acronyms and ever-changing tools. Probably the nature of the ecosystem at the moment, but having clear documentation that a dumb kernel maintainer can read to make shiny things would be good.
josh _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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 31 October 2013 08:10, Sam Kottler skottler@redhat.com wrote:
----- Original Message -----
From: "David Nalley" david@gnsa.us To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Thursday, October 31, 2013 10:02:17 AM Subject: Re: ZOMG WHAT ARE WE BUILDING?!
From the peanut gallery, feel free to treat accordingly.
On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com
wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
Well the cloud instances aren't running on 32 bit hardware. The cloud server is probably 64 bit xen but the instances are 128MB -> 256 MB instances from what I can tell.
On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler skottler@redhat.com wrote:
----- Original Message -----
From: "David Nalley" david@gnsa.us To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Thursday, October 31, 2013 10:02:17 AM Subject: Re: ZOMG WHAT ARE WE BUILDING?!
From the peanut gallery, feel free to treat accordingly.
On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
This is pretty much the only use case I hear of for 32bit images. Stupid question: is it somehow possible to force Python to behave like it was a 32bit system even though both the instance/VM and the image are actually 64bit?
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
From a Cloud perspective, I don't know of a single public cloud using ARM. There are tons of benefits to using ARM, but I am not seeing deployments personally. This is a nice to have IMO at this stage, though we shouldn't ignore it, I think the power savings will make it prominent in very short order, but not sure that it's in the purview of
I now we're getting closer to actually see ARM clouds (and think some private cloud proof of concepts are in their final stages). So yes, we should eventually support ARM. But right now? No. We really have enough on our plates by 1) defining how many and what images to produce, 2) implement all of them, 3) make sure we deliver the expected features and quality. Once we feel we're doing the right thing and are good at what we're doing, we can add the added complexity of ARM. Maybe we also have the necessary HW (or public clouds) to actually test ARM images by then.
- 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.)
So, from a person that doesn't use cloud stuff but might actually want to try and create an image to make sure I don't break things (kernel maintenance is fun!), I'd really like one way to make images. Knowing all of the images are made one way makes it easier to spin my own to recreate and then test fixes, etc. If I have to worry about person X building one way and something breaking, but person Y building another way and it works, it's going to drive me crazy.
So Fedora should have a way of building images - and that way should also be easily consumable by others. (e.g. Koji is probably not the best answer). Image Factory, Boxgrinder, Vagrant. Bonus points if we don't reinvent a tool and adopt something that the rest of the world is already consuming and familiar with.
+1 on supporting a single (or if good use cases are given) a very few methods. +1 on using an readily available, easy-to-use, flexible tool that everyone can spin up on their laptop if they want to do their own images. Bonus points if the tool is already widely adopted (which I don't think any is). +1 on using a tool/method that is not specific to Fedora (i.e. let e.g. Ubuntu users build Fedora images the same way).
IMHO it's also important that the method does not require the user to disable SELinux (as about half of them do).
More bonus points if the method allows for cross-building ARM images on x86(_64) systems. Not sure that's actually a good idea, though - I hear there's reasons Koji doesn't do this for package building.
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.
Please! I really want to use more virt/cloudy things myself, but I'm lost in a sea of acronyms and ever-changing tools. Probably the nature of the ecosystem at the moment, but having clear documentation that a dumb kernel maintainer can read to make shiny things would be good.
Not sure if that should be added to this discussion or not: we really need to find a way to release updated images more often. Spinning up dozens or hundreds of instances just to pull in hundreds of MBs of updates right away with each and every single one sucks.
-- Sandro
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Thu, 31 Oct 2013 15:34:39 +0100 "Sandro "red" Mathys" red@fedoraproject.org escribió:
On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler skottler@redhat.com wrote:
----- Original Message -----
From: "David Nalley" david@gnsa.us To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Thursday, October 31, 2013 10:02:17 AM Subject: Re: ZOMG WHAT ARE WE BUILDING?!
From the peanut gallery, feel free to treat accordingly.
On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
This is pretty much the only use case I hear of for 32bit images. Stupid question: is it somehow possible to force Python to behave like it was a 32bit system even though both the instance/VM and the image are actually 64bit?
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
From a Cloud perspective, I don't know of a single public cloud using ARM. There are tons of benefits to using ARM, but I am not seeing deployments personally. This is a nice to have IMO at this stage, though we shouldn't ignore it, I think the power savings will make it prominent in very short order, but not sure that it's in the purview of
I now we're getting closer to actually see ARM clouds (and think some private cloud proof of concepts are in their final stages). So yes, we should eventually support ARM. But right now? No. We really have enough on our plates by 1) defining how many and what images to produce, 2) implement all of them, 3) make sure we deliver the expected features and quality. Once we feel we're doing the right thing and are good at what we're doing, we can add the added complexity of ARM. Maybe we also have the necessary HW (or public clouds) to actually test ARM images by then.
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
- 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.)
So, from a person that doesn't use cloud stuff but might actually want to try and create an image to make sure I don't break things (kernel maintenance is fun!), I'd really like one way to make images. Knowing all of the images are made one way makes it easier to spin my own to recreate and then test fixes, etc. If I have to worry about person X building one way and something breaking, but person Y building another way and it works, it's going to drive me crazy.
So Fedora should have a way of building images - and that way should also be easily consumable by others. (e.g. Koji is probably not the best answer). Image Factory, Boxgrinder, Vagrant. Bonus points if we don't reinvent a tool and adopt something that the rest of the world is already consuming and familiar with.
+1 on supporting a single (or if good use cases are given) a very few methods. +1 on using an readily available, easy-to-use, flexible tool that everyone can spin up on their laptop if they want to do their own images. Bonus points if the tool is already widely adopted (which I don't think any is). +1 on using a tool/method that is not specific to Fedora (i.e. let e.g. Ubuntu users build Fedora images the same way).
IMHO it's also important that the method does not require the user to disable SELinux (as about half of them do).
More bonus points if the method allows for cross-building ARM images on x86(_64) systems. Not sure that's actually a good idea, though - I hear there's reasons Koji doesn't do this for package building.
We need one way, it needs to work both inside koji and outside. there is work to migrate to oz/imagefactory using qemu building images on x86 should be possible.
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.
Please! I really want to use more virt/cloudy things myself, but I'm lost in a sea of acronyms and ever-changing tools. Probably the nature of the ecosystem at the moment, but having clear documentation that a dumb kernel maintainer can read to make shiny things would be good.
Not sure if that should be added to this discussion or not: we really need to find a way to release updated images more often. Spinning up dozens or hundreds of instances just to pull in hundreds of MBs of updates right away with each and every single one sucks.
This is part of why I want someone from the cloud space to join releng and work on the tooling.
Dennis
On Thu, Oct 31, 2013 at 10:59:00AM -0500, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Thu, 31 Oct 2013 15:34:39 +0100 "Sandro "red" Mathys" red@fedoraproject.org escribió:
On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler skottler@redhat.com wrote:
----- Original Message -----
From: "David Nalley" david@gnsa.us To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Thursday, October 31, 2013 10:02:17 AM Subject: Re: ZOMG WHAT ARE WE BUILDING?!
From the peanut gallery, feel free to treat accordingly.
On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier jzb@redhat.com wrote:
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:
Note: I am a cloud newbie. Please bear with my stupid questions.
- Should we drop 32-bit?
I was under the impression that 32-bit guests on 64-bit hosts were fairly common for applications where the advantages of 64-bit address space isn't needed. E.g. "64-bit python sucks a lot". Maybe that's becoming less of a concern?
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
This is pretty much the only use case I hear of for 32bit images. Stupid question: is it somehow possible to force Python to behave like it was a 32bit system even though both the instance/VM and the image are actually 64bit?
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
From a Cloud perspective, I don't know of a single public cloud using ARM. There are tons of benefits to using ARM, but I am not seeing deployments personally. This is a nice to have IMO at this stage, though we shouldn't ignore it, I think the power savings will make it prominent in very short order, but not sure that it's in the purview of
I now we're getting closer to actually see ARM clouds (and think some private cloud proof of concepts are in their final stages). So yes, we should eventually support ARM. But right now? No. We really have enough on our plates by 1) defining how many and what images to produce, 2) implement all of them, 3) make sure we deliver the expected features and quality. Once we feel we're doing the right thing and are good at what we're doing, we can add the added complexity of ARM. Maybe we also have the necessary HW (or public clouds) to actually test ARM images by then.
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
AFAIK, the work was limited to supporting libvirt LXC on ARM with OpenStack. No one in their right mind should use that since it offers no meaningful security, since there was no work done to make OpenStack request use of SELinux or AppArmour for LXC.
I've not seen any patches (upstream at least) to support KVM on ARM in OpenStack from any Ubuntu devs, or indeed from anyone at all.
We're still pretty early in terms of KVM support for ARM, so one of the bigger problems is anyone getting access to hardware to actually test it with. I expect that will change significantly over the next year, to the extent that KVM + ARM will be more easily consumable by devs, and thus I'd expect OpenStack to have support for KVM ARM at some point during this next year. If no one else submits the changes required, I'll likely try to do them myself.
Regards, Daniel
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
AFAIK, the work was limited to supporting libvirt LXC on ARM with OpenStack. No one in their right mind should use that since it offers no meaningful security, since there was no work done to make OpenStack request use of SELinux or AppArmour for LXC.
Linaro is actively working on libvirt ARM for Openstack it but from some of their status reports the progress is slow.
I've not seen any patches (upstream at least) to support KVM on ARM in OpenStack from any Ubuntu devs, or indeed from anyone at all.
Well Linaro is working on it, I get the feeling they're not at the upstreaming point.
We're still pretty early in terms of KVM support for ARM, so one of the bigger problems is anyone getting access to hardware to actually test it with. I expect that will change significantly over the next year, to the extent that KVM + ARM will be more easily consumable by devs, and thus I'd expect OpenStack to have support for KVM ARM at some point during this next year. If no one else submits the changes required, I'll likely try to do them myself.
I think this is something we should aim for soon but not now, it'll become more relevant when aarch64 lands.
Peter
On 11/06/2013 05:58 PM, Peter Robinson wrote:
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
AFAIK, the work was limited to supporting libvirt LXC on ARM with OpenStack. No one in their right mind should use that since it offers no meaningful security, since there was no work done to make OpenStack request use of SELinux or AppArmour for LXC.
Linaro is actively working on libvirt ARM for Openstack it but from some of their status reports the progress is slow.
I've not seen any patches (upstream at least) to support KVM on ARM in OpenStack from any Ubuntu devs, or indeed from anyone at all.
Well Linaro is working on it, I get the feeling they're not at the upstreaming point.
Yupp, that's what I found out. There is a trystack.org instance running OpenStack on ARM, based on the work from Linaro.
Those ARM machines are probably not that common nowadays, but still I don't think we should exclude an arch right now.
Matthias
On Thu, Nov 07, 2013 at 09:28:31AM +0100, Matthias Runge wrote:
On 11/06/2013 05:58 PM, Peter Robinson wrote:
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
AFAIK, the work was limited to supporting libvirt LXC on ARM with OpenStack. No one in their right mind should use that since it offers no meaningful security, since there was no work done to make OpenStack request use of SELinux or AppArmour for LXC.
Linaro is actively working on libvirt ARM for Openstack it but from some of their status reports the progress is slow.
I've not seen any patches (upstream at least) to support KVM on ARM in OpenStack from any Ubuntu devs, or indeed from anyone at all.
Well Linaro is working on it, I get the feeling they're not at the upstreaming point.
Yupp, that's what I found out. There is a trystack.org instance running OpenStack on ARM, based on the work from Linaro.
I believe that is only running LXC, not KVM - at least it was last time I looked at it. There have been zero patches submitted for KVM ARM with OpenStack.
Daniel
On Thu, Nov 07, 2013 at 09:28:31AM +0100, Matthias Runge wrote:
Those ARM machines are probably not that common nowadays, but still I don't think we should exclude an arch right now.
If we have the resources to do ARM in addition to other, more immediately relevant targets, then we should be working on it. Otherwise, I think it'd make sense to plan to look at ARM down the road when it's more likely to be in demand. There's no sense in spending a lot of cycles working on an arch that isn't going to be used, but we need to be ready when ARM starts taking off there.
Do we have the resources currently to tackle ARM, or does it make sense to put it on the "roadmap" for F22, for instance?
Best,
jzb
On Wed, Nov 06, 2013 at 04:58:43PM +0000, Peter Robinson wrote:
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
AFAIK, the work was limited to supporting libvirt LXC on ARM with OpenStack. No one in their right mind should use that since it offers no meaningful security, since there was no work done to make OpenStack request use of SELinux or AppArmour for LXC.
Linaro is actively working on libvirt ARM for Openstack it but from some of their status reports the progress is slow.
I've not seen any patches (upstream at least) to support KVM on ARM in OpenStack from any Ubuntu devs, or indeed from anyone at all.
Well Linaro is working on it, I get the feeling they're not at the upstreaming point.
It would be nice to encourage them to participate in the upstream openstack community more - at least for them to tell the openstack-dev community what areas they're working on, so people don't duplicate work.
Daniel
On Thu, Oct 31, 2013 at 10:59:00AM -0500, Dennis Gilmore wrote:
I know ubuntu is working on supporting ARM in openstack, I really think we should as well. We should go big or go home. all of this change is about making Fedora bigger and better. This is a avenue we should pursue. while ppc is a secondary arch we need to also consider it. there is a lot of work inside of IBM on KVM and openstack.
I'd agree we need to target ARM at some point, not sure that it's a viable target for the majority of developers in the next 6-12 months (at minimum). As was mentioned earlier, no public cloud provider is offering ARM as an option currently or likely in the very near future.
Best,
jzb
On Thu, Oct 31, 2013 at 10:10:05AM -0400, Sam Kottler wrote:
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
I'm not too worried about an IaaS running 32-bit nodes, more a question of whether folks are choosing 32-bit or 64-bit for their workload on AWS or other providers.
Some very light research shows me that 32-bit is slightly less necessary now that AWS supports 64-bit across all instance types:
http://alestic.com/2012/03/ec2-64-bit
Best,
jzb
Agree - lots of situations where 32-bit is preferable, and in many cases still the defacto arch.
It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?
I'm not 100% certain but I believe hadoop algorithms are fairly optimised for 32 bit due to historical architectural reasons so that might be another use case.
Peter
Hi,
On 10/31/2013 03:02 PM, David Nalley wrote:
- Should we be targeting ARM?
Now? Maybe. In the future? Probably should, yes.
From a Cloud perspective, I don't know of a single public cloud using ARM. There are tons of benefits to using ARM, but I am not seeing deployments personally. This is a nice to have IMO at this stage, though we shouldn't ignore it, I think the power savings will make it prominent in very short order, but not sure that it's in the purview
I would encourage avoiding being tied to x86_64. Power64 (not so much) and ARM (more so) are going to be rich for the pickings for Linux IaaS and virt projects. It'll take a while, but I'm comfortable betting that the reduced space, power, electricity & heat of ARM will help it make inroads into servers fast. That said, I also think the same could be said of Bay Trail Atom systems now that they support virt extensions, run 64 bit, and appear to have overcome some of the heat issues earlier generations had. So don't forget Atom either.
So Fedora should have a way of building images - and that way should also be easily consumable by others. (e.g. Koji is probably not the best answer). Image Factory, Boxgrinder, Vagrant. Bonus points if we don't reinvent a tool and adopt something that the rest of the world is already consuming and familiar with.
Agreed!
Cheers, Dave.
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.
-
Daniel P. Berrange -
Dave Neary -
David Nalley -
Dennis Gilmore -
Haïkel -
Joe Brockmeier -
Josh Boyer -
Matthias Runge -
Peter Robinson -
Sam Kottler -
Sandro "red" Mathys -
Stephen John Smoogen