Open Stack

Hi,

Thanks Jean-Daniel for a good initiative and a good email!

I totally agree that we need this clear reference point for this, even 
though I guess it won't be a "requirement" for the first release in 
Sydney, just since it's not enough time to get consensus in the matter.

Regarding the reference infrastructure I think it's good to use 
something that is already defined. I can probably be fine with that 
amount of resources, even though I generally think that half of it would 
be enough as well to evaluate a cloud in a trial. But as I said, like 
the reference to a reference infrastructure...

Earlier we haven't talked about Object Storage, not all participants 
offer that. Could be a part of the total storage amount any way. Also 
agree that we should remove all things like traffic and bandwidth from 
the equation.

@Jean-Daniel - are you coming to Sydney? This is a great topic for the 
"Passport Forum Session".

Thanks,
Tobias Rydberg
@tobberydberg


On 2017-10-19 17:57, Jean-Daniel Bonnetot wrote:
> Hi PCWG
>
> About the passport offering, we agreed on:
> * The message: "valid for at least XX resources on any participating public cloud for 1 month"
> * To avoid value comparison, agree on a minimal amount of resources a token would be valid (it's ok to offer more)
> (https://review.openstack.org/#/c/511252/1/doc/source/passport_program.rst)
>
> So here we have the message (XX ressources for a period of time) and the period (1 month).
> We need to define the minimal XX. Everybody can offer more of course.
>
> Let's try something like that:
> - As reference infrastructure, I propose this web app: https://www.openstack.org/software/sample-configs/#web-applications
> - As the first goal is to try OpenStack (APIs, fast delivery, features...) and not performances, let keep the smallest configuration
> 	- consider only the existing instances, not the auto-scaling ones
> 	- each nova instance is 1vCPU, 1GB RAM, 5GB disk
> 	- each cinder volume is 10GB
> 	- each swift repository is 10GB
> 	- consider special features as +1 instance, for example some of us don't have the LB feature
> 	- remove the bandwidth and traffic question from the minimal offer
> 	- remove the heat question too (that means metrics, triggers....)
>
> Some calculation latter, the minimal offer could be announced like that:
> - 8 vCPUs
> - 8GB RAM
> - 40GB for local storage
> - 20GB for remote block storage
> - 10GB for object storage
> => up and running for one month
>
> Is that ok for you?
> We can round up some values if you think it's better, and/or group some parts (like storage to simplify to 100GB of storage)
>
> So the final message from the foundation could be:
> 1. Valid for at least 8vCPUs, 8GB of RAM, 40GB of local storage, 20GB of remote block storage and 10GB of object storage on any participating public cloud for 1 month
> or
> 2. Valid for at least 8vCPUs, 8GB of RAM, 100GB of storage on any participating public cloud for 1 month
>
> Then to estimate your offer, you can just take reference infrastructure as describe previously and calculate the price for one month, or if your billing model match with 8vCPUs, 8GB or RAM... it's even more simple. Over that, offer what you want depending on your marketing strategy.
>
> How does it sound to you? Is it reasonable for your?
>
>
> Jean-Daniel Bonnetot
> ovh.com | @pilgrimstack
>
>
>
>
>
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3945 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20171022/baf7d3ec/attachment.bin>