| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 10:44:09 | bauzas | not the result of the placement decision we made | |
| 10:44:17 | bauzas | well | |
| 10:44:25 | johnthetubaguy | yeah, that sounds wrong to me | |
| 10:44:30 | bauzas | first, build request is only temporary | |
| 10:44:37 | johnthetubaguy | yeah, I was meaning the other one | |
| 10:44:42 | bauzas | secondly, I agree, it's rather RequestSpec | |
| 10:44:48 | johnthetubaguy | yeah, request spec, my bad | |
| 10:44:55 | bauzas | but I wrote that object later | |
| 10:44:57 | bauzas | so | |
| 10:45:09 | bauzas | a move could be to totally remove the instance AZfield | |
| 10:45:12 | bauzas | AZ field | |
| 10:45:32 | bauzas | I mean, deprecate it at the object level, and wait for a major version bump to remove it | |
| 10:45:46 | johnthetubaguy | instance.host tells you the current host, instance.az feels like it should be similar | |
| 10:45:49 | johnthetubaguy | but thats just me | |
| 10:46:00 | johnthetubaguy | anyways, I think I get enough for the docs patch now | |
| 10:46:01 | jsheeren | johnthetubaguy: tags look like an option, but we're still on mitaka .. :( | |
| 10:46:09 | bauzas | johnthetubaguy: no, that's then duplicate information | |
| 10:46:39 | bauzas | johnthetubaguy: I by far prefer to only keep instance.host and leave the transitivity to determine an instance AZ | |
| 10:46:51 | johnthetubaguy | bauzas: it is duplicating host, but its kinda useful, its the AZ cached at the time the instance landed on the host | |
| 10:46:57 | johnthetubaguy | just like flavor | |
| 10:47:12 | bauzas | there are a full list of bugs related to the fact we badly manage that relationship | |
| 10:47:18 | johnthetubaguy | but anyways, I clearly see this differently, needs a spec to sort that out | |
| 10:47:43 | bauzas | well, you're kinda busy this cycle, so I could give an hand | |
| 10:47:47 | johnthetubaguy | we should record, where we first landed, and what the user requested, I believe | |
| 10:48:06 | johnthetubaguy | bauzas: I have no time to sort that out this cycle, if you have cycles feel free | |
| 10:48:12 | bauzas | but honestly, touching AZs is like trying to unfuse a bomb | |
| 10:48:40 | bauzas | certainly not a thing for people willing to contribute at first hand, unfortunately :( | |
| 10:48:43 | johnthetubaguy | bauzas: maybe a backlog spec to capture the thoughts? | |
| 10:48:49 | bauzas | sorting all that out took me like 5 cycles | |
| 10:49:02 | bauzas | I could do that | |
| 10:49:15 | bauzas | I'm pretty free this cycle since I really wanted to make reviews | |
| 10:49:29 | johnthetubaguy | bauzas: include the use cases frickler talks about, its easier than the harder server groups one, and its what folks want | |
| 10:49:51 | bauzas | the fact that one would want to RR between AZs ? | |
| 10:49:55 | johnthetubaguy | yeah, just want to capture these requests, I know my product org asked me some questions on that | |
| 10:49:59 | johnthetubaguy | RR? | |
| 10:50:04 | johnthetubaguy | round robin | |
| 10:50:05 | bauzas | round-robin, my bad | |
| 10:50:15 | johnthetubaguy | yeah, not sure its round robin you want | |
| 10:50:22 | johnthetubaguy | you want to balance load between them all | |
| 10:50:42 | bauzas | well, it's a placement question for sure | |
| 10:50:54 | bauzas | because RR is one way to spread your load | |
| 10:50:58 | johnthetubaguy | like if AZ_3 fills up, send more builds to the other two, if folks don't have a preference | |
| 10:51:04 | bauzas | yeah | |
| 10:51:08 | johnthetubaguy | thats what people *really* want | |
| 10:51:29 | johnthetubaguy | frickler | |
| 10:51:31 | johnthetubaguy | oops | |
| 10:51:39 | johnthetubaguy | frickler please do correct me if I am wrong ^ | |
| 10:52:00 | bauzas | to me, the default_schedule_zone flag would rather be "stick_with_the_AZ_I'm_scheduled_for_all_my_lifecycle" and a boolean as value | |
| 10:52:13 | frickler | well that is one use case. but thinking about it, the other one would be: create three instances in three different AZs | |
| 10:52:22 | bauzas | that's a scheduling thing | |
| 10:52:23 | johnthetubaguy | yeah, thats the server groups one | |
| 10:52:38 | bauzas | you could have different placement strategies | |
| 10:52:46 | bauzas | using weighters or other things | |
| 10:53:01 | johnthetubaguy | if you just create one instance, and you don't care were it goes, try get an even load between all AZs so the folks targeting to a specific AZ are able to get there | |
| 10:53:09 | johnthetubaguy | bauzas: there is a clear 80% default here I think | |
| 10:53:11 | bauzas | so, my thoughts are | |
| 10:53:25 | johnthetubaguy | bauzas: lets get them in the spec, I need to get on with other things | |
| 10:53:28 | bauzas | first boot schedule is a placement decision | |
| 10:53:46 | bauzas | but a move operation is depending on that first placement decision or not | |
| 10:53:56 | bauzas | yeah, lemme try to capture all the best I can | |
| 10:54:17 | johnthetubaguy | ping me for a review, I am interested it getting that all down on paper | |
| 10:56:04 | sfinucan | johnthetubaguy: I think I have all comments on https://review.openstack.org/#/c/364468/ addressed now | |
| 10:56:12 | bauzas | johnthetubaguy: sure thing | |
| 10:57:12 | jsheeren | johnthetubaguy: small update on filtering on metadata. if you are an admin user, you can use the filter detail?metadata=<urlencoded-metadata-json> but not as a regular user | |
| 10:57:20 | jsheeren | so, this is a policy issue then? | |
| 10:58:36 | johnthetubaguy | jsheeren: possibly, its a really nasty DB query, so you probably don't want to allow that | |
| 11:00:04 | jsheeren | johnthetubaguy: in the policy.json everything with metadata in the string has admin_or_owner so i'm confused | |
| 11:00:36 | jsheeren | going to look at the code again .. :-) | |
| 11:01:40 | openstack | Launchpad bug 1667667 in OpenStack Compute (nova) "Rebuilding instance ignores image's property hw_disk_bus" [Low,Confirmed] | |
| 11:01:40 | akijak | hi, I've found a bug in nova concerning rebuilding and 'hw_disk_bus' image property (https://bugs.launchpad.net/nova/+bug/1667667), I'm looking for someone who could give me some directions how to fix that :) can you help? | |
| 11:03:51 | jsheeren | https://github.com/openstack/nova/blob/stable/mitaka/nova/compute/api.py#L3304 check_policy(context, 'get_all_instance_%s' % metadata_type,instance) .. but in the policy: "compute:get_all_instance_metadata": "rule:admin_or_owner" | |
| 11:36:01 | johnthetubaguy | bauzas: can you take over that patch and fix up the comments how you think makes sense: https://review.openstack.org/#/c/438887 | |
| 11:36:25 | openstackgerrit | jichenjc proposed openstack/nova master: api-ref: Body verification for os-hypervisors.inc https://review.openstack.org/383691 | |
| 11:52:58 | andymccr | are the [placement_database] specifics configured in nova.conf working? I'm noticing that although everything is working and no errors/issues are caused the database specified is empty - wondering if thats a configuration issue my side | |
| 11:54:23 | johnthetubaguy | andymccr: hmm, thats a bit surprizing for sure | |
| 11:54:55 | openstackgerrit | jichenjc proposed openstack/nova master: Prevent delete cell0 in nova-manage command https://review.openstack.org/433476 | |
| 11:55:48 | andymccr | johnthetubaguy: there is a probably high chance its a config issue my side :) but then i almost expect errors somewhere - so thought it'd be worth checking before i release | |
| 11:57:54 | frickler | andymccr: https://review.openstack.org/362766 does still seem pending. did you check the api-db? | |
| 12:01:49 | andymccr | frickler: ahh ok thanks! so the separation of the database hasn't merged yet - i figured it must be using the nova_api one since it was working and not creating errors. | |
| 12:02:06 | andymccr | but good to know i havent misconfigured it (yet) :) | |
| 12:04:17 | sean-k-mooney | sfinucan: free to pop into the neutron channel for a sec | |
| 12:05:55 | sean-k-mooney | sfinucan: kevinbenton: has a patch for port filtering for os-vif that relates to the security behavior we were disscussing last week | |
| 12:05:57 | sean-k-mooney | https://review.openstack.org/#/c/438272/2 | |
| 12:07:20 | frickler | andymccr: still the current situation seems pretty broken, https://review.openstack.org/#/c/349021/13/releasenotes/notes/placement-database-5aa94ece29eab820.yaml is in place and if people follow that advice, their setup is broken. guess you could open a bug for that | |
| 12:08:02 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add use-local-scheduler spec https://review.openstack.org/438936 | |
| 12:09:03 | openstackgerrit | Kevin Benton proposed openstack/os-vif master: Don't install iptables rules if neutron is filtering https://review.openstack.org/438272 | |
| 12:14:48 | andymccr | frickler: hmm that placement sync bit has been removed | |
| 12:16:01 | johnthetubaguy | andymccr: frickler was right, we send stuff to the API db | |
| 12:16:03 | johnthetubaguy | andymccr: if you configure the compute nodes to have the api-db point to the placement API, you might get what you want | |
| 12:16:04 | johnthetubaguy | its not officially supported right now, but thats probably what you want | |
| 12:16:06 | johnthetubaguy | oops | |
| 12:16:15 | johnthetubaguy | I mean placement-api conf has api-db point to placement-db | |
| 12:16:21 | johnthetubaguy | andymccr: ^ | |
| 12:16:38 | johnthetubaguy | thats assuming all the tables are created in there now | |
| 12:16:53 | johnthetubaguy | but doing api-db sync on a node that has api pointing to placement | |
| 12:17:02 | johnthetubaguy | api-db pointing, that is | |
| 12:20:23 | andymccr | johnthetubaguy: not really looking to work around it until its ready i guess :) hoping there is a decent migration path though so its unobtrusive - just wanted to make sure i wasnt doing something bogus since the configuration is still in the sample conf with an explanation and recommendation that it is used. | |
| 12:20:39 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add use-local-scheduler spec https://review.openstack.org/438936 | |
| 12:20:48 | johnthetubaguy | andymccr: its worth avoiding the migration path | |
| 12:21:05 | johnthetubaguy | andymccr: but we sure will have to write one | |