| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 18:19:12 | mriedem | johnthetubaguy: i see this backport popped up for ocata https://review.openstack.org/#/c/432954/ is that something we should get into rc2? | |
| 18:19:19 | mriedem | it adds a config option for the placement endpoint | |
| 18:19:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix suggested database migration command https://review.openstack.org/420060 | |
| 18:20:13 | johnthetubaguy | mriedem: I am tempted to add it, although it is a bit feature-like, it does mean users can use their service catalog in their normal way for placement | |
| 18:21:19 | mriedem | johnthetubaguy: checking config options, i guess you can do this same thing more or less for connecting to glance/cinder/neutron/ironic too | |
| 18:22:02 | johnthetubaguy | mriedem: the other ones have URL over-rides that do a similar (but worse) thing | |
| 18:22:39 | mriedem | yeah | |
| 18:23:27 | johnthetubaguy | mriedem: its a bit like this I guess: https://github.com/openstack/nova/blob/8de0c648c218dd748c2076551d1d9819dbeb3bd6/nova/conf/cinder.py#L25 | |
| 18:23:52 | mriedem | yeah | |
| 18:24:15 | mriedem | it will be fun when someone wants to not call the endpoint "placement" in their service catalog | |
| 18:25:02 | mriedem | oh also, this missed nova-status | |
| 18:25:18 | mriedem | https://github.com/openstack/nova/blob/master/nova/cmd/status.py#L182 | |
| 18:25:25 | johnthetubaguy | mriedem: there is some follow up work from that service token stuff, where we should fix up what we do with all that | |
| 18:25:46 | johnthetubaguy | mriedem: dang, that bit got missed | |
| 18:25:50 | mriedem | johnthetubaguy: as far as pike bp? | |
| 18:26:41 | johnthetubaguy | mriedem: I haven't created a BP for that, probably worth doing (tells raj_singh so there are two folks trying to remember that ^) | |
| 18:26:45 | mriedem | johnthetubaguy: https://blueprints.launchpad.net/nova/+spec/use-service-tokens-pike | |
| 18:26:48 | mriedem | it's already done | |
| 18:26:55 | johnthetubaguy | its more follow on from that I guess | |
| 18:27:18 | johnthetubaguy | like glance doesn't use the service catalog at all right now | |
| 18:27:24 | mriedem | yeah i know | |
| 18:27:33 | mriedem | the patch to use ksa was approved but tests were failing | |
| 18:27:41 | mriedem | b/c of the global variables being mocked | |
| 18:27:58 | mriedem | anyway, the pike bp is approved | |
| 18:28:22 | mriedem | no unit test for this? https://review.openstack.org/#/c/426163/ | |
| 18:28:23 | mriedem | gah | |
| 18:28:43 | raj_singh | mriedem: I think we fixed the tests for that, let me take a look. | |
| 18:29:14 | johnthetubaguy | mriedem: :S yeah, no tests, not sure how I missed that, grrr | |
| 18:29:28 | mriedem | i can add tests and also fix the nova-status thing, | |
| 18:29:41 | mriedem | but if we're going to backport the config option change, we should have the other stuff (unit test and nova-status | |
| 18:29:58 | mriedem | plus i'm also procrastinating on dealing with https://etherpad.openstack.org/p/nova-ptg-pike | |
| 18:30:11 | johnthetubaguy | good to get both fixed for sure | |
| 18:30:13 | raj_singh | mriedem: https://review.openstack.org/#/c/412634/ Can you take your -2 off. | |
| 18:30:31 | mriedem | raj_singh: done | |
| 18:30:47 | raj_singh | thx, you are welcome to replace it with -1 :) | |
| 18:30:51 | johnthetubaguy | the others could be post release, worst case, but thats probably a bad idea | |
| 18:31:19 | mriedem | well if we land the one but nova-status doesn't use it, nova-status could fail since it's pusing the wrong endpoint | |
| 18:31:26 | mriedem | *using | |
| 18:31:37 | mriedem | assuming people are going to use nova-status, but i hope they do | |
| 18:32:21 | johnthetubaguy | yeah, it sucks to have that broken | |
| 18:32:29 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835 | |
| 18:32:40 | mriedem | raj_singh: did you see this gem? https://review.openstack.org/#/c/431713/ | |
| 18:33:01 | raj_singh | mriedem: you rock! | |
| 18:35:42 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in aggregate and usage https://review.openstack.org/433224 | |
| 18:39:08 | melwitt | dansmith, mriedem: what's "newton computes" mean? | |
| 18:39:27 | dansmith | melwitt: compute nodes still running n-cpu from newton | |
| 18:39:41 | melwitt | oh, okay | |
| 18:42:08 | sterdnotshaken | With regard to regions, is it required to have replica's of Cinder, Neutron, Nova, etc within each region? I know that all the separate regions share Horizon and Keystone instances, but I'm just wondering if we can get away with not duplicating some of these services in each region… | |
| 18:43:13 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add policy-project-checks spec https://review.openstack.org/433037 | |
| 18:47:08 | oomichi | sdague: johnthetubaguy: hi, about api-ref thing: Which do you prefer: "Including object name in parameter" or not (like addFixedIp.networkId vs networkId) | |
| 18:47:44 | oomichi | sdague: johnthetubaguy: I am reviewing https://review.openstack.org/#/c/338606/18/api-ref/source/servers-action-fixed-ip.inc | |
| 18:48:23 | oomichi | addFixedIp.networkId seems easy to understand the structures of requrest/response of APIs | |
| 18:49:12 | johnthetubaguy | oomichi: I thought we only did that if it was unclear which bit of the request/response we were talking about | |
| 18:49:47 | johnthetubaguy | oomichi: so for host.host, we needed it for all of them | |
| 18:50:02 | oomichi | johnthetubaguy: like multiple paramters in a single object? | |
| 18:50:17 | johnthetubaguy | oomichi: like "host" appears twice | |
| 18:50:18 | oomichi | johnthetubaguy: ah, nice sample :) | |
| 18:50:36 | mriedem | we have that all over, like networks.port | |
| 18:50:42 | mriedem | block_device_mapping_v2.boot_index | |
| 18:51:03 | sterdnotshaken | Anyone happen to know the answer to my question regarding regions? | |
| 18:51:16 | mriedem | sterdnotshaken: see the channel topic please, | |
| 18:51:29 | mriedem | that's a question better asked in ask.openstack.org, or #openstack, or in the general mailing list | |
| 18:52:21 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add policy-project-checks spec https://review.openstack.org/433037 | |
| 18:53:51 | oomichi | mriedem: yeah, that aslo is a nice sample. "create a server" is super complex API, then it is nice to clarify which object the parameters belong to | |
| 19:03:20 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: WIP: spec about having observer role by default https://review.openstack.org/427872 | |
| 19:04:23 | EmilienM | mriedem: hey! in https://review.openstack.org/#/c/432954/ - do you mean the patch is currently noop? | |
| 19:04:49 | mriedem | EmilienM: no | |
| 19:05:16 | openstack | Launchpad bug 1664334 in OpenStack Compute (nova) "CONF.placement.os_interface is not used in nova-status upgrade check" [Medium,Confirmed] - Assigned to Matt Riedemann (mriedem) | |
| 19:05:16 | mriedem | EmilienM: https://bugs.launchpad.net/nova/+bug/1664334 | |
| 19:06:19 | EmilienM | mriedem: ok, so it's lower priority than nova-compute trying to reach placement, right? | |
| 19:07:06 | mriedem | it's not low priority if you use the nova-status upgrade check command to verify the upgrade and talking to 'public' doesn't work | |
| 19:08:58 | EmilienM | mriedem: I see. Thanks | |
| 19:21:30 | sdague | oomichi: yeh, that was the convention we came up with x.y | |
| 19:21:47 | sdague | we never really explained it a ton, I'm sure the cover docs could be better | |
| 19:23:54 | sneti | mriedem, additional-notification-fields-for-searchlight is reapproved for Pike. can you remove -2 on https://review.openstack.org/#/c/407228/ | |
| 19:23:55 | cfriesen | question for resourcetracker types....is it possible for a sched filter to determine whether a host is running with KVM support vs software qemu? | |
| 19:24:34 | mriedem | cfriesen: if a tree falls in the woods but no one is around to hear it, does it make a sound? | |
| 19:25:35 | mriedem | sneti: done | |
| 19:25:57 | sneti | mriedem, thanks! | |
| 19:29:02 | oomichi | sdague: yeah, that could be better. Now most parameters are not described with x.y. So we will face huge amount of works/patches if we will apply it to all other parts | |
| 19:30:05 | sdague | oomichi: yeh, well, it was never going to be easy to dig out of all the debt here | |
| 19:34:03 | oomichi | sdague: OK, I guess it might be good to have some conversation with doc-team also for consistent api-ref docs of all projects before doing that on all our part | |
| 19:39:08 | sdague | cdent: is there more motivation around this - https://review.openstack.org/#/c/426163/6 ? I don't actually understand why there would be multiple registrations of the endpoint | |
| 19:41:29 | cdent | sdague: when that was proposed there was some discussion in IRC about that, about why have the interface notion at all, etc. And the gist of why it ended up in was "this is how we do things in our cloud, we do use, across the board the concept of different interfaces for the same server" and | |
| 19:42:09 | cdent | because resource tracker and scheduler's use of placement went out with no way to declare the interface, it defaulted to doing "public" | |
| 19:42:13 | cdent | evidently | |
| 19:42:21 | mriedem | https://docs.openstack.org/developer/keystoneauth/using-sessions.html | |
| 19:42:26 | mriedem | interface: the network exposure the interface has. This will be one of: public: An endpoint that is available to the wider internet or network. internal: An endpoint that is only accessible within the private network. admin: An endpoint to be used for administrative tasks. | |
| 19:42:49 | mriedem | the docs make it sound as though it's not free-form | |
| 19:42:52 | cdent | so fixing it meant expose the interface concept | |
| 19:42:56 | mriedem | maybe it's not meant to be | |
| 19:42:58 | cdent | and yeah, what mriedem jus said | |
| 19:44:14 | sdague | it's definitely 100% free form | |
| 19:44:43 | cdent | free form in keystone, but apparently not in the keystoneauth docs? | |
| 19:44:46 | sdague | public, internal, admin is basically as rax taxonomy that made it's way to devstack | |
| 19:44:53 | mriedem | apparently it can also be 'auth' | |
| 19:44:53 | sdague | cdent: it's freeform in keystoneauth code | |
| 19:45:17 | mriedem | https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/base.py#L173 | |
| 19:45:48 | cdent | the fact that there is a default is the pain issue, right? | |
| 19:46:01 | sdague | cdent: no, that it's a limitted list | |