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