Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-18
14:17:45 edleafe bauzas: me too, but it's "in-tree" :)
14:17:47 sean-k-mooney edleafe: yes that is one example where it needs to talk to an atestation server.
14:17:58 bauzas mriedem: attestation server = silly TrustedFilter
14:18:13 mriedem oh yes
14:18:23 mriedem trusted filter is gone in queens
14:18:26 mriedem so don't complain too much
14:18:29 sean-k-mooney mriedem: bauzas i could do most of this with a costom filter + costum weigher to update the external inventory system with the final choice
14:18:54 mriedem i'd argue the custom external inventory system should be pumping custom resource class information into placement
14:18:58 mriedem which the filter scheduler can then use
14:19:15 edleafe mriedem: that would be best
14:19:25 bauzas hangout time ?
14:19:32 edleafe mriedem: but not always feasible
14:19:40 sean-k-mooney bauzas: the trusted filter today dose not vaildate that the plathfrom trust is still present just that you labled it as such. with the atestation server it dose a mesuared boot and attest the trust is still valid
14:19:42 bauzas I really wanted to explain my thoughts but my brain translates too slow
14:20:02 bauzas so I hope my thoughts could be clearer if I would voice
14:20:09 mriedem i can't spend all morning on this, so if there is further discussion we should probably move it to the ML
14:20:21 bauzas to make it clear, thoughts are :
14:20:28 mriedem i'll mark that bug as rc potential though since i think we need to handle it somehow
14:20:34 bauzas 1/ placement for all drivers
14:20:47 mriedem nack to 1
14:20:50 mriedem you can't enforce it
14:21:02 bauzas I'd love to
14:21:20 mriedem bauzas: just start a ML thread
14:21:22 sean-k-mooney bauzas: mriedem i can support my usecase with costome filter and weighers but a custom self contaitned driver just seemed cleaner so dont block on this cleanup on my account
14:21:22 bauzas placement would give to the driver which hosts to schedule
14:21:26 mriedem and we'll bikeshed to exhaustion there
14:21:39 sean-k-mooney dansmith: mriedem i just wanted to hilight that there may be usecase implications that would be limited
14:21:51 sean-k-mooney bauzas: ^ not dansmith
14:21:53 mriedem sean-k-mooney: honestly anyone that wants that level of custom is just going to carry a patch to revert the change to break the entrypoint anyway
14:21:59 bauzas how the driver is choosing between hosts (either by looping over filters or doing at once a choice) is left to the internals of the driver
14:22:36 bauzas like, ChanceScheduler should just random.choice() between what's passed by placement, that's it
14:22:48 gibi jaypipes: asking for MAGIC only leads to HTTP 500 with a stack trace: http://paste.openstack.org/show/615732/
14:23:17 bauzas but having ChanceScheduler having a different list of hosts from FilterScheduler seems to me very wrong
14:23:24 jaypipes gibi: aha! :) that's the source of the issue I think
14:23:25 sean-k-mooney mriedem: ya probably but for interop reason it would be nice if they did not need too.
14:23:31 jaypipes gibi: cdent fixed that bug.
14:23:40 jaypipes gibi: one sec, grabbing link to patch for you to apply.
14:23:49 gibi jaypipes: thanks
14:23:55 gibi jaypipes: sounds good
14:24:00 mriedem sean-k-mooney: if you have a custom out of tree scheduler driver, there is no interop guarantee
14:24:03 bauzas how a scheduler driver works should be a blackbox, but inputs of that blackbox should necessarly be identical between all drivers
14:24:08 mriedem sean-k-mooney: so it makes no difference imo
14:24:11 sean-k-mooney mriedem: the other way to solve this is to allow claims against placement api resouces to be passed as part of the nova boot and have a filter that will use those claimes for the placement.
14:24:23 bauzas mriedem: no, you could interop if you decide between the same hosts
14:24:23 jaypipes gibi: try this out: https://review.openstack.org/#/c/484162/
14:24:37 sean-k-mooney mriedem: yes that is true
14:24:45 gibi jaypipes: OK, I will report back soon
14:24:48 jaypipes btw, mriedem and dansmith, https://review.openstack.org/#/c/484162/ is a good fix (and important one)
14:24:53 bauzas mriedem: what I think people want is crazy foos of decision making based on weather or name of my pants
14:25:07 mriedem jaypipes: starred
14:25:14 dansmith bauzas: that was impressively unintelligible
14:25:39 bauzas dansmith: isn't the intent ? :)
14:26:04 dansmith bauzas: I dunno, I just saw that notification pop up and noticed not all those words belong together
14:26:11 bauzas everyone wants their blackbox for deciding which kid they have is the best
14:26:16 dansmith if that was the intent, then.. bravo :)
14:26:37 bauzas the real problem is that the list of kids is depending on the blackbox
14:26:52 sean-k-mooney bauzas: mriedem basically for the ONAP case when a host is selected and resouce allocated they need to relay that up into there own invetory system also. i think today they do that via connectin directly to the nova db.
14:27:24 bauzas sean-k-mooney: sure, but my point is that the input you should get should only hosts that placement agrees with
14:27:37 sean-k-mooney bauzas: yes i agree with that too
14:27:49 bauzas sean-k-mooney: like, you should never choose between hosts that don't have resources for the asked flavor
14:28:00 sean-k-mooney bauzas: yes
14:28:09 bauzas sean-k-mooney: that's how we guarantee interop
14:28:13 bauzas a flavor is an interop thing
14:28:49 bauzas so whatever the decision system is doing, you as a user will be sure that your instance will be on a host that can support X CPUs, Y RAM and Z disk
14:29:06 bauzas the rest is left to you
14:29:26 sean-k-mooney bauzas: so as i said there are way to supprot them if they need it without a costom driver. i just dont know how many people have already used the plugable interface that would be effect by the bug.
14:29:48 bauzas you could decide to pick host A against B and C because you're Saggitarian if you wish
14:30:07 dims mriedem : i had a cleanup from looking at castellan, do we want to do that now or when queens opens up? https://review.openstack.org/#/c/484036/
14:30:10 bauzas that's why I turned my choice
14:31:09 mriedem alex_xu: i replied in https://review.openstack.org/#/c/469800/
14:31:19 mriedem dims: that conflicts with a change that kfarr did
14:31:25 mriedem did you see that?
14:31:35 dims oops checking
14:31:42 mriedem dims https://review.openstack.org/#/c/439855/9
14:32:10 dims mriedem : kfarr's works! looking deeper
14:32:43 sean-k-mooney jaypipes: hehe i need to figure out how to integreate weechat with spell also a git hook for same
14:33:04 jaypipes sean-k-mooney: :)
14:34:23 dims mriedem : yep +1 on that review, we should get that in for Pike if possible
14:34:38 openstackgerrit Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/484582
14:34:55 jaypipes sean-k-mooney: re: ONAP, if they have chosen to architect their system by subverting the public interfaces of Nova, it is not our job to cater to those architectural fauxpas. The best advice I would have to ONAP folks is what mriedem said and have their global inventory system work with the placement service via Placement's public REST APIs and let the filter scheduler do its job (with custom weighers as you mentioned)
14:35:52 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for os-volume-attachments instead of stevedore https://review.openstack.org/484824
14:35:53 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for extension_info instead of stevedore https://review.openstack.org/484826
14:35:53 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for os-snapshots instead of stevedore https://review.openstack.org/484825
14:36:12 sean-k-mooney jaypipes: yep i agree and that is the direction i would be pushing them towords but i do not spend much time on ONAP to be honest so not sure how much they will listen.
14:36:33 jaypipes sean-k-mooney: who are the driving forces in ONAP?
14:37:36 jangutter jaypipes: Telcos, I believe.
14:38:06 sean-k-mooney jaypipes: AT&T from the ecomp side and several asian telcos form the OpenO community. ONAP is a fusion of both comunitys under the linux foundation. intel is a member but we have not been invole in the achitecher of this part whic come mainly form ecomp i belive
14:38:14 jaypipes jangutter: well, yeah :)
14:38:53 openstackgerrit Sylvain Bauza proposed openstack/nova master: Add a scheduler custom driver possibility https://review.openstack.org/484828
14:38:54 sean-k-mooney jaypipes: there is little european representation in ONAP current with most European telcos look more to OSM instead
14:39:13 jaypipes sean-k-mooney: wow, that was impressive :) comunitys, invole, achitecher, whic and belive. all new words in one sentence!
14:39:19 bauzas sean-k-mooney: mriedem: jaypipes: I need to disappear from a certain amount of time because I need to pick my daughter and do some stuff, but I'll respond to the ML thread
14:39:23 jaypipes sean-k-mooney: ok, I'm going to stop poking fun now :)
14:39:34 bauzas sean-k-mooney: mriedem: jaypipes: reviews welcome on https://review.openstack.org/484828
14:40:08 jangutter jaypipes: there was _lots_ of representation from Chinese telcos on ONAP at OPNFV.
14:40:09 sean-k-mooney jaypipes: :)
14:41:29 jaypipes jangutter: k. good to know. I'm more looking for specific people, though. any names or emails would be good to get so I can reach out and have a chat.
14:41:48 jaypipes I suppose I can hit up alanmeadows from AT&T for that info
14:42:51 jangutter jaypipes: I'll see if there's a nice mini-summit link for the presentations with contact details.
14:42:55 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Populate the 'configuration' section https://review.openstack.org/478473

Earlier   Later