Re: [openstack-dev] [HA] About next HA Team meeting (VoIP)

2016-05-18 Thread Sam P
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  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  wrote:
>> Sam P  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


Re: [openstack-dev] [HA] About next HA Team meeting (VoIP)

2016-05-17 Thread Sam P
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  wrote:
> Sam P  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


Re: [openstack-dev] [HA] About next HA Team meeting (VoIP)

2016-05-09 Thread Adam Spiers
Sam P  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-dev] [HA] About next HA Team meeting (VoIP)

2016-05-09 Thread Sam P
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.

--- Regards,
Sampath

__
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