Open Stack

+1 :)

Fox, Kevin M wrote:
> +1
> ________________________________________
> From: Blair Bethwaite [blair.bethwaite at gmail.com]
> Sent: Wednesday, July 20, 2016 4:39 PM
> To: Christopher Aedo
> Cc: user-committee
> Subject: Re: [User-committee] [app] What is an App?
>
> +1
>
> On 28 June 2016 at 04:57, Christopher Aedo<doc at aedo.net>  wrote:
>> Pardon the top-post here but what I'm seeing in this exchange is a
>> significant disconnect and a great example of why we're continuing to
>> struggle to define what an application is in the context of OpenStack.
>> I heard Jimmy asking for a PaaS, and Michael responding with how to
>> use an OpenStack environment to do some PaaS-like things.
>>
>> OpenStack at it's heart is an infrastructure as a service - a way to
>> programatically provision resources (computers, network, storage).
>> Over time we've added lots of other projects on top that provide more
>> complicated services (load balancers, database services, etc.)  We've
>> also added some projects that provide a PaaS-like interface on top of
>> that infrastructure (murano, solum, maybe others?  Now with kubernetes
>> and some of the other container orchestration systems the lines are
>> getting more blurry.)
>>
>> To bring it back to what I think Jimmy was talking about though - the
>> things he'd like to achieve (scaling, automatically attaching shared
>> storage, etc) are all things you get out of the box with most PaaS
>> approaches (openshift, cloud foundry, etc.)  For developers,
>> abstracted access to those constructs plus an ability to package and
>> deploy (to share) your application are the things that matter.
>>
>> OpenStack doesn't provide those things in a consistent or
>> interoperable way.  If you're building your own cloud, you can
>> definitely choose which projects to bake in and maintain in order to
>> do this, but you can't count on that way being the same from cloud to
>> cloud.  I think Murano is about the only OpenStack-specific way to
>> handle these concerns *IF* we agree that this is what we mean when we
>> say "Application".  If there are other definitions of an application
>> we should focus on them and categorize them - I think it's the only
>> way we are going to get on the same page and start really reaching the
>> larger developer audience.
>>
>> -Christopher
>>
>>
>>
>>
>>
>> On Mon, Jun 27, 2016 at 7:47 AM, Michael Krotscheck
>> <krotscheck at gmail.com>  wrote:
>>> Hello there, Jimmy-
>>>
>>> It really sounds like what you are looking for is a traditional support
>>> channel. i.e. an entity whom you are 'paying' to advocate to a community on
>>> your behalf, often with developers. Since you're currently running on
>>> Rackspace, you are covered under the CLA under which those resources have
>>> been donated to the Foundation. I recommend you reach out to Thierry to get
>>> the contact information for your account representative. I'm certain that
>>> Rackspace would be more than happy to assist you in scaling your
>>> applications.
>>>
>>> That's the official "dude, we're not a support channel" response. Here's the
>>> "I'm also an engineer" response that actually solves the problem you've
>>> listed:
>>>
>>> Firstly, simulated SAN failover feature (multiattach volumes) has been a
>>> coordinated discussion between Nova, Neutron, and Cinder for several cycles
>>> now, and it's been the subject of a whole 45 minute session at the Austin
>>> summit. Work is currently ongoing, but there are too many moving parts that
>>> need to land by feature freeze - in short, it's unlikely to land in Newton.
>>>  From personal experience, Ocata's also a tossup; and that assumes the
>>> feature lands bug free with no performance implications.
>>>
>>> With that in mind, I personally would advise you against relying on a
>>> cloud-specific feature like this, because it's actually a limiting factor -
>>> you'd be restricted to a single cloud/region/zone for your DB clustering,
>>> plus it's a version and vendor lock-in; you'd only be able to replicate in
>>> on one zone on one particular OpenStack version.
>>>
>>> There's plenty of alternatives. Distributed filesystems are one
>>> (HDFS/Gluster), or the lower-level Distributed Replicated Block Device
>>> (drbd). Also, most databases have their own replication logic included, and
>>> while most of them were not built with cloud operations in mind, they
>>> usually don't require much tweaking to make them perform reliably.
>>>
>>> I hope this was helpful :)
>>>
>>> Michael Krotscheck
>>>
>>>
>>> On Thu, Jun 23, 2016 at 12:16 PM Jimmy Mcarthur<jimmy at tipit.net>  wrote:
>>>>
>>>> Michael Krotscheck wrote:
>>>>
>>>> On Wed, Jun 22, 2016 at 11:50 AM Jimmy Mcarthur<jimmy at tipit.net>  wrote:
>>>>> An example: you can't currently assign block storage to more than one VM
>>>>> at a time. This is something that I think is just sitting around as a patch
>>>>> to be approve in Neutron, but it's causing major problems for us as web
>>>>> application developers that are deploying on top of OpenStack. Basically, as
>>>>> a result of this and the lack of replication in Trove, we can't cluster.
>>>>>
>>>>>
>>>>> It's remarkably difficult to get integrated in IRC channels without
>>>>> knowing the lingo. Is there some suggestion from the user committee about
>>>>> where users like us could turn?
>>>> To address this specific issue: It sounds like you want to land a specific
>>>> feature in Neutron. The correct place to advocate for this is the weekly
>>>> neutron meeting. As someone who's recently landed a cross-project feature
>>>> (in 23 different projects), I can confidently say that every team is open to
>>>> - if occasionally grumpy about - unscheduled features that aren't on their
>>>> roadmap. It took me only a few questions, and quite a bit of humility, to be
>>>> given a primer on each teams' approval governance, approval process, and
>>>> roadmap feature selection.
>>>>
>>>> Maybe I wasn't clear about my role in OpenStack :) I'm not an OpenStack
>>>> developer. I'm a web and mobile application developer (more appropriately, a
>>>> project manager) that hosts our sites on OpenStack public cloud. I don't
>>>> have a patch to land in Neutron. I understand that it was already done and
>>>> is waiting for approval by that team.
>>>>
>>>>
>>>> OpenStack's governance empowers those who are willing to advocate for
>>>> themselves, as long as they are willing to back their requests with actual
>>>> code. I'm sure that Neutron would be very happy to address and shepherd any
>>>> patches you'd be willing to provide.
>>>>
>>>> Keep in mind that there is no place that I can currently advocate for my
>>>> team, which is why I'm raising the point :) I work for the Foundation
>>>> building web and mobile applications, but rely on OpenStack for
>>>> infrastructure. Specifically, we're running on the Rackspace cloud in the
>>>> same data center as Infra. The features I mention aren't within our skill
>>>> set to develop, but they're critical if OpenStack is to become a viable
>>>> option on which to host scalable web applications that need to share
>>>> data/resources.  Though I'm sure many could do it very ably, I don't expect
>>>> OpenStack developers to come and write PHP or javascript in order to use our
>>>> website. We're valid users of the software you all are doing such a great
>>>> job of building.
>>>>
>>>>
>>>> In regards to understanding the IRC 'lingo', I don't really know what that
>>>> could refer to. Could you clarify?
>>>>
>>>> Like any software product, there is common nomenclature that defines it.
>>>> Even reading the documentation can't possibly catch you up on the history of
>>>> the project and the people, especially since so much of it takes place in
>>>> IRC. If you're not out to become a full time OpenStack developer and simply
>>>> need something to work in a particular way, trying to integrate with that
>>>> project can be pretty tough.
>>>>
>>>> I certainly don't mean to start a great debate, but I would encourage you
>>>> to think of app developers that don't use OpenStack SDKs as well as those
>>>> that do. If we're not providing a place for those users to deliver feedback
>>>> and communicate, we could be missing out on lots of opportunities to study
>>>> how they are using the software. Companies (both large and small) don't
>>>> always have the resources to contribute back to OpenStack anymore than every
>>>> user of Ubuntu can contribute upstream.  There is a whole world of
>>>> application developers out there that have no need/ability to be involved at
>>>> that level.
>>>>
>>>> Cheers!
>>>> Jimmy
>>>>
>>>>
>>>> Michael Krotscheck
>>>>
>>>>
>>> _______________________________________________
>>> User-committee mailing list
>>> User-committee at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>>>
>> _______________________________________________
>> User-committee mailing list
>> User-committee at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>
>
> --
> Cheers,
> ~Blairo
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20160720/2dffc878/attachment-0001.html>