15:10:20 #startmeeting satori 15:10:21 Meeting started Mon Apr 21 15:10:20 2014 UTC and is due to finish in 60 minutes. The chair is zns. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:10:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:10:24 The meeting name has been set to 'satori' 15:10:28 o/ 15:10:34 Hi there - apologies for being later. 15:10:40 Hi gondoi - who else is here? 15:10:51 o/ 15:12:04 o/ 15:12:08 Cool. 15:12:13 o/ 15:12:16 #topic Action Items 15:12:34 o/ 15:12:39 #action zns start ML discussion & blueprint for built-in python data plane discovery 15:12:46 Not done - moving back again 15:12:55 caleb_ Developer docs for doing discovery using Python rather than the command line 15:13:02 caleb_ is not here. 15:13:29 update documentation to point to #openstack-satori channel - done. I did not find anywhere else to change. Thanks to gondoi who handled it. 15:13:51 #topic Schema Blueprint 15:13:56 #link https://blueprints.launchpad.net/satori/+spec/satori-discovery-schema 15:14:37 I updated the blueprint based on our meeting two weeks ago (last week was all about heartbleed). Any feedback on the updates? 15:14:56 Looks good to me 15:16:16 Does the schema assume we will do discoveries based solely on individual netlocs, then? 15:17:03 I don't believe so. Can you explain what about the schema leads you to make that assumption? 15:17:27 I think its the find key, which I, in general find a bit confusing. 15:17:46 It seems to me that the data you have there is, essentially, information about a DNS domain resource 15:18:41 And that 'found' is vague enough that I would not know what to expect to find in it. Resources are 'found' after all. Pretty much all the data in the discovery is. That being, sort of the definition of discovery. 15:19:46 Its difficult to imagine a good alternative for the name, though, since I don't understand what would really belong there. It feels sorta like the junk drawer. 15:20:51 We had a number of random facts coming back (like ip-address, and such) that were not resources. I grouped those under the "found" key. 15:21:07 I suppose my argument woudl be: those facts arent' random. 15:21:22 They are directly connected to a DNS record, the ones you have listed there. 15:21:48 ... with the intent to also make those keys map back to items requested at the beginning of a discovery. That way requested items either end up in errors or found. 15:21:50 Or it seems so to me? 15:22:22 But - wouldn't most items requested to be discovered be specific to certain resources? 15:23:08 Unless we're talking about this being a place for information that summarizes data about multiple resources, like the Time Zone work samstav was working on. 15:23:12 Yes, sorry, my choice of word was not accurate. They're not random, but not predictable as they depend on how the discovery goes. 15:24:16 I'm just not clear on why the answers woudl go here, and not under the resources they are answering about. 15:24:17 No necessarily. We could end up discovering DNS data and certificate information and not be able to identify any resources since resources are mostly control plane items. 15:24:57 I would argue that DNS data and certificate information IS a resource. Our control plane in that case is highly limited (essentially, its whois). But nonetheless, that's a control plane 15:25:44 A certificate is a resource. We can discover info about it using the WHOIS control plane. 15:26:09 A DNS record is a resource. We can always discover info using the WHOIS control plane. Sometimes we can discover more using some alternate control plane. 15:26:13 Does that make sense? 15:26:34 But, feel free to shut me down, I don't want to eat the whole meeting over this. 15:28:28 How about this as an example: If the given target for a discovery is a URL (http:www.example.com) and we output the FQDN (www.example.com). It feels unnecessary to create a Resource for that? 15:28:58 A resource is no more expensive than a 'found' key. 15:29:05 And its at least clearer. 15:30:34 I disagree with "A resource is no more expensive than a 'found' key." It's one string. It's always a string. It's totally overcomplicating it to create a resource key for that. 15:30:52 But - 15:31:33 In general, that FQDN is not te only thing someone is discovering. That would be the first step, then they woudl resolve the fqdn to an ip, and look up, say, the length of the DNS lease maybe, etc, etc, etc. 15:31:42 All that data is related, around a DNS resource 15:32:05 I don't think I have a strong opinion regarding this implementation. Found does not seem ridiculous. 15:32:37 *shrugs* Like I said, I don't want to eat the whole meeting over it. It just does not feel intuitive to me what precisely belongs in found. 15:32:45 I can see as more data is discovered that there may be a bigger difference between Found and Resources 15:32:58 which is not as clear in the example 15:33:34 walker: I agree, but I feel like right now the definition is just 'Stuff that doesn't belong in resources'. Defining a data domain in the negative is just a synonym for 'junk drawer' in my mind. 15:34:03 jasonpgignac1: perhaps a good action item then is to explore how exactly those should be defined 15:34:04 Can you explain what you mean by "Defining a data domain in the negative"? 15:35:50 zns: I mean this: the pithiest description of what goes in 'found' right now, to my understanding is 'Things we discovered that aren't resources'. So we haven't defined what these thigns are, just whtat they aren't. Which means that it is too easy for us to just throw new pieces of data into here, instead of really thinking about where they belong. 15:35:59 The data we have listed, dns stuff, just feels like an example of that to me. 15:36:53 Developers, especially in a hurry, follow the path of least resistance for outputting data. If you have a path that's defined as 'stuff that's data' and nothing else, really, then that will be the path of least resistance. 15:36:58 And it will end up being a junkpile. 15:37:01 IMHO 15:37:25 The keys in found toe back to the conversation we had about errors being tied back to requested items in the discovery. You were the one that asked for that, jasonpgignac1. So we added keys to errors, so you can link errors back to items you asked for and you can see which, of the items you asked for, you got and which failed and why. The found key is the complement to that request, but for things that succeeded. I recognize that that list 15:37:25 right now is static (we assume you asked for fqdn, ip-address, etc... when you request a discovery) and that the list will be dynamic at some point. So the found key is not a junk pile, it's a list based on what you will be asking satori to do. 15:39:03 I.e. think of it as when you run "satori find A,B,C,D" it will respond with the JSON equivalent of I foun: A, B, but C, and D errored out with these errors. 15:39:13 I agree with the value of keying errors to data. I imagine we need to be able to do that with data about resource data too. And after all, one thing I'll ask satori to do is discover resource data, specific pieces of resource data. Essentially, 'answers to questions you asked Satori to answer' is a definitino of the entire JSON data structure. Not just the 'found' key. 15:40:23 Sorry, not trying to be difficult. 15:43:46 way to go jasonpgignac1, you killed zns 15:44:04 Part of the challenge is that we explicitly said we were not going to solve too far down the line. So we don't have a clear mechanism for specifying what we are requesting satori to discover. So you're forcing us to either step back and simplify by dropping the keys in errors and found, or solving for the more comprehensive use case. I think we can do the latter, but we'll need to spend a lot more time designing and we won't be able to 15:44:04 iterate our way there. I'm opting for solving just for what is listed at the top of the spec and not over-designing. 15:45:24 That's fine. I think we can use the spec here. I just think it would be better to keep the answers inside of a data structure that defines the domain they are answering about, like resources, as long as posisble. But YMMV. 15:45:42 I propose that this be moved to the blueprint and that if there are disagreements with implementation, they be countered with alternatives 15:45:54 I can agree with that 15:46:15 otherwise, I don't think this is helpful 15:46:18 And I recognize that is incomplete. But it has it's pragmatic benefits. Namely, we know we want those features today and we can use them. And we can use them as spec'er. As for the concerns you raise, they're not blockers right now. 15:46:51 spec'ed (speced? spec'd...) ... 15:46:57 *shrug* That's fine, if I'm the only one worrying about, its probably just me. 15:46:58 specified in the spec!!!! 15:47:20 easy for you to say 15:47:57 *crawls quietly back into his gadfly cage* 15:48:01 Is jasonpgignac1 the only one fighting for a more comprehensive use case? 15:48:50 Any other comments, concerns about the spec? 15:50:28 jasonpgignac1- thank you for pushing on this. Your comments from the previous meeting resulted in a better spec, IMO. I like where it stands now, and I don't think it precludes putting things in resources as you request. Maybe you can just ignore the found key and get your data from resources... 15:50:33 Cool. 15:50:39 Any other topics to discuss? 15:51:34 Going once... 15:51:50 Going twice... 15:52:08 SOLD 15:52:26 Gone... thank you all! See you next week. Pls get any new blueprints/specs in by Thursday to discuss next Monday. 15:52:30 #endmeeting