<div dir="ltr">Hello there, Jimmy-<div><br></div><div>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. <span style="line-height:1.5">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.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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:</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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.</span></div><div><br></div><div>I hope this was helpful :)</div><div><br></div><div>Michael Krotscheck</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 23, 2016 at 12:16 PM Jimmy Mcarthur <<a href="mailto:jimmy@tipit.net" target="_blank">jimmy@tipit.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<span>Michael Krotscheck wrote:</span><br>
<blockquote type="cite">
<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 22,
2016 at 11:50 AM Jimmy Mcarthur <<a href="mailto:jimmy@tipit.net" target="_blank">jimmy@tipit.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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.<span style="line-height:1.5"> </span></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
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? </div></blockquote><div><br></div><div>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.</div></div></div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
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.</div><div bgcolor="#FFFFFF" text="#000000"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote"><div><br></div><div>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.<span style="line-height:1.5"> I'm sure that Neutron would be very happy to
address and shepherd any patches you'd be willing to provide.</span></div></div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
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. <br></div><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote"><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">In regards to understanding the IRC 'lingo', I
don't really know what that could refer to. Could you clarify?</span></div></div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
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. <br>
<br>
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 <span style="font-style:italic">how</span> 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.<br>
<br>
Cheers!<br>
Jimmy<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote"><div><br></div><div><span style="line-height:1.5">Michael Krotscheck</span> </div></div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>