Open Stack

Hi All,

 Thank you all for attending to meeting.
 You can find the meeting notes at following etherpad in section
[Notes from meeting 2016/05/18 Wed]
 https://etherpad.openstack.org/p/newton-instance-ha

 Next meeting will be on 5/23 Monday (normal IRC meeting).
 http://eavesdrop.openstack.org/#High_Availability_Meeting

--- Regards,
Sampath



On Tue, May 17, 2016 at 8:03 PM, Sam P <sam47priya at gmail.com> wrote:
> Hi All,
>
>  Since no objections raised, HA team VoIP meeting will shift to 9am
> UTC 18th May 2016.
>
> Here are the gotomeeting details for the meeting.
> 1.  Please join the meeting, May 18, 2016 at 18:00 GMT+9 (9am UTC).
> https://global.gotomeeting.com/join/424496645
> 2. You will be connected to audio using your computer's microphone and
> speakers (VoIP).  A headset is recommended.
> Meeting ID: 424-496-645
>
>
>
>
> I would like to add following topic to agenda.
> -------------------------------------------------------
> Instance HA API use case
>
>   We consider following use cases need APIs to manage instance HA in operation.
>   Detailed specs and database schema can be found at following link.
>   https://github.com/ntt-sic/masakari/wiki/Masakari-API-Design
>
> [Failover Segment]
> System can be zoned from top to down levels, into Regions,
> Availability Zones and Host Aggregates (or Cells). Within those zones,
> one or more pacemaker/pacemaker-remote clusters may exist. In addition
> to those boundaries, shared storage boundary is also important to
> decide the optimal host for fail-over. Openstack zoned boundaries
> (such as Regions, AZ, Host Aggregates, etc..) can be managed by the
> nova scheduler. However, shared storage boundaries are difficult to
> manage. Moreover, the operator may want to use other types of boundary
> such as rack layout and powering. Therefore, operator may want to
> define the segment of hypervisor hosts and assign the failover
> host/hosts for each of them. Those segment can be define based on the
> shared storage boundaries or any other limitations may critical for
> selection of the failover host.
>
> [Capacity Reservation]
> Service provider who ensures an uptime of VM instance to their
> customer needs to make sure that the certain amount of host capacity
> are reserved to prepare a failure event. If the host capacity of
> system is full and the host failure happens, the VM on the failure
> host cannot be evacuated to other host. The system capacity is
> typically fragmented into segments due to underlying component’s
> scalability and each segment has a limited capacity. To increase
> resource efficiency, high utilization of host capacity is preferred.
> However, as any user consume resources on demand, the host capacity of
> each segment tends to reach the full if the system doesn’t provides
> the way to reserve the portion of host capacity to the operators.
> Therefore, the function to reserve host capacity for failover event is
> important to ensure the high availability of VM instance.
>
> [Host Maintenance]
> A host has to be temporarily and safely removed from the system for
> the maintenance such as hardware failure, firmware update and so on.
> During the maintenance, the monitoring function on the host should be
> disabled and the monitoring alert from the host should be ignored not
> to trigger any recovery action of VM instance on the host if it’s
> running. The host should be excluded from reserved hosts as well.
> -------------------------------------------------------
> --- Regards,
> Sampath
>
>
>
> On Mon, May 9, 2016 at 8:45 PM, Adam Spiers <aspiers at suse.com> wrote:
>> Sam P <sam47priya at gmail.com> wrote:
>>> Hi All,
>>>
>>>  In today's ( 9th May 2016) meeting we agree to skip the next IRC
>>> meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
>>> 18th May 2016 (Wednesday).
>>>  Today's meeting logs and summary can be found here.
>>>  http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html
>>>
>>>  About the meeting Time:
>>>  Every one was convenient with 8:00am UTC.
>>>  However due to some resource allocation issues, I would like to shift
>>> this VoIP meeting to
>>>  9am UTC 18th May 2016
>>>
>>>  Please let me know if you are convenient or not with this time slot.
>>
>> That later time is fine for me :)  Thanks!
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev