| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-09 | |||
| 15:22:32 | tbachman | lol | |
| 15:22:36 | tbachman | superdan: thx | |
| 15:22:52 | superdan | \o/ | |
| 15:22:57 | giblet | lol | |
| 15:23:01 | tbachman | give that man a cape! | |
| 15:23:04 | Systemotic | In Korean, Teehee is 티히 | |
| 15:23:07 | finucannot | 0aGVyIGNlbGwsCnRoaXMgY29tbWFuZCB3aWxsIHJldHVybiBhbiBleGl0IGNvZGUgb2YgMy4gSWYgdGhlIHByb3BlcnRpZXMgY2Fubm90IGJlIHNldCwKdGhpcyB3aWxsIHJldHVybiAyLiBPdGhlcndpc2UsIHRoZSBleGl0IGNvZGUgd2lsbCBiZSAwLgoKLi4gbm90ZTo6CgogIFVwZGF0aW5nIHRoZSBgYHRyYW5zcG9ydF91cmxgYCBvciBgYGRhdGFiYXNlX2Nvbm5lY3Rpb25gYCBmaWVsZHMgb24gYQogIHJ1bm5pbmcgc3lzdGVtIHdpbGwgTk9UIHJlc3VsdCBpbiBhbGwgbm9kZXMgaW1tZWRpYXRlbHkgdXNpbmcgdGhlIG5ldwogIHZhbHVlcy4gIFVzZSBjYXV0aW9uIHdoZW4gY2 | |
| 15:23:12 | finucannot | hhbmdpbmcgdGhlc2UgdmFsdWVzLgoKYGBub3ZhLW1hbmFnZSBjZWxsX3YyIGRlbGV0ZV9ob3N0IC0tY2VsbF91dWlkIDxjZWxsX3V1aWQ+IC0taG9zdCA8aG9zdD5gYAoKRGVsZXRlIGEgaG9zdCBieSB0aGUgZ2l2ZW4gaG9zdCBuYW1lIGFuZCB0aGUgZ2l2ZW4gY2VsbCB1dWlkLiBSZXR1cm5zIDAKaWYgdGhlIGVtcHR5IGhvc3QgaXMgZm91bmQgYW5kIGRlbGV0ZWQgc3VjY2Vzc2Z1bGx5LCAxIGlmIGEgY2VsbCB3aXRoCnRoYXQgdXVpZCBjb3VsZCBub3QgYmUgZm91bmQsIDIgaWYgYSBob3N0IHdpdGggdGhhdCBuYW1lIGNvdWxkIG5vdCBiZQpmb3VuZCwgMyBpZiBhIGhvc3Qgd | |
| 15:23:13 | tbachman | nooooooo | |
| 15:23:15 | superdan | come on | |
| 15:23:17 | finucannot | 2l0aCB0aGF0IG5hbWUgaXMgbm90IGluIGEgY2VsbCB3aXRoIHRoYXQgdXVpZCwgNCBpZgphIGhvc3Qgd2l0aCB0aGF0IG5hbWUgaGFzIGluc3RhbmNlcyAoaG9zdCBub3QgZW1wdHkpLg== | |
| 15:23:19 | Systemotic | It's all buffered | |
| 15:23:20 | finucannot | Christ, Sorry | |
| 15:23:22 | Systemotic | his client is still sending it | |
| 15:23:24 | finucannot | mriedem: Take two: http://paste.openstack.org/show/696393/ | |
| 15:24:21 | giblet | what a Friday :) | |
| 15:25:32 | kashyap | Stephen, isn't it too early for a beer? | |
| 15:25:35 | kashyap | :D | |
| 15:25:43 | kashyap | Ah, he's out of the channel | |
| 15:26:03 | finucannot | I'm back | |
| 15:26:08 | finucannot | Well, that was fun | |
| 15:26:18 | finucannot | #FridayBants | |
| 15:27:24 | mriedem | i dropped the +2, feel free to make the changes you want | |
| 15:27:36 | mriedem | also, goo.gl | |
| 15:28:08 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Allow overriding a compute node's UUID https://review.openstack.org/551315 | |
| 15:28:12 | leakypipes | giblet: ^ | |
| 15:28:46 | finucannot | mriedem: Rejected it as an invalid link (probably because of all the encoding) | |
| 15:29:43 | Systemotic | All this activity makes me sad you folks will be on your weekend for my next two days of work :P | |
| 15:30:00 | mriedem | leakypipes: giblet: ew what is that for? | |
| 15:30:22 | superdan | ugh, really? | |
| 15:30:29 | giblet | leakypipes: thanks | |
| 15:30:41 | leakypipes | mriedem, superdan: thx for your vote of confidence. | |
| 15:30:52 | mriedem | well changing uuids is generally pretty terrible | |
| 15:30:57 | mriedem | we can all agree | |
| 15:31:06 | leakypipes | mriedem: it's for *new* compute hosts that haven't started up. | |
| 15:31:14 | leakypipes | it's not changing anything. | |
| 15:32:03 | superdan | oh this is that neutron thing | |
| 15:32:07 | leakypipes | mriedem: this is to solve the chicken-and-egg problem where external agents cannot manage child provider resources because there's no way to tell the agent what the UUID of the compute node resource provider is. | |
| 15:32:11 | leakypipes | mriedem: right. | |
| 15:32:12 | giblet | mriedem, superdan: for me it is just a usage example to better understand the intention of https://review.openstack.org/#/c/550244/ | |
| 15:33:14 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/queens: [placement] Add sending global request ID in get https://review.openstack.org/543116 | |
| 15:35:16 | mriedem | so operator defines a yaml file of the compute node and all of it's nested providers and their inventory and traits, etc, and all services that care about it read from that file when creating new things, rather than rely on their own information | |
| 15:37:27 | mriedem | can we make it xml and conform to CIM standards? :) | |
| 15:39:17 | mriedem | so this is just the uuids or everything? | |
| 15:39:28 | mriedem | like a heat template for placement? | |
| 15:40:03 | mriedem | what happens when nova-compute says that the inventory the operator put into the yaml file is different from what it calculates? | |
| 15:41:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix indentation in doc/source/cli/* https://review.openstack.org/549166 | |
| 15:41:40 | finucannot | mriedem: ^ the things I do for docs | |
| 15:42:22 | finucannot | That God awful formatting of block comments in openstackdocstheme really needs to be fixed too | |
| 15:43:54 | rabel | finucannot: thank you! while you're at it, could you have a look at https://review.openstack.org/#/c/549180/ too? it's glance's cli docs and probably has the same problem | |
| 15:44:11 | finucannot | rabel: Sure :) | |
| 15:46:43 | finucannot | rabel: That ones not as bad because they're using definition lists correctly - they just happen to have them indented wrongly | |
| 15:46:54 | finucannot | Some comments left all the same, if you fancy tackling them | |
| 15:49:39 | rabel | finucannot: did you post the comments? i can't see them | |
| 15:49:49 | finucannot | whoops | |
| 15:50:01 | finucannot | rabel: actually published now | |
| 15:50:37 | leakypipes | mriedem: no. I specifically did *not* make the provider config YAML format include nested providers. One file per provider. | |
| 15:51:23 | rabel | finucannot: thanks | |
| 15:51:40 | finucannot | rabel: FYI this is the defacto reference guide for all things reStructuredText http://docutils.sourceforge.net/docs/user/rst/quickstart.html | |
| 15:51:40 | mriedem | leakypipes: ok, so it's a yaml file per provider, and can include the full provider description, including inventory, allocations, traits, aggregates, etc? | |
| 15:51:49 | leakypipes | mriedem: if a virt driver or external agent wishes to set overrides on a bunch of resource providers (possibly in a tree of providers), they can use multiple YAML files. I have left the implementation details of that stuff to the agent implementors. | |
| 15:51:49 | finucannot | The actually Sphinx docs are awful (I'm working on it) | |
| 15:51:58 | leakypipes | mriedem: no allocations. | |
| 15:52:02 | leakypipes | mriedem: no aggregates. | |
| 15:52:09 | leakypipes | mriedem: only inventory and traits. | |
| 15:52:10 | mriedem | so just what the RT would report today | |
| 15:52:15 | leakypipes | correct. | |
| 15:52:26 | mriedem | and then the RT will overwrite those, b/c that's what it does today | |
| 15:52:58 | leakypipes | mriedem: I have only submitted a spec describing the behaviour of a single override -- the resource provider's UUID -- in the resource tracker. | |
| 15:53:13 | mriedem | leakypipes: the spec says it can also be inventory and traits | |
| 15:53:31 | leakypipes | mriedem: I haven't discussed overriding inventory or traits in the resource tracker yet. I've only commented on a possible format for describing those inventory/traits overrides. | |
| 15:53:38 | mriedem | https://review.openstack.org/#/c/551315/1/specs/rocky/approved/override-compute-node-uuid.rst@84 | |
| 15:54:01 | mriedem | then ^ should probably come out | |
| 15:54:07 | leakypipes | mriedem: why? | |
| 15:54:29 | mriedem | we need to be clear about what happens if an operator is going to put inventory and trait information in this yaml file, | |
| 15:54:32 | superdan | leakypipes: if we just let them explicitly set the name on the provider, then can't we avoid providing a generic override mechanism so that other services can use the name to sync up? | |
| 15:54:36 | mriedem | because today the RT is going to override that | |
| 15:54:54 | mriedem | if you plan to support out of band inventory/traits definitions, then the spec needs to discuss fixing the override so that nova merges those in | |
| 15:55:05 | leakypipes | mriedem: I'm happy to remove that from the use cases list. | |
| 15:55:28 | leakypipes | mriedem: I planned on another spec to discuss the implementation of inventory and trait overrides in the resource tracker. | |
| 15:55:37 | leakypipes | mriedem: that spec is just for the compute node UUID override. | |
| 15:56:39 | leakypipes | superdan: UUID or name, I don't really care. But there has to be a way of signaling to the resource tracker not to use the CONF.host value. | |
| 15:57:11 | superdan | leakypipes: or we just define a new conf option for the name of the RP, default=None means use CONF.host | |
| 15:57:19 | mriedem | ^ was just thinking that | |
| 15:57:25 | superdan | and then roll from there, without having to provide generic override mechanisms, hard coding uuids, etc | |
| 15:58:03 | leakypipes | superdan: and how does that signal to other agents running in other containers what the value should be that they look up? | |
| 15:58:36 | superdan | the same way as if this override yaml file is present and has a uuid set I guess? | |
| 15:59:26 | superdan | for the container file namespace issue, you can put that one option in its own conf file in a common location | |
| 15:59:39 | superdan | *filesystem namespace I mean | |
| 15:59:43 | leakypipes | superdan: how so? the agent may a) be managing multiple compute nodes and need information on multiple providers and b) needs some way of indicating what those compute node identifiers are. | |
| 16:00:10 | leakypipes | superdan: "one option in its own conf file" vs a standardized descriptor file format for resource providers? | |
| 16:00:25 | superdan | I'm confused. | |
| 16:00:31 | leakypipes | superdan: I would have thought you'd be supportive of not adding yet more configuration options. | |
| 16:00:51 | mriedem | leakypipes: this spec doesn't talk about non-nova agents managing multiple compute nodes | |
| 16:01:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 16:01:23 | mriedem | i'm reading this all as 1:1 with a single compute node | |
| 16:02:21 | leakypipes | mriedem: I can add text about 1:M because that's what neutron agents do... many of them run on controller nodes and manage resources for hundreds of compute nodes. | |
| 16:03:46 | mriedem | sorry for my lack of neutron agent know-how, but that's not the case for OVS and LB is it? | |
| 16:03:55 | mriedem | otherwise how would os-vif plugins work for those? | |
| 16:04:03 | mriedem | since we don't use rpc or rest apis in os-vif | |