Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-29
22:09:27 openstackgerrit Jay Pipes proposed openstack/nova master: add _get_usages_from_trees() function https://review.openstack.org/534967
22:09:27 openstackgerrit Jay Pipes proposed openstack/nova master: validate provider summary structure https://review.openstack.org/536516
22:09:28 openstackgerrit Jay Pipes proposed openstack/nova master: WIP - populate alloc cands for trees https://review.openstack.org/534968
22:26:42 openstackgerrit Matt Riedemann proposed openstack/nova master: reno for notification-transformation-queens https://review.openstack.org/518018
22:30:11 mriedem dansmith: want to hit this pike backport? https://review.openstack.org/#/c/536981/
22:30:26 mgagne what's the use case for aggregates in Placement API?
22:32:12 mriedem mgagne: the primary one is modeling things where one provider shares a resource with another, like a shared storage pool
22:33:12 mgagne mriedem: thanks for the clarification, I tried to read/understand https://developer.openstack.org/api-ref/placement/#resource-provider-aggregates
22:34:31 mgagne and I'm not sure the doc fully explain its purpose, I would have never guess what you said from the doc, it mainly explains how it's not nova aggregates
22:34:37 mriedem mgagne: is the spec that talks about aggregates the most i think https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/generic-resource-pools.html
22:34:46 mriedem mgagne: heh yeah that's what i was thinking
22:34:59 mgagne how is Generic Resource Pools == aggregates? =)
22:35:59 mgagne will read and see if I can get more answers
22:37:11 mgagne thanks for the link btw ;)
22:41:09 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: provide more detail on what a provider aggregate is https://review.openstack.org/539033
22:41:10 mriedem mgagne: see if ^ helps wording-wise
22:41:42 mriedem sorry about ending on a preposition
22:42:23 mriedem maybe it's not, me fail english
22:42:37 mgagne mriedem: I think it's enough to give a hint that aggregates do have a purpose other than not being nova aggregates =)
22:43:10 mgagne I'm still trying to digest the spec you linked above.
22:45:48 mgagne would it be ok to update past spec to reflect current implement? Ex.: openstack resource-provider is now openstack resource provider
22:52:21 mriedem mgagne: if it's not too invasive, then that's probably fine
22:52:25 mriedem especially for CLI examples
22:55:14 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Update references to OSC resource provider command https://review.openstack.org/539038
23:00:11 efried mgagne mriedem Sharing providers aren't the only use case FWIW.
23:00:33 mriedem efried: i'm not up to date on the new aggregate hotness
23:00:37 mriedem but yes i know sean-k-mooney has a thing
23:00:39 mgagne efried: please let me know if there is a doc I can read =)
23:00:43 mriedem mgagne: left some comments in there
23:01:03 mriedem mgagne: that spec was written in i think mitaka or newton, so the cli stuff was all future ideas
23:01:06 efried mgagne: Not really a single doc, no. But as an example, see this ML thread...
23:01:11 mgagne mriedem: and now I find that aggregates ARE nova aggregates but not totally :O
23:01:18 mgagne mriedem: yea found the Other end user impact section
23:01:39 efried mgagne: http://lists.openstack.org/pipermail/openstack-dev/2018-January/126685.html
23:01:52 mriedem it might be easier to just add a note that any CLIs are subject to change and the definitive CLI guide is in the osc-placement docs <link>
23:02:06 mgagne efried: ok, I'm a n00b when it comes to placement, I'm trying to catch up very fast so I can answer to jaypipes but it isn't easy to find all the relevant info
23:02:36 efried mgagne: Specifically (6) and its subsequent references in the models
23:02:50 efried mgagne: Answer what from jaypipes?
23:02:55 mgagne mriedem: if there is no doc, I read specs, they often contain more info although some bit might be outdated.
23:03:17 mgagne efried: http://lists.openstack.org/pipermail/openstack-dev/2018-January/126283.html
23:03:39 efried mgagne: Yeah, had a feeling it was that :)
23:05:11 mgagne efried: so English is not my first language and I often have a hard time to grasp new concepts without visual aids. But once I understand, it's all fine =)
23:05:50 efried Je pourrais t'aider en français si tu veux, mais je crois que la langue n'est pas la problème :)
23:06:07 efried Sauf, la langue naturelle...
23:06:37 mgagne hehe, c'est quoi l'affaire de placement :O ;)
23:07:22 efried Seulement pour enregistrer les resources, rien d'autre
23:07:30 efried (pas vraiement)
23:07:55 mgagne yea, I got the idea. just trying to understand all the fine prints
23:08:41 efried Definitely. I admit I haven't kept thoroughly updated with that particular ML thread, but if you have a couple of minutes to hang about while I read it, I may be able to answer your questions more easily.
23:08:59 mriedem maciejjozefczyk_: looks like your change https://review.openstack.org/#/c/529236/
23:09:30 efried The problem I have (and the reason I wasn't following to closely) is that I don't really know about this Filter business, or what compute aggregates are/do (just that they aren't placement aggregates).
23:09:39 efried s/to/too/
23:09:44 mgagne efried: I'm trying to finish my email now. I do have some questions but tbh, it's mostly missing bits so one could transition from an aggregate based solutions to placement
23:11:59 efried mgagne: Are you trying to make an existing deployment work on a particular version of openstack?
23:13:12 mgagne efried: yes, you guessed right. in fact, it has been my job for the last year, upgrading, discovering major changes, cursing and adapting =)
23:13:35 efried mgagne: Okay, which version of openstack?
23:15:09 mgagne efried: We are running Mitaka, trying to move to Newton (currently on pause due to our friends meltdown and spectre)
23:15:53 mgagne efried: but I'm still monitoring ML and now I'm answering the email because I discovered the mentioned change that would break/change our current flow/ways of doing thing.
23:16:07 efried Oh, okay, wow. And Jay is talking about implementing these hacks all the way back to Newton? (which we're trying to EOL afaik)
23:16:24 mgagne efried: so I'm not ready for Ocata yet but I know I will have to cross that river someday
23:16:34 mgagne efried: no ^
23:17:17 mgagne efried: but the challenge is that once I'm ready to cross that river, it will be too late to complain about changes in Ocata I wasn't aware about. I'm playing catch up here.
23:18:41 mgagne efried: I don't know if you understand in what kind of boat I'm in.
23:18:54 efried mgagne: Well, I think the first thing that'll help you is to get placement aggregates out of your head. They're not related to host aggregates, and they're not fully implemented in Newton (or Ocata, or Pike, or Queens).
23:19:48 efried It sounds to me like all you need is a way to customize allocation ratios. Which can be done via placement calls, as long as there's *some* switch to turn off the automatic setting from the conf, as Jay suggests.
23:19:50 mgagne efried: ok, I found that it's not the answer to my problem. But I still need to educate myself on the concept
23:20:13 mgagne efried: yes, that's the conclusion I ended up with too
23:20:27 efried mgagne: Has anyone proposed a patch that would do that yet?
23:20:37 mgagne not that I'm aware of
23:22:32 mriedem efried: this? https://review.openstack.org/#/c/532924/
23:23:40 efried mriedem: Certainly looks related, at a glance.
23:25:21 efried mgagne: Have you tried patching ^ in?
23:26:28 mgagne efried: I'm not running master
23:27:02 efried mgagne: Yeah, I get that, I'm asking if you've tried patching that into your running environment to see if it resolves the issue.
23:27:10 efried or rather, allows you to resolve it via conf.
23:27:40 mgagne I'm not sure I understand what you are asking
23:31:28 efried mgagne: IIUC, the point of that patch will be to backport it to where you can use it (which I guess would be Newton? Though again, I thought we were EOLing that guy)
23:31:47 efried mgagne: So I'm suggesting you could do that backport locally and see if it works for you.
23:31:59 mgagne I'm really confused. what's "it" ? =)
23:32:03 efried Though I suppose things have probably changed quite a bit in those areas, so the backport may not be trivial.
23:32:12 mgagne the bug is very technical and I don't fully understand the problem and proposed solution
23:32:15 efried Sorry, the patch mriedem mentioned above - https://review.openstack.org/#/c/532924/
23:32:42 efried The proposed solution would allow you to set your allocation ratios via conf, end of story.
23:33:10 efried Nothing else would change; in particular, you would continue to be able to use your filtery thingies as you did before.
23:33:35 mriedem efried: we don't backport config option default changes
23:33:44 efried oh
23:34:01 mriedem since, you know, changing defaults on people in stable is kind of mean
23:34:02 efried what about the rest of that patch?
23:34:14 efried yeah, makes sense when you put it like that.
23:34:18 mriedem :)
23:34:24 mriedem i haven't looked at the rest of the patch in a few weeks
23:34:31 mgagne efried: what's via conf for you? Isn't already the case where you can provide allocation ratio on compute node in nova.conf? I'm totally lost
23:34:33 mriedem and i don't think i have the brain power to do so right now
23:35:09 efried mgagne: Yeah, you're right. And I'm probably just confusing the issue even more. I should stop.
23:35:50 mgagne efried: my issue is I'm being told to stop using aggregates (and allocation ratio in metadata) because they are broken.
23:36:19 mgagne efried: and to use nova.conf itself on compute node because "Config management is the solution to your problem"
23:36:29 efried I can understand where that's a problem.
23:37:11 mgagne efried: that's not what I want, this is not my flow, far from it.
23:38:42 mgagne efried: so that's basically it. Something I could do through an API now needs to be done through our config system and the person performing this task might not have access to our config system.
23:39:00 mgagne and you lose "agility" in your operations

Earlier   Later