Hi All, I'd like to see if I can get some input on the current state of the Placement API split. For some background, the nova placement API was removed from nova in train, and it's been split into its own project. It's mostly just a basic API charm. The tricky part is the migration of tables from the nova_api database to the placement database. Code is located at: https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...) Test scenarios I've been testing with: 1) deploy nova-cc et al train, configure keystonev3, deploy instance 2) deploy nova-cc et al stein, configure keystonev3, deploy instance 1, deploy placement train, deploy instance 2, upgrade nova-cc to train, deploy instance 3 There is currently an issue with the second test scenario where instance 2 creation errors because nova-scheduler can't find a valid placement candidate (not sure of the exact error atm). However if I delete instance 1 before creating instance 2 it is created successfully. It feels like a DB related issue but I'm really not sure so I'll keep digging. Thanks! Corey
One other issue is "pxc-strict-mode: disabled" for percona-cluster is required to test this. /usr/share/placement/mysql-migrate-db.sh may need some updates but I haven't dug into that yet. Thanks, Corey On Fri, Oct 4, 2019 at 9:41 AM Corey Bryant <corey.bryant@canonical.com> wrote:
Hi All,
I'd like to see if I can get some input on the current state of the Placement API split.
For some background, the nova placement API was removed from nova in train, and it's been split into its own project. It's mostly just a basic API charm. The tricky part is the migration of tables from the nova_api database to the placement database.
Code is located at: https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement
https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...)
Test scenarios I've been testing with: 1) deploy nova-cc et al train, configure keystonev3, deploy instance 2) deploy nova-cc et al stein, configure keystonev3, deploy instance 1, deploy placement train, deploy instance 2, upgrade nova-cc to train, deploy instance 3
There is currently an issue with the second test scenario where instance 2 creation errors because nova-scheduler can't find a valid placement candidate (not sure of the exact error atm). However if I delete instance 1 before creating instance 2 it is created successfully. It feels like a DB related issue but I'm really not sure so I'll keep digging.
Thanks! Corey
On Fri, Oct 4, 2019 at 9:48 AM Corey Bryant <corey.bryant@canonical.com> wrote:
One other issue is "pxc-strict-mode: disabled" for percona-cluster is required to test this. /usr/share/placement/mysql-migrate-db.sh may need some updates but I haven't dug into that yet.
I have a review up for this issue now at: https://review.opendev.org/#/c/687056/ Thanks, Corey
On Fri, Oct 4, 2019 at 9:41 AM Corey Bryant <corey.bryant@canonical.com> wrote:
Hi All,
I'd like to see if I can get some input on the current state of the Placement API split.
For some background, the nova placement API was removed from nova in train, and it's been split into its own project. It's mostly just a basic API charm. The tricky part is the migration of tables from the nova_api database to the placement database.
Code is located at: https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement
https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...)
Test scenarios I've been testing with: 1) deploy nova-cc et al train, configure keystonev3, deploy instance 2) deploy nova-cc et al stein, configure keystonev3, deploy instance 1, deploy placement train, deploy instance 2, upgrade nova-cc to train, deploy instance 3
There is currently an issue with the second test scenario where instance 2 creation errors because nova-scheduler can't find a valid placement candidate (not sure of the exact error atm). However if I delete instance 1 before creating instance 2 it is created successfully. It feels like a DB related issue but I'm really not sure so I'll keep digging.
Thanks! Corey
On Fri, Oct 4, 2019 at 9:41 AM Corey Bryant <corey.bryant@canonical.com> wrote:
Hi All,
I'd like to see if I can get some input on the current state of the Placement API split.
For some background, the nova placement API was removed from nova in train, and it's been split into its own project. It's mostly just a basic API charm. The tricky part is the migration of tables from the nova_api database to the placement database.
Code is located at: https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement
https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...)
Test scenarios I've been testing with: 1) deploy nova-cc et al train, configure keystonev3, deploy instance 2) deploy nova-cc et al stein, configure keystonev3, deploy instance 1, deploy placement train, deploy instance 2, upgrade nova-cc to train, deploy instance 3
There is currently an issue with the second test scenario where instance 2 creation errors because nova-scheduler can't find a valid placement candidate (not sure of the exact error atm). However if I delete instance 1 before creating instance 2 it is created successfully. It feels like a DB related issue but I'm really not sure so I'll keep digging.
Nothing to see here. Small compute node with limited resources. So this is not an issue. Thanks!
Corey
On Fri, Oct 4, 2019 at 9:41 AM Corey Bryant <corey.bryant@canonical.com> wrote:
Hi All,
I'd like to see if I can get some input on the current state of the Placement API split.
For some background, the nova placement API was removed from nova in train, and it's been split into its own project. It's mostly just a basic API charm. The tricky part is the migration of tables from the nova_api database to the placement database.
Code is located at: https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement
https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...)
Test scenarios I've been testing with: 1) deploy nova-cc et al train, configure keystonev3, deploy instance 2) deploy nova-cc et al stein, configure keystonev3, deploy instance 1, deploy placement train, deploy instance 2, upgrade nova-cc to train, deploy instance 3
There is currently an issue with the second test scenario where instance 2 creation errors because nova-scheduler can't find a valid placement candidate (not sure of the exact error atm). However if I delete instance 1 before creating instance 2 it is created successfully. It feels like a DB related issue but I'm really not sure so I'll keep digging.
Thanks! Corey
In case anyone needs these for testing prior to the code getting merged I've pushed placement and nova-cloud-controller charms to the charm store under my namespace. I've released them to the edge channel. https://jaas.ai/u/corey.bryant/placement/bionic/0 https://jaas.ai/u/corey.bryant/nova-cloud-controller/bionic/0 Thanks, Corey
On Fri, Oct 4, 2019 at 3:46 PM Corey Bryant <corey.bryant@canonical.com> wrote:
Hi All,
Hey Corey, Great to see the charm coming along! Code is located at:
https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement
https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...)
1) Since the interface is new I would love to see it based on the ``Endpoint`` class instead of the aging ``RelationBase`` class. Also the interface code needs unit tests. We have multiple examples of interface implementations with both in place you can get inspiration from [0]. Also consider having both a ``connected`` and ``available`` state, the available state could be set on the first relation-changed event. This increases the probability of your charm detecting a live charm in the other end of the relation, both states are also required to use the ``charms.openstack`` required relation gating code. 2) In the reactive handler you do a bespoke import of the charm class module just to activate the code, this is no longer necessary as there has been implemented a module that does automatic search and import of the class for you. Please use that instead. [1] import charms_openstack.bus import charms_openstack.charm as charm charms_openstack.bus.discover() 0: https://github.com/search?q=org%3Aopenstack+%22from+charms.reactive+import+Endpoint%22&type=Code 1: https://github.com/search?q=org%3Aopenstack+charms_openstack.bus&type=Code -- Frode Nordahl
On Wed, Oct 9, 2019 at 2:06 AM Frode Nordahl <frode.nordahl@canonical.com> wrote:
On Fri, Oct 4, 2019 at 3:46 PM Corey Bryant <corey.bryant@canonical.com> wrote:
Hi All,
Hey Corey,
Great to see the charm coming along!
Code is located at:
https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement
https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...)
1) Since the interface is new I would love to see it based on the ``Endpoint`` class instead of the aging ``RelationBase`` class. Also the interface code needs unit tests. We have multiple examples of interface implementations with both in place you can get inspiration from [0].
Also consider having both a ``connected`` and ``available`` state, the available state could be set on the first relation-changed event. This increases the probability of your charm detecting a live charm in the other end of the relation, both states are also required to use the ``charms.openstack`` required relation gating code.
2) In the reactive handler you do a bespoke import of the charm class module just to activate the code, this is no longer necessary as there has been implemented a module that does automatic search and import of the class for you. Please use that instead. [1]
import charms_openstack.bus import charms_openstack.charm as charm
charms_openstack.bus.discover()
0: https://github.com/search?q=org%3Aopenstack+%22from+charms.reactive+import+Endpoint%22&type=Code 1: https://github.com/search?q=org%3Aopenstack+charms_openstack.bus&type=Code
-- Frode Nordahl
Hey Frode, Thanks very much for the input. I have these up in gerrit now with the changes you mentioned so I think we can move further reviews to gerrit: https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR+...) Thanks, Corey
participants (2)
-
Corey Bryant
-
Frode Nordahl