Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-06-02
16:04:16 cdent dansmith: different doc job, let me find link
16:04:25 leakypipes cdent: thx
16:04:36 dansmith found it
16:04:40 cdent gate-placement-api-ref-nv
16:06:31 openstackgerrit Artom Lifshitz proposed openstack/nova master: Convert instance to primitive for metadata cache https://review.openstack.org/469978
16:07:46 dansmith we're really spoiling our users with this api_ref nonsense
16:09:43 leakypipes dansmith: lol
16:09:50 mriedem dansmith: don't worry, we still have plenty of config options that change the behavior of the API in ways not communicated,
16:09:58 mriedem so we can still screw them
16:10:06 openstackgerrit Matt Riedemann proposed openstack/nova master: show flavor info in server details https://review.openstack.org/434514
16:10:50 mriedem ^ and below are +2'ed
16:10:56 mriedem looks big but it's mostly api-ref and api samples
16:11:08 mriedem now it's burger time
16:11:22 mriedem_burgerti damn
16:12:00 artom The little known Bugatti knock-off, Burgerti
16:12:46 leakypipes "It's Burger! It's Burger time!".
16:13:49 dansmith leakypipes: we're allowing renaming of resource classes?
16:15:06 leakypipes dansmith: yes.
16:15:17 leakypipes dansmith: only custom ones of course.
16:15:28 dansmith isn't that going to confuse things?
16:15:35 figleaf to make them even more customer
16:15:52 dansmith like, we have requests in flight that refer to the old name
16:15:55 leakypipes dansmith: no. internally custom ones are just an integer code. the name can be whatever the user wants.
16:16:10 dansmith and/or someone creates two and swaps them
16:16:20 dansmith don't we communicate between services using the symbolic names?
16:16:22 figleaf leakypipes: they will have to match whatever's in the flavor, though, no?
16:16:23 leakypipes dansmith: we leave that as an exercise for the readeer? :)
16:16:33 dansmith yeah what figleaf said
16:17:00 dansmith I just see no reason to allow that.. might as well just delete and re-create so you get a new integer id and no confusion
16:17:00 figleaf dansmith: not feeling super today?
16:17:07 dansmith figleaf: definitely am not
16:17:36 leakypipes dansmith: you and figleaf make a good point. cdent is our API master so I defer to him.
16:18:03 figleaf dunno if it has much to do with the API
16:18:13 cdent I already fixed that in microversion 1.7
16:18:40 dansmith cdent: fixed what? https://review.openstack.org/#/c/467596/4 says we can rename them
16:18:44 leakypipes cdent: so we don't allow changing resource class names in 1.7 and beyond?
16:18:53 cdent because it was not only a bad flow, but also an issue with the external issue
16:19:21 cdent leakypipes: if you are using a high microversion, correct, you cannot not rename a resource class
16:19:42 cdent you can delete and create another
16:19:44 cdent or rather
16:19:45 cdent create another
16:19:46 cdent everything external is using the name
16:19:47 cdent we can't allow changing it
16:19:58 dansmith ++
16:20:35 figleaf cdent: ah, good
16:20:46 cdent I kind of feel like we should de-document the old way
16:20:52 cdent but that would lead to problems
16:21:09 cdent so perhaps a warning on the 1.2-1.6 microversion?
16:21:24 dansmith cdent: I think we should drop it from the docs, TBH
16:21:25 cdent I mean the doc for put /resource_classes/{name}
16:21:39 dansmith nobody is using this but us yet, so no reason to document something that is already obsolete
16:21:48 claudiub efried: not as it should. it doesn't consume the self / cls argument. if you are patching a function or a static method, it works fine though.
16:21:59 dansmith also, is PUT the right verb for "create or verify existence" ?
16:22:11 dansmith I would expect POST and return 409 if exists, no?
16:22:37 cdent PUT is the standard for idempotency when you know the url of the resoruce
16:22:50 cdent the idea here is that you can PUT /resource_classes/{name} all day long
16:23:00 dansmith hrm, okay
16:23:07 cdent and it will always return some form of success
16:23:10 dansmith seems wrong, but I guess I don't have time to convince the rest of the world today
16:23:10 claudiub mriedem: you didn't answer my one question :D : the cinder 3rd party ci requirements state that "CI's do not need to kick off tests until Jenkin's has given a +1", is there a similar policy for nova as well? ( https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Third_Party_CI_Requirements )
16:23:30 cdent dansmith: the decision was driven by code in the resource tracker which was doing to "get_or_create_resource_class"
16:23:40 cdent I wanted to change it to "do one call to do both"
16:23:42 cdent which is PUT
16:24:25 artom I think with PUT you're supposed to send the entire resource, and PATCH is for when you just send the changes?
16:24:33 leakypipes dansmith, cdent: added a note on 467596 to add a big fat warning in the UPDATE t1.2 through 1.6 section.
16:24:35 dansmith that way we can't log whether we created it, which means we can't highlight with a warning "I just created CUSTOM_GUP, hope you didn't typo that"
16:24:43 cdent artom: yes, but this is a different issue. a resource class PUT has no body
16:25:22 cdent dansmith: different resposne code on create or existence:
16:25:24 artom cdent, then we should only allow HEAD on it :D
16:25:41 cdent artom: :P
16:26:16 artom Bikeshedding about HTTP verbs? You don't say ;)
16:26:18 dansmith cdent: I see. less obvious, IMHO, but doesn't matter
16:26:27 dansmith I/we aren't bikeshedding
16:26:31 dansmith just chatting
16:27:07 cdent dansmith: of course that's not what the code is doing now, it doesn't log on success, and I'm pretty sure it didn't before?
16:27:32 openstackgerrit Artom Lifshitz proposed openstack/nova master: Use VIR_DOMAIN_BLOCK_REBASE_COPY_DEV when rebasing https://review.openstack.org/465205
16:28:05 dansmith cdent: I haven't even looked, and I assume we won't know we need to log such a thing until the flood of bugs complaining about it
16:28:20 dansmith cdent: but if we have a way to tell so we can add that in the future then that's fine
16:28:33 dansmith that == that log line
16:28:46 cdent (just check, it isn't, at least not on the RT side, but yeah, there's a way to distinguish)
16:28:53 cdent s/check/checked/
16:28:54 artom sfinucan ^^ addressed your feedback, except in one case where I don't agree :P
16:31:12 sfinucan artom: That's all g with me
16:31:37 harlowja mriedem whats up
16:31:48 harlowja `we should probably deprecate/remove tooz service group api driver`
16:32:13 harlowja i'd say that'd be ok, though its really up to u guys if u want to do that, and just go direct to etcd
16:32:41 harlowja both imho are the same level of effort of undoing/redoing the stuff in nova that is specific to a database (for service groups)
16:33:23 harlowja that was the main problem that was hit i think when trying to refactor that stuff, is there are a bunch of places in nova that are tied to a database for that stuff (because calling serivice group stuff a driver interface is somewhat of a lie)
16:33:39 leakypipes harlowja: yup.
16:34:34 harlowja refactoring to etcd (and a database for daatabase driver users), will likely be the same effort as refactoring to tooz in the end
16:34:41 harlowja so ya, meh, do as u want :-P
16:35:16 harlowja penick yahoo never continued down the path of that after vilobh left right?
16:35:48 harlowja (ie continuing the service group refactor to tooz and/or whatever else)
16:36:00 artom sfinucan, thanks g
16:36:23 artom (We so gangsta)
16:39:27 harlowja leakypipes mriedem what are your plans for that thing?
16:39:32 harlowja just go directly to etcd3?
16:39:46 harlowja or try again to have 2 drivers (one for database, one for etcd3 or ???)
16:45:25 openstackgerrit Merged openstack/python-novaclient master: Help message for aggregate-update is ambiguous https://review.openstack.org/469753
16:48:00 openstackgerrit Merged openstack/nova master: libvirt: fix call args to destroy() during live migration rollback https://review.openstack.org/469958

Earlier   Later