On Mon, Jul 17, 2017 at 6:40 PM, Jay Pipes <jaypi...@gmail.com> wrote:
On 07/17/2017 11:31 AM, Balazs Gibizer wrote:
> On Thu, Jul 13, 2017 at 11:37 AM, Chris Dent
<cdent...@anticdent.org>
> wrote:
>> On Thu, 13 Jul 2017, Balazs Gibizer wrote:
>>
>>>
/placement/allocation_candidates?resources=CUSTOM_MAGIC%3A512%2CMEMORY_MB%3A64%2CVCPU%3A1"
>>> but placement returns an empty response. Then nova scheduler falls
>>> back to legacy behavior [4] and places the instance without
>>> considering the custom resource request.
>>
>> As far as I can tell at least one missing piece of the puzzle here
>> is that your MAGIC provider does not have the
>> 'MISC_SHARES_VIA_AGGREGATE' trait. It's not enough for the compute
>> and MAGIC to be in the same aggregate, the MAGIC needs to announce
>> that its inventory is for sharing. The comments here have a bit
more
>> on that:
>>
>>
https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L663-L678
>
> Thanks a lot for the detailed answer. Yes, this was the missing
piece.
> However I had to add that trait both the the MAGIC provider and to
my
> compute provider to make it work. Is it intentional that the compute
> also has to have that trait?
No. The compute node doesn't need that trait. It only needs to be
associated to an aggregate that is associated to the provider that is
marked with the MISC_SHARES_VIA_AGGREGATE trait.
In other words, you need to do this:
1) Create the provider record for the thing that is going to share the
CUSTOM_MAGIC resources
2) Create an inventory record on that provider
3) Set the MISC_SHARES_VIA_AGGREGATE trait on that provider
4) Create an aggregate
5) Associate both the above provider and the compute node provider
with
the aggregate
That's it. The compute node provider will now have access to the
CUSTOM_MAGIC resources that the other provider has in inventory.
Something doesn't add up. We tried exactly your order of actions (see
the script [1]) but placement returns an empty result (see the logs of
the script[2], of the scheduler[3], of the placement[4]). However as
soon as we add the MISC_SHARES_VIA_AGGREGATE trait to the compute
provider as well then placement-api returns allocation candidates as
expected.
We are trying to get some help from the related functional test [5] but
honestly we still need some time to digest that LOCs. So any direct
help is appreciated.
BTW, should I open a bug for it?
As a related question. I looked at the claim in the scheduler patch
https://review.openstack.org/#/c/483566 and I wondering if that patch
wants to claim not just the resources a compute provider provides but
also custom resources like MAGIC at [6]. In the meantime I will go and
test that patch to see what it actually does with some MAGIC. :)
Thanks for the help!
Cheers,
gibi
[1] http://paste.openstack.org/show/615707/
[2] http://paste.openstack.org/show/615708/
[3] http://paste.openstack.org/show/615709/
[4] http://paste.openstack.org/show/615710/
[5]
https://github.com/openstack/nova/blob/0e6cac5fde830f1de0ebdd4eebc130de1eb0198d/nova/tests/functional/db/test_resource_provider.py#L1969
[6]
https://review.openstack.org/#/c/483566/3/nova/scheduler/filter_scheduler.py@167
Magic. :)
Best,
-jay
> I updated my script with the trait. [3]
>
>>
>> It's quite likely this is not well documented yet as this style of
>> declaring that something is shared was a later development. The
>> initial code that added the support for GET /resource_providers
>> was around, it was later reused for GET /allocation_candidates:
>>
>> https://review.openstack.org/#/c/460798/
>
> What would be a good place to document this? I think I can help with
> enhancing the documentation from this perspective.
>
> Thanks again.
> Cheers,
> gibi
>
>>
>> --
>> Chris Dent ┬──┬◡ﾉ(° -°ﾉ)
https://anticdent.org/
>> freenode: cdent tw:
@anticdent
>
> [3] http://paste.openstack.org/show/615629/
>
>
>
>
>
__________________________________________________________________________
> 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
__________________________________________________________________________
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
