Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-13
03:58:58 gmann which we might need to modify seems
04:00:00 Kevin_Zheng Actually I like the format way better
04:00:55 alex_xu gmann: if we can get a correct message that will be great, not sure there is way to change that message
04:01:29 Kevin_Zheng it will be harder than the new format thing I think
04:01:56 alex_xu yea, i'm also worry about that
04:01:58 gmann alex_xu: yea error message is issue but let me check if we can easily modify that
04:02:03 Kevin_Zheng the mssage is below the one I changed for the current way
04:02:45 Kevin_Zheng maybe hard to identify the "not" thing because it might be a validation error?
04:02:46 alex_xu gmann: really appreciate that :)
04:03:00 Kevin_Zheng VallidationError
04:03:38 gmann Kevin_Zheng: yea it will be validation error from json itself
04:04:45 Kevin_Zheng gmann: yeah, but other also raise ValidationError and the msg was generated. So we have to identify the case of this
04:04:58 Kevin_Zheng maybe harder than the current way
04:05:49 gmann Kevin_Zheng: yea, that is pain point.
04:14:24 gmann alex_xu: Kevin_Zheng yea we have to add hack for that which kindda new overridden code on top of json schema. That is what new formatter way.
04:31:33 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: [WIP][py35] Trying to get cinder+rally working https://review.openstack.org/419476
04:36:57 gmann alex_xu: Kevin_Zheng i think formatter is ok which is much easy, how about showing few schema example with new 'format' also in https://review.openstack.org/#/c/419256/7
05:19:23 openstackgerrit Zhenyu Zheng proposed openstack/nova: [poc] add some code to reject known bad filters. https://review.openstack.org/419256
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.

Earlier   Later