Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-13
05:21:21 Kevin_Zheng gmann: thanks, and I replied your comment, and I just came up with the idea to also assert the error message in one test, will add it later
05:24:52 gmann Kevin_Zheng: i see, nice. thanks test case will be nice there
05:57:54 openstackgerrit zhaolihui proposed openstack/nova: Fix keypair quota error https://review.openstack.org/403529
06:16:28 openstackgerrit Jeremy Liu proposed openstack/python-novaclient: Enable coverage report in console output https://review.openstack.org/419723
06:35:20 openstackgerrit Istvan Imre proposed openstack/python-novaclient: Pass relevant parameters to Token based authentication https://review.openstack.org/419441
06:56:30 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add some code to reject known bad filters. https://review.openstack.org/419256
06:57:02 Kevin_Zheng gmann, alex_xu tests added ^
08:04:11 snikitin alex_xu: Hi Alex! good point about upgrade problem in diagnostics api. You described case when we have new api and old compute, right? I think we can handle this case in view class https://review.openstack.org/#/c/355540/18/nova/api/openstack/compute/views/server_diagnostics.py
08:04:11 snikitin As response of new micriversion is standartized we must return all diagnostics fields. But as we noted in spec and docs, some of this fields may be 'None' because some hypervisors can't provides some kinf in information.
08:04:11 snikitin In our upgrade case we can try to fill diagnostics fields by information we got from old hypervisor drivers (most of fields in old and new diagnostics objects are equal) and left other fields empty. And of course we should log warning something like "Your compute is to old so data in diagnostics response may be incomplete" . What do you think?
08:04:59 snikitin *some kind of information
08:08:58 alex_xu snikitin: emm....i feel it is ok
08:09:30 snikitin alex_xu, good! ty
08:09:39 alex_xu snikitin: i'm thinking whether it makes the API behaviour different in the upgrade
08:10:00 alex_xu snikitin: but yes, empty is valid value
08:10:07 openstackgerrit Istvan Imre proposed openstack/python-novaclient: Pass relevant parameters to Token based authentication https://review.openstack.org/419441
08:10:13 alex_xu we didn't break any API contract
08:10:54 snikitin okay
09:57:23 amoralej hi, i have a question about cellsv2 in ocata
09:57:55 amoralej when initially deploying nova, we create cell0 and map the registered compute nodes using simple_cell_setup
09:58:15 amoralej but, if i add new compute nodes, are they automatically added or do i need to run nova-manage manually to map them?
10:17:09 johnthetubaguy amoralej: I think this is the command you want: https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L1367
10:17:49 amoralej thanks johnthetubaguy
10:31:18 Kevin_Zheng johnthetubaguy: hi, I update the code here: https://review.openstack.org/#/c/419256/
10:31:41 Kevin_Zheng it contains two approach, could you have a look?
10:31:56 Kevin_Zheng the reject bad param thing :)
10:44:21 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: [WIP][py35] Trying to get cinder+rally working https://review.openstack.org/419476
11:06:24 openstackgerrit Balazs Gibizer proposed openstack/nova: handle uninited fields in notification payload https://review.openstack.org/415857
11:10:35 mdbooth lyarwood: Any reason you split https://review.openstack.org/#/c/402163/ and its predecessor into separate patches?
11:12:16 openstackgerrit Balazs Gibizer proposed openstack/nova: handle uninited fields in notification payload https://review.openstack.org/415857
11:14:31 lyarwood mdbooth: not that I can think of, happy to squash them togther tbh
11:15:07 mdbooth lyarwood: Got a bit of a narrative going on there, btw. I asked you for an additional test, but then said you don't seem to need to parse filesystem at all.
11:15:13 mdbooth In which case you wouldn't need a test, I guess.
11:15:40 mdbooth The code which consumes this already assumes it's a disk, not a filesystem
11:18:41 lyarwood mdbooth: hmm do we not even call this when using lxc?
11:18:56 mdbooth lyarwood: I don't know, but it's already busted in the case I think
11:19:08 lyarwood mdbooth: true
11:19:23 mdbooth https://review.openstack.org/#/c/402163/10/nova/virt/libvirt/guest.py
11:19:34 mdbooth node = doc.find("./devices/disk/target[@dev='%s'].." % target_device)
11:19:36 mdbooth Line 311
11:20:21 mdbooth Do we support filesystems as volumes?
11:20:45 mdbooth If no, I think we don't worry about it for the moment
11:20:56 mdbooth Maybe leave a comment
11:21:46 lyarwood mdbooth: I'm not sure tbh, the lookup hasn't changed here so if we do it's already broken
11:21:56 mdbooth My thinking too
11:22:15 mdbooth I suspect we don't
11:23:26 lyarwood we do as eph storage right?
11:25:39 mdbooth I'd have to check. Don't recall off the top of my head.
11:25:58 mdbooth eph is local, though, so completely different.
11:26:52 mdbooth lyarwood: Are you working on this series while I'm reviewing, btw?
11:27:19 lyarwood mdbooth: not yet, give me 10 and I'll squash the first two
11:27:26 mdbooth i.e. Do you want me to continue sending a stream of consciousness, or wait a bit between hitting the DENIED button?
11:27:40 lyarwood mdbooth: feel free to continue
11:31:14 mdbooth lyarwood: Maybe hold off squashing...
11:31:31 Kevin_Zheng johnthetubaguy: so you are suggesting the decorator idea?
11:31:32 mdbooth That's easy done later
11:32:03 johnthetubaguy Kevin_Zheng: that was my preference at the meeting, but honestly, I am tempted to merge what we have now, and refactor later
11:32:34 johnthetubaguy Kevin_Zheng: I don't think we are talking about behaviour changes (apart from maybe different error messages?)
11:34:42 cdent Kevin_Zheng: since you're around, are you still working on https://review.openstack.org/#/c/410128/ or would you prefer someone else pick that up?
11:35:42 Kevin_Zheng cdent: one sec, I'm having some problem with my network now :(
11:37:03 Kevin_Zheng cdent: Ah, you can pick it up
11:37:21 dims cdent : good afternoon. have some time for me?
11:37:38 amoralej may i get some help on https://bugs.launchpad.net/puppet-nova/+bug/1656276 ?, i'd like to understand the best workflow to deploy nova environment with cellsv2
11:37:38 openstack Launchpad bug 1656276 in tripleo "Error running nova-manage cell_v2 simple_cell_setup when configuring nova with puppet-nova" [Critical,Triaged]
11:37:40 cdent Kevin_Zheng: will do, I didn't want to mess with it if you still had is in progress
11:37:48 cdent dims: I always have at least a little time for you
11:37:49 mdbooth lyarwood: I'm looking here, line 1530
11:38:01 mdbooth lyarwood: And here: http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainBlockJobAbort
11:38:12 Kevin_Zheng cdent: yeah thanks for ask
11:38:18 dims cdent thanks :) please review a WIP for me https://review.openstack.org/#/c/419476/
11:38:35 dims cdent : with those changes, i can get some nova scenarios working http://logs.openstack.org/43/418643/5/check/gate-rally-dsvm-py35-cinder-nv/0a95698/rally-plot/results.html.gz#/CinderVolumes.create_and_attach_volume/details
11:38:52 mdbooth lyarwood: It seems to me that if we already have an unambiguous full patch to the source disk, using target dev name is only a potential source of error?
11:38:57 Kevin_Zheng johnthetubaguy: you mean the current implement of https://review.openstack.org/#/c/408571/
11:39:06 mdbooth lyarwood: What was your thinking in making this change?
11:39:19 johnthetubaguy Kevin_Zheng: yeah
11:39:19 mdbooth I haven't looked at the next patch yet, so may be missing context
11:39:27 lyarwood mdbooth: sorry you didn't link to the review, which file are we looking at?
11:39:46 mdbooth https://review.openstack.org/#/c/402163/10/nova/virt/libvirt/driver.py
11:40:00 lyarwood thanks
11:40:16 Kevin_Zheng johnthetubaguy: hmm fine by me, maybe check with alex?
11:40:23 mdbooth lyarwood: Trying to understand the motivation moving from disk_path -> target
11:40:53 mdbooth The purpose of this change and the previous one seems to be to move away from using disk_path, but I don't get why yet.
11:42:28 lyarwood mdbooth: so off the top of my head I think this was to allow us to swap rbd volumes etc
11:42:51 lyarwood mdbooth: basically anytime we don't have an actual path
11:42:57 lyarwood mdbooth: let me go over this again quickly
11:43:13 mdbooth lyarwood: Ah....
11:43:22 mdbooth RBD has no path
11:44:16 mdbooth Although, libvirt has its own representation of rbd 'paths' iirc
11:44:56 openstackgerrit jichenjc proposed openstack/nova: Allow -1 as limit value to pager https://review.openstack.org/419893
11:46:30 lyarwood mdbooth: ah and the main reason for doing this was that we would end up stashing either a disk_path or target_dev in BlockDevice._disk that was really confusing
11:47:02 lyarwood mdbooth: so I thnk i just went with target_dev as we should always have it and it's going to work when we don't have a file path
11:47:23 cdent dims, left a comment, what's there is probably fine, but I also offered an alternative plan which I can do (but not today) if you think it is better.
11:47:43 lyarwood mdbooth: sorry I should really get all of this context back in my head before asking for a review ;)
11:47:54 cdent dims I gotta go to lunch now, but will check back with you and/or the review later in the day
11:56:48 mdbooth lyarwood: FYI, in terms of merging, I think I'd split your change to Guest.get_disk into a separate patch, and merge the rest of the patch into the previous patch.
11:57:07 mdbooth I think that makes it a little more obvious what's going on.
12:01:28 lyarwood mdbooth: ack thanks
12:01:38 mdbooth lyarwood: I'm still going, btw.
12:01:57 mdbooth I don't like the change to BlockDevice, just writing why.
12:02:45 alex_xu johnthetubaguy: Kevin_Zheng i'm good with refactor the code later

Earlier   Later