Hey Guys,
I was just wondering if the strategy will be the same for C7 as it was for C6 with regards to using Amazon Marketplace or not. I think some arguments have been made in the past that using the Marketplace approach limits flexibility. Is it possible to adopt the same strategy that fedora uses [1] and not use the Amazon Marketplace approach?
Thanks, Dusty
[1] https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:filter=al...
On 08/01/2014 10:04 PM, Dusty Mabe wrote:
Hey Guys,
I was just wondering if the strategy will be the same for C7 as it was for C6 with regards to using Amazon Marketplace or not. I think some arguments have been made in the past that using the Marketplace approach limits flexibility. Is it possible to adopt the same strategy that fedora uses [1] and not use the Amazon Marketplace approach?
What are the top 5 issues of using the AMP interface ?
- KB
On Mon, Aug 04, 2014 at 01:12:19PM +0100, Karanbir Singh wrote:
On 08/01/2014 10:04 PM, Dusty Mabe wrote:
Hey Guys,
I was just wondering if the strategy will be the same for C7 as it was for C6 with regards to using Amazon Marketplace or not. I think some arguments have been made in the past that using the Marketplace approach limits flexibility. Is it possible to adopt the same strategy that fedora uses [1] and not use the Amazon Marketplace approach?
What are the top 5 issues of using the AMP interface ?
I don't necessarily have 5 but I will give you a few.
- Using AMP there is a restriction on what you can do with snapshots/volumes that are derived from marketplace images. I imagine this is an effort to prevent people from copying the image and creating their own, but that doesn't really make sense with CentOS does it? I know other users have experienced this as well [1]. This is the message I get from the web console:
"Error attaching volume: 'vol-9dc7579c' with Marketplace codes may not be attached as a secondary device."
- When working in a larger organization where you may have IAM credentials to do a certain subset of tasks (i.e. only launch/destroy instances but nothing else) it becomes a pain to figure out what you need to do in order to enable launching of an AMI from AMP. This forces people to workaround the issue if they don't want to bother people, etc..
Considering the fact that there are (at least some) drawbacks to using AMP marketplace I guess it would be nice to know what the benefits are? If we can lay it all out on the table then perhaps we can understand why one choice is made over the other.
- Dusty
[1] https://aws.amazon.com/marketplace/review/product-reviews/ref=dtl_prp_review...
On 08/04/2014 07:00 PM, Dusty Mabe wrote:
On Mon, Aug 04, 2014 at 01:12:19PM +0100, Karanbir Singh wrote:
On 08/01/2014 10:04 PM, Dusty Mabe wrote:
Hey Guys,
I was just wondering if the strategy will be the same for C7 as it was for C6 with regards to using Amazon Marketplace or not. I think some arguments have been made in the past that using the Marketplace approach limits flexibility. Is it possible to adopt the same strategy that fedora uses [1] and not use the Amazon Marketplace approach?
What are the top 5 issues of using the AMP interface ?
I don't necessarily have 5 but I will give you a few.
- Using AMP there is a restriction on what you can do with snapshots/volumes that are derived from marketplace images. I imagine this is an effort to prevent people from copying the image and creating their own, but that doesn't really make sense with CentOS does it? I know other users have experienced this as well [1]. This is the message I get from the web console: "Error attaching volume: 'vol-9dc7579c' with Marketplace codes may not be attached as a secondary device." - When working in a larger organization where you may have IAM credentials to do a certain subset of tasks (i.e. only launch/destroy instances but nothing else) it becomes a pain to figure out what you need to do in order to enable launching of an AMI from AMP. This forces people to workaround the issue if they don't want to bother people, etc..
Considering the fact that there are (at least some) drawbacks to using AMP marketplace I guess it would be nice to know what the benefits are? If we can lay it all out on the table then perhaps we can understand why one choice is made over the other.
lower barrier to entry, access to wider resources at AWS, and being the recommended delivery format by AWS folks... Also, the general thinking is that folks who know what they are doing are going to byoi anyway, its the ones that done we want to help with the AMP.
Also, traditionally, we've never done anything that would be a one way vendor endorsement, AMP was a way for amazon to acknowledge we exist.
The plan here is to deliver AMP images, and also .raw backing files with manifests that allow people to either s3 or ebs inject their own images. I can easily complement that with a public shared image set as well ( we might need that in some AZ's regardless ). But we'd need to workout some way to work around cost of doing this. Were looking at a couple of hundred USD a month.
On Mon, Aug 04, 2014 at 08:26:49PM +0100, Karanbir Singh wrote:
On 08/04/2014 07:00 PM, Dusty Mabe wrote:
On Mon, Aug 04, 2014 at 01:12:19PM +0100, Karanbir Singh wrote:
On 08/01/2014 10:04 PM, Dusty Mabe wrote:
Considering the fact that there are (at least some) drawbacks to using AMP marketplace I guess it would be nice to know what the benefits are? If we can lay it all out on the table then perhaps we can understand why one choice is made over the other.
lower barrier to entry, access to wider resources at AWS, and being the recommended delivery format by AWS folks... Also, the general thinking is that folks who know what they are doing are going to byoi anyway, its the ones that done we want to help with the AMP.
BYOI. Yes that is typically the case. With cloud-init, however, I think people (at least the ones who know about it) will try to use an off-the-shelf image and just configure it on bringup using cloud-init. That way they don't have to manage their own images but simply the cloud-init configuration.
Also, traditionally, we've never done anything that would be a one way vendor endorsement, AMP was a way for amazon to acknowledge we exist.
The plan here is to deliver AMP images, and also .raw backing files with manifests that allow people to either s3 or ebs inject their own images. I can easily complement that with a public shared image set as well ( we might need that in some AZ's regardless ). But we'd need to workout some way to work around cost of doing this. Were looking at a couple of hundred USD a month.
This would be great! The flexibility of the public image is very desirable. I don't think it would be too hard for people to find if we had a page similar to the one Fedora has [1].
Thanks, Dusty