| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-15 | |||
| 18:33:31 | melwitt | sean-k-mooney: thanks | |
| 18:34:06 | sean-k-mooney | my inital reaction is this shound never happen in any release after we added the vif plugged events as we wait for those on boot | |
| 18:34:58 | melwitt | oh, I see. I think it's been awhile since those were added | |
| 18:35:10 | melwitt | i.e. before queens | |
| 18:35:19 | sean-k-mooney | yes back in like mitaka or so queens should have it | |
| 18:35:32 | sean-k-mooney | im going to ask from mor info on what network backend they are using | |
| 18:35:44 | melwitt | ok, cool | |
| 18:35:45 | sean-k-mooney | if they are using odl then that would explain the behavior | |
| 18:36:02 | melwitt | oh, right. I vaguely remember that from last time I tried to think about vif plug events xD | |
| 18:36:04 | sean-k-mooney | odl sends the event on port bind not when odl wires it up | |
| 18:50:46 | fried_rice | mordred: ! | |
| 18:52:03 | fried_rice | mordred: I pulled down your openstacksdk patch, diddled with it a little bit, added a kwarg to Connection, instantiated it with a CONF and a session/auth established from ks_loading, and succeeded in talking to placement through it. | |
| 18:52:31 | mordred | fried_rice: SWEET! | |
| 18:52:36 | fried_rice | mordred: Permission to upload my changes to your patch so I can create one in nova that depends-on it and proceed? | |
| 18:52:40 | mordred | please do | |
| 18:53:20 | mordred | fried_rice: that's super exciting that it worked and stuff | |
| 18:53:37 | mordred | or, you know "worked" well enough for you to make it actually work | |
| 18:53:39 | fried_rice | mordred: FYI, my ipython session looked roughly like this: | |
| 18:53:39 | fried_rice | import openstack | |
| 18:53:39 | fried_rice | from nova import conf | |
| 18:53:39 | fried_rice | conf.CONF(args=['--config-file', '/etc/nova/nova-cpu.conf']) | |
| 18:53:39 | fried_rice | from keystoneauth1 import loading | |
| 18:53:40 | fried_rice | auth = loading.load_auth_from_conf_options(conf.CONF, 'placement') | |
| 18:53:40 | fried_rice | sess = loading.load_session_from_conf_options(conf.CONF, 'placement', auth=auth) | |
| 18:53:41 | fried_rice | from openstack import connection | |
| 18:53:41 | fried_rice | conn = connection.Connection(session=sess, oslo_conf=conf.CONF) | |
| 18:53:42 | fried_rice | conn.placement.get('/resource_providers').json() | |
| 18:54:01 | fried_rice | and obviously the money shot was that last thing producing the expected json payload. | |
| 18:54:12 | mordred | fried_rice: ++ | |
| 18:55:10 | mordred | fried_rice: fwiw, when you stitch it in to nova - pass app_name and app_version to the parameters (app_name of "nova" I think :) ) - it updates the user agent strings | |
| 18:55:34 | fried_rice | mordred: okay, will do. | |
| 18:55:46 | mordred | but does it via appending - so it'll be like nova/blah openstacksdk/blah keystoneauth/blah | |
| 18:55:47 | fried_rice | mordred: um, maybe will add a TODO | |
| 18:55:49 | mordred | ++ | |
| 18:56:00 | mordred | add a todo - I can followup | |
| 18:56:01 | fried_rice | right now I just want to PoC this sucker. | |
| 18:56:04 | mordred | yup | |
| 18:56:53 | fried_rice | mordred: btw, is the above connection-y stuff how you envisioned this tying together from the pov of the openstacksdk consumer (i.e. nova)? | |
| 18:57:15 | fried_rice | awkward that there's already a kwarg called `config`; I figured `oslo_conf` was adequately explicit. | |
| 18:58:10 | mordred | fried_rice: yeah - I think that totally works. I was originally thinking the user might just use the openstack.config.from_conf or whatever I called it to make a CloudRegion that could be passed to Connection's config parameter ... | |
| 18:58:29 | mordred | fried_rice: but your way makes total sense and I think should make it nicer for other openstack projects to follow suit | |
| 18:58:44 | fried_rice | ight | |
| 18:58:51 | mordred | so "yes" | |
| 18:58:56 | fried_rice | ight | |
| 19:02:50 | sean-k-mooney | melwitt: i have marked https://bugs.launchpad.net/nova/+bug/1801303 as incomplet and subsribed my self to the bug. if i get a responce i will retriage but this likely will end up getting moved to invlaide since its been a few months since it was first reported. | |
| 19:02:52 | openstack | Launchpad bug 1801303 in OpenStack Compute (nova) "VM send DHCP request before openflow is created in br-int" [Low,Incomplete] | |
| 19:03:28 | melwitt | sean-k-mooney: thanks for helping with that. yeah, hopefully we'll get a response | |
| 19:04:55 | mordred | fried_rice: it seems like a slight logic error in Connection ... | |
| 19:05:02 | mordred | but you said it worked for you | |
| 19:05:11 | fried_rice | mordred: what seems like a logic error? | |
| 19:05:25 | mordred | if session: is the first thing, then elif oslo_conf: | |
| 19:05:37 | mordred | fried_rice: but you're passing in an oslo_conf and a session | |
| 19:05:49 | fried_rice | hum, maybe that means it's only using the session and I don't need the conf :) | |
| 19:05:58 | fried_rice | iow I'm not hitting your code at all | |
| 19:06:03 | fried_rice | trying... | |
| 19:06:05 | mordred | yeah. it'll totally work just with teh session | |
| 19:06:46 | mordred | but - if there are any adapter level conf settings - like ... interface, region_name or endpoint_override they'll be ignored | |
| 19:07:12 | mordred | (those being teh ones I could imagine are most likely for someone to set in their nova.conf file | |
| 19:07:55 | fried_rice | ack (and confirmed btw). Will twiddle and retry to make sure it still works :) | |
| 19:08:34 | mordred | cool! I left a comment on the review for posterity | |
| 19:09:20 | fried_rice | ...also works fwiw | |
| 19:09:29 | mordred | \o/ | |
| 19:09:45 | fried_rice | I guess I would need to do something nonstandard with adapter-only settings to make sure it's actually excercising the code, but for now... | |
| 19:09:59 | mordred | or just put ina print statement :) | |
| 19:10:13 | mordred | but yeah - I thnk for now that's fine | |
| 19:10:17 | fried_rice | No, I mean *exercising* | |
| 19:10:40 | fried_rice | like, I should remove the public interface from my service catalog and set my conf to private | |
| 19:10:42 | fried_rice | or something. | |
| 19:10:46 | mordred | yeah. totally | |
| 19:13:22 | mordred | fried_rice: if it's ok with you - I'll start updating that with docs | |
| 19:13:52 | fried_rice | mordred: It's all yours. I'll buzz you if I need to diddle with it any further for local testing purposes, but I think I'm done for now. | |
| 19:17:37 | fried_rice | mordred: What happens if I pass kwargs like microversion and headers into primitives like .get? | |
| 19:18:03 | fried_rice | I think what I'm asking is, do I have to go around and remove all that shit from my placement client to make it go, or can I do that cleanup later? | |
| 19:18:06 | mordred | it works exactly like keystoneauth adaptr (it is a subclass of a ksa adapter) | |
| 19:18:17 | fried_rice | okay, so probably redundant, but harmless | |
| 19:18:34 | mordred | nah - I think you should totally pass those thigns in | |
| 19:19:18 | mordred | conn.placement.get() is pure passthrough ksa.Adapter. it doesn't do anything special with microverions for you - other than doing major version discovery | |
| 19:19:45 | mordred | the higher order methods for other services, like ironic, are where the sdk will be handling microversions and headesr for you | |
| 19:19:56 | mordred | but for placement - just a one-to-one swap should be totally fine | |
| 19:21:55 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: Use openstacksdk for placement https://review.openstack.org/643664 | |
| 19:22:05 | fried_rice | mordred: ^ | |
| 19:22:12 | fried_rice | expect that to fail unit/functional but pass tempest etc. | |
| 19:22:21 | fried_rice | assuming Depends-On chain works here... | |
| 19:22:32 | mordred | probably because unit tests mock ksa somehow? | |
| 19:22:40 | fried_rice | yes | |
| 19:22:44 | fried_rice | um | |
| 19:22:45 | mordred | I mean - to be fair - mocking ksa should still work | |
| 19:22:47 | fried_rice | maybe | |
| 19:22:57 | mordred | since it's still basically ksa | |
| 19:22:57 | fried_rice | yeah, I suppose it's possible most of the unit/functional will still pass. | |
| 19:23:09 | fried_rice | Just the ones that actually mock the get_ksa_adapter utils | |
| 19:23:15 | fried_rice | will fail | |
| 19:23:16 | mordred | yeah | |
| 19:23:22 | fried_rice | we'll see | |
| 19:23:30 | fried_rice | maybe the whole thing will blow up because I effed something. | |
| 19:23:41 | fried_rice | But I'm generally super pleased with how simple this is turning out to be to get off the ground. | |
| 19:24:55 | mordred | fried_rice: yeah - being pleased is almost always the wrong choice :) | |
| 19:25:06 | mordred | fried_rice: but yeah -s ince you already jinxed it - I'm also super pleased :) | |
| 19:25:18 | fried_rice | hah! | |
| 19:25:26 | fried_rice | Drinks tonight. Mourning next week. | |