16:56:05 #startmeeting mercadorproject 16:56:06 Meeting started Fri Jun 26 16:56:05 2015 UTC and is due to finish in 60 minutes. The chair is geoffarnold. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:56:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:56:10 The meeting name has been set to 'mercadorproject' 16:56:15 \o 16:56:26 Greetings 16:56:40 Let's give it a few minutes 16:56:58 sure 16:58:45 #topic welcome 16:58:55 welcome 16:59:33 hi marekd :) 16:59:35 what's on the menu? 16:59:43 So this is the first meeting of the Mercador stackforge project. If you're not interested in OpenStack service federation, you're in the wrong place 17:01:06 I went ahead and set up the project with zero content (except for the wiki page) because I wanted to start with a level field; everyone gets a chance to review and contribute to everything 17:02:10 The primary goal of this first meeting is to identify participants and roles 17:02:29 is there anythong to review already? 17:02:39 hi all 17:03:18 The starting point is the material in the wiki page: https://wiki.openstack.org/wiki/Mercador 17:03:27 hello 17:03:44 #topic introductions 17:04:27 I'd like it if everybody could introduce themselves: name, affiliation, interest level 17:05:04 Geoff Arnold, Cisco Intercloud Services, initiator of this effort 17:05:48 Marek Denis, CERN, has been working on OS-FEDERATION since October 2013 17:05:55 David C, Cisco Intercloud Services, co-initiator, dev 17:06:26 Raildo Mascena, Universidade Federal de Campina Grande, core team from mercador, working with hierarchical multitenancy and reseller on keystone 17:06:27 Rodrigo Duarte, Universidade Federal de Campina Grande, working with federation since the Juno release 17:06:43 Arvind Tiwari Cisco Intercloud Services 17:06:59 Guang Yee, HP Helion, I help solve problems :) 17:07:00 Iury Gregory, Universidade Federal de Campina Grande, working with federation since the Kilo release 17:07:10 gyee, best definition 17:07:14 * morganfainberg is a lurker and hides in the corner. 17:07:28 Seth Mason, Cisco Intercloud Services 17:07:33 Orran Krieger of Massachusetts Open Cloud would be here, but had an urgent commitment 17:07:36 Ganesh, Cisco India, interested in OpenStack development 17:08:16 Any more? 17:09:05 #topic housekeeping 17:10:03 I'd like to propose that we use Trello to track the various subtasks for this project: https://trello.com/b/6tlmk3z4/mercador-stackforge-project 17:10:39 It's a public Trello board, but I don't think we need to worry about vandalism 17:11:51 I think all of the necessary links are in the wiki - repos, meetings, project 17:12:55 Any questions at this stage? 17:13:50 no =) 17:13:57 ;-0 17:14:00 OK 17:14:52 The objective for the Liberty cycle is to implement a virtual region proof-of-concept in order to demonstrate it at Tokyo 17:16:05 ok 17:16:05 There are a couple of challenges in achieving this 17:16:52 First is functional: successfully automating the [re]configuration of Keystone and Horizon when we add (and remove) a virtual region 17:17:44 Second is infra-related: how do we create a testing context for this system. It requires two independent OpenStack instances 17:17:51 Devstack won't cut it 17:18:27 The rest should be fairly straightforward: 17:18:51 Data modeling, service implementation (using Pecan), CLI 17:19:01 API 17:19:06 Yup 17:19:18 Three APIs: 17:19:27 CLI-to-publisher 17:19:34 CLI-to-subscriber 17:19:44 subscriber-to-publisher 17:20:17 trust management 17:20:35 marekd: ++ 17:20:43 Agreed. Feels like a very distinct role 17:20:55 what transport layer (protocol) are you going to use? 17:21:23 https, I assume 17:21:38 i was rather asking about protocols like OpenID connect 17:21:44 so, identity management. 17:22:02 when sub with pub communicate, you are going to rely on some sort of service accounts? 17:22:03 Oh I see - I assume we'd build on the Keystone-to-Keystone 17:22:33 so sub would still rely on keystone as identity master 17:22:38 Right. Publisher sets up virtual regions, creates an admin account for each 17:22:44 yes 17:24:04 One fairly urgent issue is to identify dependencies on Keystone (and Horizon) work 17:24:28 For example, the whole question of namespaces for HMT 17:25:06 Since the whole "virtual region" model builds on HMT 17:25:25 can it be shared? 17:25:32 geoffarnold, the Reseller effort should be merged in Liberty 17:25:42 among identtities coming different clouds ? 17:25:53 also, with namespacing concepts like service providers to projects/domains 17:26:18 rodrigods: that was supposed to be endpoint filtering? 17:26:24 I don't think a single virtual region can be shared, since when it's subscribed it uses the subscriber's IDM 17:26:29 marekd, it is supposed :) 17:26:30 * stevemar sneaks in late 17:26:35 what's the topology like? cloud -> domains -> subdomains -> projects -> subprojects? 17:26:49 s/cloud/region/ 17:27:10 i believe a virtual region can be considered as a lease on resources 17:27:13 Pictures in the Wiki (I hate embedded images in IRC) 17:27:33 you could potentially sublease, but it may not be shared 17:28:00 so it;s not for creating a one chunk of resources spanned across multiple clouds, but also for collaborative use 17:28:22 or wait, maybe it is... 17:28:49 well, the lease would span multiple disparate clouds 17:29:12 It's about gluing a chunk of resources from one cloud into another, and representing that as a region (so that things like Horizon multiregion, Heat, etc. work across the regions) 17:29:23 so you would create a federated homogenous cloud from disparate clouds through requesting multiple leases 17:29:40 N number of v regions for my new federated cloud 17:29:44 my thoughts however 17:30:15 alright, from the user perspective user would need to keep token-per-cloud or just local token and mercador sub i suppose would somehow map it ? 17:30:27 so we have service provider concept in keystone catalog today 17:30:57 otherwise i think the burden is put on keystoneclient to be smart enough to switch between regions and know which token to use which region. 17:31:19 well I think the keystone-to-keystone would take care of that complexity 17:31:22 so what's the difference between "service provider" and "region" because they are totally different concepts 17:31:41 gyee, service provider is a remote trusted cloud 17:31:42 davidjc: k2k is for authenticating, not caring of that complexity.... 17:31:52 Keystoneclient needs to know where it is in the HMT tree, and which IDM applies 17:32:22 which was in the original domain stuff, IIRC 17:32:44 geoffarnold: is the mercador by design a tool for setting up vregions or also takes care of neat abstraction of having multiple separate clouds? 17:33:24 I'm not sure what the difference is 17:33:36 A cloud is a collection of regions 17:33:39 so I believe the use cases presented on the wiki are uni-directional 17:33:50 you would simply make them bi-directional 17:34:13 Let's not over-complicate 17:34:19 ++ 17:34:39 ++ for not overloading "region" 17:34:48 Today, all of the regions in a cloud (as seen through Horizon/Keystone) are "local" 17:34:48 ++ 17:34:54 yes 17:34:55 i was simply mentioning, the model is recursive 17:35:03 in the sense of under a single admin 17:35:30 ++ 17:36:17 Mercador simply introduces the concept of a virtual region, provided by one service provider (cloud), and integrated into a second cloud 17:36:52 ok, so to me the burden of switching between the clouds is still within keystoneclient competences. 17:37:19 what do you mean by "switching between the clouds"? 17:37:41 marekd, correct, its essentially a set of orchestrations underneath 17:37:45 i will need to choose : i now want to use cloud "A" 17:37:50 and openstack server list 17:38:02 will list VMs from my project, from cloud B 17:38:12 now i say "I want to use vregion at cloud B" 17:38:26 and openstack server list will give me the list of my VMs at cloud B 17:38:41 Our assumption is that a user interacts with a CSP (via Horizon/Keystone) and sees multiple regions in the cloud 17:38:49 it's not that typing: openstack server list will print me all VMs across all federated clouds. 17:39:20 The user doesn't know or care whether region A is local to the CSP or a federated virtual region 17:39:39 ok 17:39:55 marekd, its more like a single facade, pulling resources from all the clouds, and do the switching underneath 17:40:12 mercador is going to create a meta-cloud 17:40:17 gyee: where? 17:40:23 shaleh: what is metacloud ? 17:40:31 One of the goals (and a strong requirement from my product folks) is that the user experience doesn't change 17:40:32 hahaha 17:40:42 cisco owns metacloud now 17:40:48 gyee: yeah 17:40:49 sigh 17:40:59 I'm supposed to say something about Cisco trademarks, I think ;-) 17:41:01 * shaleh doesn't speak corp very well :-) 17:41:10 we are creating mapping of os resources that represent the lease 17:41:18 a logic representation 17:42:06 One of the tasks in the data modeling is to come up with "region metadata" 17:42:43 real region => logical model of the regions lease of cloud provider A, leased by B 17:43:09 So a future UX extension is "tell me which region supports service X" or "is located in Germany" (data sovereignty) 17:43:13 so you want to change region model in Keystone? 17:43:19 No 17:43:25 Layer on top of it 17:43:35 ok 17:43:54 more freedom then :P 17:44:03 Ideally Keystone and Horizon don't change (same UX) 17:44:04 davidjc, I agree, it has to be seamless for end users, like creating my own playlist in spotify or something 17:44:08 client take care of the rest 17:44:45 Today if you log in to Horizon and see five regions, how do you know which one to use? 17:44:59 It's established via out-of-band policy 17:45:22 Nothing in OpenStack captures that 17:45:57 #topic next steps 17:45:59 no, we need to figure out a way to aggregate them 17:46:11 OK, let's talk next steps 17:46:32 I'd hoped that the use cases in the wiki were unambiguous, but :-( 17:47:04 geoffarnold: the use cases are good. I think what we need is a little more meat. They are very high level. 17:47:20 I need to identify core members and update the project info 17:47:42 How are you going to do this? 17:48:00 Depends on how many volunteers I get ;-) 17:48:21 geoffarnold, shaleh also from HP Helion and he would love to contribute, so I heard :) 17:48:24 This is the first project I've kicked off 17:48:38 geoffarnold: understood. 17:48:41 geoffarnold, are you the PTL as well? 17:48:52 rodrigods, ++ 17:49:12 Yes until the get a quorum and someone votes me off 17:49:17 we get 17:49:59 geoffarnold, heh 17:50:54 There's a dedicated IRC channel, #openstack-mercador which I monitor 17:51:51 Let's post volunteer info there - because I know there are people who aren't here who want to participate 17:52:06 geoffarnold, ++ 17:52:09 Deadline next Wednesday 17:52:11 geoffarnold, ++ 17:52:17 i'd be willing to review, not sure if i have the time to code :( 17:52:23 is writing code requirement? 17:52:27 geoffarnold, ++ of course :) 17:52:30 Review is most important 17:53:01 I can take a look at some code too! 17:53:01 geoffarnold, for reviews, I can absolute help 17:53:07 marekd, ++ 17:53:23 for code and reviews i think i can help 17:53:31 i can help with the hmt and reseller parte 17:53:31 I can help motivate people 17:53:37 I'm particularly interested in people who've wrestled with the testing workflows 17:53:39 part* :) 17:53:44 gyee: with a stick or carrot? 17:53:51 stevemar: with beer and wine 17:53:53 stevemar, it depends 17:54:03 t-shirts are the normal currency 17:54:08 marekd: knows how to motivate! 17:54:12 geoffarnold, lol 17:54:16 lol 17:54:25 haha 17:54:26 stevemar: that's my fuel! 17:54:36 t-shirts area a good idea =P 17:54:45 missing the craft beers from vancouver 17:54:45 are* 17:54:52 * gyee is on the phone with the market people 17:54:58 marketing 17:55:04 #action all - post participation intention to #OpenStack-mercador 17:55:05 already orginising beer 17:55:39 geoffarnold: so, what exactly does it mean? 17:55:41 And please post questions about gaps in the user stories 17:55:56 Mercador? Portuguese for "merchant" 17:56:15 our native language! (cc raildo iurygregory ) 17:56:21 yes =D 17:56:25 It's hard finding a name that doesn't conflict in all the repos, PyPi, etc. 17:56:25 geoffarnold: no,no, post participation intention...am i supposed to add myself (sb else) to some list, or write an e-mail? 17:56:45 marekd, ++ 17:56:50 sounds good see some in portuguese on openstack :) 17:57:00 marekd, please send the application along with the fees directly to me 17:57:08 Email to me - geoff@geoffarnold.com - or post on IRC #OpenStack-mercador 17:57:12 geoffarnold: the other likelt candidate is some variation on broker or agent which is highly over subscribed 17:57:30 OK, thanks all - we're out of time 17:57:38 #endmeeting