Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-19
07:26:50 bauzas good morning stackers
07:27:16 bauzas sorrison: this is correct
07:27:57 bauzas dpawlik_: a super conductor is just a normal conductor with a specific configuration
07:30:24 dpawlik_ bauzas: but its reading amqps queue from vhost / and its also talking with nova_cell0 db yes?
07:31:01 dpawlik_ and the second conductor e.g. cell1 is reading from another vhost e.g. nova_cell1 and its also puting data to nova_cell1 db
07:31:26 dpawlik_ I just describe my point of knowledge how it should be configured, is it true?
07:32:01 dpawlik_ I just take it from devstack
07:32:33 dpawlik_ and Im wondering why after executing the same commands like it is done on devstack, on my controller I have duplicated nova services
07:40:20 bauzas dpawlik_: sorry, I was on mute so I missed your ping
07:40:41 bauzas dpawlik_: hold on, we have some docs that explain this
07:40:59 dpawlik_ bauzas: thx
07:41:57 bauzas dpawlik_: https://docs.openstack.org/nova/latest/user/cells.html#setup-of-cells-v2
07:42:20 bauzas dpawlik_: and https://docs.openstack.org/nova/latest/user/cellsv2-layout.html
07:42:31 bauzas hope that will help you understand the cells v2 concepts
07:42:34 dpawlik_ So im doing the same how its described and TBH its not working well
07:42:47 dpawlik_ Im still have duplication of nova services
07:43:03 dpawlik_ yesterday I send it to dansmith how my cell mappings looks like
07:43:24 dpawlik_ and let me quote "looks like only one mapping in there, so I guess you're good"
07:45:40 dpawlik_ hmm, clean host, new day
07:45:41 dpawlik_ bauzas:
07:45:50 dpawlik_ bauzas: pro tip to setup cells
07:46:09 bauzas how many services are you running in parallel ?
07:46:13 dpawlik_ stop nova-conductor services before start setup cells_v2
07:46:45 bauzas dpawlik_: you're in an upgrade case or greenfields ?
07:47:29 dpawlik_ bauzas: for now Im just testing deployment queens release on new infra
07:47:42 dpawlik_ for now I don't want to touch "upgrade" procedure
07:47:49 bauzas but yeah, I'm assuming you populate the mappings first before starting the services
07:48:03 bauzas since those services use the mappings you need to set
07:48:24 dpawlik_ Now I will know
07:48:24 bauzas dpawlik_: but we could make it clearer in docs, I presume
07:48:46 bauzas dpawlik_: so yeah, that's why you had duplicate services
07:48:52 dpawlik_ bauzas: Small notification on the top of the doc will be helpful for other people
07:48:54 bauzas those first registered on startup
07:49:10 bauzas dpawlik_: yeah, that makes sense in https://docs.openstack.org/nova/latest/user/cells.html#cells-v2
07:49:21 bauzas I could spin a change
07:49:46 dpawlik_ dansmith: ^^ above is description why I have duplicated services on good cell mapping xD
07:50:15 dpawlik_ bauzas: please :)
07:50:43 dpawlik_ bauzas: if you can, write it please
07:51:31 openstackgerrit Brin Zhang proposed openstack/python-novaclient master: Add support changes-before for microversion 2.66 https://review.openstack.org/603549
07:58:09 bauzas dpawlik_: lemme stash my current work :)
08:02:49 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Spec: allocation candidates in tree https://review.openstack.org/603585
08:08:53 openstackgerrit Sylvain Bauza proposed openstack/nova master: cells: Be explicit in docs about service restarts https://review.openstack.org/603588
08:10:04 bauzas dpawlik_: ^
08:16:45 openstack Launchpad bug 1789868 in OpenStack Compute (nova) "RFE: Add a virtio-rng device to Nova instances by default" [Medium,Triaged] - Assigned to Kashyap Chamarthy (kashyapc)
08:16:45 kashyap Sigh, copy-pasting Git commit messages seem to break the line-wrapping in LaunchPad: https://bugs.launchpad.net/nova/+bug/1789868
08:16:58 kashyap The formatting is now fugly
08:18:46 dpawlik_ bauzas: checking
08:22:23 dpawlik_ bauzas: maybe warning will be better than info
08:22:34 dpawlik_ but it looks good
08:23:18 bauzas not really
08:24:09 dpawlik_ bauzas: im reading it from my perspective where I was wondering half day why my deployment doesn't work correctly
08:38:15 kashyap bauzas: johnthetubaguy: Hey there, this trivial thing is ready for merge: https://review.openstack.org/#/c/602592/
09:26:14 openstackgerrit Vlad Gusev proposed openstack/nova stable/queens: WIP libvirt: Reduce calls to qemu-img during update_available_resource https://review.openstack.org/603358
09:33:20 openstackgerrit Vlad Gusev proposed openstack/nova stable/queens: libvirt: Reduce calls to qemu-img during update_available_resource https://review.openstack.org/603358
09:46:35 bauzas kashyap: sorry, was on meeting
09:48:22 bauzas kashyap: do we recreate the guest XML on start() ?
09:48:34 bauzas kashyap: I'm confused by https://review.openstack.org/#/c/602592/3/releasenotes/notes/Use-virt-as-machine-type-for-ARMv7-cd2c252336057ec8.yaml
09:48:37 bauzas but I can check
09:49:39 bauzas kashyap: nevermind, I check
09:49:41 bauzas checked*
09:50:09 bauzas https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2931
09:51:36 bauzas oops, bad link https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2895
09:58:03 kashyap bauzas: Sorry, was out to get some groceries
09:58:16 bauzas nah no worries
09:59:03 kashyap bauzas: Would you like me to update the text here: https://review.openstack.org/#/c/602592/3/releasenotes/notes/Use-virt-as-machine-type-for-ARMv7-cd2c252336057ec8.yaml
09:59:21 kashyap bauzas: Since your question is answered (by yourself), or is the text good as-is for you?
09:59:28 kashyap Ah, you +2ed it
10:00:33 kashyap Thanks for looking!
11:49:21 pvc good evening bauzas is vgpu supported on ocata?
11:49:52 bauzas nope, queens only
11:50:02 pvc queens and rocky right?
11:50:05 bauzas but you can passthru in ocata
11:50:17 bauzas queens and later, yes
11:50:57 pvc thank you so much
12:01:35 tssurya johnthetubaguy or alex_xu: could you review https://review.openstack.org/#/c/596285/ whenever you have the time ?
12:11:59 sean-k-mooney tssurya: thanks for working on https://review.openstack.org/#/c/603352/2/specs/stein/approved/alloc-candidates-negative-member-of.rst. i saw it yesterday when i went to write up the same spec :)
12:12:26 sean-k-mooney tssurya: i have not had time to review properly yet but at a glance you seam to have captured the important points
12:13:30 tssurya sean-k-mooney: you are surely talking to the wrong person :)
12:13:43 jaypipes stephenfin: do you really have someone on your internal team named Jon Snow?
12:18:47 stephenfin jaypipes: Within the company, yes, and the puns come thick and fast
12:20:38 jaypipes stephenfin: that is... well, that is awesome.
12:21:20 jaypipes stephenfin: do you require him to carry a Valorian steel blade around the office?
12:22:04 tssurya I am thinking he must have the hardest time with the sentence "You know no'ting Jon Snow"
12:22:06 cdent sean-k-mooney: you're looking tetsuro
12:22:22 stephenfin jaypipes: No, but it appears he is the least knowledgeable person in the company
12:22:37 stephenfin tssurya: Indeed :D
12:22:41 tssurya :D
12:23:03 jaypipes tssurya: ++
12:36:47 sean-k-mooney cdent: tssurya sorry yes
12:42:21 sean-k-mooney jaypipes: quick question for the device whitelist spec im working on.
12:42:58 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/603737
12:42:59 sean-k-mooney did you want versioning, a schma or both. if both would you like it to also cover migrations. trying to refine scope
12:43:41 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/603738
12:44:07 openstackgerrit Lee Yarwood proposed openstack/nova stable/ocata: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/603740
12:46:10 jaypipes sean-k-mooney: doesn't have to cover the evolution of the schema, just needs to have a schema and a version attribute in the schema so that we *can* evolve the schema over time.
12:46:36 sean-k-mooney jaypipes: that is much simpler :) i was hopping you would say that.
12:46:38 jaypipes sean-k-mooney: i.e. you don't need to go into the implementation details of evolving the schema over time. just make sure there's a schema and version.
12:49:26 sean-k-mooney jaypipes: im debating about proposing jsonscma as the validation language for the schmea but it does not have built in migration support. oslo.config also can do the validation but forces ini and ovo gives the versioning but is way to verbose and annoying for configfiles. so of the eaisly accessable tools there was not one i could tink of that nativly was file format independent, did validation and
12:49:28 sean-k-mooney hand native migration/versioning
12:50:12 jaypipes sean-k-mooney: go with JSONSchema.

Earlier   Later