<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">+1 :)<br>
<br>
<span>Fox, Kevin M wrote:</span><br>
<blockquote
cite="mid:1A3C52DFCD06494D8528644858247BF01B9A7201@EX10MBOX03.pnnl.gov"
type="cite">
<pre wrap="">+1
________________________________________
From: Blair Bethwaite [<a class="moz-txt-link-abbreviated" href="mailto:blair.bethwaite@gmail.com">blair.bethwaite@gmail.com</a>]
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 <a class="moz-txt-link-rfc2396E" href="mailto:doc@aedo.net"><doc@aedo.net></a> wrote:
</pre>
<blockquote type="cite"><pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:krotscheck@gmail.com"><krotscheck@gmail.com></a> wrote:
</pre><blockquote type="cite"><pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:jimmy@tipit.net"><jimmy@tipit.net></a> wrote:
</pre><blockquote type="cite"><pre wrap="">
Michael Krotscheck wrote:
On Wed, Jun 22, 2016 at 11:50 AM Jimmy Mcarthur <a class="moz-txt-link-rfc2396E" href="mailto:jimmy@tipit.net"><jimmy@tipit.net></a> wrote:
</pre><blockquote type="cite"><pre wrap="">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?
</pre></blockquote><pre wrap="">
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
</pre></blockquote><pre wrap="">_______________________________________________
User-committee mailing list
<a class="moz-txt-link-abbreviated" href="mailto:User-committee@lists.openstack.org">User-committee@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a>
</pre></blockquote><pre wrap="">_______________________________________________
User-committee mailing list
<a class="moz-txt-link-abbreviated" href="mailto:User-committee@lists.openstack.org">User-committee@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a>
</pre></blockquote>
<pre wrap=""><!---->
--
Cheers,
~Blairo
_______________________________________________
User-committee mailing list
<a class="moz-txt-link-abbreviated" href="mailto:User-committee@lists.openstack.org">User-committee@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a>
_______________________________________________
User-committee mailing list
<a class="moz-txt-link-abbreviated" href="mailto:User-committee@lists.openstack.org">User-committee@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee</a>
</pre>
</blockquote>
<br>
</body></html>