| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 19:31:56 | cdent | mtreinish: for now, sure, but the hope and dream is to change | |
| 19:31:56 | mtreinish | it supports uwsgi though, and that's a much better model | |
| 19:32:13 | cdent | mtreinish: above I should have said "devstack would like uwsgi..." | |
| 19:32:27 | cdent | but I'm a bad typer in the first place, and especially bad at the end of the week | |
| 19:33:01 | mtreinish | cdent: ah, I just misread that as 'devstack uses uwsgi' | |
| 19:33:32 | mtreinish | but from the goal perspective it doesn't actually matter, because as long as the wsgi_script entry point is in the setup.cfg that's enough for anyone to use either model | |
| 19:33:57 | sdague | yeh, I just don't want to be doing apache things in devstack because it really breaks the debug flow | |
| 19:33:58 | cdent | speaking of the wsgi_script entry point, I think that pbr puts that in $PREFIX/bin is a bug | |
| 19:34:24 | sdague | cdent: well, where things can be installed in python is ... limited | |
| 19:34:39 | cdent | it requires a <directory /usr/bin> that opens things up in an icky way | |
| 19:34:40 | mriedem | so steps are moving placement to uwsgi in devstack, | |
| 19:34:48 | mriedem | and then fixing the known service version bug for nova-api, | |
| 19:34:52 | sdague | yeh | |
| 19:34:56 | mriedem | and then calling out https://github.com/openstack/nova/blob/master/nova/wsgi/nova-api.py in nova's setup.cfg, | |
| 19:35:06 | mriedem | and then finally running nova-api under uwsgi? | |
| 19:35:15 | sdague | yeh, pretty much | |
| 19:36:22 | mriedem | now i have to find the bug again | |
| 19:36:41 | sdague | cdent: I do get the concern, we also just have the issue that what you can do in python packaging is kind of limited, and the previous approach was "leave as an exercise to the user" | |
| 19:37:10 | cdent | i suppose having it somewhere predictable on the filesystem leaves open the option to move it in a predictable fashion | |
| 19:37:38 | sdague | yeh, and more importantly that when you make changes, even in the default scenario it installs over the old default place | |
| 19:37:42 | sdague | that was the big issue before | |
| 19:37:59 | mriedem | dansmith: do you have the link to the service version bug for api under wsgi? | |
| 19:38:05 | sdague | there was a completely out of band "copy this file now" part of the process | |
| 19:38:57 | mriedem | ah i think this was it https://bugs.launchpad.net/nova/+bug/1661360 | |
| 19:38:57 | openstack | Launchpad bug 1661360 in OpenStack Compute (nova) "tempest test fails with "Instance not found" error" [Undecided,In progress] - Assigned to Dan Smith (danms) | |
| 19:39:02 | cdent | would it make any sense for the wsgi script handling to be a bit like the console-script handling which produces a wrapper file in the installed location that points into the relevant module in the package, such that there isn't any "real" code in the wsgi script? | |
| 19:39:54 | dansmith | mriedem: I don't know that I had one | |
| 19:39:55 | sdague | cdent: maybe, but, again it's completely out of bounds | |
| 19:40:10 | dansmith | mriedem: I guess that title is rather obscure for this issue | |
| 19:40:11 | cdent | "out of bounds" of what? | |
| 19:40:22 | sdague | python's idea of where it can install | |
| 19:41:30 | cdent | sdague: that's what I'm saying, if we are installing it in /usr/bin and someone moves it, as long as there's not much code in it, the problem of them forgetting to copy the new version into their custom location isn't one, because the "real" code is in site-packages | |
| 19:41:37 | mriedem | dansmith: updated the title | |
| 19:41:46 | sdague | cdent: that turns out not to be true | |
| 19:41:52 | cdent | oh? | |
| 19:42:06 | sdague | because even though there is *very* little code in it, there is some | |
| 19:42:13 | sdague | like a module and function | |
| 19:42:22 | sdague | and, people change that stuff | |
| 19:42:32 | cdent | that ought to be a very limited interface, yes? | |
| 19:42:43 | sdague | because they didn't ever think they were signing up for that to be a contract interface | |
| 19:43:22 | sdague | or it turns out we need a fix, like the threading fix | |
| 19:43:37 | sdague | cdent: I get the theory, but the fact is we did used to do that hing | |
| 19:43:55 | sdague | and then it broke because people actually needed to make changes in even the trivial stubs | |
| 19:44:04 | cdent | the past is a pain | |
| 19:44:14 | cdent | but what we've got | |
| 19:44:31 | sdague | right, but given that we needed that before | |
| 19:44:49 | sdague | I don't think it's fair to say "we've solved it forever" now | |
| 19:46:58 | sdague | I do really wish that python packaging had more rich constructures for things like SHARE directory and CONFIG directory like perl packaging does | |
| 19:47:13 | sdague | because being in SHARE would be ideal | |
| 19:47:52 | mriedem | does go have all of the packaging issues solved? because if so, let's move to go. | |
| 19:48:05 | mriedem | i heard dependency management in go is great. | |
| 19:48:12 | thomasem | Lol | |
| 19:48:45 | thomasem | Coming along https://github.com/golang/dep | |
| 19:48:50 | mriedem | dansmith's toilets are all running on golang now | |
| 19:48:52 | mriedem | i heard | |
| 19:49:07 | mriedem | toilet apps i should say | |
| 19:49:25 | dansmith | as far as you know | |
| 19:49:27 | thomasem | I can just imagine the applications. | |
| 19:49:38 | mriedem | the toilet app in go wipes your ass in half the time | |
| 19:49:38 | thomasem | "I can't do that, Dave..." | |
| 19:49:53 | mriedem | *blistering* speed | |
| 19:49:55 | dansmith | hah | |
| 19:50:00 | dansmith | ouch | |
| 19:50:33 | thomasem | D= | |
| 19:51:31 | cdent | I think this might be a good time to leave. | |
| 19:51:48 | mriedem | thanks, i got what i needed out of this https://review.openstack.org/#/c/454866/ | |
| 19:51:52 | mriedem | to keep ttx at bay | |
| 19:52:30 | cdent | \o/ | |
| 19:56:28 | mriedem | we can have an index on a nullable column right? | |
| 19:56:35 | mriedem | wondering if we should put an index on services.uuid | |
| 19:56:40 | mriedem | for the lookups that the api will be doing | |
| 19:57:22 | mriedem | we don't have one for compute_nodes though i guess | |
| 19:57:35 | mriedem | maybe we should, we look those up by a list of uuids from the scheduler, but would an index help there/ | |
| 19:57:36 | mriedem | ? | |
| 19:57:54 | mriedem | where is leakypipes when i need him | |
| 20:02:49 | mriedem | hmm, if we declared the field as unique=True we wouldn't have to index it, but these are not specified that way, presumably b/c they are nullable=True for existing entries that are None | |
| 20:03:55 | mriedem | zzzeek: can you have a unique=True and nullable=True column? | |
| 20:04:06 | mriedem | or does the nullable=True defeat the unique constraint? | |
| 20:04:18 | mriedem | i know you can't do that in db2, but i think mysql lets you get by with it | |
| 20:04:31 | zzzeek | mriedem: yes but the rules for if NULL is counted are not necessarily consistent across backends | |
| 20:06:12 | mriedem | https://www.postgresql.org/docs/9.0/static/indexes-unique.html | |
| 20:06:16 | zzzeek | mriedem: A UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. For all engines, a UNIQUE index permits multiple NULL values for columns that can contain NULL. | |
| 20:06:16 | mriedem | Null values are not considered equal. | |
| 20:06:32 | zzzeek | mriedem: yeah I think SQL server is the one that might be different | |
| 20:06:38 | mriedem | and db2 | |
| 20:07:00 | mriedem | i at least know that db2 never allowed a unique constraint with nullable columns | |
| 20:07:09 | mriedem | it would allow a unique index though i think... | |
| 20:07:22 | mriedem | it's been a long time since i had to remember | |
| 20:07:40 | zzzeek | db2 makes oracle look like sqlite, installation-wise, so ive hardly ever run a DB2 | |
| 20:07:44 | mriedem | anyway, it sounds like mysql and postgresql are ok with this | |
| 20:07:47 | zzzeek | yep | |
| 20:07:58 | mriedem | db2 install requires a phd i think | |
| 20:08:11 | sdague | mriedem: just half a shelf of manuals | |
| 20:08:21 | mriedem | certified db2 installer | |
| 20:08:45 | mriedem | i think i asked someone 5 years ago for a db2 server rpm for simple install and was laughed at | |
| 20:09:20 | sdague | which, is kind of dumb, because honestly the install steps are very repeatable | |
| 20:09:48 | sdague | they wrote them in the manual, why they didn't just write them in the rpm post-install always blew my mind | |
| 20:09:53 | sdague | brb | |
| 20:10:23 | mriedem | zzzeek: if i wanted to make a column unique=True in an alter during an offline migration, is that a pretty bad time sink? | |
| 20:10:28 | mriedem | for the compute_nodes table | |