Open Stack

+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