Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-09
15:29:37 belmoreira thanks cdent
15:32:19 mriedem melwitt: are you working on a patch for bug 1669468? otherwise i can throw one up quick to see if it explodes.
15:32:19 openstack bug 1669468 in OpenStack Compute (nova) "tempest.api.compute.servers.test_novnc.NoVNCConsoleTestJSON.test_novnc fails intermittently in neutron multinode nv job" [Medium,Confirmed] https://launchpad.net/bugs/1669468
15:33:04 melwitt mriedem: I was planning to but haven't looked yet. if you have something to try, go ahead
15:33:39 mriedem btw i've got most of the tests in https://review.opendev.org/#/c/675218/ fixed but there are 2 failing for some yet unknown reason https://review.opendev.org/#/c/675218/
15:34:33 melwitt ack
15:41:22 openstackgerrit Merged openstack/nova stable/queens: fix cellv2 delete_host https://review.opendev.org/672690
15:41:29 openstackgerrit Merged openstack/nova stable/queens: Add functional regression test for bug 1837955 https://review.opendev.org/673567
15:41:29 openstack bug 1837955 in OpenStack Compute (nova) queens "MaxRetriesExceeded sometime fails with messaging exception" [Medium,In progress] https://launchpad.net/bugs/1837955 - Assigned to Matt Riedemann (mriedem)
15:42:13 openstackgerrit Merged openstack/nova stable/queens: libvirt: flatten rbd images when unshelving an instance https://review.opendev.org/668123
15:46:05 mriedem frickler: melwitt: this might have been the regression https://review.opendev.org/#/c/672493/6
15:46:33 mriedem heh, and test_novnc failed on that change http://logs.openstack.org/93/672493/6/check/tempest-multinode-full/2e30174/testr_results.html.gz
15:46:42 mriedem but the tempest-multinode-full job is non-voting in devstack so no one noticed
15:47:22 melwitt ah, yeah looks like it
15:47:26 mriedem that explains the recent up-tick in this failing all of a sudden again
15:52:41 cdent ah, melwitt, we're around at the same time. I was tasked yesterday with checking with you (and others) about the urgency/priority of consumer types so we can determine if we need to push harder o nit
15:55:43 melwitt cdent: I wouldn't say it's "urgent" but definitely something important. the earliest we could integrate it in nova is U though
15:56:08 melwitt and I expect the integration to be pretty involved
16:03:09 openstackgerrit Merged openstack/nova stable/queens: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/673576
16:05:17 finucannot mriedem: What's the difference between 'filter_by(foo == False)' and 'filter_by(foo == false())' in the context of SQLAlchemy?
16:05:45 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: doc: Fix a parameter of NotificationPublisher https://review.opendev.org/670226
16:07:11 mriedem my understanding is that false() can be implemented by underlying db translation layers, e.g. ibm_db_sa, to translate what false means, so if the boolean type is an int (0 or 1) rather than False/True
16:07:17 mriedem but, it's a question for zzzeek really
16:07:39 mriedem https://docs.sqlalchemy.org/en/13/core/sqlelement.html?highlight=false#sqlalchemy.sql.expression.false
16:07:51 mriedem "A backend which does not support true/false constants will render as an expression against 1 or 0:"
16:08:11 finucannot I was looking at that (linked to it in a review) but didn't get whether we needed it or not
16:08:24 finucannot I guess MySQL, Postgres and SQLite all support the constants
16:08:29 mriedem for mysql/pg i don't think it's a problem
16:08:30 mriedem yeah
16:08:42 finucannot fair. Much of a muchness so
16:08:46 mriedem https://www.postgresql.org/docs/9.1/datatype-boolean.html
16:11:31 mriedem how do i know? because older versions of db2, when i needed to care, used 0/1 for booleans
16:11:52 mriedem boolean booleans were for gen-x'ers and their ilk
16:12:48 finucannot flashbacks to writing embedded C with Acme crap proprietary compilers back in uni
16:15:02 mriedem but did you wear a uni in uni? https://photos.app.goo.gl/fu4qRMpbNGtbTDfU6
16:16:40 mriedem dansmith: i think https://bugs.launchpad.net/nova/+bug/1839621 is where you come in and say # in the password has to be encoded
16:16:40 openstack Launchpad bug 1839621 in OpenStack Compute (nova) "Inappropriate split of transport_url string" [Undecided,New]
16:17:39 finucannot Much to my dismay, no, I did not
16:22:56 cdent thanks melwitt, I got your response out of the logs. Had a power outage just then.
16:24:54 cdent melwitt: so from your perpective getting the funcitonality done in placement before U starts up would be helpful
16:27:36 melwitt cdent: I don't think it's critical, but I feel like the question would be better answered by someone like tssurya, who is planning to consume the changes
16:27:59 cdent melwitt: she was involved in the earlier discussions and was hoping for more input from you
16:29:05 melwitt heh. well, there are some quirks with counting quota usage from placement today which need consumer types to be resolved. but counting from placement is opt-in, and I'd be looking to operators to know how urgently they want the quirks resolved
16:30:08 melwitt and AFAIK only CERN is planning to opt-in to counting quota usage from placement, the majority of folks will be running the default I expect
16:31:01 melwitt so, I consider it as medium priority unless operators signal otherwise
16:31:39 cdent I think in that case we can let CERN drive the bus then, and if tssurya needs an assist from other placement folk we can work that out. if this never ending performance improvement train in placement ever stops there may be some cycles spare
16:31:45 openstackgerrit Stephen Finucane proposed openstack/nova master: Add 'Instance.get_vifs' helper method https://review.opendev.org/675665
16:32:23 melwitt cdent: sounds reasonable to me
16:34:14 dansmith mriedem: yep, piled on
16:37:09 melwitt cdent: to be clear, on my side my plan is to start working on integration whenever the placement side is ready. we can't do it this cycle, it's too late, but whenever it's ready I would write up a spec to consume it
16:38:31 cdent melwitt: one factor is that none of the regular active contributors to placement has any particular need for the feature, so it's good (and appropriate) that tssurya is willing and able to work on it
16:40:08 melwitt cdent: yeah, makes sense. just wanted to be clear that it wouldn't get dropped on the floor once it's done. I'd write up the spec and do the integration once ready, but that said it's medium priority in my mind unless CERN turns up the priority
16:40:57 cdent ✔
16:42:07 openstackgerrit Merged openstack/nova stable/pike: Replace non-nova server fault message https://review.opendev.org/674877
17:12:58 mgoddard hi mriedem, quick question about upgrade checks
17:13:20 efried mgoddard: I think Matt's at lunch fyi
17:13:32 mgoddard efried: oh ok, thanks
17:13:57 efried dansmith knows things about upgrades tho
17:21:09 mgoddard here's the question, perhaps someone else can answer
17:21:44 openstackgerrit Merged openstack/nova stable/queens: Delete resource providers for all nodes when deleting compute service https://review.opendev.org/666862
17:21:51 mgoddard it's my understanding that nova-status upgrade check should be run after DB sync and data migrations
17:21:55 openstackgerrit Merged openstack/nova master: Filter UnsupportedServiceVersion warning https://review.opendev.org/674515
17:22:15 mgoddard could it be harmful to run it before starting an upgrade (using the new code)?
17:22:20 dansmith no,
17:22:28 dansmith it's expected to run before the upgrade to tell you what to look out for,
17:22:36 dansmith and after to make sure everything went green
17:23:16 mgoddard that's how I wanted it to work, but when I've discussed it with mriedem previously I came away with the above impression
17:23:32 dansmith nova-status does not *do* anything, so no damage could occur
17:24:52 mgoddard no, but I don't want it to fail due to running it at the wrong time
17:24:53 mgoddard Install new code
17:24:55 mgoddard Sync the database schema for new models (nova-manage api_db sync; nova-manage db sync)
17:24:57 mgoddard Run the online data migrations (nova-manage db online_data_migrations)
17:24:59 mgoddard Run the upgrade check (nova-status upgrade check)
17:25:01 mgoddard Restart services with new code
17:25:03 mgoddard from https://docs.openstack.org/nova/latest/reference/upgrade-checks.html
17:25:18 dansmith sure
17:25:42 dansmith are you worried about it "failing" because you're scripting this and you want to know if you can always run it and expect a zero return or what?
17:25:54 mgoddard right
17:26:10 dansmith okay, well, it's probably not something you can do blindly regardless,
17:26:34 dansmith because sometimes the checks are things like "yo dawg, you need to modify your flavors to remove X which we've deprecated" or whatever
17:26:36 mgoddard can I safely run it before doing any part of the upgrade (including db sync)?
17:26:42 dansmith which isn't going to get "fixed" by running them
17:26:59 dansmith again, define "safely"
17:27:10 dansmith if you mean "without breaking stuff" then ... of course
17:27:17 mgoddard I don't mind if it tells me to do something that I do need to do
17:27:29 dansmith nova-status is read-only
17:27:32 dansmith it doesn't make changes
17:27:45 dansmith you can run it any time you want and the worst thing that will happen is it will complain about something, end of story
17:27:48 mgoddard but if it fails because I'm running it at the wrong point then that's bad
17:28:20 dansmith you know that it will *usually* not return zero right?
17:28:26 dansmith so I mean, again, define "fail"
17:28:37 mgoddard yeah, we allow 0 or 1
17:29:05 dansmith IIRC, the point of it not using the db models is so it can run entirely against the old schema and do its checks,
17:29:10 mgoddard let me try to rephrase
17:29:17 dansmith so barring bugs, I think you will get constrained results even before db sync
17:29:44 mgoddard in order to get the 'right' answer out of it, should I run upgrade checks only after doing the DB sync and migrations?
17:30:02 dansmith I don't think it's that simple,
17:30:16 dansmith because I think that we've had some checks which were "hey before you do anything you need to manually change X"
17:31:00 dansmith mriedem has done 95% of the work on this and definitely has the current scope/intent in his head more than me, so I guess I'll just shut up,
17:31:01 mgoddard so it could be useful to run both before DB sync, and after?

Earlier   Later