Open Stack

Nice to see a discussion around this! I can have understanding for that 
Tomas, for sure, we all represent companies of different sizes, so our 
opinions will differ.

Though, I like the idea of an infrastructure, that is how we would like 
customers to build there solutions.

Even if we will have this on the agenda in Sydney at the Forum session I 
strongly encourage you to continue the discussion here by email, and 
would really like to have more opinions as from more cloud 
representatives...

Cheers,
Tobias


On 2017-10-24 16:29, Jean-Daniel Bonnetot wrote:
> We (OVH) gonna manage a limited quantity, step by step, to avoid 
> issues (hackers/miners).
>
> For example, we gonna start with a limit of 200 trials and see how 
> it's used, if the customers are here to try OpenStack or to mine 
> something... How long does it take to consume 200 trial...?
> Then we'll add 200 more or 1000 if everything is OK.
> Of course we'll try to not have a blank period between 2 batches.
>
> Like many public cloud providers, we used to have a lot of users with 
> bad intentions. We'll manage it as usual.
>
> About the reference infrastructure, I suggest to keep the idea of an 
> infrastructure, not a stand alone instance.
>
> Jean-Daniel Bonnetot
> ovh.com <http://ovh.com> | @pilgrimstack
>
>
>
>
>
>> On 24 Oct 2017, at 15:27, Tomáš Vondra <vondra at homeatcloud.cz 
>> <mailto:vondra at homeatcloud.cz>> wrote:
>>
>> Hi!
>> We would prefer a lower quota and/or duration of the trial.
>>
>> For one, if someone finds a reference architecture for Bitcoin 
>> mining, he could do quite a lot of damage on 8 CPUs.
>>
>> For two, I think the reference architecture is too complex. It is not 
>> something one would actually build to test a cloud. As for me, I 
>> would run one VM and do some low-level benchmarks.
>> On a conference workshop, I gave away accounts with a quota of 
>> 2/2/20, and we have fit in 2 instances of Wordpress, one of HAProxy 
>> and one of MySQL because we also offer a 0,5 CPU 0,5 RAM and 5 disk 
>> flavor. The user could also launch one instance of 2/2/20 and do some 
>> benchmarking if they wanted.
>>
>> The other possibility is to limit the number of concurrent trial 
>> accounts, which is I think also something that was said in these 
>> discussion circles. Etherpad, maybe?
>> Tomas from Homeatcloud
>>
>> -----Original Message-----
>> From: Tobias Rydberg [mailto:tobias at citynetwork.se]
>> Sent: Monday, October 23, 2017 4:45 PM
>> To: Jean-Daniel Bonnetot
>> Cc: passport at openstack.org <mailto:passport at openstack.org>; 
>> user-committee at lists.openstack.org 
>> <mailto:user-committee at lists.openstack.org>
>> Subject: Re: [User-committee] [publiccloud-wg][passport] Minimal offer
>>
>> On 2017-10-23 16:30, Jean-Daniel Bonnetot wrote:
>>>
>>>> On 22 Oct 2017, at 11:47, Tobias Rydberg <tobias at citynetwork.se 
>>>> <mailto:tobias at citynetwork.se>> wrote:
>>>>
>>>> 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.
>>> So what is your suggestion for Sydney? Every public cloud provider 
>>> do his best without a common base?
>> I would really like to have a common base for everyone for Sydney, 
>> though I believe we will have a hard time pull that through, hard 
>> enough to get all in with the information needed. From my POV I will 
>> make sure that we honor that reference specification, just to have 
>> that said.
>>
>> With that said, I guess that will be the case, but we can for sure 
>> try to push for the common spec. Wednesday is a good opportunity for 
>> that!
>>>> 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".
>>> Yep, I'll be there. Let's discuss it in Sydney with pleasure.
>> Sounds good!
>>>> 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_progr
>>>>> am.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
>>>>
>>
>>
>>
>
>
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20171025/5d88707d/attachment-0001.html>
-------------- 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/20171025/5d88707d/attachment-0001.bin>