Monday, 2018-10-15

*** dave-mccowan has joined #openstack-sdks01:03
*** slaweq has joined #openstack-sdks01:11
*** chenyb4 has joined #openstack-sdks01:15
*** slaweq has quit IRC01:15
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Add registered limit CRUD support  https://review.openstack.org/60957201:34
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Add limit CRUD support  https://review.openstack.org/60960401:34
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Add registered limit CRUD support  https://review.openstack.org/60957201:36
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Add limit CRUD support  https://review.openstack.org/60960401:36
*** dave-mccowan has quit IRC01:53
*** d0ugal has quit IRC02:16
*** d0ugal has joined #openstack-sdks02:20
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Add registered limit CRUD support  https://review.openstack.org/60957203:01
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Add limit CRUD support  https://review.openstack.org/60960403:01
openstackgerritwangxiyuan proposed openstack/openstacksdk master: Remove duplicate code  https://review.openstack.org/61040403:06
*** slaweq has joined #openstack-sdks03:45
*** slaweq has quit IRC03:49
*** e0ne has joined #openstack-sdks06:00
*** Luzi has joined #openstack-sdks06:10
*** e0ne has quit IRC06:28
*** pooja_jadhav has joined #openstack-sdks06:31
*** slaweq has joined #openstack-sdks06:42
*** tosky has joined #openstack-sdks07:45
*** ttsiouts has joined #openstack-sdks08:04
*** jpich has joined #openstack-sdks08:06
*** ttsiouts has quit IRC08:06
*** ttsiouts has joined #openstack-sdks08:17
*** ttsiouts has quit IRC08:22
*** ttsiouts has joined #openstack-sdks08:24
*** olivierb has joined #openstack-sdks08:51
*** ttsiouts has quit IRC09:11
*** ttsiouts has joined #openstack-sdks09:12
*** ttsiouts has quit IRC09:16
*** ttsiouts has joined #openstack-sdks09:17
dtantsurmordred: impressive!09:41
*** imacdonn has quit IRC09:54
*** imacdonn has joined #openstack-sdks09:54
samueldmqmorning10:13
samueldmqdoes recall if there was ever a version 1 of keystone, nova and neutron?10:13
samueldmqI suspect there was but only in the first days of openstack. I don't remember why we chose to jump to 2.0 on all those..10:14
samueldmqmordred:  ^ I know you were here since the first days ... so you might know somehting about thsi10:14
*** charz has quit IRC10:15
*** ttsiouts has quit IRC10:19
fricklersamueldmq: this has a bit of history for keystone https://docs.openstack.org/keystone/pike/contributor/http-api.html#history . I'm also pretty sure neutron only ever implemented v2, but I can only guess that that happened in order to match nova when it was split out10:22
fricklersamueldmq: and this makes me assume that nova v1 was also the legacy rackspace api https://blueprints.launchpad.net/openstack-sdk-php/+spec/nova-api-v110:24
samueldmqHmm. Awesome10:37
samueldmqThanks frickler10:37
*** dave-mccowan has joined #openstack-sdks11:01
*** chenyb4 has quit IRC11:07
dtantsurfrickler++ this is interesting11:10
*** dtantsur is now known as dtantsur|brb11:30
*** ttsiouts has joined #openstack-sdks11:40
*** ttsiouts has quit IRC12:25
*** ttsiouts has joined #openstack-sdks12:35
*** jroll has quit IRC12:38
*** jroll has joined #openstack-sdks12:39
*** dtantsur|brb is now known as dtantsur12:59
*** bobh has joined #openstack-sdks13:07
mordredfrickler: yes - nova v1 was the legacy rackspace api ... keystone v1 was, iirc, the legacy rackspace auth13:18
mordredah - yes, that link above says much the same about keystone13:18
mordredsamueldmq: ^^13:18
*** mriedem has joined #openstack-sdks13:19
*** lbragstad has joined #openstack-sdks13:20
*** zxiiro-pto is now known as zxiiro13:23
samueldmqmordred: awesome, thanks for confirming13:32
samueldmqthat helps answering the question "why does sdk not support those API versions?"13:32
mordreddtantsur: so - in a very slow answer to your question - yes, you should be worried about http methods ignoring error_message ... error_message is a parameter to _adapter._json_response - so that means we missed an update to a callsite13:32
mordredsamueldmq: ++13:32
samueldmqmordred: it would probably be useful to have that somewhere in our docs13:33
dtantsurmordred: that's what I suspected13:33
* mordred is fixing13:33
*** dave-mccowan has quit IRC13:42
*** dave-mccowan has joined #openstack-sdks13:43
*** cdent has joined #openstack-sdks13:56
*** Luzi has quit IRC13:58
*** elmiko has joined #openstack-sdks14:07
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Use network proxy in openstack.cloud  https://review.openstack.org/60464514:15
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Remove all the deprecated stuff  https://review.openstack.org/60550814:15
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Start shifting cloud object-store methods to proxy  https://review.openstack.org/60831714:15
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin  https://review.openstack.org/60831814:15
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Revert the Proxy metaclass  https://review.openstack.org/60974714:15
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Rearrange shade image code  https://review.openstack.org/60968314:15
mordreddtantsur: ok. I think 604645 is good now14:16
dtantsurgreat :)14:20
dtantsurmordred: re _normalize_* stuffs: what is its role?14:20
dtantsurI thought as a bare minimum we should remove "links", etc?14:20
*** jamielennox has quit IRC14:27
*** jamielennox has joined #openstack-sdks14:29
mordreddtantsur: well - long term I think _normalize_* should go away and the data model contract should just be expressed in the Resource objects ...14:53
mordredbut that's a little handwavey14:54
dtantsurthe Resource objects do have a bit technical things like "links". do we want to keep them in the output?14:54
mordreddtantsur: it's a good question. I'm less opposed to them than I was in years past because we have the underlying structure to do something with them now (it use to be you got a link in a novaclient object, but didn't have any configured rest client that could actually make a request from that link)15:05
mordredso maybe they're ok to keep around now? or maybe they're a terrible idea ...15:05
dtantsurI'm fine with either way, but we need it consistent15:07
dtantsurcurrently we're quite inconsistent, at least in the baremetal world15:07
mordredyah. I agre - consistency is the most important15:08
mordreddtantsur: to  me I think it's more important that we get to a place where you get the same return object whether you use shade layer or proxy layer - because that way you can write nicer programs that sometimes use a higher-level helper method and sometimes lower-level methods15:09
dtantsurokay, then hiding links probably does not make much sense..15:09
mordredyah15:09
dtantsurokay, so I'll probably drop _normalize_machine and won't introduce _normalize_nic15:10
*** ttsiouts has quit IRC15:21
mordred++15:23
*** ttsiouts has joined #openstack-sdks15:40
*** melwitt has joined #openstack-sdks15:46
*** openstackgerrit has quit IRC15:47
*** openstackgerrit has joined #openstack-sdks15:47
openstackgerritMonty Taylor proposed openstack/openstacksdk master: WIP Use proxy layer in shade networks  https://review.openstack.org/61062415:47
mordredsamueldmq: there's a half-written stab at using self.network.networks() for list_networks ...15:47
mordredsamueldmq: which I think may get us further than doing new normalize methods like https://review.openstack.org/#/c/60221815:50
dtantsurheh, openstackcloud.py is so big, it even makes vim slow :D15:50
mordreddtantsur: hehe15:50
openstackgerritDmitry Tantsur proposed openstack/openstacksdk master: Switch bare metal NIC actions in OpenStackCloud to baremetal Proxy calls  https://review.openstack.org/61002415:51
*** e0ne has joined #openstack-sdks16:04
samueldmqmordred: kk, I'll take a look at that today16:06
samueldmqmordred: it'd be awesome to have that and the rest of the patches approved soon16:07
samueldmqthey're all ready for review, passing tests16:07
mordredyah16:08
mordredsamueldmq: it's also possible that what we should do is start by landing your normalize patches (possibly making sure that they normalize things into a form that also looks like the fields in the Resource classes)16:09
samueldmqexcept for a _metadata test that insists on failing intermitently16:09
samueldmqmordred: have you seen some gates breaking with taht?16:10
*** ttsiouts has quit IRC16:10
mordredand then a second set of patches to shift to using Resource- so that we can see the test updates along with the normalize (I think we're likely going to need to change some of the tests to be better)16:10
samueldmqmordred: ++16:10
mordredI haven't?16:10
mordredsamueldmq: although - my network patch from above (https://review.openstack.org/604645) is totally gonna merge-conflict yours16:10
samueldmqmordred: because for the specific esources that we don't normalize yet we need to include all the known attributes anyway16:10
samueldmqotherwise we wouldn't keep backwards compatibility upon normalziaiotn16:11
mordredsamueldmq: yah16:11
*** ttsiouts has joined #openstack-sdks16:11
mordredsamueldmq: well - althugh - within reason I'm ok with some skew here as we haven't ever defined a contract, and neutron objects are very variable depending on deployer plugins and stuff16:11
samueldmqmordred:  so it's really free in the wild16:12
mordredso - I don't think we should go crazy, but I also don't think our tests of that api surface are particularly great, so I think we can make a best effort16:12
mordredyah16:12
samueldmqkk sounds reasonable16:12
mordredfor instance - we're letting values like provider:physical_network through as keys directly - while the sdk resource is normalizing that to provider_physical_network16:13
mordredwe might have to get clever at some point ...16:14
samueldmqmordred: you want to nomalize that? or should we keep both?[16:14
samueldmqmordred: yes. I think we all understand we need to improve things at some point16:14
mordred:)16:15
samueldmqbut we don't liek to talk about not being backwards compatible. perhaps a deprecation approach that is very solid could be adopted16:15
*** ttsiouts has quit IRC16:15
mordredyeah. or - maybe resource gives us enough tools to define 'provider:physical_network' as an alias for provider_physical_network16:15
samueldmqmordred: but then we keep including both formats forever?16:16
mordredso that if a user does network['provider:physical_network'] it'll still return a value - but the api docs will show network.provider_physical_network16:16
samueldmqhmm, we would need  to support that while reading the munch16:16
mordredsamueldmq: yeah - I think it's more generally thinking about how we provide a good and consistent interface but also letting people use the names from the service api docs?16:16
samueldmqeven though it's not in the munch if you only do print(my_resource)16:17
mordredyeah. I *think* resource can already handle that16:17
samueldmqmordred: maybe. I don't like to think about the services at all16:17
samueldmqI like to think as a newcomer that just wants things done in a cloud16:17
samueldmqI don't care about being too clever, just use the basic things (get a server up)16:18
samueldmqand that's all shade is about right16:18
*** e0ne has quit IRC16:21
samueldmqmordred: I don't think we have a clear picture of what goes in abstraction layer and what doesn't in terms of depth in the resources16:22
samueldmqI get confused whether we want to have a one handle'em all abstraction layer, or really the most important/common16:23
samueldmq"Clouds can do many many many things - but there are probably only about 10 of them that most people care about with any regularity."16:23
mordredsamueldmq: yah. I agree - it's definitely unclear16:24
mordredsamueldmq: how I've been thinking about it recently is to try to make the Resource layer be similar to the _normalize_* methods from shade - so that we can have objects that are returned with consistent field names no matter which api you're using16:25
samueldmqmordred: sure for that part yes, I agree 100%16:26
mordredand then have shade have the "10 things more people care about" methods - and the sdk/proxy layer have the more service-oriented specific methods16:26
mordredso - like with that image patch as an example - there are methods in the proxy layer for image.v1.upload_image and image.v2.upload_image and block_storage.v2.create_image_from_volume - but in the shade layer there's still just 'create_image' that just works16:27
*** e0ne has joined #openstack-sdks16:27
*** e0ne has quit IRC16:28
samueldmqmordred: that makes total sense16:28
samueldmqwhat I was saying is that we should watch for how deep we go in representing resources. we might be normalizing to attributes that require not basic usage, let's keep abstraction layer simple16:29
samueldmqmordred: what if the user could define what their resources look like by defining their own aliases. does that make sense at all?16:30
samueldmqmy rationale is that simple may vary from user to user,16:31
*** cdent has left #openstack-sdks16:32
samueldmqmaybe that's not the best api design. can be crazy to maintain16:33
mordredsamueldmq: hrm. it's an interesting thought ... but I think maybe what I'm thinking is somewhere in the middle16:35
mordredlike, since Resource does magic with __getattribute__ anyway - we should be able to make any attribute of the original json from the service accessible?16:36
samueldmqwhat if I inherit Munch in MunchWithAliases16:36
samueldmqhmm yes that's the same concept16:37
samueldmqif I do print(network) it gives me {"provider_physical_network": True}, but I can access with16:38
samueldmqnetwork['provider_physical_network'] == network['provider:physical_network'] == network.provider_physical_network16:38
*** jpich has quit IRC16:44
samueldmqmordred: yes you're right, https://github.com/openstack/openstacksdk/blob/master/openstack/object_store/v1/container.py#L4216:53
samueldmqResource can do that for us, with a single alias, but should be enoguh for now16:54
*** dtantsur is now known as dtantsur|afk17:38
mordredsamueldmq: \o/17:54
openstackgerritCorey Bryant proposed openstack/keystoneauth master: Change python3.5 job to python3.7 job on Stein+  https://review.openstack.org/61068518:05
*** dmellado has quit IRC18:05
*** dmellado has joined #openstack-sdks18:05
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Remove all the deprecated stuff  https://review.openstack.org/60550818:22
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Start shifting cloud object-store methods to proxy  https://review.openstack.org/60831718:22
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin  https://review.openstack.org/60831818:22
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Revert the Proxy metaclass  https://review.openstack.org/60974718:22
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Rearrange shade image code  https://review.openstack.org/60968318:22
openstackgerritMonty Taylor proposed openstack/openstacksdk master: WIP Use proxy layer in shade networks  https://review.openstack.org/61062418:22
*** bobh has quit IRC18:27
openstackgerritMaxime Guyot proposed openstack/openstacksdk master: Update Auro cloud profile  https://review.openstack.org/61069918:38
*** Miouge has joined #openstack-sdks19:00
openstackgerritMaxime Guyot proposed openstack/openstacksdk master: Update ElastX cloud profile  https://review.openstack.org/61070419:04
*** bobh has joined #openstack-sdks19:05
*** bobh has quit IRC19:05
*** bobh has joined #openstack-sdks19:06
openstackgerritMaxime Guyot proposed openstack/openstacksdk master: Update ElastX cloud profile  https://review.openstack.org/61070419:09
*** bobh has quit IRC19:11
*** mriedem has quit IRC19:32
*** mriedem has joined #openstack-sdks19:35
*** bobh has joined #openstack-sdks20:08
*** bobh has quit IRC20:43
*** openstackgerrit has quit IRC21:56
*** openstackgerrit has joined #openstack-sdks21:58
*** openstackgerrit has quit IRC21:58
*** openstackgerrit has joined #openstack-sdks22:00
*** slaweq has quit IRC22:05
*** eandersson has joined #openstack-sdks22:07
openstackgerritMerged openstack/python-openstackclient master: Handle not having cinderclient.v1 available  https://review.openstack.org/60947322:07
*** slaweq has joined #openstack-sdks22:11
*** openstackgerrit has quit IRC22:12
*** openstackgerrit has joined #openstack-sdks22:14
mordredShrews: if you're bored, the stack ending at https://review.openstack.org/#/c/609683 is green now22:15
*** slaweq has quit IRC22:15
openstackgerritMonty Taylor proposed openstack/openstacksdk master: DNM Testing magnum gate fix  https://review.openstack.org/61074422:38
*** openstackgerrit has quit IRC22:43
*** openstackgerrit has joined #openstack-sdks22:50
openstackgerritFilippo Inzaghi proposed openstack/cliff master: Change python3.5 job to python3.7 job on Stein+  https://review.openstack.org/61074622:50
openstackgerritFilippo Inzaghi proposed openstack/openstackclient master: Change python3.5 job to python3.7 job on Stein+  https://review.openstack.org/61074822:50
openstackgerritFilippo Inzaghi proposed openstack/osc-lib master: Change python3.5 job to python3.7 job on Stein+  https://review.openstack.org/61074922:52
openstackgerritFilippo Inzaghi proposed openstack/python-openstackclient master: Change python3.5 job to python3.7 job on Stein+  https://review.openstack.org/61075122:52
*** mriedem has quit IRC23:00
*** slaweq has joined #openstack-sdks23:11
*** slaweq has quit IRC23:16
*** tosky has quit IRC23:25

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!