Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-20
16:23:08 mriedem ?
16:23:44 zzzeek "0" is a str
16:23:45 snecklifter mriedem: thanks
16:23:59 mriedem zzzeek: yeah so i'm not sure what code example is incorrect
16:24:18 zzzeek mriedem: this one: https://review.openstack.org/#/c/427901/3/nova/db/sqlalchemy/migrate_repo/versions/358_add_compute_node_mapped.py
16:24:29 zzzeek "server_default" vs. "default"
16:24:30 snecklifter mriedem: so change 1.16 to 1.17?
16:24:45 dansmith zzzeek: ah, jay said it wasn't slow
16:25:06 zzzeek dansmith: well if you have 1M rows it has to popualte 1M rows w/ a value and probably do some locking too. depends on your table
16:25:18 dansmith zzzeek: I tried server_default at jaypipes' suggestion anyway, and it causes other problems for us in the oslo.db migration checker
16:25:19 dansmith zzzeek: ah, definitely can't have that then
16:25:23 mriedem CERN has what, 10K+ compute nodes?
16:25:49 zzzeek dansmith: i'd agree it's not "slow" but it is def. a variable-length operation, i would think
16:26:10 zzzeek dansmith: problems in oslo.db should be fixed in oslo.db , feel free to post a launchpad
16:26:33 dansmith zzzeek: okay, what I meant was, jaypipes said it wouldn't require a rewrite
16:26:41 dansmith it really doesn't matter though,
16:26:51 dansmith we can handle this on read just as easily and not have to walk the table
16:26:55 jaypipes zzzeek: I don't think anyone's suggesting there's something wrong with oslo.db.
16:27:10 zzzeek dansmith: ok jaypipes knows mysql internals more than I do but in my experience, when you have server deafult in a migration w/ nullable=false, it has to write data to every row
16:27:26 zzzeek jaypipes: dansmith just referred to some problem with oslo.db's migration checker
16:27:31 jaypipes zzzeek: yes, that's correct.
16:27:31 mriedem snecklifter: yes
16:27:55 openstackgerrit Claudiu Belu proposed openstack/nova master: POC: tests: autospecs all the mock.patch usages https://review.openstack.org/447505
16:27:57 jaypipes zzzeek: ah, the migration checker thing... sorry, yeah
16:29:04 claudiub efried: mriedem: ^ in case you're curious about the autospec stuff. :)
16:29:57 claudiub still experimental, and it's just the 1st step.
16:31:03 mriedem dansmith: why even set mapped=0 in fake compute node records in https://review.openstack.org/#/c/427901/ ?
16:32:00 EmilienM mriedem: I have updates
16:32:15 EmilienM 1. the patch that dansmith sent to have more logging, is still running so I'll give update later on logs
16:32:23 dansmith mriedem: because we create from that and we don't have it optional on create
16:32:32 EmilienM 2. the patch that revert jaypipes's patch is fixing our problem, I see it in the logs
16:32:35 dansmith mriedem: go run without that and I think you'll see it tries to lazy-load on create
16:33:02 EmilienM so I confirm the issue is related to this patch: https://review.openstack.org/#/c/441544/
16:33:09 openstackgerrit Christopher Brown proposed openstack/nova master: Add lan9118 as valid nic for hw_vif_model property for qemu https://review.openstack.org/393489
16:33:40 mriedem dansmith: create of the object or the db record?
16:33:41 EmilienM [overcloud.AllNodesDeploySteps.CephStorageDeployment_Step3]: CREATE_COMPLETE state changed ---- It means that overcloud nodes were deployed successfuly (and now deployment is moving forward)
16:34:12 dansmith mriedem: ComputeNode.create()
16:34:47 dansmith mriedem: even still, we're adding something as nullable purely for speed, we don't want to treat it as optional going forward
16:35:43 mriedem i don't see how create() will fail when _from_db_object has a check for null: value = 0 if value is None else value
16:38:38 openstackgerrit Sergey Nikitin proposed openstack/nova master: Added nova objects for intance diagnostics https://review.openstack.org/434745
16:38:38 openstackgerrit Sergey Nikitin proposed openstack/nova master: Replace diagnostics objects with Nova diagnostics objects https://review.openstack.org/394480
16:38:40 openstackgerrit Sergey Nikitin proposed openstack/nova master: Standardization of VM diagnostics info API. https://review.openstack.org/355540
16:38:42 openstackgerrit Sergey Nikitin proposed openstack/nova master: Completed implementation of instance diagnostics for Xen https://review.openstack.org/399613
16:40:43 dansmith mriedem: it still pulls it out of the db object on L175, and only interprets the value and tolerates None on L207
16:41:56 mriedem dansmith: idk, but see my update in the change, i pulled it down, mangled that check and nothing failed
16:42:02 mriedem so we're not testing the None case
16:42:24 dansmith mriedem: you ran all of py27 and functional?
16:42:40 dansmith mriedem: but yeah, might not be covering the None case
16:42:43 mriedem no, nova.tests.unit.objects.test_compute_node and nova.tests.unit.compute
16:42:59 mriedem i shouldn't probably need to dig into running all of functional for a simple logic check test
16:43:22 dansmith if you're asking about covering none, then sure,
16:43:39 dansmith if you're asking about changing that fake, I think lots of other places that use that fake
16:43:49 mriedem i'm asking about testing none: https://review.openstack.org/#/c/427901/3/nova/objects/compute_node.py@208
16:44:02 dansmith yeah, willing to believe I'm missing that
16:44:15 mriedem but i thought the whole point of a nullable=True with a default is you don't need to provide actual values
16:44:38 dansmith mriedem: if you're really loading from the DB sure,
16:44:43 dansmith if you're loading from a fake, then it matters
16:44:57 mriedem true
16:45:01 mriedem then you need the key
16:45:03 mriedem but not the value
16:45:20 mriedem i.e. your fake could just be mapped=NOne
16:45:23 mriedem but anyway
16:45:25 dansmith eventually I'd like to make this non-nullable,
16:45:27 openstackgerrit Christopher Brown proposed openstack/nova master: Add lan9118 as valid nic for hw_vif_model property for qemu https://review.openstack.org/393489
16:45:31 dansmith so I'd rather a legit value in there,
16:45:40 dansmith and then cover the specific load of null case as you pointed out
16:45:41 dansmith but whatever
16:45:52 mriedem sure, that's fine, let's just test the none case and move on with this enjoyable and productive day :)
16:46:08 mriedem i'm in trouble for not putting the asparagus in the fridge
16:46:51 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: create functional test base class https://review.openstack.org/407055
16:46:51 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Validate huge pages https://review.openstack.org/399653
16:46:52 mriedem i mean, it grows in the ground right?
16:46:58 mriedem which is unrefrigerated
16:47:15 cfriesen This is maybe an odd question, but is there a primer somewhere on how to deal with running out of DB connections? Are there ways to optimize the python code to allow quicker connection re-use?
16:51:09 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Make 'get_domain' private https://review.openstack.org/417378
16:54:00 openstackgerrit Stephen Finucane proposed openstack/nova master: netutils: Ignore 'use_ipv6' for network templates https://review.openstack.org/430910
16:54:00 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Fix indentation in conf/netconf https://review.openstack.org/430717
16:54:01 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Ignore 'use_ipv6' for port filters https://review.openstack.org/430909
16:54:01 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Deprecate 'use_ipv6' https://review.openstack.org/430911
16:54:02 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Final cleanups in conf/network https://review.openstack.org/431023
16:54:02 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Deprecate 'allow_same_net_traffic' https://review.openstack.org/430913
16:54:03 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Ignore 'allow_same_net_traffic' for port filters https://review.openstack.org/430912
17:17:54 mriedem EmilienM: yeah http://logs.openstack.org/22/447522/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha/2eecbc6/logs/undercloud/var/log/nova/nova-scheduler.txt.gz#_2017-03-20_16_44_02_099
17:18:03 mriedem logging in the scheduler shows nothing coming back from placement
17:18:19 mriedem i'm going to add more logging to dan's patch for the actual resource reporting
17:18:39 EmilienM ok, you'll need to recheck the tripleo-ci patch to actually see it in our logs
17:18:43 mriedem yup
17:19:38 EmilienM or even change something in the commit message to actually kick off jobs (jobs are still running now)
17:20:09 mriedem when i push the dep, zuul will kill those running jobs
17:21:27 EmilienM ah indeed
17:22:08 edmondsw johnthetubaguy I replied to your comments in https://review.openstack.org/#/c/389314/
17:24:07 johnthetubaguy edmondsw: so I think we need a deprecated default on oslo.policy for all this kind of stuff
17:24:17 johnthetubaguy s/on/in/
17:24:42 edmondsw johnthetubaguy for most things I agree, but I don't think you can in this case
17:25:38 openstackgerrit Sujitha proposed openstack/nova master: Remove unused policy rule in admin_actions.py https://review.openstack.org/447611
17:25:45 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: Log placement result in scheduler https://review.openstack.org/447520
17:26:39 edmondsw johnthetubaguy I gave 4 reasons that doesn't really make sense here in my reply to one of your comments
17:26:47 edmondsw patch set 5
17:27:08 johnthetubaguy edmondsw: the problem is how do we keep our upgrade promise, that the old policy file works perfectly with the new release
17:28:03 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: Log placement result in scheduler https://review.openstack.org/447520

Earlier   Later