| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 10:38:12 | bauzas | johnthetubaguy: I mean, None means "leave the Instance object having the AZ field unset" | |
| 10:38:19 | bauzas | exactly | |
| 10:38:51 | bauzas | if the Instance object doesn't have an AZ information, it will never stick to the AZ the host where it was placed belongs to | |
| 10:38:54 | jsheeren | johnthetubaguy: https://github.com/openstack/nova/blob/stable/mitaka/nova/compute/api.py#L2112 | |
| 10:39:03 | jsheeren | metadata is listed in the filter_mapping | |
| 10:39:54 | bauzas | there are 2 colocality informations : one for the instance and one for the host | |
| 10:40:04 | bauzas | an host can belong to an AZ | |
| 10:40:15 | bauzas | and one instance can belong to an host | |
| 10:40:31 | laci | hi! | |
| 10:40:36 | bauzas | so, this is transitive | |
| 10:41:00 | bauzas | one instance can be in one AZ by the transitivity of the relationship AZ -> host -> instance | |
| 10:41:29 | bauzas | that's the default | |
| 10:42:00 | bauzas | but you can give a specific colocality information on one instance if you specify which AZ it should belong to | |
| 10:42:28 | bauzas | in that case, we would force to honor the transitivity by making sure we pick hosts only belonging to the same AZ | |
| 10:43:04 | johnthetubaguy | bauzas: was looking in the code, I was expecting AZ to get set to the host value when we set the host on the instance, somewhere near here: https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L579 | |
| 10:43:12 | johnthetubaguy | bauzas: I can't find the right place though right now | |
| 10:43:25 | bauzas | johnthetubaguy: I would violently -1 it if I was seeing that code | |
| 10:43:41 | johnthetubaguy | bauzas: I guess I don't get why | |
| 10:43:49 | bauzas | johnthetubaguy: because the AZ information attached to the instance is what the user expressed | |
| 10:43:57 | johnthetubaguy | thats in the build request | |
| 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) :) | |