Re: Testing of http://dl.fedoraproject.org/pub/alt/stage/21-20150309/Cloud-Images/x86_64/Images/

2015-03-20 Thread Juerg Haefliger
On Thu, Mar 19, 2015 at 1:56 PM, Joe Brockmeier  wrote:
> On 03/19/2015 06:22 AM, Kushal Das wrote:
>>
>> I tested the images locally following the cloud tests. They passed
>> successfully. But I failed to make them to boot on fed-cloud02.
>
> This is converting b/c images are actually qcow3 and OpenStack doesn't
> love qcow3? (or v3 qcow2, if you prefer)

Depends on the version of the underlying qemu, OpenStack shouldn't
care. FWIW HP Public Cloud can't handle v3 yet.

...Juerg


> Best,
>
> jzb
> --
> Joe Brockmeier | Project Atomic Doer of Things
> j...@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
>



-- 
Juerg Haefliger
Hewlett-Packard
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Re: Cloud image lifetimes

2015-03-20 Thread Juerg Haefliger
On Thu, Mar 19, 2015 at 1:58 PM, Ryan Brown  wrote:
> On 03/19/2015 08:54 AM, Joe Brockmeier wrote:
>> On 03/18/2015 06:38 PM, David Gay wrote:
>>> Greetings!
>>>
>>> We sort of ran out of time in today's Cloud WG meeting, but I did want
>>> to ask:
>>>
>>> What are your thoughts on AMI lifetimes? That is to say, how long should
>>> EC2 AMIs exist before they're deleted? A few points to consider:
>>
>> I feel like I should know this, but I don't.
>>
>> If a user spins up an AMI and then it's deleted by the provider, do they
>> still have their instance(s) or do they lose the ability to create new
>> images?
>
> The instances they already started would still run and be available, but
> they wouldn't be able to spin up anything new. If creating/killing
> instances is something they do a lot (autoscaling groups, worker farms,
> etc) then that could hose them just as surely as killing their existing
> instances.

We (HP Public Cloud) even had a customer yell at us after we changed
the name of an image because that was what they were using in their
tooling to spin up instances. I'd be very careful not to break
customers and clearly communicate and have the image lifecycle
officially documented. We always advise customers to take snapshots
and use those instead of the base images so that the image is fully
under their control. But customers don't always listen...


>> That would color my response a bit.
>>
>> Do we know how other projects handle theirs? If I go to spin up a Foo
>> Linux release from 2 years ago, is the AMI still there?
>>
>> At minimum, we should probably delete any AMIs that are no longer a
>> supported version of Fedora, and I'd also be for deleting any TC, alpha,
>> beta, etc. AMIs - especially once a release is published. So, for
>> instance, any F21 alpha, beta, etc. AMIs can probably go to the great
>> bit bucket in the sky at this point.
>>
>> Also wonder if this is something we need to have ACK'ed by FESCo?
>>
>> Best,
>>
>> jzb
>>
>>
>>
>> ___
>> cloud mailing list
>> cloud@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
>
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
> ___
> 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
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Re: Cloud image lifetimes

2015-03-20 Thread Juerg Haefliger
On Thu, Mar 19, 2015 at 3:09 PM, Dennis Gilmore  wrote:
> On Thursday, March 19, 2015 08:45:36 AM Joe Brockmeier wrote:
>> On 03/19/2015 12:11 AM, M. Edward (Ed) Borasky wrote:
>> > If you have raw data, I'd be happy to explore it for you - email me
>> > off-list if you need an NDA or something like that.
>>
>> Any data we have should be shared with all or none. We don't have a
>> Fedora NDA AFAIK.
>>
>> Best,
>>
>> jzb
> AFAIK amazon does not make available any usage data at all.

I think could get you data from HP Public Cloud if that is useful. Let me know.

...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
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Re: Fedora EC2 Amis: SriovNetSupport

2015-03-20 Thread milanisko k
That would be one way.
However, since it actually is a majority of the instance types[1] that
support this feature, I'd vote to make it the default.
That's unless it prevents using/booting the "small" instances of course,
what AFAIK isn't the case --- I was able to create a snapshot ami from an
F21 instance,
register it with the sriov flag and boot both a t2 and an r3 instances
without any issue and confirmed the sriov flag was in effect on the r3
instance.
The only limit I know of is the ami has to be HVM[2].
Moreover, the feature is for free, no extra charges apply so why not to
take advantage of lower latencies on the instances.

Cheers,
milan

[1] Enhanced Networking Support, The Instance Types Matrix,
http://aws.amazon.com/ec2/instance-types/
[2] Enabling Enhanced Networking on Other Linux Distributions,
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html



2015-03-19 18:39 GMT+01:00 Garrett Holmstrom :

> On 2015-03-19 9:11, milanisko k wrote:
>
>> I'd like to ask about the status/plan of SriovNet support[1] for Fedora
>> Amazon images.
>> I was able to set this up manually for recent F21 ami ami-5cd9ea41, but
>> it is quite an inconvenient experience --- one has to instantiate, stop,
>> set attribute value through the CLI tool and start again to enable the
>> feature.
>> Would it be possible to register future Fedora amis with the enhanced
>> networking flag enabled[1]?
>> As far as motivation is concerned, please check the blog post[2] for
>> some performance evaluation.
>>
>
> Since that only works for some types of instances it wouldn't make sense
> to do that for all images, but registering a separate image (from the same
> bundle/snapshot) with that enabled would be reasonable.
>
> --
> 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
>
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Re: NetworkManager and network services both enabled in Fedora Atomic

2015-03-20 Thread Colin Walters


On Thu, Mar 19, 2015, at 01:09 PM, Matthew Miller wrote:
> On Thu, Mar 19, 2015 at 12:47:22PM -0400, Dusty Mabe wrote:
> > I would suggest that we adopt the approach that Fedora Cloud Base
> > takes by just having the Network service enabled. This would also mean
> > we can pull the NetworkManager packages out of atomic and make the
> > image smaller.
> 
> I'm in favor. For F23, we should look at NetworkManager (or
> _possibly_ systemd-networkd) again —
> https://bugzilla.redhat.com/show_bug.cgi?id=863515 should be in place,
> so nothing will need to persist, and NetworkManager should be using the
> new lighter-weight dhcp client from systemd-networkd, 

We can do this latter bit right now.  Just tested and it works:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f22&id=cde583e3a2e2f79e0e4719a05a773b5a74a6bf92
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct