Open Stack

On Mon, Jul 17, 2017 at 6:40 PM, Jay Pipes <jaypipes at 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+os at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev