Open Stack

I'm not aware of any blueprints for user selectable root or ephemeral
storage, but I do have similar use cases where adding yet another custom
flavor seems less than ideal.

In fact I'm personally not 100% happy with the idea of flavors, but they're
so entrenched as a basic concept I suspect implementing some form of
dynamic flavors would be a fairly large under taking.

-Jon


On Tue, Aug 6, 2013 at 1:25 PM, Damian <avghacker at gmail.com> wrote:

> In that one instance I would create a flavor with a larger root disk and
> allow only that one user to leverage that template.  Personally I think
> it's a bad habit that Microsoft created allowing/encouraging the
> installation of everything on the "C" drive.  Software like MS SQL is huge
> yes, but storing a DB on the root disk with the OS files is a bad practice.
>
> Even with a larger flavor for your one cloud user I would encourage them
> to leverage a separate disk/partition for their DB.
>
> -D
>
> On Aug 6, 2013, at 1:11 PM, Joe Topjian <joe.topjian at cybera.ca> wrote:
>
> Yes, that does make sense in a lot of ways, but in other ways, there are
> valid reasons for wanting a larger root disk size.
>
> The background of my inquiry comes from a cloud user who is unable to
> install Microsoft SQL Server on a volume (looking into this issue now) and
> as a supplementary question asked why they could not modify their root disk
> size like they can on AWS.
>
> The "serious abuse" is able to be mitigated by adding a new quota item for
> root disks size. It's a bit odd that quotas for root and ephemeral disks
> don't exist in the first place. I did a quick search and found that this
> was brought up previously:
>
> http://www.gossamer-threads.com/lists/openstack/dev/26069
>
>
>
>
> On Tue, Aug 6, 2013 at 11:00 AM, Damian <avghacker at gmail.com> wrote:
>
>> Wouldn't it make more sense to deploy m1.tiny instances (or whatever size
>> you need) and then mount additional storage through network based storage
>> like NFS?
>>
>> As already mentioned, if this was a feature it would lead to serious
>> abuse.  With a networked storage component you could easily expand quotas
>> for users and provide additional storage as needed.  Only downside I can
>> see here is cost & possibly performance if you have a poor network backend.
>>
>>
>> On Aug 6, 2013, at 11:48 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:
>>
>> Indeed. I believe there's currently no quota for root disk size
>> ("gigabytes" is only for volumes), so if this feature was implemented, it
>> would have to account for that.
>>
>>
>> On Tue, Aug 6, 2013 at 9:42 AM, Warren Wang <warren at wangspeed.com> wrote:
>>
>>> I agree with Joe. It would be a nice to have, though it tends to lead to
>>> abuse by users, but that is a totally different issue.
>>>
>>> --
>>> Warren
>>>
>>> On Aug 6, 2013, at 11:35 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:
>>>
>>> Hi,
>>>
>>> Yes, that's correct.
>>>
>>> However, what I'm looking for is the ability to change the "Disk"
>>> portion of the flavor on the fly while keeping the rest of the flavor
>>> attributes intact. This is possible in AWS.
>>>
>>> While I could create a new flavors for various root disk sizes
>>> (m1.tiny-10, m1.tiny-20, m1.tiny-30, m1.xlarge-10, m1.xlarge-20, etc etc),
>>> this still only allows for certain given sizes and wouldn't allow a user to
>>> specify a root disk of, say, 11 or 12gb. Not to mention the complexity of
>>> managing so many different flavors.
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>> On Tue, Aug 6, 2013 at 9:30 AM, JuanFra Rodriguez Cardoso <
>>> juanfra.rodriguez.cardoso at gmail.com> wrote:
>>>
>>>> Hi Joe,
>>>>
>>>> OpenStack make use of 'flavors' for defining sizes such as RAM, root
>>>> disk, swap... in your instances.
>>>> You can look
>>>> http://docs.openstack.org/trunk/openstack-ops/content/flavors.html for
>>>> extend the info.
>>>>
>>>> Regards,
>>>> ---
>>>> JuanFra
>>>>
>>>>
>>>> 2013/8/6 Joe Topjian <joe.topjian at cybera.ca>
>>>>
>>>>>  Hello,
>>>>>
>>>>> In Amazon AWS, when a user launches an instance, they have the ability
>>>>> to specify a custom root disk size. All other aspects of the flavor will
>>>>> stay the same.
>>>>>
>>>>>  Is this currently possible to do (Folsom+) or is there a blueprint to
>>>>> implement this? I apologize if there is -- I was unable to find one.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>> --
>>>>> Joe Topjian
>>>>> Systems Architect
>>>>> Cybera Inc.
>>>>>
>>>>> www.cybera.ca
>>>>>
>>>>> Cybera is a not-for-profit organization that works to spur and
>>>>> support innovation, for the economic benefit of Alberta, through the use
>>>>> of cyberinfrastructure.
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Joe Topjian
>>> Systems Architect
>>> Cybera Inc.
>>>
>>> www.cybera.ca
>>>
>>> Cybera is a not-for-profit organization that works to spur and support
>>> innovation, for the economic benefit of Alberta, through the use
>>> of cyberinfrastructure.
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>>
>> --
>> Joe Topjian
>> Systems Architect
>> Cybera Inc.
>>
>> www.cybera.ca
>>
>> Cybera is a not-for-profit organization that works to spur and support
>> innovation, for the economic benefit of Alberta, through the use
>> of cyberinfrastructure.
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> Joe Topjian
> Systems Architect
> Cybera Inc.
>
> www.cybera.ca
>
> Cybera is a not-for-profit organization that works to spur and support
> innovation, for the economic benefit of Alberta, through the use
> of cyberinfrastructure.
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130807/de217643/attachment.html>