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 <sam47pr...@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 <aspi...@suse.com> wrote: >> Sam P <sam47pr...@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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev