Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-28
04:08:30 mriedem you're also watching over telnet?
04:08:47 dansmith off and on to make sure it's not stuck
04:08:55 openstackgerrit Merged openstack/nova master: placement: account for move operations in claim https://review.openstack.org/487589
04:09:49 dansmith hmm, I pulled and got the commit but no merge commit yet
04:10:02 dansmith for the first one
04:11:19 mriedem much like the line for the carousel tonight, you must have patience
04:11:27 dansmith heh
04:11:30 mriedem and a high tolerance for carney folk
04:12:33 openstackgerrit Merged openstack/nova master: claim resources in placement API during schedule() https://review.openstack.org/483566
04:13:08 mriedem duh duh duh
04:13:15 dansmith got that one but still no merge commits
04:13:45 mriedem don't we just need 23c4eb34380bdf3eece11abbe0f6ccb68c060f47 ?
04:14:02 dansmith you list the merge commit in the release thing right?
04:14:06 dansmith not the actual commit
04:14:13 mriedem no,
04:14:15 mriedem tip of master
04:14:17 dansmith your WIP patch is a merge commit
04:14:26 mriedem that was just tip of master at the time
04:14:27 dansmith erm, okay
04:14:49 dansmith so maybe zuul does a ff merge if it's clean or something? I thought it always did merge commits
04:15:24 mriedem you want to update the release patch since you've watched this all night?
04:15:30 dansmith just did
04:15:50 mriedem well touche
04:16:03 dansmith both of the other milestones were merge commits
04:16:23 mriedem not intentionally
04:17:09 dansmith hrm, I don't understand, but whatever :)
04:17:22 dansmith glad you were here to tell me that
04:17:28 dansmith so I didn't wait all night
04:17:37 mriedem ha
04:17:54 mriedem would have to ask dhellmann tomorrow if there is magic behind the scenes
04:18:11 mriedem now that that's done, i suppose no one is around to actually merge and tag the damn thing
04:18:30 dansmith several I checked from ocata just now were merge commits too
04:18:43 dansmith mriedem: dims said he'd get it in the morning if ttx didn't first
04:18:56 mriedem yeah doug said they'd do it by the 10am CT release meeting
04:19:04 dansmith aye
04:20:15 mriedem alright, well f yeah, i'm going to watch some much deserved garbage tv and then go to bed
04:20:31 dansmith enjoy
04:20:42 mriedem thanks for shepharding
04:20:46 mriedem *shepherding?
04:20:48 dansmith np, g'nite
04:25:45 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/488283
06:00:24 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove unnecesary code https://review.openstack.org/488299
06:01:27 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove unnecessary code https://review.openstack.org/488299
07:33:47 openstackgerrit Takashi NATSUME proposed openstack/nova master: Amend uuid4 hacking rule https://review.openstack.org/488315
08:07:28 openstackgerrit longxingmiao proposed openstack/nova master: test review https://review.openstack.org/488328
08:24:09 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test resize with placement api https://review.openstack.org/487958
08:31:56 openstackgerrit jichenjc proposed openstack/nova master: refactory some code on get_password https://review.openstack.org/449458
08:35:25 openstackgerrit jichenjc proposed openstack/nova master: add cert when send keystone request https://review.openstack.org/485121
08:37:43 openstackgerrit jichenjc proposed openstack/nova master: Add quiesce and unquiesce in support matrix https://review.openstack.org/482390
09:04:07 bhagyashris gibi: Hi, I have resolved my yesterday's issue there was some problem to restart the nfs server and for locking thing through nfs required statd service to enable.
09:09:44 gibi bhagyashris: good to hear that
09:11:02 bhagyashris gibi: Now everything is working fine to test the shared resource provider thing. I have just tested one scenario simply created instance as as mentioned in http://paste.openstack.org/show/616724/ but in my observation the root gb of created flavor has been considered in the allocations table against the compute resource provider and CUSTOM_DISK resource against "shared_resource" resource provider.
09:12:46 bhagyashris gibi: IMO, As i am creating the nfc backed instance so it should take the RAM and VCPU from the computes resource provider and DISK from the "shared_resource" provider
09:13:06 bhagyashris s/nfc/nfs
09:22:41 gibi bhagyashris: I don't know how can you tell nova that you want to consume DISK_GB not from the compute provider but from the shared one
09:23:07 gibi bhagyashris: this is why I suggested to use CUSTOM_DISK in the shared and then add CUSTOM_DISK to the flavor
09:23:20 gibi bhagyashris: that way I sure that the instance will consume from your shared provider
09:23:42 gibi bhagyashris: I hope others can help with this specific issue
09:29:56 bhagyashris gibi: ohk. thank you.
09:39:11 SteveRUKC hey all, quick question to which im struggling to find an answer. Is disk_allocation_ratio taken into account on live/cold migrations. As we have an allocation ratio of 6 set, but are having issues with migrations failing with a disk instance too large for target message.
09:39:34 SteveRUKC also, hypervisor_stats is showing a negative number for least_free
09:39:44 SteveRUKC if anyone has any ideas it would be most appreciated
09:48:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: DNM: trying to turn on periodic tasks https://review.openstack.org/488352
09:53:39 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
10:09:26 dims dansmith : looks like ttx took care of it 3 hours ago. w00t
10:14:46 cdent gibi: I did some similar periodic job fiddling last night and ran into the same confusion with the computes getting weird
10:15:15 cdent I’m guessing the fixture (or the the service) is not happy being in the same process with another version of itself?
10:29:49 bhagyashris cdent: Hi, Hi, I have resolved my yesterday's issue there was some problem to restart the nfs server and for locking thing through nfs required statd service to enable.
10:29:51 openstackgerrit Chris Dent proposed openstack/nova master: [placement] quash unicode warning with shared provider https://review.openstack.org/488363
10:30:12 cdent bhagyashris: ah, cool, glad you were able to make it work
10:30:51 bhagyashris cdent: Now everything is working fine to test the shared resource provider thing. I have just tested one scenario simply created instance as as mentioned in http://paste.openstack.org/show/616724/ but in my observation the root gb of created flavor has been considered in the allocations table against the compute resource provider and CUSTOM_DISK resource against "shared_resource" resource provider.
10:31:09 bhagyashris cdent: IMO, As i am creating the nfs backed instance so it should take the RAM and VCPU from the computes resource provider and DISK from the "shared_resource" provider.
10:31:12 kashyap mdbooth: Thanks for the review!
10:31:56 kashyap And also to dansmith (About: https://review.openstack.org/#/c/485752/, but not for the "summary" remark :P)
10:32:16 cdent bhagyashris: you can address that (at least in part) by using DISK_GB instead of CUSTOM_DISK for the nfs shared resource provider
10:32:17 kashyap johnthetubaguy: Maybe when you have a minute to ACK this straightforward change: https://review.openstack.org/#/c/485752/
10:33:07 cdent the thing that will be missing is that there’s nothing currently in place to manage the allocation of disk on the shared resource provider, but that’s in progress with the claim in the scheduler stuff that is being worked on this week
10:36:25 bhagyashris cdent: ohk Means instead of creating the "CUSTOM_DISK" resource class and then creating the inventory for that I need to update the inventory against "DISK_GB" resource class right.
10:37:41 cdent bhagyashris: well basically the general rule is that if you can use a standard resource class (because it maps to the unit of resource a provider is providing) you may as well
10:39:43 bhagyashris cdent: ohk. checking...
10:48:08 s-dean Hello, could someone point me in the right direction to debug this nova.exception.NeutronAdminCredentialConfigurationInvalid' ?
10:50:10 s-dean nevermind
10:53:47 bhagyashris cdent: I have updated the inventory using DISK_GB resource class against the nfs shared resource provider but in that case after booting the instance it's not using shared_storage provider.
10:54:36 bhagyashris cdent: It address the disk used against compute node resource provider.
10:58:23 vdrok good morning everyone!
10:58:38 vdrok sdague: small request, if you have some time :) https://review.openstack.org/480624
11:00:47 vdrok thanks!
11:01:01 cdent bhagyashris: ah, right, because the compue is reporting it’s own disk too, so is considered a valid target for all the resources. /me thinks
11:01:30 cdent bhagyashris: are you working from today’s master or something earlier?
11:02:29 bhagyashris cdent: yeah. I am working from todays master commit-id: 23c4eb34380bdf3eece11abbe0f6ccb68c060f47 "claim resources in placement API during schedule()"
11:07:10 cdent bhagyashris: do you have the log of it making the PUT /allocations requests? It might be that the scheduler is claimng one set of allocations, but later (in the periodic update) the resource tracker is changing things. if you’re going to be using the CUSTOM_DISK resource class you need to make sure your flavor doesn’t indicate any requests for disk_gb
11:07:53 cdent I think over the next few days things are likely to be quite unstable with claims, and there will be a few more changes coming
11:09:48 bhagyashris cdent: ohk.
11:10:28 cdent bhagyashris: it’s great that you’re doing this investigating, but right now is going to be a chaotic time
11:13:15 cdent bauzas: if this still alive? https://review.openstack.org/#/c/427200/
11:13:24 bauzas cdent: looking
11:13:47 bauzas cdent: well, maybe we should discuss with matt
11:13:58 bauzas I can rebase it
11:14:05 bauzas meanwhile
11:14:26 cdent k, thanks

Earlier   Later