Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-10-21
15:52:35 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Drop add/remove of index https://review.opendev.org/758157
15:52:35 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Merge in unique constraints https://review.opendev.org/758156
15:52:36 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Juno database migration https://review.opendev.org/758395
15:52:36 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Icehouse database migrations https://review.opendev.org/758394
15:52:37 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Liberty database migrations https://review.opendev.org/758397
15:52:37 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: db: Compact Kilo database migrations https://review.opendev.org/758396
15:52:38 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Newton database migrations https://review.opendev.org/759085
15:52:38 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Mitaka database migrations https://review.opendev.org/758398
15:52:39 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Pike database migrations https://review.opendev.org/759087
15:52:39 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Ocata database migrations https://review.opendev.org/759086
15:52:40 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Rocky database migrations https://review.opendev.org/759089
15:52:40 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Queens database migrations https://review.opendev.org/759088
15:52:41 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Train database migrations https://review.opendev.org/759091
15:52:41 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Compact Stein database migrations https://review.opendev.org/759090
15:52:43 bauzas that you have to create separately from the api db
15:52:58 bauzas stephenfin: you dawn paste bomber
15:53:24 markguz_ bauzas: so my connection strings are this https://pastebin.com/e1Sb9PjF
15:53:30 bauzas markguz_: eg. 'nova' can be your API DB
15:53:44 stephenfin gotta be done ~o~
15:54:08 stephenfin the kilo one is broken though. I haven't figured out why yet. Will pick up again later in the week
15:54:48 markguz_ bauzas: ok. confused. i thought from the docs that there is always nova, nova_api nova_cell0 and since rocky placement can be seperate
15:55:25 bauzas actually, that's me who's lost
15:56:11 markguz_ i think the only missing part of the puzzle is that the cell0 db has no conf options and has to be manually supplied at the cli if using something other than nova_cell0
15:56:27 markguz_ i'm a try it now
15:57:17 bauzas I'm litterally looking at the nova-manage source code
15:57:31 bauzas and we assume a _cell0 postfix if nothing was passed
15:58:27 markguz_ so nova_vsphere should be nova_vsphere_cell0 ?
15:58:31 bauzas ok, got it
15:58:52 markguz_ full disclosure.. this is rocky... so maybe it's been fixed subsequently?
15:59:26 bauzas looking at the rocky code then
15:59:49 bauzas no changes
15:59:53 bauzas ok, got the answer
15:59:56 bauzas markguz_: https://github.com/openstack/nova/blob/stable/rocky/nova/cmd/manage.py#L1149
16:00:16 bauzas you're entering this inner method since you don't pass a connection string as a CLI param
16:00:39 bauzas in this case, we're getting your 'nova' db
16:00:57 bauzas but then we consider that the cell0 connection URL will be 'nova_cell0'
16:01:11 markguz_ bauzas: gibi: as a sidenote, is creating a separate region the only way to have nova/libvirt/kvm + neutron/ml2/openvswitch coexist with nova/vsphere + neutron/nsx ?
16:01:20 bauzas in your case, mysql+pymysql://nova:XXX@192.168.128.254/nova_vsphere_cell0 indeed
16:01:51 markguz_ ok. i have created that db, but was expecting nova-manage to magically know to use nova_vsphere_cell0
16:04:07 bauzas db sync has to happen after map_cell0
16:13:17 markguz_ bauzas: gibi: that got it, all i was missing was the connection string for cell_v2 map_cell0
16:13:31 bauzas cool
16:13:34 gibi markguz_: nice to hear that
16:13:45 markguz_ is this really the only way to coexist the vsphere stuff with the libvirt/kvm stuff?
16:14:15 markguz_ the docs are pretty sketchy on having a hybrid env
16:21:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: [doc]: Fix glance image_metadata link https://review.opendev.org/759100
16:37:29 bauzas gibi: I know this is late but food for thoughts https://review.opendev.org/#/c/755477/2/specs/wallaby/approved/support-interface-attach-with-qos-ports.rst@126
16:38:01 bauzas I have to disappear, my spouse is looking at me for shopping needs
16:40:22 gibi bauzas: good point, replied in https://review.opendev.org/#/c/755477/2/specs/wallaby/approved/support-interface-attach-with-qos-ports.rst@126
16:40:31 gibi bauzas: have a nice shopping ;) o/
17:31:22 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Remove irrelevant comment https://review.opendev.org/759112
17:31:41 stephenfin gibi: ^
17:32:15 gibi stephenfin: thanks
17:36:56 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove 'BandwidthUsage', 'BandwidthUsageList' https://review.opendev.org/759114
17:37:41 stephenfin also gibi :) ^
17:37:49 stephenfin let's see what CI thinks
17:37:53 gibi thanks
18:06:21 ganso melwitt, elod: Hi! If you have a minute could you please take a look at this stable/stein backport that is the same as the stable/train you previously: https://review.opendev.org/#/c/757886/ ? Thanks in advance!
18:08:52 openstackgerrit melanie witt proposed openstack/nova stable/train: Follow up for cherry-pick check for merge patch https://review.opendev.org/759118
18:09:13 melwitt ganso: ack, will look later
18:09:25 ganso melwitt: thanks!
18:16:04 openstackgerrit sean mooney proposed openstack/nova master: Fix unplugging VIF when migrate/resize VM https://review.opendev.org/751642
18:38:13 openstackgerrit sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.opendev.org/602432
18:39:11 lyarwood sean-k-mooney: if you're still around, did I see you talking about an ipv6 issue earlier today?
18:39:37 lyarwood sean-k-mooney: just noticed tempest-ipv6-only failing across a few of my changes
18:39:39 sean-k-mooney thats in the world dump script and limestone
18:39:52 lyarwood sean-k-mooney: kk, did you have a bug for that?
18:40:14 sean-k-mooney so https://review.opendev.org/#/c/759042/ is the fix for the worlddump script
18:40:28 sean-k-mooney and the limestone ci seam to be ipv6 by default
18:40:46 sean-k-mooney but there might be a dhcp/nat issue
18:40:59 lyarwood kk
18:41:06 lyarwood I'll leave my rechecks until the morning then
18:41:09 sean-k-mooney the vms are ment to get ipv4 private ips but devstack failed because it had not ipv4 adress atall
18:41:10 lyarwood thanks!
22:44:31 openstackgerrit Xav Paice proposed openstack/nova stable/ussuri: Set migrate_data.vifs only when using multiple port bindings https://review.opendev.org/759151
23:16:12 openstackgerrit Xav Paice proposed openstack/nova stable/train: Set migrate_data.vifs only when using multiple port bindings https://review.opendev.org/759153
23:32:06 openstackgerrit Merged openstack/nova master: virt: Remove 'get_console_pool_info' API https://review.opendev.org/749311
#openstack-nova - 2020-10-22
01:12:42 openstackgerrit Xav Paice proposed openstack/nova stable/ussuri: Set migrate_data.vifs only when using multiple port bindings https://review.opendev.org/759151
01:34:19 openstackgerrit Xav Paice proposed openstack/nova stable/train: Set migrate_data.vifs only when using multiple port bindings https://review.opendev.org/759153
04:49:09 openstackgerrit Merged openstack/os-vif master: Fix - os-vif fails to get the correct UpLink Representor https://review.opendev.org/745895
06:28:08 bauzas good morning Nova
07:11:46 gibi bauzas: good morning
07:11:59 bauzas :)
08:49:59 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove 'BandwidthUsage', 'BandwidthUsageList' https://review.opendev.org/759114
09:05:19 gibi stephenfin: now I feel making o.vo fields typesafe is fultile. E.g. an o.vo IntegerField accept strings and coerce them to integeres with an int() conversion. So if I type an IntegerField to int then mypy will flag obj.int_field = '123' assignemnet which is valid in o.vo. Also if I map it to str then mypy will not flag obj.int_field = 'bob' which is invalid in o.vo
09:05:33 gibi s/flutile/futile
09:14:37 gibi which means it is very limited what we can typecheck
09:16:18 gibi List*Fields are complicated as they are coreced from Iterables but not from str or Mapping myobj.list_of_ints = {1, 2, 3}
09:16:36 gibi sorry I wanted to link https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L648
09:17:24 gibi btw myobj.list_of_ints = {'1', '2', '3'} also accepted by ovo as the elements of the iterable is coerced to int
09:27:27 stephenfin gibi: I hadn't considered coercion /o\
09:28:06 stephenfin Hmm, that does sound pretty futile alright. Damn :-\
09:29:49 stephenfin I had been thinking it might make sense to at least define the attributes and simply set their type to Any, so that we'd know you could define e.g. 'InstanceNUMACell.cpu_policy' but not '.cpu_policyyyy'. However, I guess we rely on that to store working data
09:32:48 gibi stephenfin: I can generate the fields with https://github.com/gibizer/ovo-mypy-plugin and map them to Any. I guess non o.vo fields defined via simply assigning value to them in nova code. So those can be typed in nova code and picked up by mypy
09:34:42 stephenfin gibi: I think there's probably value in that. I mean, it sounds like the best we can get unless we wanted to drop the coerce functionality
09:35:08 stephenfin which, tbc, I wouldn't be entirely against either; explicit is better than implicit and all that
09:36:12 gibi stephenfin: I don't know if the generic RPC code depends on coerce or not. But the specific nova usage of o.vo can be converted to not use coerce
09:37:13 gibi or at least to use explicit coerce
09:37:22 gibi instead of implicit during assignment
09:39:16 stephenfin Even if the RPC code did rely on it, type checking doesn't happen at run time so we could require explicit coercion for non-RPC cases

Earlier   Later