Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-20
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
17:28:09 edmondsw johnthetubaguy you shouldn't be promising that... 99.999% of the time, sure, but there will always be a 0.001% case where...
17:28:41 edmondsw johnthetubaguy with this change, there is a 0.000001% chance that someone would break on upgrade... or something extremely slim like that
17:29:08 johnthetubaguy edmondsw: there are always exceptions, but that is our promise in here: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements
17:29:37 asettle mriedem cdent - we finally *might* have an answer on the doc patch: https://review.openstack.org/#/c/438328/
17:29:51 asettle Petr has been looking into it.
17:29:55 johnthetubaguy edmondsw: well the additional bit of info I guess is I could policy as configuration
17:29:58 asettle We probably need someone from the nova team to take a look at this too.
17:30:02 edmondsw johnthetubaguy this patch fits fine with that tag
17:30:14 cdent asettle: the Directory thing? hasn't that been mentioned a few times before?
17:30:18 edmondsw it has an upgrade note for operators to consider in the very unlikely event that they need to consider this
17:30:26 cdent asettle: or maybe it was only in related email
17:30:45 asettle cdent: I didn't see it in the comments. Perhaps I am forgetting - if so, sorry! Maybe on email.
17:30:56 johnthetubaguy edmondsw: it violates bullet point 2, now that might be best thing to do, I just want to make sure thats the case
17:31:00 asettle cdent: did we document it?
17:31:48 cdent asettle: sorry, not fully contextualized at the moment, but I remember discussing it in a few different places, including asserting that one person's solution to grant all on '/' was too broad
17:32:07 edmondsw johnthetubaguy that depends on how you read point 2
17:32:45 asettle cdent: interesting. I've mentioned it to Lana and Brian, since it's nearing the end of my day rapidly. I'll ensure I check in with them again in the morning. If by chance you see it again, please let us know :)
17:33:03 cdent asettle: yeah, will look around some more once I'm done with the current thing
17:33:21 asettle Thank you cdent :)
17:33:23 edmondsw you have to consider policy as config (which I do, but not everyone does) and you have to assume that it means even really unlikely edge cases that nobody would do must still work... even if you've covered that under bullet 5
17:33:57 johnthetubaguy edmondsw: very true. We had deployers complain they had to tweak config and policy files in sync with upgrades, so we promised to avoid that, hence that was added in there and the grenade tests kinda built around that assumption.
17:34:13 edmondsw sure, I'm fully on board with that
17:35:13 edmondsw the main point here is that this is not going to break anyone. We're fixing a bug here. The chances of someone relying on this bug for things to work are miniscule
17:35:39 edmondsw furthermore, it's not possible to fix this bug without any possible chance of an upgrade impact
17:36:19 edmondsw johnthetubaguy so do we not fix the bug? That would be much worse for operators
17:38:08 edmondsw johnthetubaguy we can't leave a fully-supported API not only doing its own policy check but also relying on the policy check of another API that is deprecated... non-deprecated cannot rely on deprecated

Earlier   Later