Hi Blair Agree with you on a lot of that stuff, although on lifecycle management we certainly have a bunch of tooling in place to handle scenarios like initial creation of user environments ( basic network and router setup ), freezing resources for non-payment, offboarding of customers after account deletion etc. You are correct in the sense that we only get involved in lifecycle management if someone stops paying, although we've started doing some stuff around automatic IP address reclaiming from routers where we have customers sitting without any usage for extended periods.
Matt On 26 September 2016 at 09:14, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > Hi Matt, > > I think your dot points make sense. And yes, I was thinking about Science > Cloud overlap. I see Science Clouds as potentially sharing most or all of > these attributes (with the notable exception being charging in terms of end > users seeing a $ figure, showback and/or instance/cpu hour quotas might be > used instead). However, Science Clouds are probably not accessible to the > general public but require membership in, or sponsorship from, some > community in order to get an account. > > The specific problems you mention, rather than attributes of the > deployment models, are probably the best way to define this in a way that > let's folks determine their interest. The biggest difference seems to be > that commercial providers have no major interest in the lifecycle > management of customer infrastructure, whereas for Science Clouds turning > things off and cleaning up data is a policy issue that does not appear to > have resulted in any common tooling yet. > > Cheers, > Blair > > On 22 Sep 2016 6:35 PM, "Matt Jarvis" <matt.jar...@datacentred.co.uk> > wrote: > >> Hey Blair >> >> Now you've done it ! OK, I'll bite and have a go at categorising that a >> bit : >> >> 1. Multi-tenant - tenants need clear separation >> 2. Self service sign up - customers on board themselves >> 3. Some kind of charging model in place which requires resource accounting >> 4. API endpoints and possibly management applications presented outside >> of your own network >> >> Not sure that entirely works, but best I can come up with off the top of >> my head. For commercial public clouds we have some very specific problem >> spaces in common - handling credit cards and personal information, fraud >> prevention, commercial modelling for capacity planning etc. Is where you're >> going with this that some of the science clouds share some of the >> attributes above ? >> >> Matt >> >> On 22 September 2016 at 00:40, Blair Bethwaite <blair.bethwa...@gmail.com >> > wrote: >> >>> Hi Matt, >>> >>> At considerable risk of heading down a rabbit hole... how are you >>> defining "public" cloud for these purposes? >>> >>> Cheers, >>> Blair >>> >>> On 21 September 2016 at 18:14, Matt Jarvis < >>> matt.jar...@datacentred.co.uk> wrote: >>> >>>> Given there are quite a few public cloud operators in Europe now, is >>>> there any interest in a public cloud group meeting as part of the ops >>>> meetup in Barcelona ? I already know many of you, but I think it could be >>>> very useful to share our experiences with a wider group. >>>> >>>> DataCentred Limited registered in England and Wales no. 05611763 >>>> _______________________________________________ >>>> OpenStack-operators mailing list >>>> OpenStack-operators@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> ~Blairo >>> >> >> >> DataCentred Limited registered in England and Wales no. 05611763 > > -- DataCentred Limited registered in England and Wales no. 05611763
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators