2015-01-09 22:22 GMT+08:00 Sylvain Bauza <sba...@redhat.com>: > > Le 09/01/2015 14:58, Alex Xu a écrit : > > > > 2015-01-09 17:17 GMT+08:00 Sylvain Bauza <sba...@redhat.com>: > >> >> Le 09/01/2015 09:01, Alex Xu a écrit : >> >> Hi, All >> >> There is bug when running nova with ironic >> https://bugs.launchpad.net/nova/+bug/1402658 >> >> The case is simple: one baremetal node with 1024MB ram, then boot two >> instances with 512MB ram flavor. >> Those two instances will be scheduling to same baremetal node. >> >> The problem is at scheduler side the IronicHostManager will consume all >> the resources for that node whatever >> how much resource the instance used. But at compute node side, the >> ResourceTracker won't consume resources >> like that, just consume like normal virtual instance. And ResourceTracker >> will update the resource usage once the >> instance resource claimed, then scheduler will know there are some free >> resource on that node, then will try to >> schedule other new instance to that node. >> >> I take look at that, there is NumInstanceFilter, it will limit how many >> instance can schedule to one host. So can >> we just use this filter to finish the goal? The max instance is >> configured by option 'max_instances_per_host', we >> can make the virt driver to report how many instances it supported. The >> ironic driver can just report max_instances_per_host=1. >> And libvirt driver can report max_instance_per_host=-1, that means no >> limit. And then we can just remove the >> IronicHostManager, then make the scheduler side is more simpler. Does >> make sense? or there are more trap? >> >> Thanks in advance for any feedback and suggestion. >> >> >> >> Mmm, I think I disagree with your proposal. Let me explain by the best >> I can why : >> >> tl;dr: Any proposal unless claiming at the scheduler level tends to be >> wrong >> >> The ResourceTracker should be only a module for providing stats about >> compute nodes to the Scheduler. >> How the Scheduler is consuming these resources for making a decision >> should only be a Scheduler thing. >> > > agreed, but we can't implement this for now, the reason is you described > as below. > > >> >> Here, the problem is that the decision making is also shared with the >> ResourceTracker because of the claiming system managed by the context >> manager when booting an instance. It means that we have 2 distinct decision >> makers for validating a resource. >> >> > Totally agreed! This is the root cause. > > >> Let's stop to be realistic for a moment and discuss about what could >> mean a decision for something else than a compute node. Ok, let say a >> volume. >> Provided that *something* would report the volume statistics to the >> Scheduler, that would be the Scheduler which would manage if a volume >> manager could accept a volume request. There is no sense to validate the >> decision of the Scheduler on the volume manager, just maybe doing some >> error management. >> >> We know that the current model is kinda racy with Ironic because there is >> a 2-stage validation (see [1]). I'm not in favor of complexifying the >> model, but rather put all the claiming logic in the scheduler, which is a >> longer path to win, but a safier one. >> > > Yea, I have thought about add same resource consume at compute manager > side, but it's ugly because we implement ironic's resource consuming method > in two places. If we move the claiming in the scheduler the thing will > become easy, we can just provide some extension for different consuming > method (If I understand right the discussion in the IRC). As gantt will be > standalone service, so validating a resource shouldn't spread into > different service. So I agree with you. > > But for now, as you said this is long term plan. We can't provide > different resource consuming in compute manager side now, also can't move > the claiming into scheduler now. So the method I proposed is more easy for > now, at least we won't have different resource consuming way between > scheduler(IonricHostManger) and compute(ResourceTracker) for ironic. And > ironic can works fine. > > The method I propose have a little problem. When all the node allocated, > we still can saw there are some resource are free if the flavor's resource > is less than baremetal's resource. But it can be done by expose > max_instance to hypervisor api(running instances already exposed), then > user will now why can't allocated more instance. And if we can configure > max_instance for each node, sounds like useful for operator also :) > > > > I think that if you don't want to wait for the claiming system to happen > in the Scheduler, then at least you need to fix the current way of using > the ResourceTracker, like what Jay Pipes is working on in his spec. >
I'm with your guys at same line now :) > > > > -Sylvain > > >> -Sylvain >> >> [1] https://bugs.launchpad.net/nova/+bug/1341420 >> >> Thanks >> Alex >> >> >> _______________________________________________ >> OpenStack-dev mailing >> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
