Hi all,
During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing.
I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint.
And... go!
[1] https://fedorahosted.org/cloud/ticket/127
On Wed, Oct 28, 2015 at 2:43 PM, Joe Brockmeier jzb@redhat.com wrote:
Hi all,
During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing.
I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint.
Could you provide a bit more context without necessarily offering your suggestions? It's somewhat hard to discuss this without it going everywhere without some kind of background into the overlaps or disparities that you see.
josh
On 10/28/2015 03:03 PM, Josh Boyer wrote:
Could you provide a bit more context without necessarily offering your suggestions? It's somewhat hard to discuss this without it going everywhere without some kind of background into the overlaps or disparities that you see.
I can try to give some context, and yes we probably need some scope. To be clear, this isn't so much disparities/overlaps that *I* see - I just took the AI to start the discussion.
Cloud ticket 127 from roshi opened the discussion about the server WG wanting "to do some coordination with workstation and cloud" and asked for brainstorming. And then discussion followed which I won't try to summarize because I may not do it justice, so please see [1].
Some useful questions, though:
- Does the current set of editions make sense, as produced by the Cloud and Server WG?
- Is the distinction between Cloud and Server wrong?
There's a lot of history here - the Cloud group really started as a place to look at packaging OpenStack, OpenShift, Eucalyptus, CloudStack for Fedora. Then it evolved into cloud images and then a focus on Atomic.
- Should we have a "server" image in the cloud? Is the current suite of editions confusing?
And most importantly - what started the initial initial conversation, how should the Cloud & Server folks work together next release?
[1] https://fedorahosted.org/cloud/ticket/127
On Wed, Oct 28, 2015 at 06:08:13PM -0400, Joe Brockmeier wrote:
There's a lot of history here - the Cloud group really started as a place to look at packaging OpenStack, OpenShift, Eucalyptus, CloudStack for Fedora. Then it evolved into cloud images and then a focus on Atomic.
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
which says:
There are many potential cloud goals that we could be tackling, but I believe that a lot of people would agree with this proposed initial goal:
LET'S CREATE FEDORA EC2 IMAGES THAT DON'T SUCK.
(Although we did go to talking about packaging Eucalyptus by the next month.)
On 10/28/2015 07:42 PM, Matthew Miller wrote:
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
I stand, well sit, corrected. I was going off memory and wading through the original wiki materials, which ISTR were largely IaaS/PaaS focused.
Thanks!
jzb
I think this highlights the problem we're currently seeing with the Fedora Cloud Base adoption
On 10/28/2015 07:42 PM, Matthew Miller wrote:
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
There is no singular Fedora release anymore, so what are people getting when they install Cloud Base? The `cloudtoserver` script essentially disables cloud-init and installs Fedora Server. So what's in the Cloud Base box when we say it's the "base building block of the Fedora flavors"? What was the point of creating use case editions and not using them in the cloud?
I really don't want the answer [ ;-) ] b/c I think the right answer *should be* Fedora Server + required platform elements (cloud-init, cloud-initramfs-tools, etc). The Cloud base didn't change when the rest of Fedora did, and it should have. I see "cloud" as a platform like ARM and the use case for a Cloud Base image the same as any other server OS running in such a platform. I don't believe that folks working in cloud environments need a super minimal install everything OS for what they do.
Regardless of which SIG owns the work, I believe that the Cloud Base build and the Server build should be very tightly coupled. The edition should be Fedora Server, the ever shrinking minimal install target is a red herring, and the Cloud focus is making a Server "spin" (not sure if this is qualifies officially) for a known set IaaS providers.
I also think the Cloud Base could do with a bit of market research to see what other distros are providing in those IaaS platforms so we can avoid chasing geese.
-Matt M
On 03/11/15, Matt Micene wrote:
I think this highlights the problem we're currently seeing with the Fedora Cloud Base adoption
On 10/28/2015 07:42 PM, Matthew Miller wrote:
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
There is no singular Fedora release anymore, so what are people getting when they install Cloud Base? The `cloudtoserver` script essentially disables cloud-init and installs Fedora Server. So what's in the Cloud Base box when we say it's the "base building block of the Fedora flavors"? What was the point of creating use case editions and not using them in the cloud?
Because we can not even guess what all use cases people have while using a cloud instance? People generally take the base image, and have their own tooling (say ansible, or shell scripts) which deploys the required applications in the cloud. This is where the minimal cloud base image comes handy.
Kushal
Because we can not even guess what all use cases people have while using a cloud instance?
I'd say we have the same process with Server. Most people take a minimal server image and deploy required applications with their own tooling. There are some opinions (roles) that exist to do some common expected things, but (imo) rolekit is an opinionated configuration tooling system. Like ansible or shell scripts.
There's not a lot of difference between the major use cases of Server and Cloud, just an opinion on how minimal a Base should be.
- Matt M
On Wed, Nov 4, 2015 at 4:03 AM, Kushal Das mail@kushaldas.in wrote:
On 03/11/15, Matt Micene wrote:
I think this highlights the problem we're currently seeing with the
Fedora
Cloud Base adoption
On 10/28/2015 07:42 PM, Matthew Miller wrote:
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
There is no singular Fedora release anymore, so what are people getting when they install Cloud Base? The `cloudtoserver` script essentially disables cloud-init and installs Fedora Server. So what's in the Cloud Base box when we say it's the "base building block of the Fedora
flavors"?
What was the point of creating use case editions and not using them in
the
cloud?
Because we can not even guess what all use cases people have while using a cloud instance? People generally take the base image, and have their own tooling (say ansible, or shell scripts) which deploys the required applications in the cloud. This is where the minimal cloud base image comes handy.
Kushal
Fedora Cloud Engineer CPython Core Developer CentOS Cloud SIG lead http://kushaldas.in _______________________________________________ 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 Wed, Oct 28, 2015 at 6:08 PM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 03:03 PM, Josh Boyer wrote:
Could you provide a bit more context without necessarily offering your suggestions? It's somewhat hard to discuss this without it going everywhere without some kind of background into the overlaps or disparities that you see.
I can try to give some context, and yes we probably need some scope. To be clear, this isn't so much disparities/overlaps that *I* see - I just took the AI to start the discussion.
Cloud ticket 127 from roshi opened the discussion about the server WG wanting "to do some coordination with workstation and cloud" and asked for brainstorming. And then discussion followed which I won't try to summarize because I may not do it justice, so please see [1].
Read, thanks for the pointer.
Some useful questions, though:
- Does the current set of editions make sense, as produced by the Cloud
and Server WG?
Well, confusing on "what is the Cloud base image for" aside, I think the editions as produced make sense.
- Is the distinction between Cloud and Server wrong?
There's a lot of history here - the Cloud group really started as a place to look at packaging OpenStack, OpenShift, Eucalyptus, CloudStack for Fedora. Then it evolved into cloud images and then a focus on Atomic.
IMO, no it isn't wrong.
- Should we have a "server" image in the cloud? Is the current suite of
editions confusing?
I don't think it's confusing, but I also don't think having a server image in the cloud is a bad idea.
And most importantly - what started the initial initial conversation, how should the Cloud & Server folks work together next release?
Given that I only have tangential interest in either WG, this suggestion might not make sense. However, I see Server and Cloud as two separate but complimentary things. The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
So assuming we don't have one image for both, I think they can still work together more closely. I like the idea in the ticket of having a cloudtoserver script. I also like the idea of a server to cloud script that could convert a Server install into a Cloud image. If we were to take into account that an admin might want to provision a Server in a VM or on a bare metal machine and then say "take this and make it a cloud image" with said script, that might work well too. The Server image is easier for a human to use by far, and cloudify-ing a Server install into a deployable cloud image might result in a larger cloud image but some people won't care.
Anyway, the gist of my ramblings is that I think the two groups could compliment each other better but I still view them as separate Editions with separate (but possibly overlapping) audiences. My ramblings my be wrong, but they make sense in my head.
josh
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get our image adopted with something else. - lack of a great alternative.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
[1] https://github.com/tmrts/flamingo
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
I completely believe both of these.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
On Thu, Oct 29, 2015 at 8:30 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
I completely believe both of these.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :)
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
-Mike
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
On 10/29/2015 09:33 AM, Michael McGrath wrote:
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
What's the state of this at the moment?
On Thu, Oct 29, 2015 at 8:36 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/29/2015 09:33 AM, Michael McGrath wrote:
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
What's the state of this at the moment?
Joe Brockmeier | Community Team, OSAS jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
We're doing planning now for our next atomic deliverable, I'm advocating for it gets pulled into that.
On Thu, Oct 29, 2015 at 8:33 AM, Michael McGrath mmcgrath@redhat.com wrote:
On Thu, Oct 29, 2015 at 8:30 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
I completely believe both of these.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :)
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
+1
Sounds great, looking forward to more information on the topic.
-AdamM
-MikeAlso, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
-- Mike McGrath | mmcgrath@redhat.com | (312) 660-3547 Atomic | Red Hat Chicago | http://projectatomic.io/ _______________________________________________ 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 Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
On Thu, Oct 29, 2015 at 9:47 AM, Subhendu Ghosh sghosh151@gmail.com wrote:
On Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
josh
On 10/29/2015 09:50 AM, Josh Boyer wrote:
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
C'mon Josh. That *never* happens.
Best,
jzb
On Thu, Oct 29, 2015 at 9:01 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/29/2015 09:50 AM, Josh Boyer wrote:
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
C'mon Josh. That *never* happens.
And I think the scopes are a bit different. I'm hoping to bundle ansible modules with every %config that we ship starting with atomic host, but if it works it could be scoped out to the other packages as well. This is incredibly useful for things like docker build and makes writing playbooks easier.
-Mike
Best,
jzb
Joe Brockmeier | Community Team, OSAS 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 Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
At least mattdm knew of it because he mentioned it to me once when I was beating my head against the wall with it.
Peter
On Fri, Oct 30, 2015 at 11:20:36AM +0000, Peter Robinson wrote:
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
At least mattdm knew of it because he mentioned it to me once when I was beating my head against the wall with it.
Yeah, there's some discussion here: https://fedorahosted.org/cloud/ticket/23
On Fri, Oct 30, 2015 at 9:06 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Oct 30, 2015 at 11:20:36AM +0000, Peter Robinson wrote:
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
At least mattdm knew of it because he mentioned it to me once when I was beating my head against the wall with it.
Yeah, there's some discussion here: https://fedorahosted.org/cloud/ticket/23
Ah, cool. Thanks. Also, in my earlier reply I had misread "CoreOS" as "CentOS". It would have been even more disappointing if we weren't collaborating with CentOS than CoreOS. In the end, people seem to be aware of things anyway. Yay and stuff.
josh
To trow into the mix clear Linux reimplemented minimal cloud-init in C. See https://github.com/clearlinux/clr-cloud-init
/Rickard von Essen On Oct 29, 2015 2:47 PM, "Subhendu Ghosh" sghosh151@gmail.com wrote:
On Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24?
CC'ing
Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
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 Thursday, October 29, 2015 09:30:29 AM Josh Boyer wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
I have long said we need to provide packaged a service that can be run locally to provide the needed metadata, possibly having libvirt manage it. it should be trivial to import into virt-manager the cloud image and run it and have it be useful.
Dennis
On Mon, Nov 2, 2015 at 3:57 PM, Dennis Gilmore dennis@ausil.us wrote:
On Thursday, October 29, 2015 09:30:29 AM Josh Boyer wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the
single
offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and
Server
very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there.
If
it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
I have long said we need to provide packaged a service that can be run
locally
to provide the needed metadata, possibly having libvirt manage it. it
should
be trivial to import into virt-manager the cloud image and run it and
have it
be useful.
All you need is to create an OpenStack config drive and attach it to the VM. That can easily be scripted.
...Juerg
Dennis _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- Juerg Haefliger Hewlett-Packard
On Thursday, October 29, 2015 09:30:29 AM Josh Boyer wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
I have long said we need to provide packaged a service that can be run locally to provide the needed metadata, possibly having libvirt manage it. it should be trivial to import into virt-manager the cloud image and run it and have it be useful.
All you need is to create an OpenStack config drive and attach it to the VM. That can easily be scripted.
Is that the same as this procedure [1]? Or else can you point at the details?
[1] http://www.projectatomic.io/blog/2014/10/getting-started-with-cloud-init/
On Tue, Nov 3, 2015, at 04:28 AM, Peter Robinson wrote:
Is that the same as this procedure [1]? Or else can you point at the details?
[1] http://www.projectatomic.io/blog/2014/10/getting-started-with-cloud-init/
Yes. When I want to test the cloud image I often use: https://github.com/cgwalters/homegit/blob/master/bin/walters-create-cloud-vm for a small script which generates the ISO on demand from an already extracted user-data file. When using production infrastructure I normally set https://github.com/cgwalters/ansible-personal/blob/master/cloud-init/user-da... as a basic template.
I also have a `user-data.insecure` which hardcodes a password for local VMs, so usage looks like:
sudo walters-create-cloud-vm create --user-data /home/walters/Documents/user-data.insecure --name f22-atomic-test --image Fedora-Cloud-Atomic-22-20150720.x86_64
However another important point to make here is that "run a cloud image locally in libvirt on a workstation" is basically the use case for Vagrant - it does things like detecting the IP address so you can `vagrant ssh` etc.
On Tue, Nov 3, 2015 at 8:23 AM, Colin Walters walters@verbum.org wrote:
On Tue, Nov 3, 2015, at 04:28 AM, Peter Robinson wrote:
Is that the same as this procedure [1]? Or else can you point at the details?
[1] http://www.projectatomic.io/blog/2014/10/getting-started-with-cloud-init/
Yes. When I want to test the cloud image I often use: https://github.com/cgwalters/homegit/blob/master/bin/walters-create-cloud-vm for a small script which generates the ISO on demand from an already extracted user-data file. When using production infrastructure I normally set https://github.com/cgwalters/ansible-personal/blob/master/cloud-init/user-da... as a basic template.
I also have a `user-data.insecure` which hardcodes a password for local VMs, so usage looks like:
sudo walters-create-cloud-vm create --user-data /home/walters/Documents/user-data.insecure --name f22-atomic-test --image Fedora-Cloud-Atomic-22-20150720.x86_64
However another important point to make here is that "run a cloud image locally in libvirt on a workstation" is basically the use case for Vagrant - it does things like detecting the IP address so you can `vagrant ssh` etc.
I've been a fan of testcloud for this use case because I'm of the opinion that vagrant is overkill when all I want to do is boot a cloud image and ssh in.
https://github.com/Rorosha/testcloud
-AdamM
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 11/03/2015 11:24 AM, Adam Miller wrote:
I've been a fan of testcloud for this use case because I'm of the opinion that vagrant is overkill when all I want to do is boot a cloud image and ssh in.
I've lost track, have we packaged that for F23? I would love to recommend it.
Best,
jzb
On Tue, Nov 3, 2015 at 11:36 AM, Joe Brockmeier jzb@redhat.com wrote:
On 11/03/2015 11:24 AM, Adam Miller wrote:
I've been a fan of testcloud for this use case because I'm of the opinion that vagrant is overkill when all I want to do is boot a cloud image and ssh in.
I've lost track, have we packaged that for F23? I would love to recommend it.
Agreed. Having such utilities in Fedora would be excellent. Though I believe I actually tried to use this specific tool back at the origin of my complaints and it did not work for whatever reason.
josh
On Nov 3, 2015 10:36, "Joe Brockmeier" jzb@redhat.com wrote:
On 11/03/2015 11:24 AM, Adam Miller wrote:
I've been a fan of testcloud for this use case because I'm of the opinion that vagrant is overkill when all I want to do is boot a cloud image and ssh in.
I've lost track, have we packaged that for F23? I would love to recommend it.
Not yet, last I checked it was still pre-release upstream.
I just run it from a git checkout. :/
Will follow up on that tomorrow.
-AdamM
Best,
jzb
Joe Brockmeier | Community Team, OSAS 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 Tue, Nov 3, 2015 at 11:23 PM, Adam Miller maxamillion@gmail.com wrote:
On Nov 3, 2015 10:36, "Joe Brockmeier" jzb@redhat.com wrote:
On 11/03/2015 11:24 AM, Adam Miller wrote:
I've been a fan of testcloud for this use case because I'm of the opinion that vagrant is overkill when all I want to do is boot a cloud image and ssh in.
I've lost track, have we packaged that for F23? I would love to recommend it.
Not yet, last I checked it was still pre-release upstream.
I just run it from a git checkout. :/
Will follow up on that tomorrow.
Currently under package review but appears to be stalled. I will try and reach out to some folks and if we can't get movement on it, I'll take over review.
https://bugzilla.redhat.com/show_bug.cgi?id=1234649
-AdamM
-AdamM
Best,
jzb
Joe Brockmeier | Community Team, OSAS 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
However another important point to make here is that "run a cloud image locally in libvirt on a workstation" is basically the use case for Vagrant - it does things like detecting the IP address so you can `vagrant ssh` etc.
+1000
I'm trying to reproduce an issue in a not-vagrant-but-should-be-vagrant environment right now, and I'm tearing my hair out missing it.
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 Thu, Oct 29, 2015 at 1:16 PM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
This is one of the utilities I've often thought it would be great for the systemd group of utilities to absorb as it crosses over into a bunch of that space like setting hostnames, auth etc. I believe they'd likely do it some justice.
Peter
----- Original Message -----
From: "Joe Brockmeier" jzb@redhat.com To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org, server@lists.fedoraproject.org Sent: Wednesday, October 28, 2015 11:43:27 AM Subject: [DISCUSS] Cloud and Server Workgroup relationship
Hi all,
During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing.
I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint.
And... go!
My two cents: I'm looking at Fedora's editions with certain expectations. I see Workstation, and I know what I'm going to get and where I expect it to run. I see Server, and I expect:
* a fairly minimal image * something I can run on bare metal, VM or cloud
Instead, Server is a big image (2.1GB) that's not supposed to be run in the cloud.
Or, I assume I can rough something out w/ vagrant in VMs, and then deploy that on metal, but in Fedora, those are different variants, and things like LVM vs. no LVM (if I recall correctly) come into play, and there's no vagrant box for Fedora Server, because that's a cloud thing (I guess??). A no-cloud rule for Fedora Server feels antiquated and weird to me.
It's not the end of the world that my expected Fedora Server edition is in reality split into two separate editions, Server and Cloud, but I've seen it mentioned that Cloud Edition adoption has been slow -- it might be more findable for people if it's presented with or somehow integrated with the Server Edition.
Finally, I think that the movement of Fedora Atomic has been a bit slow, and I've witnessed the confusion of having cloud-base and atomic smushed together (in mtgs & such). If running well in cloud environments was part of the Server WG charter, and atomic was the focus in the Cloud WG, that'd be a cleaner arrangement. But, maybe this just means that atomic needs its own SIG (or WG -- I'm not 100% clear on the difference).
Of course, just because some might expect the Editions to work a certain way doesn't mean that this is the right way to do it, and I know that many things went into the definition of the WGs the way there are.
Regards, Jason
[1] https://fedorahosted.org/cloud/ticket/127
Joe Brockmeier | Community Team, OSAS jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
cloud@lists.stg.fedoraproject.org
-
Adam Miller -
Adam Miller -
Colin Walters -
Dennis Gilmore -
Jason Brooks -
Joe Brockmeier -
Josh Boyer -
Juerg Haefliger -
Kushal Das -
Matt Micene -
Matthew Miller -
Mike McGrath -
Peter Robinson -
Rickard von Essen -
Subhendu Ghosh