These are available from
https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC5/Images/x86_64/
and
https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC5/Images/i386/
Please help test these, either in OpenStack (or other private cloud systems, like Eucalyptus), or in EC2 -- the AMI ids are
ami-e7a1f38e : us-east-1 image for x86_64 ami-6ba6f402 : us-east-1 image for i386
(you can confirm this by looking at files on the staging server)
The test cases are here:
https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_TC5_Install?rd=Te...
and the more people we have looking the better.
In particular beyond that basic smoketest, cloud-init has been updated to a new release with a lot of changes, and those things could stand to be exercised. See https://admin.fedoraproject.org/updates/FEDORA-2013-17760/cloud-init-0.7.2-7...
Thanks!
On Thu, Oct 17, 2013 at 09:10:47AM -0400, Matthew Miller wrote:
and the more people we have looking the better.
Spun this up on AWS, with an m1.small instance.
I've done a bit of basic testing, and everything seems to work well. Spun up the image, SSH'ed in, installed some packages, verified that Apache works, etc. I'm a bit swamped for time, so I haven't done extensive testing but I can at least verify that it boots, can serve pages, etc. without upchucking all over itself. If I have time, I'll try to do more extensive testing later.
Two things:
1) You get a complaint that delta RPM isn't enabled when installing packages. Not a major problem, but talking to Matthew we wondered whether we should include delta RPM by default or suppress the warning.
2) Firewall on by default is not a good thing. It took me a minute to realize *why* I couldn't hit the default Apache page after I'd fixed the Security Group settings for AWS. Users shouldn't have to muck with two firewalls - and if you're using AWS or an IaaS like CloudStack, the assumption is that the firewall will be handled by the IaaS, not the individual instance. I will follow up on previous threads about this.
Best,
jzb
On Thu, Oct 17, 2013 at 11:09:39AM -0500, Joe Brockmeier wrote:
- You get a complaint that delta RPM isn't enabled when installing
packages. Not a major problem, but talking to Matthew we wondered whether we should include delta RPM by default or suppress the warning.
In the past, I've found deltarpm to actually be slower when bandwidth is plentiful. The package itself is small, so I'll do some tests here.
- Firewall on by default is not a good thing. It took me a minute to
realize *why* I couldn't hit the default Apache page after I'd fixed the
Yes, as mentioned, this is a frequent complaint. In the past the majority opinion was that a basic packet filter was the best choice, but given the constant feedback I get to the contrary, I'm.... inclined to revisit.
Especially as we make the cloud image a) more visibile and b) more differentiated, I think this makes a lot of sense.
On 2013-10-17 9:15, Matthew Miller wrote:
On Thu, Oct 17, 2013 at 11:09:39AM -0500, Joe Brockmeier wrote:
- You get a complaint that delta RPM isn't enabled when installing
packages. Not a major problem, but talking to Matthew we wondered whether we should include delta RPM by default or suppress the warning.
In the past, I've found deltarpm to actually be slower when bandwidth is plentiful. The package itself is small, so I'll do some tests here.
When I did some testing around this on F17 I found that deltarpm not only increased update time by a non-trivial amount, but also generated extra I/O. It would be interesting to see how it behaves nowadays.
- Firewall on by default is not a good thing. It took me a minute to
realize *why* I couldn't hit the default Apache page after I'd fixed the
Yes, as mentioned, this is a frequent complaint. In the past the majority opinion was that a basic packet filter was the best choice, but given the constant feedback I get to the contrary, I'm.... inclined to revisit.
Especially as we make the cloud image a) more visibile and b) more differentiated, I think this makes a lot of sense.
Indeed. This sounds like a differentiator for the "server" and "cloud" products you proposed. 8^)
-- Garrett Holmstrom
On Thu, Oct 17, 2013 at 8:53 PM, Garrett Holmstrom gholms@fedoraproject.org wrote:
On 2013-10-17 9:15, Matthew Miller wrote:
On Thu, Oct 17, 2013 at 11:09:39AM -0500, Joe Brockmeier wrote:
- You get a complaint that delta RPM isn't enabled when installing
packages. Not a major problem, but talking to Matthew we wondered whether we should include delta RPM by default or suppress the warning.
In the past, I've found deltarpm to actually be slower when bandwidth is plentiful. The package itself is small, so I'll do some tests here.
When I did some testing around this on F17 I found that deltarpm not only increased update time by a non-trivial amount, but also generated extra I/O. It would be interesting to see how it behaves nowadays.
- Firewall on by default is not a good thing. It took me a minute to
realize *why* I couldn't hit the default Apache page after I'd fixed the
Yes, as mentioned, this is a frequent complaint. In the past the majority opinion was that a basic packet filter was the best choice, but given the constant feedback I get to the contrary, I'm.... inclined to revisit.
Crazy idea: disable the Firewall by default but allow users to enable it through cloud-init (i.e. user-data)? Just in case there are people who prefer the instance's firewall over security groups and open the latter up a lot / completely. Probably a stupid thought, but I thought I'd share it for the lulz.
Especially as we make the cloud image a) more visibile and b) more differentiated, I think this makes a lot of sense.
Indeed. This sounds like a differentiator for the "server" and "cloud" products you proposed. 8^)
-- Garrett Holmstrom _______________________________________________ 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 17, 2013 at 12:26 PM, Sandro "red" Mathys red@fedoraproject.org wrote:
Crazy idea: disable the Firewall by default but allow users to enable it through cloud-init (i.e. user-data)? Just in case there are people who prefer the instance's firewall over security groups and open the latter up a lot / completely. Probably a stupid thought, but I thought I'd share it for the lulz.
If nothing else, if you pass a script as user-data cloud-init will execute it late in the system's startup process. It looks for "#!".
-- Garrett Holmstrom
----- Original Message -----
From: "Garrett Holmstrom" gholms@fedoraproject.org To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Thursday, October 17, 2013 5:29:06 PM Subject: Re: please help test beta test candidate cloud images
On Thu, Oct 17, 2013 at 12:26 PM, Sandro "red" Mathys red@fedoraproject.org wrote:
Crazy idea: disable the Firewall by default but allow users to enable it through cloud-init (i.e. user-data)? Just in case there are people who prefer the instance's firewall over security groups and open the latter up a lot / completely. Probably a stupid thought, but I thought I'd share it for the lulz.
If nothing else, if you pass a script as user-data cloud-init will execute it late in the system's startup process. It looks for "#!".
Yep, that'd work although it's a little hacky. Writing cloud-init modules is super easy so we could also ship our own cloud-init module that would activate the instance's firewall based on some user data.
-- Garrett Holmstrom _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct