On Tue, Jul 18, 2017 at 2:39 PM, Balazs Gibizer
<balazs.gibi...@ericsson.com> wrote:
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.
I managed to create a functional test case that reproduces the above
problem https://review.openstack.org/#/c/485088/
BTW, should I open a bug for it?
I also filed a bug so that we can track this work
https://bugs.launchpad.net/nova/+bug/1705071
Cheers,
gibi
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
__________________________________________________________________________
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
