Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-02
18:08:46 openstackgerrit Merged openstack/python-openstackclient master: fix tox python3 overrides https://review.openstack.org/606702
18:22:48 mordred dtantsur|afk: http://logs.openstack.org/14/604414/7/gate/openstacksdk-functional-devstack-tips/a3fc28f/controller/logs//syslog.txt.gz#_Sep_28_18_56_40 <-- timburke found the issue because he's smart
#openstack-sdks - 2018-10-03
01:30:12 openstackgerrit Merged openstack/python-openstackclient master: Add metavar for name parameter in subnet create https://review.openstack.org/602062
02:32:45 openstackgerrit Andriy Shevchenko proposed openstack/python-openstackclient master: fix tox python3 overrides https://review.openstack.org/607453
12:11:25 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Split advanced networking services into a job https://review.openstack.org/607199
12:13:06 ml mordred: https://review.openstack.org/#/c/592303/
12:13:27 ml am I able to trigger a recheck myself or do you have to reset the workflow?
12:13:52 mordred ml: you can - but hold off for now- the issue that's happening is the test node running out of memory
12:14:03 ml alright
12:14:26 mordred ml: I'm trying to fix with https://review.openstack.org/607199 - if it fixes it, I'll probably just squash it into your patch and merge it that way
12:15:40 ml alright, I'll keep an eye on this change. thanks for your work
13:31:04 rosmaita cdent: have an api question for you when you have a few minutes
13:33:51 cdent rosmaita: i've got time, for you, right now
13:34:32 rosmaita cdent: thanks! can you take a look at https://review.openstack.org/#/c/597648/7 /
13:34:44 rosmaita (meant that to be a ? at the end)
13:41:54 cdent rosmaita: okay, I think I'm caught up on the text of the spec and the comments
13:42:12 cdent what's the main issue you're concerned with?
13:42:50 rosmaita cdent: whether i'm right about us having to introduce a new json-patch mime type for this
13:43:03 rosmaita and whether that's a good idea
13:43:11 smcginnis Mimes are never a good idea.
13:43:25 rosmaita smcginnis: i can't hear you
13:43:31 rosmaita :)
13:43:39 smcginnis :)
13:44:57 cdent you both need to go sit on the naughty step
13:47:13 cdent rosmaita: I'd say the issue here is that the validation_data is being marked out as a separate in the representation. If checksum, os_hash_algo, and os_hash_value are legit members of the representation of the 'locations' attribute, then just pass those and _in_code_ be aware that they are validation bits
13:47:25 cdent otherwise you are not truly doing a replace operation (from a json-patch standpoint)
13:47:53 rosmaita cdent: tjat
13:48:09 rosmaita that's the key issue, we aren't doing a replace
13:48:25 cdent it sure looks like you are :)
13:49:43 rosmaita the locations attribute has a 'metadata' property, which is a json object iirc, but it doesn't have individual checksum, os_hash_* properties
13:50:28 rosmaita and we don't really want to leave 'checksum' as a location metadata item, we want there to be only one true checksum, as an image property
13:51:53 rosmaita cdent: but that's probably too much detail. i guess the key thing is that a json-patch replace operation should actually replace stuff or fail (and not do weird side-effect stuff like we're proposing)
13:52:03 cdent you say in one of your initial comments " because the "validation_data" object does not exist in the image/location schema; it's sort of an instruction, really, that produces a side effect (the population of other properties on that image)". Can you just populate those properties?
13:52:35 cdent yes: if you're using json-patch replace, it should do json-patch replace, not some special glance-only magic
13:52:54 rosmaita cdent: yes, that's the alternative (but those properties are currently read-only in the schema, which is a sticking point)
13:53:37 rosmaita the issue is that we only want these properties to be settable under one specific circumstance, and never at any other time
13:53:40 cdent making them writable during certain states is probably OK
13:53:46 cdent jinxish
13:58:37 cdent rosmaita: Have I helped or just made it worse?
13:58:48 rosmaita cdent: thinking!
13:59:27 rosmaita cdent: last question ... if we make these writable under one tiny circumstance, then we have to remove readOnly: true from the schema for them, right?
14:01:21 cdent I think that depends on how you are using and publishing the schema. In my mind schema are a validation tool used indepdently for each method:resource pair, not a contract in an of themselves
14:03:09 rosmaita cdent: thanks, that is helpful and will give us something to think about
14:03:28 cdent you're welcome
16:37:04 Luzi mordred are you there?
16:37:23 mordred Luzi: *sortof* - I'm at a conference so I'm in and out
16:38:15 Luzi okay, short question: it is planned to use openstacksdk in more projects right?
16:38:23 Luzi like nova and cinder maybe?
16:39:38 smcginnis Nothing active that I've seen, but not out of the question.
16:42:27 mordred Luzi: yes - it's already in use in heat, senlin and masakari
16:42:48 mordred Luzi: once the 1.0 is cut, I'll start poking at making patches for folks to make that possible
16:43:15 mordred Luzi: I don't know that the various services have agreed that they want such a migration yet - but from my/sdk point of view, once 1.0 is out it's a great idea
16:43:43 smcginnis mordred: Forum topic?
16:44:08 Luzi mordred, thank you for now :)
16:44:20 smcginnis Too late now to be proposed, but we may be able to find a time for it if there is interest/need.
16:50:50 mordred smcginnis: yah. I was supposed to talk to nova about it in denver - but I missed the irc ping
18:45:45 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Split advanced networking services into a job https://review.openstack.org/607199
19:35:34 kmalloc mordred: how far is SDK away from being ... usable say, in lieu of keystoneclient?
19:36:00 kmalloc mordred: i kindof want to leap early towards dropping ksc to the curb (new stuff only in SDK)
19:37:50 mordred kmalloc: we're very close to a 1.0
19:37:58 mordred kmalloc: as soon asI can get the tests to stop OOMing
19:38:14 kmalloc mordred: re-stating what i said in -keystone
19:38:23 kmalloc mordred: because i want to jump early like we did for OSC as the cli
19:39:21 kmalloc mordred: i would love to draw the line in the sand this release and say "all new stuff goes in SDK, ksc is deprecated and will see no new changes except for compat/security if an API is materially changed [see security reasons]"
19:39:33 kmalloc mordred: specifically... for new things like oslo.limit
19:39:39 kmalloc mordred: so.. yay!
19:39:48 kmalloc mordred: and boo OOMing
19:40:17 mordred kmalloc: yes - I tihnk we're in a good place for that
19:40:25 mordred kmalloc: I don't know that we're at feature parity for the existing thing
19:41:54 kmalloc cool. I'll make my -1 a little less soft on forklifting in ksc into oslo.limit
19:41:58 kmalloc and say "lets use SDK"
19:42:07 kmalloc (referencing this convo)
19:42:45 mordred ++
19:44:12 kmalloc https://review.openstack.org/#/c/596520/13 if you want to weigh in
19:44:32 kmalloc commented on it saying it's better to add support to SDK if needed than lean on ksc at this point.
19:44:45 kmalloc it's a super small set of API calls.
19:44:47 kmalloc we use there.
19:44:48 mordred kmalloc: I _certainly_ think it's valuable to start new dev that way. adding comment now
19:44:53 kmalloc :)
19:45:00 mordred kmalloc: well, and you can just use the rest layer worst case
19:45:13 kmalloc yeah, i said in my initial comment, use KSA not KSC.
19:45:23 kmalloc but figured I should talk here before firming up the -1
19:45:34 kmalloc now i'm saying "SDK"
19:45:48 kmalloc i will also push hard that all new stuff will be in SDK vs in KSC.
19:46:10 kmalloc it does mean we'll need to look at how hard it will be to re-write our ksc-plugin for OSC under SDK.
19:46:14 kmalloc should be... doable
19:46:41 kmalloc if we can make our plugin SDK, then i know everything else could lean on SDK and be 90% parity
19:46:51 mordred yes!
19:47:05 kmalloc and 90% is good enough imo to deprecate (freeze) ksc.
19:48:56 kmalloc and that saves us the headache of fixing ksc's weird session stuff that is there for compat
19:50:37 kmalloc mordred: in the interest in sharing eyebleeding patches... because... well we can
19:50:48 kmalloc mordred: https://review.openstack.org/#/c/603461/ ::will make your eyes bleed::
19:51:04 kmalloc mordred: but that is the worst forklift of keystone -> flask
21:05:57 dtroyer kmalloc: it's very easy to change commands to use the SDK, have a look at the network commands for how to use it directly, specifically security groups which handle both neutron and nova-net show how to hop between two at the same time
21:06:20 kmalloc Yep. Was looking at it just now
21:06:43 kmalloc About to embark on a "strip ksc from osc" crusade :)
21:06:46 dtroyer there are also some uses of sdk-network in the compute server commands IIRC
21:07:08 kmalloc If osc is on SDK for keystone, I can make the case ksc can die a slow death of bit rot.
21:07:27 kmalloc And all new things go sdk (carrot) for keystone.
21:07:46 kmalloc Similar to how ksc command line did a while back.

Earlier   Later