Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-28
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
12:21:30 johnthetubaguy andymccr: BTW do you like the idea in this spec: https://review.openstack.org/438936 Basically give you less services you need to install and run
12:23:53 andymccr johnthetubaguy: reading - from our perspective fewer containers == better, if they aren't required it definitely makes sense to me
12:24:37 johnthetubaguy andymccr: cool, yeah, placement has changed the need for the separate process
12:51:15 breton hi
12:52:07 breton is it a known problem that having role admin in any project i can edit flavors for all users?
12:56:57 frickler breton: admin anywhere is admin everywhere, yes
12:57:43 breton ok, 968696 then
12:58:17 frickler yes, was about to paste that bug link ;)
12:59:22 alex_xu johnthetubaguy: sdague, just checked, there isn't any API work in the priority tasks, but i guess there still have some work can be tracked by the API team? so probably we can talk about that in the tomorrow api meeting
13:07:23 _samdeep Hi All
13:07:57 _samdeep I want to fetch instance properties inside a filter
13:09:01 _samdeep but I am unable to get it using
13:09:13 _samdeep objects.Instance.get_by_uuid(spec_obj.obj_context, spec_obj.instance_uuid)
13:09:30 _samdeep any idea how to get these details?
13:11:22 johnthetubaguy alex_xu: wasn't the policy docs included?
13:11:39 johnthetubaguy alex_xu: but yeah, we can keep meeting to keep the other stuff moving anywys
13:16:28 alex_xu johnthetubaguy: yeah, anyway if you and sdague have any plan or something you want me help on, let us talk that in the meeting
13:16:54 johnthetubaguy alex_xu: there was the API concepts guide that needed finishing, and a few other loose ends
13:17:07 johnthetubaguy alex_xu: we should go through that as a team at the next meeting I guess
13:17:21 alex_xu johnthetubaguy: yea
13:17:54 sdague alex_xu: yeh, I think the thing is that when we got there most of the mindset had been around policy and the limits setting api going into keystone
13:18:19 sdague I honestly think that limits in keystone would be something that we should keep api team focus on this cycle
13:18:54 alex_xu sdague: what is limits in keystone, i probably didn't follow that in the ptg
13:19:21 openstackgerrit John Garbutt proposed openstack/nova master: Add device_id when creating ports https://review.openstack.org/431545
13:19:24 sdague the new idea on how hierarchical quotas is going to work is that we're going to store limits in keystone
13:19:32 openstackgerrit John Garbutt proposed openstack/nova master: Stop leaking ports on port_create timeout https://review.openstack.org/347183
13:19:37 sdague so the entire hierarchy is efficiently mapped there
13:19:54 sdague brb
13:20:06 alex_xu ah, i probably have some memory about that
13:20:53 alex_xu I remember we said keystone need to tell nova about the hierarchy
13:21:36 alex_xu anyway i will grab the etherpad to get more context before meeting
13:26:21 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add prep-for-network-aware-scheduling-pike spec https://review.openstack.org/432489
13:32:11 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop using mox in compute/test_hypervisors.py https://review.openstack.org/326814
13:39:59 zioproto johnthetubaguy, I am about to build ubuntu packages on top of commit 2e05c82b807624b8420df4c94d68b75563b230d2 . Is that a good candidate for new stable/mitaka tag ?
13:40:36 johnthetubaguy zioproto: unsure, I would ask lyarwood about that
13:43:02 zioproto lyarwood, ping me when you are here :)
13:43:39 lyarwood zioproto: https://review.openstack.org/#/c/438570/ but I'd wait until the tag lands
13:44:32 sfinucan macsz: I wonder if it's time to look at switching back to nose, now that it supports parallel testing? :P https://review.openstack.org/#/c/435111
13:44:46 zioproto great that is the correct commit
13:45:20 lyarwood zioproto: right but I'd wait until the tag lands in the repo to build, we've already respun that to include an additional commit in the last 24 hours
13:45:29 lyarwood zioproto: it shouldn't be long until that lands tbh
13:48:12 zioproto thanks

Earlier   Later