14:07:59 #startmeeting publiccloud-wg 14:07:59 Meeting started Wed Jul 19 14:07:59 2017 UTC and is due to finish in 60 minutes. The chair is seanhandley. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:08:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:08:02 The meeting name has been set to 'publiccloud_wg' 14:08:16 Everyone please check out the Etherpad 14:08:17 #link https://etherpad.openstack.org/p/publiccloud-wg 14:08:25 Add your details to the attendees section 14:10:12 Ok, let's start by reviewing last meeting's action points 14:10:21 #topic Review last meeting's action points 14:10:44 So, it looks like Howard isn't here today 14:11:19 So I'll talk to him about a) and b) offline and we'll follow up next time 14:11:22 looks so 14:11:37 (I haven't written any WG material with him yet) 14:11:55 so onto c) - did you get to edit the wiki yankcrime ? 14:11:56 update...know he has created a WG meetup...will see if I find the link... 14:12:12 oh great tobberydberg - please share it +1 14:12:30 my update is a short one as i can only offer an apology for not yet putting together the updates for the wiki 14:12:40 so can we just carry that action please 14:12:45 ok 14:13:21 #link https://www.meetup.com/OpenStack-Public-Cloud-WG-Meetup-Copenhagen/ 14:13:27 Regarding d) I have discussed the OpenStack Passport some more with Flanders from the OpenStack Foundation 14:13:29 aha thanks! 14:13:40 I have a rough prototype here in Ruby: https://github.com/seanhandley/passport 14:13:48 the README file explains loosely how it works 14:13:48 ...thats on the wiki as well... 14:14:02 this is by no means finalised 14:14:16 and I need to put the details into a spec on openstack.org before next meeting 14:14:28 #action Sean to make a spec for the OpenStack passport 14:14:35 +1 14:14:57 #action Nick to update the wiki with features and more info on how to get involved in the WG 14:15:21 ta 14:15:29 Does anyone have any thoughts/questions re: the prototype ? 14:15:39 It's literally me building the simplest API I could think of 14:16:32 Also, does anyone want a recap on what the OpenStack Passport scheme is and how it's loosely going to work? 14:16:44 seanhandley: it could be interested to have a schema to show the exchanges between this tool and the cloud providers 14:17:08 seanhandley: probably worth a quick recap and what your discussion with flanders concluded with 14:17:16 pilgrimstack: Like a JSON Schema ? 14:17:33 nop, picture 14:17:38 i was not aware of it being codified, i believed it to be a document, "passport" style document, that was printed and handed out 14:17:52 Oh I see pilgrimstack - yes a diagram is a must 14:18:02 mrhillsman: Thats one setup of it as well 14:18:04 #action Sean to create a diagram of flow for the passport service 14:18:15 mrhillsman: It is both :) 14:18:20 I'll recap! 14:18:24 ++ 14:18:28 not what I imagined, but that kind of basic api would actually be quite easy for us to tie into our existing billing flow oddly enough. 14:18:31 But, with central part to manage all "codes" 14:19:27 I think that technical part is relative easy but how about legal and 'anty-abuse' side? 14:19:36 OpenStack Passport recap: It's a credit scheme for public cloud providers whereby people will be handed out codes that translate to a certain dollar value of credit. So they'll sign up to your cloud, you'll receive their unique token, then you'll validate it against OpenStack's central service. 14:19:46 yeah, it needs a couple of extra layers of security 14:19:48 #link A rough outline of how the flow works https://gist.githubusercontent.com/seanhandley/45abb024511c79ebea25c195652c0d5d/raw/0e21f47651fb38cd43c4fbe2933395a43a0d48e3/gistfile1.txt 14:20:29 I'm thinking OpenStack.org mints the passport tokens and then validates them - then it's down to us as public cloud providers to mark a code as "expired" 14:20:58 then we can do whatever internal procedures need to happen in our companies/codebases to make sure the user is discounted the correct amount from their next usage bill 14:21:13 or if your cloud works on topup credit it's even simpler I guess 14:21:33 on signup, or topup, add credit 14:21:35 I like it 14:21:50 and yeah, at least for us, easy to integrate 14:22:24 My priority is to keep it as simple as humanly possible 14:22:43 easy for us as well 14:22:57 the tokens can just be securely random strings - there are good libs for generating those 14:23:27 the other side of this is the admin interface where OpenStack.org gets to create more tokens 14:23:46 one token will be usable on many providers ? 14:23:51 yes pilgrimstack 14:23:51 i think this might be a little bit overkill ? 14:24:15 the value of the scheme is that you can be given a card at a conference that lets you try out anyone's cloud, basically for free 14:24:15 in the same time ? 14:24:22 seanhandley: until your total credit runs out, or how exactly? 14:24:29 if user could just use a SSO to login to an OpenStack public cloud via OpenStack ID 14:24:34 Well, this is open for discussion actually 14:24:49 and then they could just use what ever promo scheme that cloud offers 14:25:00 :) thinking out loud 14:25:00 I'm due to have a meeting with Mark Collier to discuss it once he gets a window in his schedule 14:25:24 I'm pro that one token is valid for $xx at ONE cloud, then invalid...but could be different kinds as well 14:25:34 zhipeng: Not sure I understand - wouldn't all participating clouds need to change their auth to work with the OAuth part for that to work? 14:25:44 no 14:25:44 one time use, on cloud of your choice is probably easiest 14:25:47 zhipeng: i think it'd be more problematic to get willing cloud operators to permit logins via their openstack id than it would be to build this service 14:25:49 tobberydberg: Yes, that's an important decision we need to make 14:25:49 no 14:26:47 Right 14:26:58 Point 2 in the Etherpad is to discuss this in depth 14:27:04 so let's do that in just a second 14:27:23 we should avoid design a new auth api , that was my thinking in general 14:27:27 point 1) e. is done, our group is proposed to the user committee, so that's awesome 14:27:48 point 1) f. We submitted three CFPs for the Sydney summit 14:27:59 One is a presentation about the WG 14:28:06 the others are fishbowl forum sessions 14:28:18 one is for the passport service 14:28:40 the other is for the missing features list, to recap and get more ideas, and discuss in more depth 14:28:46 a continuation of Boston, basically 14:29:01 Lets hope to get those three accepted! 14:29:08 Fingers crossed :) 14:29:12 Ok, back to the passport stuff 14:29:21 #topic OpenStack Passport Service 14:29:44 I think it'd be worth doing a vote regarding how each token is redeemed i.e. whole amount or partial amounts 14:29:53 for me the easyest way is to simplify the interactions between openstack.org and the providers. for that, the foundation should deal vouchers and a list of providers. Then the providers should be able to manage the uniqness of a voucher on their own side 14:30:02 the case for partial amounts is that one OpenStack Passport token can be cashed in at multiple clouds 14:30:12 the case for full amounts is that it's simpler to implement 14:30:16 maybe each token has sub tokens? 14:30:19 +1 pilgrimstack 14:30:53 and a user can use as many tokens per cloud as they want, or try lots of clouds. 14:31:03 with that, the providers could manage the amount of the voucher, the expiration date... 14:31:25 btw on point 1.a I've created the meetup group for the Nordic one :) 14:31:43 thanks Howard :) 14:31:51 I could later add sean and tobias as co-organizer :) 14:32:12 shit...have to leave here... Just leaving a sentens here before I run... I believe that the most important thing to discuss is basics (what you are doing now) and what is bare minimum for a first version to work in a simple form to the Sydney summit =) 14:32:13 We'll circle back to the WG material before next meeting 14:32:16 #action Howard and Sean to begin writing up some public cloud WG material ahead of the Sydney Summit 14:32:31 also, seanhandley, you should consider making the app in python ;) 14:32:42 thxx sean 14:32:47 adriant: That's the plan! 14:33:07 I wanted a throw-away prototype just to get a feel for how it could work 14:33:15 Before then, though, spec 14:33:25 fair enough :) 14:33:50 I tend to agree with Tobias on keeping it to bare minimum for first version 14:34:17 but perhaps the OpenStack Foundation could reduce the amounts and let people have 2 or 3 passports? 14:34:27 then each passport is redeemed in full with the chosen public cloud 14:34:48 allowing partial redemption is nice in the long run but it does complicate the app 14:35:25 zhipeng: Back to your point about not writing a new service. I'm not sure how else we could make a scheme like this work... 14:36:12 i thought the original proposal was to treat the passport just as a marketing prmotional plan 14:36:20 that users see an overall concept of OpenStack Cloud Open Passport 14:36:37 and each cloud provider have the right to have their own promo scheme setup ? 14:37:02 I mean my understanding was we don't need to actually have a new "Passport token" 14:37:17 So how would a user get their free credits? 14:37:21 just use whatever exists now, just put a spin from MKT point of view 14:37:36 just as any user could get their credits now from OVH 14:37:42 or citynetworks 14:37:44 what do you think about the "KISS way" in the etherpad ? 14:38:19 it is good for a long term goal 14:38:29 i guess the foundation wants to encourage users to make use of openstack-based public clouds, but without blessing any one in particular 14:38:36 zhipeng: while I know most cloud providers have their own credit schemes, having a unified one like this may also prove interesting, and promote more to the user that openstack clouds are 'mostly' like secondary regions. 14:38:40 but I don't think foundation got the resource and motive to do that, and align with so many public clouds 14:38:43 yes 14:38:46 so with this they can just say "here's a token that'll get you free credit, you go ahead and pick one" 14:38:47 Yes, the Foundation needs to remain impartial 14:39:01 versus them handing out specific codes for ovh, citycloud, etc. 14:39:07 and having them mint the tokens makes it simpler 14:39:09 this would mean users get the SAME credit, everywhere. 14:39:23 because they can print the unique token and the dollar value onto the passport card that gets handed out to the users 14:39:28 Yes adriant 14:39:29 it's a marketing exercise for 'openstack' rather than OVH or such 14:39:34 yup 14:39:45 and we have to do a currency translation from $100 into whatever currency we like to bill 14:40:04 it benefits openstack as a whole rather than the user picking the cloud with the fanciest looking care :P 14:40:04 that's a totally arbitrary amount of credit btw - it's open for discussion :) 14:40:17 s/care/card 14:40:27 i think folks might think this foundation tighten their hands 14:40:27 seanhandley: it's impossible to speack about money with evrery public cloud 14:40:56 A ‘passport’ implies to the user that they can move between providers with their credit. Though I know from my side, the easiest thing for us to implement would be to associate a validated token with a £££ service credit. 14:41:20 if already very hard to do it internaly at OVH with concurrency and different prices of ressources in dofferent country 14:41:20 anyways my suggestions is to have the KISS thing as a Queen target maybe 14:41:58 but if we shoot for Sydney summit, we need a more short term approach 14:42:06 Yes 14:42:19 yeah rmart04, that needs clearing up 14:42:23 Basically, I want to see a working prototype that we can announce at Sydney 14:42:33 the foundation would love to get this in a keynote 14:42:38 i still do not understand why a simple coupon code would not work if the provider is managing all the details 14:42:53 I think the passport should be more like "up to X CPU, Y Ram and Z GB for 1 week free" 14:43:04 mrhillsman: because that coupon code shouldn't be a code for each cloud 14:43:12 and it's a great success story to tell for public cloud to show so many have cooperated on this universal scheme 14:43:23 it should be one (or a few) for each user, that can be redeemed once one any cloud 14:43:32 which means central store for codes 14:43:39 mrhillsman: Because the OpenStack Foundation is handing them out 14:43:41 and each cloud checking that store for the codes 14:43:57 if we all mint our own codes that only work on our own clouds then we have to send them to OpenStack 14:44:08 and we may as well all just be doing our own discount code schemes 14:44:13 rather than each cloud giving a code per bundle, and then the user getting 10+ codes 14:44:16 the prices are so different between providers, for $100 on some cloud you can run just one instance for 2 weeks, on other provider you can run it for 6 months 14:44:23 when David floated the idea 14:44:26 I appreciate the appeal of it for internal simplicity but it nullifies the spirit of the scheme 14:44:41 it was just a Azure/AWS MKT scheme to have a coupon card 14:44:45 :) 14:44:57 pilgrimstack: maybe that's part of the usefulness of the scheme, it lets the user pick which cloud works for them price wise 14:45:07 Ok 14:45:12 that's kind of the way i thought of it as well, i got a summit, i get a passport 14:45:22 I think everyone has their own take on this, which is great 14:45:29 maybe it is SYDPASSPORT code, which expires when Vancouver comes around 14:45:46 Rather than make a decision today 14:45:48 and new passports are handed out then 14:46:15 let's all consider the possibilities and write up how we see it working, including motiviations 14:46:16 mrhillsman: I love that, it's the ultra KISS way :D 14:46:17 i do understand the idea behind it being more robust 14:46:28 then we can discuss those candidate solutions next time with pros and cons 14:46:36 and maybe vote for something that works for us all 14:47:24 ++ 14:48:42 Right. If you have an idea for how it should work then add it to the Etherpad 14:48:51 OR maybe write up a Gist like I did: https://gist.github.com/seanhandley/45abb024511c79ebea25c195652c0d5d 14:49:15 Getting a passport with your OS summit ticket would be pretty awesome, having a unique token system in place means we can get metrics on how many were consumed etc… 14:49:30 rmart04: That's true :) 14:49:36 I' 14:50:04 hmm, might be privacy-related issues with sharing that kind of information though 14:50:04 I'll put my hand up for helping implement anything around this, I should be able to find time 14:50:07 could be a bit of a minefield tbh 14:50:20 mrhillsman: a single common code wouldn't work, no way of invalidating it 14:50:51 yankcrime, not if we only store collect anonymous data about number of codes claimed vs those given out and such 14:51:04 or number of codes claimed per cloud, etc 14:51:18 building that into the system shouldn't be too hard 14:51:20 adriant: probably, ianal - that's one for the foundation 14:51:28 #action Anyone with an opinion on how it should work at a high level, write up your ideas and we'll discuss our options next meeting 14:51:36 i guess given flanders has tabled it as a suggestion they're already cool with it 14:52:07 seanhandley +1 14:52:15 I need to have this meeting with Sparky tbh 14:52:17 YC - Agreed if they were distributed and assiciated with a specific OpenStack Summit passes, that could be tricky 14:52:19 I'll poke Flanders about it 14:52:34 then we should get a very clear picture of how the Foundation sees this all working 14:53:09 rmart04: I think that association isn't too useful. Keep it random, and don't store which pass got which code. 14:53:15 We're almost out of time - please do write on the Etherpad after the meeting though folks 14:53:26 not sure how extensive the invalidation would need to be, but if the individual providers are handling all that, they could just set that code to be valid until x date 14:53:59 #link https://docs.google.com/spreadsheets/d/10ID98gJTMd91hmQuKJDfdm6YtC1AjAbcf4QsgnqsPFI/edit#gid=0 14:54:03 but yeah, again, i understand the benefit of making it more robust 14:54:09 Thanks for adding your details rmart04 14:54:24 adriant: agreed, but would require integration with the summit pass printing stations… more apis! SH: np 14:54:29 I don't see catalyst on the spreadsheet yet adriant :) 14:55:18 mrhillsman: Are you associated with a public cloud provider ? 14:55:31 yep 14:55:31 seanhandley: adding us now :) 14:55:37 awesome 14:55:45 here with zhipeng repping huawei 14:56:03 :D 14:56:03 oh, and am a UC member 14:56:14 s/am/I am 14:56:17 If anyone wants to attend OpenStack Days UK in London (September) or OpenStack Days Nordic in Copenhagen (October) then we have a room reserved for the public cloud WG to discuss these things 14:56:35 so we can sit around a whiteboard and figure out the passport stuff 14:56:44 seanhandley should we have a CFP process for the meetup ? 14:56:54 I don't think so zhipeng 14:57:03 We have a medium room booked for a few hours 14:57:06 who is driving those osd? 14:57:08 casual then :) 14:57:19 so I think we do a fishbowl and talk through what's important to the group 14:57:41 cool 14:57:44 mrhillsman: DataCentred is organising the London one (so that's me and yankcrime, plus others) 14:57:47 mrhillsman: i'm one of the organisers for the UK one, and tobias from citycloud is helping nordics 14:58:05 You can talk to tobberydberg about Nordic :) 14:58:11 ok cool 14:58:13 yankcrime could you help setup the meetup group ? 14:58:40 zhipeng shoot me an email with whatever you need or talk to sean, i've got you a room that'll seat up to 30 for a couple of hours 14:58:48 We're about out of time today. Clearly we still have loads to talk about! 14:58:56 Don't forget the #openstack-publiccloud channel 14:59:02 we can discuss things in there any time 14:59:08 the scientific wg are doing something similar as well, might be worth tapping them up to see how formal / informal they're keeping it 14:59:15 and follow the same pattern 14:59:31 (for days uk anyway) 15:00:00 Thanks everyone for coming - really looking forward to seeing how things come together over the next few weeks! 15:00:03 #endmeeting