09:00:02 <priteau> #startmeeting blazar
09:00:03 <openstack> Meeting started Tue Jun 16 09:00:02 2020 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:07 <openstack> The meeting name has been set to 'blazar'
09:00:26 <priteau> #topic Roll call
09:00:59 <suzhengwei> hi
09:01:15 <priteau> Hi suzhengwei, nice to see you here!
09:01:51 <suzhengwei> sorry for absent last meeting.
09:02:00 <priteau> Let's wait a few minutes for people to join
09:02:05 <priteau> ping tetsuro
09:02:17 <tetsuro> o/
09:02:48 <tetsuro> Hi priteau and suzhengwei, nice to see you
09:03:35 <priteau> The main topic for today is to discuss integration between Blazar and Masakari / Watcher
09:03:55 <priteau> This is why suzhengwei is here, thanks a lot
09:04:34 <suzhengwei> https://wiki.openstack.org/wiki/Masakari
09:04:39 <priteau> I don't think anyone else will join so let's start
09:04:43 <priteau> #topic Integration between Blazar and Masakari / Watcher
09:05:34 <suzhengwei> I would like to give a simple introduce of Masakari.
09:05:51 <suzhengwei> Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances.
09:06:15 <suzhengwei> When one host failed, Masakari will evacuate all instances from the failure host to other hosts.
09:06:58 <suzhengwei> Worsely, when large scale hosts failed, there is not enough resource to recovery all failed instances, so the reserved resource is very useful to the cloud patform.
09:07:43 <suzhengwei> Masakari tags some hosts as reserved hosts by itself, not through Blazer.
09:08:38 <suzhengwei> I wonder if Masakari can use reserved resources managed by Blazar.
09:08:51 <priteau> How does your host tagging work? Does it integrate with Nova?
09:09:46 <suzhengwei> No, Masakari just tag some hosts in its database.
09:11:04 <priteau> So it doesn't have any impact on scheduling decisions? Is it used as the target host for evacuation?
09:12:14 <suzhengwei> Yes, it used as the target host for evacuation. and it has problem on instance scheduling.
09:13:10 <priteau> So, let me present how Blazar works
09:13:30 <priteau> We have two modes of operation for compute resources: instance reservation and host reservation
09:14:20 <priteau> With instance reservation, you create a reservation for a number of instances (>= 1) with a given amount of vCPUs/RAM/disk, optionally with affinity or anti-affinity policies
09:14:43 <priteau> Blazar tracks resource allocation on hypervisors to make sure reserved resources are always available.
09:15:54 <priteau> With host reservation, you reserve a full hypervisor (or several). Once the reservation has started, you can launch instances on this/these hypervisor(s) until you reach their capacity.
09:17:33 <priteau> I don't think we've ever tried live migration with Blazar. I suppose it would work if done between hosts of the same host reservation, assuming there are enough spare resources.
09:17:59 <priteau> It doesn't really fit well with the instance reservation model though.
09:18:54 <suzhengwei> I wonder if reserved hosts managed by Blazar can be used by HA in special condition, such as large scale hosts failure.
09:20:04 <priteau> Host reservation would probably fit best with Masakari. You could have Masakari manage a reservation of spare hypervisors. When a hypervisor failure happens, remove a hypervisor from the reservation and use it as target?
09:20:24 <priteau> That's assuming the HA instances are not launched within a reservation to start with
09:21:24 <suzhengwei> yes.
09:22:20 <suzhengwei> But before introducing to the Masakari, I must be clear about Blazer's capabilities about host reserve.
09:22:30 <priteau> If HA instances are launched inside a host reservation, the spare hypervisor would probably have to be added to the reservation itself for the live migration to succeed
09:25:06 <priteau> suzhengwei: What kind of capabilities are you looking for?
09:25:39 <suzhengwei> If we want to evacuate instances to reserved host, should we remove the host from reserved hosts pool?
09:25:52 <suzhengwei> If nova-scheduler can select reserved hosts when instance migrate or evacuate?
09:27:00 <suzhengwei> If not, is it easy to tranfer one normal host to a reserved host, or tranfer a reserved host to one normal host?
09:27:26 <priteau> I am not completely sure about the behaviour of migration / evacuation with Blazar reservations, as I have never tried it, but I expect the Nova scheduler would prevent migration to a host in a different reservation
09:28:22 <priteau> Changing a reserved (or reservable host) to a normal host involves removing it from Blazar via the host-delete command (or DELETE API)
09:29:09 <priteau> I believe there are issues adding it back later, so if it's a behaviour that is needed by Masakari we would have to fix it
09:30:57 <priteau> Unless Masakari can use reserved hosts directly.
09:31:07 <priteau> How are HA instances created?
09:32:25 <priteau> Directly with Nova, or via a Masakari API?
09:32:28 <suzhengwei> It rebuild/evacuate the instance on other node when host failure.
09:32:38 <suzhengwei> via Nova.
09:33:54 <priteau> I mean the original instance, the one that failed
09:34:02 <priteau> Is it created directly by the user through Nova?
09:34:04 <suzhengwei> Maskari just detect the failure and trigger instances evacuation.
09:34:35 <suzhengwei> yes, created dtrectly via Nova.
09:36:32 <suzhengwei> Reserved hosts may be useful for Watcher project, too.
09:37:44 <priteau> What would Watcher do with reserved hosts?
09:39:43 <suzhengwei> In Watcher DPM(power saving) strategy, it could power on or off some reserved hosts, by comparing the number of reserved hosts with configure value.
09:42:51 <suzhengwei> Only partly reserved hosts is power-on. If more reserved hosts id needed, power on the rest.
09:43:02 <priteau> What I see would be really useful is powering off unreserved hosts until just before they are needed.
09:43:37 <priteau> Yeah that would be really cool.
09:44:23 <priteau> Does watcher listen for notifications before taking some decisions?
09:45:16 <suzhengwei> yes, it mainly listen for Nova/Neutron/Cinder notifications.
09:45:46 <suzhengwei> Of course, it can extend.
09:46:01 <priteau> Great, so the code to handle notifications is already in place
09:46:36 <priteau> Currently Blazar only sends notifications on start / before_end / end of reservations, but we could add a before_start which would trigger watcher actions
09:47:00 <priteau> We would need the hosts to power on a few minutes before a reservation starts, to make sure they are ready
09:47:04 <suzhengwei> it only handle special notification.
09:47:53 <suzhengwei> I would like to introduce Blazar to Watcher.
09:49:03 <priteau> I would be happy to collaborate with the Masakari and Watcher projects.
09:49:26 <priteau> I suggest the first step would be to gather design ideas into a common etherpad
09:49:34 <suzhengwei> yep
09:49:37 <priteau> Then turn it into a spec,
09:51:32 <suzhengwei> I will learn more of Blazar before integration.
09:53:32 <priteau> Should Masakari and Watcher integration be two completely separate efforts?
09:55:39 <suzhengwei> I think so. They are two separate projects, and difrrent framework.
09:56:10 <priteau> OK. And you are in both teams, but I guess not everyone is
09:56:26 <priteau> #action Create Etherpads for Masakari and Watcher integration with Blazar
09:56:52 <suzhengwei> diffirent framework
09:58:10 <suzhengwei> Time is out:)
09:58:27 <priteau> Thanks a lot for your time suzhengwei! We'll keep progress on Etherpads and will see when is the best time and place to chat next
09:58:36 <priteau> #topic AOB
09:58:48 <priteau> Skipping Victoria OpenStack-wide priorities for today, let's discuss next week
09:58:51 <priteau> Anything else to share today?
10:00:07 <priteau> Out of time. Thanks for joining!
10:00:10 <priteau> #endmeeting