Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2 setup guide (pike only)

[Chen CH Ji]

Thanks for sharing, our zvm CI had exactly same issue those days , we need
'nova hypervisor-list' to be 'up' in order to do further conf/test
so ,even if nova service-list returns 'up' info but actually the host
mapping is not built and in turn you still can't schedule workload to it
so we build a loop and because the discovery hosts action are idempotent,
we build a loop and keep discover host until
the compute node is created and then in turn create the hostmap

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   04/17/2017 11:46 PM
Subject:    Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2
    setup guide (pike only)



On 4/16/2017 10:35 PM, Alex Xu wrote:
> Is it strange that the 'nova service-list' and 'nova host-list' return
> the hosts which didn't have host mapping yet?

It's kind of strange yes. We could probably make GET /os-hypervisors
work without requiring the host mappings, but it just doesn't today
because of some targeted calls within each cell to fill the response.

So we could probably decouple things a bit internally in the API if we
wanted to do this differently and not require a host mapping, but for
now I knew we could get the same results by just using os-services and
get Kolla unblocked (this came up Friday morning last week so I was
rushing for a solution).

>
> How the user to know whether a host was added to a cell or not?

A user doesn't need to know, but an operator would care. This actually
came up in IRC last week [1] when Kevin Fox was asking similar
questions, and I have a TODO to write some FAQs for cells v2.

We talked about how the "nova-manage cell_v2 discover_hosts" command is
idempotent and if there are new unmapped hosts you could just run it and
pick them up - the trick is knowing when to run it, unless you configure
the scheduler to use "discover_hosts_in_cells_interval" for auto-discovery.

We also talked about the option of building on the "nova-manage cell_v2
list_cells" command to also optionally dumping hosts per cell, or just
run the "nova-manage host list" command pointed at your cell config.

At some point we might want to consider returning cell uuid out of the
os-services API when listing services or hosts, something like that.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-10.log.html#t2017-04-10T20:25:47


--

Thanks,

Matt

__
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

Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2 setup guide (pike only)

[Matt Riedemann]

On 4/16/2017 10:35 PM, Alex Xu wrote:

Is it strange that the 'nova service-list' and 'nova host-list' return
the hosts which didn't have host mapping yet?


It's kind of strange yes. We could probably make GET /os-hypervisors 
work without requiring the host mappings, but it just doesn't today 
because of some targeted calls within each cell to fill the response.


So we could probably decouple things a bit internally in the API if we 
wanted to do this differently and not require a host mapping, but for 
now I knew we could get the same results by just using os-services and 
get Kolla unblocked (this came up Friday morning last week so I was 
rushing for a solution).




How the user to know whether a host was added to a cell or not?


A user doesn't need to know, but an operator would care. This actually 
came up in IRC last week [1] when Kevin Fox was asking similar 
questions, and I have a TODO to write some FAQs for cells v2.


We talked about how the "nova-manage cell_v2 discover_hosts" command is 
idempotent and if there are new unmapped hosts you could just run it and 
pick them up - the trick is knowing when to run it, unless you configure 
the scheduler to use "discover_hosts_in_cells_interval" for auto-discovery.


We also talked about the option of building on the "nova-manage cell_v2 
list_cells" command to also optionally dumping hosts per cell, or just 
run the "nova-manage host list" command pointed at your cell config.


At some point we might want to consider returning cell uuid out of the 
os-services API when listing services or hosts, something like that.


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-10.log.html#t2017-04-10T20:25:47


--

Thanks,

Matt

__
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

Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2 setup guide (pike only)

[Alex Xu]

Is it strange that the 'nova service-list' and 'nova host-list' return the
hosts which didn't have host mapping yet?

How the user to know whether a host was added to a cell or not?

2017-04-14 23:45 GMT+08:00 Matt Riedemann :

> Nova is working on adding multi-cell aware support to the compute API. A
> side effect of this is we can now have a chicken-and-egg situation during
> deployment such that if your tooling is depending on the compute API to
> list compute hosts, for example, before running the discover_hosts command,
> nothing will actually show up. This is because to list compute hosts, like
> using 'nova hypervisor-list', we get those from the cells now and until you
> run discover_hosts, they aren't mapped to a cell.
>
> The solution is to use "nova service-list --binary nova-compute" instead
> of "nova hypervisor-list" since we can pull services from all cells before
> the hosts are mapped using discover_hosts.
>
> I have a patch up to update our docs and add a release note:
>
> https://review.openstack.org/#/c/456923/
>
> I'll be updating the official install guide docs later.
>
> Note that this is master branch (Pike) only, this does not impact Ocata.
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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-dev] [nova][deployment] FYI: changes to cells v2 setup guide (pike only)

[Matt Riedemann]

Nova is working on adding multi-cell aware support to the compute API. A 
side effect of this is we can now have a chicken-and-egg situation 
during deployment such that if your tooling is depending on the compute 
API to list compute hosts, for example, before running the 
discover_hosts command, nothing will actually show up. This is because 
to list compute hosts, like using 'nova hypervisor-list', we get those 
from the cells now and until you run discover_hosts, they aren't mapped 
to a cell.


The solution is to use "nova service-list --binary nova-compute" instead 
of "nova hypervisor-list" since we can pull services from all cells 
before the hosts are mapped using discover_hosts.


I have a patch up to update our docs and add a release note:

https://review.openstack.org/#/c/456923/

I'll be updating the official install guide docs later.

Note that this is master branch (Pike) only, this does not impact Ocata.

--

Thanks,

Matt

__
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