Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-03
12:31:46 gibi ShilpaSD: I get the following from my patch
12:31:47 gibi Extension error:
12:31:47 gibi Could not import extension ext.versioned_notifications (exception: No module named 'nova')
12:31:50 gibi ERROR: InvocationError for command '/home/ebalgib/upstream/git/masakari/.tox/docs/bin/python setup.py build_sphinx' (exited with code 1)
12:32:05 gibi ShilpaSD: and as I said this is expected as I just blindly copied versioned_notifications.py from nova
12:32:12 gibi and that python code imports nova
12:33:27 ShilpaSD ok, will check further, give me few time, will get back to you
12:33:49 gibi ShilpaSD: so the next step with that patch would be to adapt the code in versioned_notificaton.py to masakri
12:33:51 gibi ShilpaSD: sure
12:34:01 ShilpaSD gibi: sure
12:42:12 ShilpaSD gibi: thanks, after adding 'https://review.openstack.org/#/c/621558/1/doc/source/conf.py@19', its giving me proper stack trace, and now i am on the way to resolve errors listed
12:42:40 ShilpaSD earlier it gives, exception: cannot import name 'json_ref'
12:43:03 gibi ShilpaSD: cool
12:43:05 ShilpaSD after resolving its giving further error with detailed stack trace
12:43:17 gibi ShilpaSD: json_ref is also something that is inside nova
12:43:37 ShilpaSD gibi: yes, that i have got it
12:43:44 gibi OK
12:44:00 ShilpaSD now further issues with my code, will check and get back to you if any further hurdles
12:44:58 gibi ShilpaSD: sure, you can ping me any time (I'm working mostly in EU timezone)
12:45:28 ShilpaSD gibi: sure thnaks
13:11:34 sean-k-mooney sligtly off topic but does anyone know if any of the people from packet are on the nova irc?
14:01:34 stephenfin sean-k-mooney: packet?
14:02:18 sean-k-mooney stephenfin: https://www.packet.com/
14:02:41 stephenfin sean-k-mooney: You learn something new every day
14:05:33 sean-k-mooney i am planning on setting up a 2 node openstack over the christmas + nodepools/zuul but i was debating about using some burst capasity from them or another cloud provider also
14:06:03 sean-k-mooney i have the hardware locally to do ci but as you heard my rackmount server are not exactly quite
14:07:19 sean-k-mooney ahyway i might not but just wanted to ask them a few questions like can i set a montly limit on pricing that kind of thing
14:14:48 adrianc sean-k-mooney: Hi, regarding libvirt-neutron-sriov-livemigration, did you have a chance to look further at the code ? Also did you get a chance to work on the direct port support for POC ?
14:15:28 adrianc sean-k-mooney: i.e the detach/attach flow
14:18:46 sean-k-mooney adrianc: i hope to start working on the direct mode support this/ next week as my primary focus. i have been dealing with downstream bugs for the last week or more so other then deploying your code i have not made much progress
14:19:43 sean-k-mooney adrianc: i see you pushed a new version of the code yesterday
14:19:59 adrianc sean-k-mooney: ack, ill upload an updated PS today, dealing with some unit test issues
14:20:14 sean-k-mooney i should get a change to re review and redeploy with it tomorrow
14:20:33 adrianc sean-k-mooney: yes, addressing some of the issues that we talked abou, plus better clarifying the code
14:20:58 sean-k-mooney i will be respinnign the spec today/tommorow too by the way
14:22:04 adrianc sean-k-mooney: any major changes ? or mainly what was discussed in the review ?
14:22:25 sean-k-mooney ill try and align the spec to the code you have submitted.
14:22:52 mriedem bauzas: while you're here, it would be good to get another core looking at the initial allocation ratio series, starting here https://review.openstack.org/#/c/620154/
14:22:52 sean-k-mooney adrianc: am bauzas had some cleanups/clarifing questions but no major changes
14:23:22 bauzas mriedem: sure, will do
14:23:58 sean-k-mooney adrianc: ill be addressing his nits first but if you want to respond to any of his questions ill incoperate your answers tomorrow after i review the latest version fo the code
14:24:26 adrianc adrianc: great, so seems we are on the right track, ill look at his comments today and comment if needed
14:25:11 sean-k-mooney adrianc: the main question resolves around how the claims will work and how we handel mixed verions of compute nodes
14:28:25 sean-k-mooney adrianc: i am hoping we can converge on the spec and approve it in the next week or so and then have the code ready for a runway not too long after. if we can land this before m2 that would be ideal but we will see how things go
14:28:46 sean-k-mooney there are several higher priority items ahead of it
14:56:30 jangutter jaypipes, sean-k-mooney: regarding the os-vif-generic-datapath-spec-of-doom, how would I go about "freezing the object versions prior to a major version bump"?
14:57:16 sean-k-mooney you wouldnt we jsut would not bump them if that is what we agreed to do
14:57:52 jangutter jaypipes, sean-k-mooney: OK, is there some way of submitting that as a doc patch to os-vif?
14:57:54 jaypipes sean-k-mooney: I've proposed just back-versioning everything to 1.0 on all those objects.
14:58:04 jaypipes sean-k-mooney: since nothing is sent over the wire anyway
14:58:20 sean-k-mooney jaypipes: so kuryr might be
14:58:26 jaypipes ugh
14:58:30 sean-k-mooney they should not be but they might be
14:58:38 sean-k-mooney but we will figure that out
14:58:55 sean-k-mooney im fine with flatneing to 1.0 or 2.0
14:59:08 sean-k-mooney jaypipes: did you see my mail by the way
14:59:25 jaypipes sean-k-mooney: yes but haven't gotten to it yet this morning
15:00:34 sean-k-mooney it kindof long you can skip most of it
15:01:02 jangutter is there a separate mailing list for os-vif (or is it mostly nova + neutron)...
15:01:42 sean-k-mooney i will likely propsoe a patch to our docs later this week to update our usage docs to document some of expections we have more explictly
15:02:05 sean-k-mooney jangutter: i useally add [os-vif] and [nova][neutron]
15:02:12 sean-k-mooney but not really
15:14:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529
15:14:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
15:14:20 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
15:14:20 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078
15:14:21 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079
15:18:12 jangutter sean-k-mooney, jaypipes: if I don't need to jump through hoops, I hope https://review.openstack.org/#/c/572081 is a good representative of 'Option 1'.
15:21:03 mriedem dansmith: online data migration pattern check here https://review.openstack.org/#/c/613499/12/nova/objects/compute_node.py@211 - it works, but not sure if it's the "right way"
15:21:21 openstackgerrit Balazs Gibizer proposed openstack/nova master: Deprecate the unversioned notifications https://review.openstack.org/603079
15:21:29 dansmith mriedem: queued
15:21:45 adrianc Ah i really need to setup an IRC bouncer, sean-k-mooney: understood, ive dealt with the mixed version in the code. we will see how it goes.
15:22:39 sean-k-mooney adrianc: i just set up znc on kubernets over the weekend. k8s is a pain on the ass but i now have a bouncer
15:23:48 sean-k-mooney it was so much more work then i had planned vs plain docker
15:23:50 adrianc i may go straight with docker then :)
15:25:33 sean-k-mooney well i had to set up helm to deploy nginx/ingress contoller + certmanger for lets encyrpet certs to then deploy znc with config via config maps + an init sidecar container
15:25:56 sean-k-mooney or i could have deployed 2 contienrs by hand.
15:26:34 sean-k-mooney my k8s cluster is a single node on an old laptop so its not like ita actully does anyting other then booting a docker container anyway
15:49:34 adrianc thinking about it further maybe ill spin up a VM on my development machine and run it there, quicker ramp-up time as i havent actually used docker but it may be a good experience on the other hand :)
15:50:32 sean-k-mooney you can always just install znc to the host. people are still allowed to do that :)
15:51:10 cdent heresy!
15:54:57 adrianc lol
15:55:31 cdent mriedem: on the nova-status tests: they rely on the placement database. Would you prefer: a) move the test into the functional hierarchy so only functional tests are using the "remote" placement database fixture, b) unwind the removal of a "local" placement database fixture (in nova/test.py, c) mock the shit out of that stuff, or d) not bother and leave the test removed?
16:00:52 cdent efried, jaypipes, dansmith, edleafe ^
16:02:50 cdent e) use the placement database fixture under 'unit' is not an option, because only the functional tests install placement
16:03:45 edleafe You know I despise unit tests that test more than a unit
16:04:20 edleafe If it stays in unit, mock it. But moving to functional sounds like a better option
16:07:12 cdent thanks edleafe, for now I'm going with move to functional as anything else is way more work than it is worth
16:07:59 jaypipes cdent: my vote would be same as Ed's. move it to functional...
16:08:34 cdent thanks jaypipes
16:09:13 gibi +1 for moving it to functional :)
16:15:11 mriedem sorry was in another channel,
16:15:32 mriedem or e) i could rewrite those tests to use the placement rest api fixture (not the db fixture) in a patch below this one
16:17:26 cdent mriedem: the test, as currently written in master, cannot pass with the other changes in the patch, which remove the placement database, locally
16:17:53 cdent so it would definitely need to be a prioer to this one, if you're feeling inclined
16:18:24 mriedem but the placement fixture (rest api) continues to work, right? but it gets the fixture from placement.
16:19:27 cdent yes, but that fixture is only available to functional tests, not unit
16:19:43 cdent (because only the functional tox jobs import placement master)
16:20:01 cdent this seemed a good safeguard to insure that unit tests are unit tests
16:20:11 cdent and is part of why this test ran into issues

Earlier   Later