21:00:34 #startmeeting scientific-sig 21:00:35 Meeting started Tue Dec 12 21:00:34 2017 UTC and is due to finish in 60 minutes. The chair is oneswig. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:38 The meeting name has been set to 'scientific_sig' 21:01:01 greetings indeed craig__ thanks for coming 21:01:23 #link agenda for today https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_December_12th_2017 21:01:30 hi all 21:01:35 hi 21:01:36 Martial says you're talking about fed clouds today. I'm involved in the NIST/IEEE Joint WG 21:01:43 hello trandles cleong 21:01:52 craig__: indeed, that is the plan 21:02:23 ah, I've just heard from Blair, he'll be a little late 21:02:38 craig__: did you hear from Martial recently? 21:02:59 We were on the phone yesterday. He should be here. 21:03:03 hey everybody 21:03:06 martial_: joined a few mins ago 21:03:09 Hi Mike 21:03:23 ah excellent 21:03:27 #chair martial_ 21:03:28 Current chairs: martial_ oneswig 21:03:46 Do we have Khalil here today? 21:03:50 Hello.. Bob Bohn from NIST here 21:03:56 hi Bob 21:04:26 who else is here? 21:04:31 OK, I suggest until we hear from Khalil we shuffle the agenda and put the NIST project first 21:04:57 qwebirc82044: craig__ from NIST 21:05:05 (correct?) 21:05:18 * ildikov is lurking as well :) 21:05:21 ACtually from The Aerospace Corp. but doing work for NIST 21:05:35 #topic NIST/IEEE federation working group 21:05:43 ok.. we can shuffle agenda. Where is one? 21:06:00 Agenda's up here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_December_12th_2017 21:06:34 ok.. never mind. I have it. 21:06:35 OK craig__ qwebirc82044 - I had a question to get started. What standards do you have in mind that do not exist today? 21:06:45 Good question. 21:07:08 There are a number of existing relevant standards, but we could possibly talk about standards for how to manage a federation 21:07:47 How to manage the semantic interop. How two or more orgs can understand what services are available, what policies are to be observed, etc. 21:08:08 Should I go on? 21:08:37 What is the use case for two orgs to share private clouds - purely a research use case? 21:08:58 We have two clouds 21:09:00 No. I think two orgs could share private clouds for various business goals. 21:09:07 Supply chain mgmt, eg. 21:09:09 FYI, Bob is coming, but having issues joining 21:09:26 Bob is here... 21:09:31 oh wait, he is here ;) 21:09:34 I also want to make the point that fed could be done at diff levels in the sys stack 21:09:35 Hi martial_ 21:09:53 IaaS, PaaS, and SaaS -- fed could be done for arbitrary business functions 21:10:41 i think if we want to discuss resource discovery, there is a section in the V0.9 of the P2302 draft 21:11:05 it's an interesting idea that software could become ubiquitous even when the hardware is distributed. 21:11:16 Hi Stig 21:11:35 But I'm not sure, that sounds more FOSDEM than IEEE 21:13:15 Imho the Keystone object model could be augmented to manage arb federations 21:13:22 hello, appologies for being late. forgot to reset my calendar ;) 21:13:35 The IEEE processes are famously slow. How are you going to keep up with the pace of change in cloud? 21:13:36 Also.. I think if we start to consider "standrads", looking at interfaces between components is a good place to start 21:14:06 A Keystone domain is tantamount to a federation; a domain could be virtual, meaning it's used to share info among specific federation partners for that specific domain/virtual organization 21:15:07 If a "federation agent" capability was added to Keystone, we could talk about a standard communication protocol among keystone-based fed agents. 21:15:15 might be a bit off-topic (my apology): for IEEE, are we/anyone looking into the IEEE P2301 and P2302? 21:15:16 oneswig: my hope is that open source will have influence on standardization processes as well at some point in the hopefully not too far future 21:15:37 I had a question on this - do you get everything necessary for keystone-to-keystone federation from the public API? 21:15:45 Hi. I chair P2302 along with David Bernstein 21:15:52 oneswig: my personal thinking re they are being famously slow 21:16:03 "Rough consensus and running code" -- whoever has a running prototype that seems to work and provide user value, that will get attention 21:16:04 ildikov: I would like that. 21:16:43 oneswig: same; I hope if I repeat this to enough people enough times at the right place then it will magically happen :) 21:16:45 qwebirc82044: nice.. is there something that the group can collaborate here? i know P2302/P2301 have been there for awhile 21:17:07 craig__: +1 21:17:14 qwebirc82044: Is that an IEEE-standard IRC nick? :-) 21:17:36 probably not a standard irc monniker 21:18:04 If there was a standard for that, it could be fatal! 21:18:23 leong - what do you mean about the group collaborating here? You mean P2302 contribute here or vice versa? 21:18:32 craig__: qwebirc82044: so who is part of the WG and how long has it been running? 21:18:33 sorry.. first time here... 21:18:43 How has the Scientific SIG been thinking about collaboration mgmt? 21:18:50 qwebirc82044: you are very welcome 21:19:08 qwebirc82044: P2302 aimed to address standard for interop and federation, is there anything we can do here at OpenStack? 21:19:16 NIST/P2302 have been working together since August 21:19:55 P2302 has been looking at "cloud wholesaling" as a fairly narrow use case. they have taken a very network-oriented approach to supporting this use case. 21:19:56 leong... i can send you a copy of an older draft P2302 standard that you can read 21:20:16 qwebirc82044: what is the membership of the WG? 21:20:43 oneswig - it is an open group, bot P2302 and the NIST 21:20:48 Keystone has already built-out basic support for pair-wise federation of the core OS services. 21:21:13 imho, with minor additions, Keystone could be used to manage arbitrary federations of app-level services. 21:21:29 THere would be scalability challenges, but what that would be a good problem to have 21:21:33 if anybody wants to participate in NIST Fede Cloud and/or P2302 - please send email to me with your request: robert.bohn@nist.gov 21:21:41 qwebirc82044: i think i have the older draft.. unless there is a newer version? 21:22:01 there are several old drafts. V0.9 is the latest 21:22:28 qwebirc82044: can you post a link to the latest? 21:23:28 martial_: Given I think you understand both projects, what are the key differences between NIST/IEEE P2302 and ORCA? 21:23:52 ... and what is in common? 21:24:02 no... sorry.. I do not have it online 21:24:53 oneswig: was helping Khalil join 21:24:58 The older v 0.2 is avail on intercloudtestbed.org 21:25:01 I am in 21:25:04 oneswig: ask the question again please 21:25:06 thanks 21:25:28 Hi khalil, thanks for joining 21:25:36 thank you 21:25:37 question was: martial_: Given I think you understand both projects, what are the key differences between NIST/IEEE P2302 and ORCA? 21:25:44 ... and what is in common? 21:26:08 in common, not InCommon... ;-) 21:26:13 qwebirc82044: i just send you an email ..:-) 21:26:19 ORCA is an application of federation 21:26:34 the NIST/IEEE efforts are defining federation 21:26:58 #chair b1airo 21:26:59 Current chairs: b1airo martial_ oneswig 21:27:06 hi blair 21:27:14 ORCA hopes to provide input to the NIST/IEEE effort then implement to the standards 21:27:48 o/ (I have been lurking few 15 mins) 21:27:57 khalil: thanks, that makes sense 21:28:40 There are also a number of fed-related projects underway. We need to understand what emergent dominant practices might be 21:28:55 craig__: qwebirc82044: when a consensus becomes a standard, does that then mean a "down-selecting" of potential components of federation? Eg, auth protocols, etc. 21:29:01 otherwise - ORCA is a use case that (IMHO) exposes quite a wide range of the issues that are relevant to understanding the scope of standards relevant to describing federation 21:29:38 explain "down-selecting" 21:30:02 There are diff possible fed deployment models that are suitable for diff app domains. 21:30:12 As in, defining the standard around one set of technologies 21:30:25 These could have diff requirements for diff components. The challenge is to understand the "fat" part of the market, is poss 21:31:59 I think the NIST/IEEE effort will identify the technical areas that are relevant/necessary for establishing a "cloud federation" without prescribing a particular deployment model 21:32:33 Yes, initially that's what we are targeting. Once we have the basics identified, we can approach deployment/implementation models 21:33:21 Sounds sensible - I think the likeliest path to success is much more bazaar than cathedral 21:33:26 there will naturally be use-case dependencies on how things like authorization work in practice 21:33:41 agree 21:34:16 I think NIST will generalize the model conceptually, IEEE will take that material to create a standard. My thinking is that it should be open enough so there is more than 1 possible implementation (solution). 21:34:23 We have to understand the design space, then we can choose one (or more) implemenation/deployments that might work for a good set of use cases 21:34:41 the challenge of the parsimony in guidance -- general model that admits the highest level of diversity in outcomes 21:35:47 Are the Aristotle folks on? 21:36:04 qwebirc82044: more than 1 implementation that are incompatible with one another? 21:36:31 Sig -- could you expand on that? 21:36:35 unfortunately, the person we invited was not avble to attend tonight 21:37:01 a research use case is different from say, a financial one 21:37:13 ultimately - i think they would need to be compatible on some level if they are solutions to a federated model 21:37:19 but they want to follow up on this conversation, maybe the next USA friendly SSIG IRC meeting can be a part 2 21:38:10 khalil: what I mean is, when Bob's saying about supporting multiple implementations, do those implementations need to be compatible with one another? It's a very open standard if they do not, but it would exclude technologies in use if it did. 21:38:19 If there was a standard fed protocol that enabled diff "fed agents" or "fed brokers" to understand each other, that would go a long way 21:39:22 thanks Sig. I think that they would have to be differentiated an potentially incompatible. 21:40:21 as example - a federation that is purposed to genomics data might not want to allow other federation access as a security measure 21:41:06 at the end of the day, I think that federating two or more clouds must be "purposeful" and therefore, unique 21:41:31 Federation instances will be unique 21:42:00 interesting... i see that they would need to be differentiated and belonging to different federations. Hence, they could be incompatible and unique 21:42:48 a fed instance is a security and collab context where diff policies could be jointly defined and enforced among the participants 21:43:08 nonetheless, the description of what a federation is could be applicable to all instances 21:43:16 By "incompatible" I assume you mean "separate" 21:43:37 i agree with the last 2 statements 21:44:31 separate yes. incompatible to the extent that one federation will not accept (w/o some agreement to do so) participation of another federation 21:44:41 incompatible by design 21:45:22 There's a better word than incompatible -- separate by policy 21:45:56 we are going into the SLA conversation again? :) 21:46:04 Earlier you referred to candidate implementations - what activity is going on around that? 21:46:41 EGI fed cloud, Nectar, EU-Brazil Fogbow, Keystone, Aristotle, MOC, ... 21:46:54 KeyVOMS 21:47:16 ORCA would be a candidate implementation..? 21:47:20 assume so 21:48:04 sounds reasonable to me 21:48:06 craig__: so the effort is around characterising the technologies and protocols of each? 21:48:37 Understanding them all at a detailed level and understanding commonalities/differences needs to be done 21:48:53 Is there any useful way for operators and architects to engage today? 21:49:01 Anybody want to drop a few $100k on me? ;-> 21:49:16 and Khalil 21:49:18 include me in that... :) 21:49:28 thanks Martial 21:49:36 that's like 5 bitcoins... 21:49:56 Can I use bitcoin to buy plane tix? 21:51:03 We're almost to the top of the hour. What are the action items? 21:51:34 to Blair's question -- I think it will be important to get input from operators and architects to ensure that we have covered the necessary scope in developing standards and that the guidance from the standards is at the "right level" to allow for uniqueness in deployments 21:51:52 I don't think we have any - it's been interesting to hear the discussion 21:52:26 on action items - how to involve a larger group in the vetting of the standards would be great 21:52:38 Understanding the desired use cases is necessary. From there, we can understand required capabilities and tooling. 21:52:58 for ORCA, that is essential, for NIST/IEEE the more input the better (IMHO) 21:53:03 +1 21:53:15 i agree 21:53:37 Ok, maybe some Xmas holiday reading for me then 21:54:07 Sig/Blair/Martial + others -- how do we get more participation from the technical folks on the development of "essential requirements" for ORCA? 21:54:20 if you choose to participate with NIST effort or P2302, please contact me (robert.bohn@nist.gov) 21:54:40 Dec 26 would be the next meeting for USA, that is going to be a tough one to continue this conversation 21:55:07 khalil: it would help to run IRC or similar meetings I think 21:55:41 the next P2302 mtg is Monday Dec 18 at 1:00pm ET 21:55:46 Perhaps we could have a monthly coordination slot in these meetings..? 21:55:55 and in general easy access to ongoing work and discussion items as well as minutes of meeting 21:56:21 That's the nice thing about IRC - autominutes! 21:56:34 that would be helpful, we have working group areas: identity, security, data, business transactions enablement, etc... 21:56:34 ok 21:56:44 Here are some relevant sites- 21:56:48 Link to P2302 Public Site https://standards.ieee.org/develop/project/2302.html Link to NIST PWGFC Twiki http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/FederatedCloudPWGFC Link to the Intercloud Testbed (and materials) http://www.intercloudtestbed.org/ 21:56:55 b1airo: +1 21:57:23 My only challenge with IRC is presenting the framing slides... 21:57:45 Point to a google doc 21:57:45 khalil: I think federations will develop locally, as they have done, and perhaps it's worth defining how the interfaces used are characterised. I'm pretty sure there's work in this area that could be adapted. 21:58:41 Here is how to participate with P2302 - IEEE P2302 meeting (1:00 pm EDT/10:00AM PT) Connect via: join.me/ieeesa_robert.bohn 21:59:28 thanks for putting this session togther 21:59:55 should we discuss a continuation of this discussion? 21:59:56 We are out of time, alas. Thank you for coming 22:00:15 thanks 22:00:19 Thanks 22:00:21 agree on continuing 22:00:27 thanks... 22:00:32 me too 22:01:44 bye for now. talk to you later 22:01:50 TOSCA - that's what I was thinking of. You need something like that for describing federation 22:01:53 #endmeeting