Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-13
14:54:48 mriedem bhagyashris: this is all in the release notes and docs
14:55:13 mriedem bhagyashris: http://docs.openstack.org/developer/nova/placement.html#upgrade-notes
14:55:25 mriedem bhagyashris: http://docs.openstack.org/releasenotes/nova/unreleased.html
14:55:32 mriedem let me know if you have further questions
14:59:50 bhagyashris mriedem: I have seen this patch: https://review.openstack.org/#/c/428505/6/ this patch updates the compute node table with correct disk info in case of volume backed instance.
15:00:30 mriedem bhagyashris: yeah, which is based on https://review.openstack.org/#/c/428481/ which was a split from an earlier change that melwitt had
15:00:57 bhagyashris mriedem: yes, so my question is as we are using placement service for scheduling then why there is a need to update this info
15:01:28 bhagyashris mriedem: placement service will give appropriate disk info is that right?
15:02:46 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
15:03:24 mriedem bhagyashris: that's a good question, which i'm going to have to ask melwitt, dansmith or jaypipes to help with, since i haven't dug into those patches yet
15:04:32 dansmith bhagyashris: because claims are still in the old format for the time being, which means even if we pick a good compute node with placement, the compute node's own accounting (claims) may still reject it
15:05:00 mriedem ah i forgot about claims
15:05:25 mriedem i knew the report client wasn't reporting disk allocations for BFV instances into placement, but forgot about the old claims code in the RT
15:08:54 mriedem which reminds me, are we going to try and get that into rc2? or can we backport it?
15:09:22 bhagyashris mriedem: IMO, the BFV instance reports the disk usages correctly in the allocations table on current master
15:11:50 mriedem bhagyashris: yes but the scheduler isn't doing claims yet
15:12:12 mriedem the RT is doing the claim on the compute and not taking BFV into account, which is what melwitt's patch is for
15:12:17 mriedem if i'm understanding this all correctly
15:12:56 mriedem so the scheduler can use placement to pick a host that would work, but if the actual claim when building the instance on that host fails because it's not accounting for BFV, then the allocations table doesn't really matter
15:18:11 bhagyashris mriedem: is there a future plan of adding the claims in palcement service?
15:18:21 mriedem bhagyashris: yes
15:18:24 mriedem well,
15:18:26 mriedem in the nova-scheduler
15:18:29 mriedem not the placement service
15:18:49 snikitin mriedem: Done https://review.openstack.org/#/c/427637/
15:19:37 mriedem snikitin: +W
15:19:38 mriedem thanks
15:19:47 bhagyashris mriedem: does not mean the compute node table is not gonna being used for the instance creation ?
15:19:51 snikitin thank you
15:20:12 bhagyashris * does that mean the compute node table is not gonna being used for the instance creation ?
15:21:10 mriedem bhagyashris: i'm unclear on the long-term plans for claims in the scheduler, there is a scheduler subteam that just wrapped up a meeting so hopefully someone from that team can answer, like edleafe or bauzas
15:21:22 mriedem i don't think we have a spec on that yet
15:21:55 edleafe bhagyashris: that is the goal, but we aren't there yet
15:22:19 edleafe bhagyashris: the goal is for a compute node to be just one kind of resource provider
15:23:26 snikitin mriedem: We have branch stable/ocata. As I understand it means that master is for Pike now. If so, could you remove -2 from diagnostics patch please? https://review.openstack.org/#/c/394480/
15:23:37 mriedem snikitin: yup was getting there
15:24:07 snikitin thanks!
15:24:16 bhagyashris edleafe: ok.
15:25:36 bhagyashris mriedem: dansmith: edleafe: Thank you very much for information and valuable time.
15:37:32 mriedem1 snikitin: done
15:46:04 Dinesh_Bhor Hi all, a small TrivialChange to review: https://review.openstack.org/#/c/427041/1
15:50:36 openstackgerrit Sivasathurappan Radhakrishnan proposed openstack/nova-specs master: Live Migration of Rescued Instances https://review.openstack.org/347161
15:57:25 mriedem sfinucan: mdbooth you guys should check the exceptions aren't actually used in https://review.openstack.org/#/c/427041/ :)
15:57:57 mdbooth mriedem: I checked that it had a +1 from Jenkins... are they still in use?
15:58:06 mriedem oh wait
15:58:12 mriedem that moved to xenapi library
16:02:36 mriedem nvm, sorry, +W on that one now
16:02:55 mriedem fwiw i don't trust jenkins on cleanups like this since we might not have test coverage
16:03:48 mdbooth mriedem: True, but at the same time not trusting it for things like this kinda devalues it.
16:04:38 mriedem i still value it, but i don't trust it for dead code removal
16:04:42 mriedem trusty, but verify
16:04:48 mriedem like the great reagan always said
16:04:54 mriedem *trust :)
16:11:08 sfinucan mriedem: Aye, I checked them all first :)
16:12:57 lyarwood mdbooth: yup you are correct re the stable/newton test backport btw
16:13:27 mdbooth lyarwood: Just learned you're on holiday. Go away :)
16:13:43 lyarwood \o/
16:27:31 cdent rust, but vitrify, like the great reagan always did
16:30:36 cfriesen does anyone know off the top of their head whether any code paths other than initial instance creation set task_state=task_states.SCHEDULING ?
16:40:09 openstackgerrit Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_provider https://review.openstack.org/433176
16:41:42 markus_z mriedem: I tried to summarize the whole newton-backport story here: https://review.openstack.org/#/c/406898/3 Is that a format which helps you?
16:42:33 mriedem oof, maybe
16:42:41 mriedem i can't digest that right now though
16:43:26 markus_z mriedem: OK, let me know when I can provide more info there.
16:57:40 openstackgerrit Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_provider https://review.openstack.org/433176
16:59:37 openstackgerrit Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835
17:03:01 openstackgerrit Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835
17:12:50 mriedem sdague: if we're going to bump the minimum required libvirt in pike https://review.openstack.org/#/c/432700/ to a version that exceeds what's available in trusty 14.04, do i also need to change https://github.com/openstack-dev/devstack/blob/e0a37cf21e43fbb4ba3f9f8fa5321a0a0e1bedf1/stack.sh#L195 so trusty isn't in that list?
17:12:54 mriedem at least when using libvirt
17:13:10 sdague mriedem: yeh
17:13:13 mriedem same for a few of those others
17:13:13 mriedem ok
17:13:41 sdague which is fine, xenial has been out for a year, there really is no reason for devstack to still stay on trusty
17:22:50 mriedem hmm, not sure what rhel7.1 shows up as
17:22:53 mriedem we check for 'rhel7'
17:23:11 mriedem kashyap: do you have a rhel 7.1 system handy?
17:23:23 mriedem or is rhel7 == rhel 7.0?
17:25:03 cfriesen mriedem: /etc/redhat-release has the appropriate release number...latest is 7.3.1611
17:25:13 cfriesen not sure what you're using to check the release
17:26:05 openstackgerrit John Garbutt proposed openstack/nova-specs master: WIP: spec about having observer role by default https://review.openstack.org/427872
17:27:20 mriedem cfriesen: what does "lsb_release -r -s" show?
17:28:20 mriedem i assume just 7.3.1611
17:28:37 mriedem so we treat all minor versions of rhel 7 the same
17:28:39 mriedem in devstack
17:29:06 cfriesen controller-1:~$ ./lsb_release -r -s
17:29:08 cfriesen 7.3.1611
17:30:04 cfriesen mriedem: on CentOS 7.2 it shows 7.2.1511
17:30:15 mriedem yeah, we treat those all as rhel7 in devstack
17:30:20 mriedem answers my question though, thanks
17:35:06 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: mark glance.api_servers opt as required https://review.openstack.org/428241
17:38:08 mriedem sdague: is the 7.0 in that list for oracle linux?
17:38:16 mriedem still trying to find when that was added
17:38:49 mriedem if you don't know that's fine, i'm digging
17:43:31 mriedem oh i guess it's debian 7.0
17:53:59 mriedem BobBall: does the xen ci use this? https://github.com/openstack-dev/devstack/blob/master/tools/xen/xenrc#L66
17:54:20 BobBall *hangs his head in shame*
17:54:30 mriedem or can that be changed to xenial?
17:54:33 BobBall I don't want to answer that...
17:54:34 BobBall :D
17:54:57 BobBall We actually have a work item to change to Xenial which is something we're looking at currently

Earlier   Later