Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-21
12:36:41 sean-k-mooney mnaser: so the logic is really old flavor could only be plublic so default to public? if that is the case then yes this makes sense
12:37:49 mnaser jangutter: i pride myself in checking my stuff, hah
12:38:12 mnaser sean-k-mooney: well we either have to assume its public or its not. given that we default to public=True, and that field is missing, it probably is true
12:38:50 sean-k-mooney ok i can see the logic in that argument.
12:57:47 sean-k-mooney jaypipes: https://review.openstack.org/#/c/602384/ responces in line. ill respin once you decide if you would like to see addtional changes but i think the typo was the only thing you wanted adressed in the patch correct
13:01:05 jaypipes sean-k-mooney: yup. was just curious about the other questions...
13:14:07 sean-k-mooney cool in that case ill fix the typo. can you cast your eye over the follow up patch when you have a chance
13:49:46 mriedem dansmith: lyarwood: https://review.openstack.org/#/q/topic:bug/1799892+(status:open+OR+status:merged) on stable should be good to go now
13:50:33 mriedem other cores, the hpet change just needs a final +2 https://review.openstack.org/#/c/605902/
13:53:33 openstackgerrit Hervé Beraud proposed openstack/nova stable/rocky: Stop to mocking oslo.service.loopingcall._ThreadingEvent since this class was removed https://review.openstack.org/619246
13:58:03 frickler mriedem: do you want to continue waiting on https://review.openstack.org/616580 ? it would be great if we could get that fix into the next round of stable releases, not sure whether there is something scheduled for that yet
14:00:16 mriedem frickler: i was waiting for more core reviews, but they didn't come, so approved
14:00:21 mriedem you'll need to backport to stable/rocky
14:00:39 mriedem we likely won't be doing a series of stable releases until after the US thanksgiving holiday (which is tomorrow)
14:02:53 openstackgerrit Jens Harbott (frickler) proposed openstack/nova stable/rocky: Make supports_direct_io work on 4096b sector size https://review.openstack.org/619251
14:04:16 frickler mriedem: stable/rocky is a simple cherry-pick from master, which I did now. stable/queens required editing because the function moved its location, which is why I prepared that patch earlier
14:08:12 frickler mriedem: do you think that it should also go into pike and ocata? seems those would require more editing, but the bug is present in those branches, too.
14:08:29 openstackgerrit Hervé Beraud proposed openstack/nova stable/rocky: Stop to mocking oslo.service.loopingcall._ThreadingEvent since this class was removed https://review.openstack.org/619246
14:09:32 mriedem frickler: can you re-cherry-pick to rocky using the command line?
14:09:35 mriedem with the -x option
14:09:46 mriedem the gerrit UI won't do that until the change you're cherry picking *from* has merged
14:10:28 mriedem frickler: ocata is in extended maintenance mode and i'm not really sure this needs to go that far back upstream
14:10:47 mriedem EM means it *could* go that far back, but i'm not sure it's high enough priority
14:10:57 mriedem s/priority/severity/
14:12:28 frickler mriedem: oh, I was hoping gerrit would be the better option than command-line. but does it do anything other than add the "cherry picked from" line to the commit message? in that case I'd just add that line manually
14:13:30 frickler mriedem: o.k., so I'll do pike but not ocata. pike is the release most of our deployments are currently running on.
14:14:37 openstackgerrit Jens Harbott (frickler) proposed openstack/nova stable/rocky: Make supports_direct_io work on 4096b sector size https://review.openstack.org/619251
14:17:48 mriedem stable cores: we have quite a few rocky backports that need a final +2 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/rocky+label:Code-Review=2
14:18:37 openstackgerrit Jens Harbott (frickler) proposed openstack/nova stable/pike: Make supports_direct_io work on 4096b sector size https://review.openstack.org/619254
14:31:21 gary_perkins Hi! I'm not sure if this would be the best channel to ask, but I ask anyway :) I have a kolla-ansible deployment of Queens. I have set a nova policy rule "os_compute_api:servers:create:zero_disk_flavor": "rule:admin_api" to stop any image-backed instances with a zero root-disk from being created. I want to only allow cinder-volume backed instances. But, for some reason, this policy change has had no noticable effect. I'm expecting my "
14:31:22 gary_perkins openstack server create" to return an error, but instead it creates an instance consuming local storage. Is there something I'm missing?
14:31:49 gary_perkins TIA
15:12:17 sean-k-mooney so rather then ask this in the olso changel again.. the stien schdule does not list the nova specs freeze. is it m2
15:15:34 cdent sean-k-mooney: last I heard, yes, but I don't have a good memory for arbitrary deadlines
15:17:01 sean-k-mooney cdent: ya that i why i check the scduel. m2 is still the first week of january so that means really the dealin is decemebr ish before people evaporate
15:17:47 Sundar Can somebody tell me how to derive a SQLalchemy model (table) from an OVO, or vice versa?
15:18:18 dansmith Sundar: they're not related
15:18:19 jangutter rule of thumb, the spec freeze is about two weeks before the first possible free time of the reviewers who can approve them.
15:18:54 dansmith Sundar: some of our SQLA models match our OVO objects pretty close, but many do not.. but either way, they're not 1:1
15:19:20 Sundar dansmith: So, we may have to represent the same object in 2 different ways and translate back and forth?
15:20:24 dansmith Sundar: I'm not sure I understand what you mean, but.. yes? In nova at least, the model is how we store it, and the OVO object is how we speak it over RPC.. sometimes they're very similar, but not always
15:20:40 Sundar OK. Thank you.
15:28:24 mriedem sean-k-mooney: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule
15:28:36 mriedem gary_perkins: you're sure disk=0 on the flavor?
15:28:52 sean-k-mooney mriedem: ah thank you
15:29:36 sean-k-mooney ah and the os-vif frees is listed too perfect
15:31:13 mriedem gary_perkins: and that a bdm isn't being passed on the server create request?
15:31:57 gary_perkins mriedem: yes, disk=0 on the flavor
15:32:54 gary_perkins mriedem: bdm?
15:33:20 mriedem block_device_mapping_v2
15:33:26 gary_perkins my command line to spin up an instance is: os server create --image bionic-server-cloudimg-arm64 --flavor c2.large --key-name gary-key --nic net-id=2e8281a6-30f4-4cdc-b433-c87137413af7 test-1
15:33:29 mriedem the dict-o-doom for boot from volume
15:33:50 mriedem ok and that image doesn't have a block_device_mapping_v2 property in it?
15:34:04 mriedem which is the trojan horse way of boot from volume
15:34:15 gary_perkins hmmm.. good point, will check
15:34:55 mriedem fwiw, this is a functional test for exactly what you're trying to see https://github.com/openstack/nova/blob/d74f9d62c5c320539ff5a46f28b0104c3b236633/nova/tests/functional/wsgi/test_servers.py#L385
15:36:53 mriedem mnaser was trying to switch the default on that rule in stein but it turns out the flavors used in devstack, which tempest uses in our CI, have disk=0 so they explode :) https://review.openstack.org/#/c/603910/
15:36:53 gary_perkins mriedem: thanks! and no block_device_mapping_v2 property
15:37:08 gary_perkins ha!
15:37:22 mnaser mriedem: ah sorry i never actually got around cleaning that one up
15:37:34 mriedem mnaser: it's going to be non-trivial
15:37:44 mriedem gary_perkins: which policy file did you modify?
15:38:01 mriedem /etc/nova/policy.json?
15:38:17 jangutter something that still shows how much of a noob I am: regarding blueprint and specs. Is there a specific order in which things get approved normally? spec -> blueprint? Or is it not ordered?
15:38:21 mriedem make sure whatever policy file you modified is the one this option points at https://docs.openstack.org/nova/queens/configuration/config.html#oslo_policy.policy_file
15:38:26 mnaser mriedem: because now in tempest we need to use a flavor that is non root_gb=0 first before that can ever work, right?
15:38:34 mriedem jangutter: spec and then blueprint
15:38:52 mriedem mnaser: yeah, and tempest is configured with flavors that devstack sets up in our CI
15:39:17 mriedem https://github.com/openstack-dev/devstack/blob/master/lib/tempest#L191
15:39:58 jangutter mriedem: thanks!
15:40:02 mriedem tempest is also configured with the cirros images https://github.com/openstack-dev/devstack/blob/master/lib/tempest#L326
15:40:15 mriedem so maybe we just need to get the image size from glance and use that for the flavor disk size
15:40:51 mnaser mriedem: will we still be able to get coverage for bfv with root_gb=0 then?
15:41:15 mnaser or that might involve probably adding tempest tests
15:41:17 mriedem not unless you add a specific test to tempest for that
15:41:24 mriedem we have functional tests in nova for it
15:41:31 mriedem but those don't use a real virt driver
15:42:12 mriedem yay min_disk=0 on the image http://logs.openstack.org/34/615134/2/check/tempest-full/f6d351a/controller/logs/devstacklog.txt.gz#_2018-11-02_13_20_26_698
15:42:16 mriedem that's helpful
15:43:04 gary_perkins mriedem: yes, /etc/nova/policy.json originally copied from https://docs.openstack.org/nova/queens/_downloads/nova.policy.yaml.sample
15:43:45 mriedem gary_perkins: but what is [oslo_policy]/policy_file in nova.conf in the nova-api service pointing at?
15:43:57 mriedem b/c you said policy.json but you linked to a policy.yaml sample
15:45:09 gary_perkins mriedem: oh, sorry. Just trying to find my original sample. That's obviously the wrong one
15:46:42 gary_perkins mriedem: nova.conf: policy_file = policy.json
15:47:42 mriedem hmm, and you shouldn't have to restart nova-api after modifying the policy file, it should be read fresh each time
15:49:23 gary_perkins and ofc, policy.json has: "os_compute_api:servers:create:zero_disk_flavor": "rule:admin_api"
15:49:39 gary_perkins amongst may other policies!
16:17:13 mriedem gary_perkins: i'm not sure. have you tried tweaking any other policy rules to make sure it's not something with the configuration of the policy file?
16:45:47 xek gibi, there are no versioned network.floating_ip.associate network.floating_ip.disassociate notifications?
16:46:00 artom mriedem, hey, so, I'm being told from people who were at summit that you were in the room at the NFV pain points session (https://etherpad.openstack.org/p/BER-nfv-hpc-pain-points). Now, to me, that sounds like nothing could make you happier than reviewing https://review.openstack.org/#/c/599587/, right ;)
16:46:21 gibi xek: is there an unversioned one from nova about those?
16:47:43 gibi xek: OK I see there is unversioned ones for those
16:47:53 xek gibi, I see they are emitted in nova.network.floating_ips, but I'm not sure if there is an alternative somewhere else? maybe in neutron?
16:48:22 mriedem artom: lots of things could make me happier
16:48:39 artom mriedem, what if I promised ice cream?
16:48:52 mriedem xek: gibi: i don't think we'd port that to versioned notifications since they are nova-network specific and that's deprecated
16:49:05 mriedem artom: i have ice cream like 30 feet away
16:49:11 artom Foiled again!
16:49:39 artom mriedem, in seriousness, I know y'all are overloaded, I'm just trying to get it over the line, so if you have energy/bandwidth, it'd be appreciated
16:50:59 gibi xek, mriedem: yeah, I just found that it is only emitted from the nova network code patch, this is why they are not on the todo list for versioned transformation

Earlier   Later