Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-07
15:04:50 luksky ?
15:04:54 cdent naw, I think we need to go deeper
15:05:26 efried again, realizing it's not perfectly pure, this is the best way to get where we want to be. Which is why we've ended up here several times after having discussed it the same way every time.
15:06:03 sean-k-mooney luksky: no
15:06:38 sean-k-mooney luksky: the retry filter on subsequet iterations does not retry host it knows cant pass
15:07:16 edleafe I think calling something "perfectly pure" is a bit condescending. I'm just pointing out that this approach is not the way placement is designed to work, and there may be downsides. If you all have agreed to go ahead with that, your eyes are wide open.
15:07:47 sean-k-mooney luksky: if its the first iteration and no filter have ran then the delta between 26 and 22 is because placemnt determined the other 4 instace did not have space for the instance and elminated them
15:08:56 mriedem jaypipes: i've gone fishing in the ML for the mystery of the server_group_members counting logic
15:09:02 mriedem maybe someone like tim bell will remmeber
15:10:28 jaypipes mriedem: to understand the mystery of the server group member counting, one must first understand the mystery that is the server groups implementation.
15:11:25 mriedem you said you're cool with server groups
15:12:07 luksky sean-k-mooney: thank You, does it can have some relation with not running discovered_host on some (i.e 4 compute) computes ?
15:16:17 luksky sean-k-mooney: I mean "nova-manage cell_v2 discover_hosts"
15:22:38 jaypipes mriedem: the concept? yes. the implementation... erm, not so much.
15:23:46 mriedem efried_mtg: bauzas: commented on the semver version for the novaclient release https://review.openstack.org/#/c/641678/
15:23:48 mriedem i'm a bit torn
15:23:56 mriedem because of the first bullet here https://docs.openstack.org/releasenotes/python-novaclient/unreleased.html#upgrade-notes
15:24:41 openstackgerrit Boxiang Zhu proposed openstack/nova master: Raise error when force_raw_images and images_type are incompatible https://review.openstack.org/640271
15:25:21 bauzas mriedem: great comment
15:25:25 bauzas I missed that one
15:25:50 kashyap Dead-simple +2/+W, can anyone put this out of its misery: https://review.openstack.org/#/c/640866/
15:26:54 mriedem kashyap: uh...
15:27:08 mriedem kashyap: if that change isn't going to land in stein, the spec has to be re-proposed for train anyway,
15:27:20 mriedem so why not just make that change in the re-proposed spec with a note in the history abou the change?
15:28:03 kashyap Whatever works; alex_xu was also onboard with the above, FWIW.
15:28:09 kashyap mriedem: Will it / can it land for Stein?
15:28:37 kashyap mriedem: So, to be clear: you want me to repropose the whole spec fo Train?
15:28:44 mriedem kashyap: it would have to merge today
15:28:57 kashyap mriedem: Ah ... right, the freeze
15:29:14 mriedem i see alex_xu and stephenfin were reviewing it, but stephenfin was only reviewing docs
15:29:17 mriedem it looks like
15:29:36 kashyap See Alex's comment on line 548.
15:30:05 stephenfin Nah, it was just the docs/config opt naming that I had comments on
15:30:11 stephenfin rest of it is noddy
15:30:14 stephenfin (IMO)
15:31:00 kashyap stephenfin: Did you see this: https://review.openstack.org/#/c/640866/3
15:31:04 kashyap dansmith: LOL
15:31:30 kashyap dansmith: Typing: 'define noddy' in Google shows this:
15:31:39 kashyap (1) [DATED] a foolish person.
15:31:46 kashyap (2) a tropical tern with mainly dark-coloured plumage.
15:31:56 stephenfin oops. noddy = easy or simple
15:32:10 dansmith kashyap: yes, I know how to use google and did.. still don't know
15:32:33 kashyap dansmith: Wasn't daring to tell you to LMGTFY ... just sharing the amusement
15:32:41 dansmith stephenfin: as in "something you nod (in agreement) at" ?
15:32:58 dansmith stephenfin: homonym-wise, sounds like "naughty" as in "not good"
15:32:58 kashyap (That's how I read it)
15:33:29 mriedem i want to say something about being offended as an american that i don't understand the language being used here
15:33:34 stephenfin I guess? I've never really though about it, to be honest
15:33:55 mriedem and how i need to take to social media to express my language victimizatoin
15:33:57 mriedem *ion
15:34:10 kashyap mriedem: Do you do social media besides IRC? I doubt that
15:34:20 dansmith I could sue stephenfin in portland for micro-aggression
15:34:35 dansmith (and probably win)
15:34:45 kashyap Yes, you will be quarantined into a "safe space"
15:35:02 mriedem kashyap: i have a linkedin account
15:35:05 mriedem does that count?
15:35:23 kashyap mriedem: Nah ... unless you're actively talking about marketecture there
15:35:23 dansmith and he treats it like facebook
15:35:39 mriedem dansmith claims to be an angry old man, but i think i have him beat
15:35:41 dansmith mriedem: so what's the deal with the user_id patch? what's the plan?
15:35:52 dansmith I don't want to be around late into the afternoon dealing with this
15:36:28 mriedem dansmith: i agree with what you said earlier,
15:36:29 mriedem "(8:49:57 AM) dansmith: mriedem: yeah I think we've been over that before.. definitely doesn't seem like something we can change on a whim regardless of the reason"
15:36:50 dansmith so, we add user_id, and user_id/project_id then yeah?
15:37:21 mriedem if we assume the server group member quota count is going to continue to be user_id only yeah
15:37:33 mriedem even if we don't, the additional index doesn't hurt does it?
15:37:37 mriedem jaypipes: ^
15:37:39 dansmith no
15:37:58 jaypipes no, it doesn't really hurt anyuthing
15:38:07 dansmith I've got the set pulled down, I'll fix up the index
15:38:12 mriedem ok so the actual counting functions later in the series don't need to merge in stein
15:38:55 dansmith right, so maybe I'll just orphan them
15:40:36 mriedem sure
15:40:41 mriedem i'm targeting to get to https://review.openstack.org/#/c/633351/
15:49:33 jaypipes +1
15:52:19 bauzas mriedem: thanks for giving us the path to the legacy job for comparing, it helps
15:52:27 bauzas context being https://review.openstack.org/#/c/640181
15:53:15 openstackgerrit Dan Smith proposed openstack/nova master: Add user_id column to the instance_mappings table https://review.openstack.org/633349
15:53:15 openstackgerrit Dan Smith proposed openstack/nova master: Add user_id field to InstanceMapping https://review.openstack.org/633350
15:53:16 openstackgerrit Dan Smith proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules https://review.openstack.org/638574
15:53:16 openstackgerrit Dan Smith proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351
15:54:19 bauzas mriedem: I guess you just copy/pasted the job definition YAML ?
15:54:57 bauzas or do I really need to do my job and diff the files ?
15:56:29 sean-k-mooney luksky: sorry i was on a call. im just runnig to another one but you only need to run discover hosts wehn you add new nodes
15:57:07 efried mriedem, bauzas: done
15:57:18 sean-k-mooney luksky: and you only need to run nova-manage cellv2 discover_hosts on the contoler nodes not on the compute nodes
16:02:46 mriedem dansmith: i just went through https://review.openstack.org/#/c/633351/24 again while you rebased, see if my comments make sense
16:03:05 mriedem bauzas: yes i copied the playbook
16:03:10 mriedem and changed the name/description
16:03:53 bauzas mriedem: yeah so blame on you, you forced me to diff
16:04:19 jaypipes dansmith: sorry if I wasn't clear about the multi-column index earlier.
16:04:49 jaypipes dansmith: I've added a comment to the revision you just pushed. If we go with a (user_id, project_id) multi-column index, there's no need for a single-column (user_id) index.
16:05:08 dansmith jaypipes: oh I was sure you said to add both
16:06:08 jaypipes dansmith: tried to explain in that comment, sorry. if you added a (project_id, user_id) index, you'd also want a (user_id) single-column index.
16:06:27 dansmith wait, what?
16:06:39 dansmith oh, it matters the ordering of them?
16:06:45 jaypipes dansmith: yep
16:06:49 dansmith jesus
16:06:52 jaypipes :)
16:06:58 dansmith so, surely these will also be looked up via project only right?

Earlier   Later