| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-09 | |||
| 13:06:10 | sdague | that's the first time I've seen that in practice | |
| 13:06:33 | artom | kashyap, so would I be correct in understanding that transient domains came about more as a technical necessity of long running operations that cannot last across reboots rather than as a user-facing feature? | |
| 13:07:04 | sdague | bauwser: that being said, it would be nice to actually catch these misconfiguration items and be more explicit about them | |
| 13:07:19 | bauwser | sdague: agreed, I'll add a better exception | |
| 13:07:22 | bauwser | for that | |
| 13:07:30 | sdague | bauwser: ok, cool | |
| 13:07:31 | kashyap | artom: Almost correct. It's also useful for "user-facing" feature in the sense that -- if you're testing something w/ libvirt, and don't want to clean up the guests your self, you can use transient domains | |
| 13:07:34 | artom | So what happens if the host dies while such an operation is happening? It aborts, obviously, the transient domain is lost, but the persistent domain, the one without the operation going on, is saved, and comes back after the host recovers? | |
| 13:08:02 | sdague | bauwser: while you are looking at things - https://review.openstack.org/#/c/472266/ really feels like we should get it in soon | |
| 13:08:12 | sdague | that's the fail to start instances after upgrade bug | |
| 13:08:19 | bauwser | sdague: roger. | |
| 13:10:57 | sfinucan | sdague: That sounds good to me. +Wd now | |
| 13:10:59 | openstackgerrit | falseuser proposed openstack/nova master: Clear instance root_device_name in rebuild operation https://review.openstack.org/464991 | |
| 13:11:34 | bauwser | oh man, +W'd duplicated :) | |
| 13:11:43 | bauwser | shit. | |
| 13:40:58 | sdatko | hello | |
| 13:42:01 | sdatko | tiny question: nova.db.sqlalchemy.models.InstanceTypeExtraSpecs vs nova.db.sqlalchemy.api_models.FlavorExtraSpecs | |
| 13:43:31 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Provide a better log when api_servers is unset https://review.openstack.org/472685 | |
| 13:43:33 | sdatko | for first one there is note about being deprecated; however, when performing context.session.query(models.InstanceTypeExtraSpecs) i can see results, while for context.session.query(api_models.FlavorExtraSpecs) i receive empty array | |
| 13:43:44 | bauwser | sdague: see https://review.openstack.org/472685 for the api_servers opt | |
| 13:44:21 | mriedem | sdatko: the former is in the cell database (nova db), the latter is in the api db (nova_api db), flavors were moved from the cell to the api db a few releases ago | |
| 13:44:24 | mriedem | mitaka i think | |
| 13:44:49 | sdatko | hmm | |
| 13:45:07 | sdatko | ok, to be honest, i just played and created some tests | |
| 13:45:30 | sdatko | in those tests, i used nova.db.sqlalchemy.api.flavor_create() | |
| 13:45:50 | sdatko | this one is outdated? | |
| 13:46:22 | mriedem | you shouldn't be playing around with the db apis directly | |
| 13:46:49 | mriedem | everything goes through nova.objects.flavor.Flavor | |
| 13:47:58 | sdatko | ouuu | |
| 13:48:28 | sdatko | my fault then | |
| 13:48:33 | sdague | bauwser: I would honestly throw an exception there as well | |
| 13:48:44 | sdatko | thanks mriedem | |
| 13:48:45 | sdague | the rest of the code is going to fail with a different exception later | |
| 13:49:04 | bauwser | sdague: fine, I was just thinking of leaving the glanceclient providing its own exception | |
| 13:49:14 | mriedem | sdague: bauwser: here is the ocata backport for that rbd thing https://review.openstack.org/#/c/472687/ | |
| 13:49:20 | mriedem | sdatko: yw | |
| 13:49:43 | bauwser | mriedem: hold my beer | |
| 13:50:04 | sdague | mriedem: probably should trigger a release off of that on stable as well | |
| 13:50:53 | bauwser | mriedem: in other words, ping me when master is merged | |
| 13:51:07 | mriedem | sdague: yeah we have quite a few things to get into stable/ocata for a release | |
| 13:51:25 | bauwser | we could release mid-week | |
| 13:54:24 | sdague | mriedem: meaning there are a bunch of other patches you want in/ | |
| 13:54:25 | sdague | ? | |
| 13:54:31 | sdague | or a bunch that are already? | |
| 13:55:27 | mriedem | sdague: the former | |
| 13:56:00 | mriedem | alex_xu: cdent: on the traits bp, as far as using traits, isn't jay working on some changes in the scheduler to use the misc shared aggregates trait for shared resources (storage)? | |
| 13:56:01 | sdague | mriedem: if you list them, I'll take a look | |
| 13:56:07 | sdague | or just "all of them" | |
| 13:56:18 | cdent | mriedem: yes, but that's just for that one trait | |
| 13:56:19 | mriedem | alex_xu: cdent: i think that's https://blueprints.launchpad.net/nova/+spec/shared-resources-pike | |
| 13:56:26 | cdent | not traits in general | |
| 13:56:39 | mriedem | cdent: sure but i don't think we said we were going to support users requesting traits during server create in pike | |
| 13:56:42 | mriedem | that's a queens thing | |
| 13:56:49 | mriedem | pike was about infra plumbling | |
| 13:56:52 | mriedem | *plumbing | |
| 13:56:53 | cdent | mriedem: I wasn't trying to suggest it was a pike thing | |
| 13:56:59 | cdent | just that it was something we haven't talked much about yet | |
| 13:57:00 | mriedem | ok - so we can close out the traits bp yes? | |
| 13:57:03 | mriedem | it's most about the lib and the api | |
| 13:57:06 | cdent | yes, that's what I said | |
| 13:57:14 | mriedem | ok, just double checking. thanks. | |
| 13:57:20 | cdent | ✔ | |
| 13:59:04 | mriedem | i guess gerrit just died | |
| 13:59:17 | bauwser | oh yet | |
| 13:59:19 | bauwser | yeah | |
| 13:59:20 | bauwser | fun | |
| 13:59:39 | mriedem | sdague: just all i guess, i don't have a full list right now | |
| 14:02:01 | artom | mriedem, btw, continuing the transient/persistent domain discussion from last night | |
| 14:02:47 | artom | mriedem, you may be interested in what kashyap told me this morning | |
| 14:02:48 | artom | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/latest.log.html | |
| 14:03:00 | artom | (Sorry I can't link to a specific line, but it's near the end) | |
| 14:05:07 | mriedem | ok | |
| 14:05:08 | mriedem | read it | |
| 14:05:08 | melwitt | here's a link to a line http://eavesdrop.openstack.org/irclogs/%23openstack-nova/latest.log.html#t2017-06-09T12:59:43 | |
| 14:05:30 | mriedem | artom: i'm out today in about 20 minutes, | |
| 14:05:35 | mriedem | this is my debug patch https://review.openstack.org/#/c/471494/ | |
| 14:05:43 | mriedem | in neutron which depends on a nova change that dumps debug info when we fail | |
| 14:05:54 | mriedem | interestingly it's survived a few rechecks without hitting hte issue | |
| 14:05:55 | mriedem | of course | |
| 14:31:56 | bauwser | vladikr: do we have some documentation that I can point to for NIC device tagging in order to mark https://bugs.launchpad.net/nova/+bug/1696664 as invalid ? | |
| 14:31:56 | openstack | Launchpad bug 1696664 in OpenStack Compute (nova) "Order of the interfaces is not honored when using virt and SR-IOV interfaces" [Low,Confirmed] | |
| 14:32:08 | bauwser | vladikr: I can point to the spec but it's not super handy | |
| 14:32:16 | bauwser | superdan: in case you know too ^ | |
| 14:32:37 | superdan | bauwser: not sure, ask artom | |
| 14:32:45 | vladikr | bauwser, I'm not aware of anything besides the spec.. | |
| 14:32:51 | superdan | I'm guessing maybe just the spec and the api-ref | |
| 14:33:31 | bauwser | fair enough, the api-ref is a valid document | |
| 14:33:45 | artom | bauwser, in the end, regardless of what magic we're able to achieve across the entire stack, the guest OS can still do whatever it wants | |
| 14:34:07 | artom | So even if we magically can preserve whatever order the user expects, the guest can say "lulz no, have it my way" | |
| 14:34:13 | bauwser | artom: that's the reason why you proposed tags, right? | |
| 14:34:37 | artom | bauwser, it's the reason tags came about, yeah | |
| 14:34:46 | bauwser | artom: I just want to explain to the bug reporter that he can lookup those tags instead of awaiting specific ordering | |
| 14:35:13 | bauwser | and FWIW, I'd even be in favor of removing the codepath that does the ordering now that we have that feature | |
| 14:35:26 | bauwser | because it makes false promises | |
| 14:36:13 | artom | bauwser, I'm not aware of any doc that promises preserved ordering | |
| 14:37:20 | bauwser | artom: that's worst, that's in code | |
| 14:37:39 | artom | bauwser, it's technically better, because it's easier for us to say "it's not supported" | |
| 14:37:46 | bauwser | which would mean that someone looking at the code could add some documentation | |
| 14:37:54 | bauwser | without getting full knowledge | |
| 14:38:10 | bauwser | artom: see my original comment on the bug | |