*** gkadam has joined #openstack-shade | 00:34 | |
*** thrash is now known as thrash|g0ne | 02:26 | |
*** yolanda has quit IRC | 04:29 | |
*** yolanda has joined #openstack-shade | 04:37 | |
*** ioggstream has joined #openstack-shade | 07:41 | |
*** gkadam has quit IRC | 09:35 | |
*** ioggstream has quit IRC | 11:39 | |
samueldmq | mordred: hmm gotcha | 11:40 |
---|---|---|
samueldmq | so this lack of interoperability in content is caused by the lack of data standardization (e.g images name) across multiple clouds | 11:41 |
samueldmq | that's not practical, not all clouds can/want to follow the same standards for data within the cloud, just for the sake of interoperability | 11:43 |
samueldmq | when we say interoperability at technical level (i.e API versions, etc) it's up to us, devs to ensure that | 11:43 |
samueldmq | but when it's data, it's up to the cloud providers ... | 11:43 |
samueldmq | mordred: I don't know how much you agree with this, but this is certainly a good conversation | 11:43 |
samueldmq | this is another perspective I didn't have before | 11:44 |
samueldmq | mordred: that might be what is called syntactic vs semantic interoperability | 12:00 |
samueldmq | and shade does both | 12:00 |
mordred | samueldmq: yes, that's right (syntactic vs. semantic) | 12:02 |
mordred | samueldmq: I also think there are semantic issues where it's a problem because there isn't an API-level construct offered | 12:02 |
mordred | samueldmq: using the image example, it's partially a problem because image metadata is almost entirely provider-defined | 12:03 |
samueldmq | mordred: yes. and shade does post-facto interoperability, i.e after openstack was running we noticed the gaps and started filling them | 12:03 |
mordred | so there is no image metadata field for "operating system" | 12:03 |
mordred | samueldmq: yup | 12:03 |
samueldmq | mordred: agreed. semantic things could have been addressed with well defined syntactic standards (like exposing metadata and querying by metadata) | 12:04 |
samueldmq | that would be possible if interoperability was taken seriously (defining open standards) since the beginning, but no, it;s post-facto in our case | 12:05 |
samueldmq | mordred: that's an interesting observation | 12:05 |
mordred | exactly - and at this point in some places pushing such things into the syntactic level is harder - image metadata has been arbitrary and deployer-defined for 7 years now - how do we impose stricter standards? | 12:05 |
mordred | samueldmq: incidentally, one of these is in keystone ... "what auth plugins does this cloud use?" :) | 12:06 |
samueldmq | mordred: aha. that's cool | 12:06 |
samueldmq | mordred: thanks for the examples, I am starting to correlate the issues with the formal definitions, which is great | 12:07 |
samueldmq | there is so much in this interoperability world | 12:07 |
samueldmq | mordred: maybe one of the keys for interop is discoverability. and looks like openstack misses a bunch of this | 12:10 |
*** thrash|g0ne is now known as thrash | 12:10 | |
mordred | YES | 12:16 |
mordred | samueldmq: I bet we could define various levels of interoperability or something - you know, like a thing that has the exact same API both semantically and syntactically is perfectly interoperable - but is also not particularly flexible to handle different use cases | 12:18 |
mordred | then as things introduce more flexibility, they lose interoperability unless they add corresponding discoverability | 12:18 |
samueldmq | makes sense, we need to "plaster" things a bit with strict open patterns to make things interoperable | 12:19 |
mordred | of course, then you could reach a point where there actually is no defined api because everything about the api is discoverable (sort of like key-value pairs vs. sql schema) | 12:19 |
mordred | samueldmq: ++ | 12:20 |
*** ioggstream has joined #openstack-shade | 12:20 | |
samueldmq | mordred: 2 ways for interoperability then: "plastered" apis that follow strict standards | 12:22 |
samueldmq | or... do allow flexibility (depending on operator install and config choices), but allow for discoverability | 12:22 |
samueldmq | the latter would still require shade though. since you'd need to make those choices transparent to end users | 12:23 |
samueldmq | the former is harder, but is fully interoperable, by definition. shade would not be needed | 12:23 |
samueldmq | key-value + discoverability is the extreme case for the latter, i.e too flexible | 12:24 |
samueldmq | I think we are on the same page | 12:25 |
mordred | ++ | 12:29 |
*** gouthamr has joined #openstack-shade | 12:30 | |
*** gouthamr_ has joined #openstack-shade | 12:37 | |
*** gouthamr has quit IRC | 12:38 | |
*** pabelanger_ is now known as pabelanger | 12:56 | |
*** gkadam has joined #openstack-shade | 13:56 | |
*** gouthamr_ has quit IRC | 15:26 | |
*** gkadam has quit IRC | 15:40 | |
*** gouthamr has joined #openstack-shade | 16:43 | |
*** gouthamr_ has joined #openstack-shade | 16:45 | |
*** gouthamr has quit IRC | 16:49 | |
*** ioggstream has quit IRC | 16:50 | |
*** slaweq_ has joined #openstack-shade | 19:00 | |
*** thrash is now known as thrash|g0ne | 19:21 | |
*** gouthamr_ has quit IRC | 20:32 | |
*** gouthamr has joined #openstack-shade | 20:35 | |
*** gouthamr has quit IRC | 20:39 | |
*** gouthamr has joined #openstack-shade | 20:42 | |
*** gouthamr has quit IRC | 20:45 | |
*** slaweq_ has quit IRC | 21:32 | |
*** slaweq_ has joined #openstack-shade | 22:03 | |
*** slaweq_ has quit IRC | 22:36 | |
*** slaweq_ has joined #openstack-shade | 22:39 | |
*** slaweq_ has quit IRC | 23:13 | |
*** slaweq_ has joined #openstack-shade | 23:18 | |
*** slaweq_ has quit IRC | 23:48 | |
*** slaweq_ has joined #openstack-shade | 23:52 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!