Open Stack

We've pushed an updated license in.
 -nld


On Thu, May 16, 2013 at 5:36 PM, Narayan Desai <narayan.desai at gmail.com>wrote:

> In the rush to get the code posted concurrently with the paper submission,
> we missed this. It should be BSD licensed; that is our legal department's
> license of choice. Other licenses are possible, just not quickly ;)
>
> Our main intent here is to get the code and ideas out, so the licensing
> was a complete oversight.
>  -nld
>
>
> On Thu, May 16, 2013 at 5:00 PM, Jeremy Hanmer <
> jeremy.hanmer at dreamhost.com> wrote:
>
>> Any chance the license could get updated to something that would
>> encourage contributions?
>>
>>
>> On Thu, May 16, 2013 at 2:16 PM, Tim Bell <Tim.Bell at cern.ch> wrote:
>>
>>> ** **
>>>
>>> Poncho would be my nomination for best project name, although Ironic
>>> deserves a special award also..****
>>>
>>> ** **
>>>
>>> Looks very interesting …****
>>>
>>> ** **
>>>
>>> Tim****
>>>
>>> ** **
>>>
>>> *From:* Narayan Desai [mailto:narayan.desai at gmail.com]
>>> *Sent:* 16 May 2013 22:52
>>> *To:* Tim Bell
>>> *Cc:* openstack-operators at lists.openstack.org; Scott Devoid; Lorin
>>> Hochstein
>>> *Subject:* Re: [Openstack-operators] Graceful VM shutdown****
>>>
>>> ** **
>>>
>>> We (Scott Devoid, Lorin Hochstein, and myself) have built something to
>>> help with this class of problem, and submitted a paper to LISA about it.
>>> The paper is still under review, but the code is already up on github. We'd
>>> love feedback on the code or approach. ****
>>>
>>> ** **
>>>
>>> Our basic goal here was to start working with a user-annotated approach
>>> for load-shedding, which will open the door to a bunch of really
>>> interesting resource management techniques and reducing the impact of basic
>>> system operations tasks.****
>>>
>>> ** **
>>>
>>> The code is called poncho (since we needed it to deal with our "full
>>> cloud" ;) and is available here:****
>>>
>>> https://github.com/magellancloud/poncho****
>>>
>>> ** **
>>>
>>> It is definitely still under development, but we hope that it will prove
>>> out the concepts before we try to build a version that would be suitable
>>> for integration into openstack.****
>>>
>>> ** **
>>>
>>> I've attached a preprint of the paper to this mail.****
>>>
>>>  -nld****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> On Thu, May 16, 2013 at 1:02 PM, Tim Bell <Tim.Bell at cern.ch> wrote:****
>>>
>>>  ****
>>>
>>> I am interested to see how other service providers handle the cases
>>> where there is a need to reboot a hypervisor but it is planned (such as a
>>> reboot after OS patching).****
>>>
>>>  ****
>>>
>>> We do not want to do live or block migration for these cases as there is
>>> no shared storage and block migration can be a bit unreliable at times.*
>>> ***
>>>
>>>  ****
>>>
>>> In my ideal case, we would be able to warn the VMs in some way so they
>>> can do a reasonable job of shutting down. In some cases, our users would
>>> like many minutes of notice to complete their current transaction.****
>>>
>>>  ****
>>>
>>> Does anyone know of a standard mechanism for hypervisor communicating to
>>> the guest to warn of an impending shutdown ?****
>>>
>>>  ****
>>>
>>> Tim****
>>>
>>>  ****
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators*
>>> ***
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> 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/20130516/32757981/attachment.html>