Open Stack

Hi everyone,

Adding DefCore back into the distribution and added the tag ("interop")
used by the team working on this challenge so that they can see/address the
items below.  I have also added my own thoughts below.

On Mon, Sep 19, 2016 at 3:42 PM, Anne Gentle <annegentle at justwriteclick.com>
wrote:

> I'm in a similar situation here at Cisco because our Metapod/Metacloud
> product, which emphasizes stability and scalability, does not support LBaaS
> v1 nor autoscaling.
>
> I thought about simply writing another heat template to set up a
> standalone Load balancer on a VM, but the templates are so tied into having
> that LB resource it's not possible.
>
> The autoscaling portion is already abstracted away, so it's the load
> balancer API and resources that are the limiter.
>
> More embedded below.
>
> On Mon, Sep 19, 2016 at 1:00 PM, Stefano Maffulli <stefano at openstack.org>
> wrote:
>
>> [trimming down the cc list, writing to user-committee because I believe
>> this is more of a general question for the app-dev working group than it
>> is a defcore thing. Feel free to forward if you think it's appropriate.]
>>
>> On 09/15/2016 03:11 PM, Rochelle Grober wrote:
>> > "The interop challenge was started in July 2016 to create a set of
>> > common workloads/tests to be executed across multiple OpenStack
>> > distributions and/or cloud deployment models. The participants in
>> > this challenge will work together to prove once and for all that
>> > OpenStack-Powered clouds are interoperable."
>>
>> this project sounds really interesting. At DreamHost I gave it a
>> shot, starting from the simplest (for me) challenge: Ansible and lamp
>> stack.
>>
>> I immediately hit a major issue: the default customer of DreamHost cloud
>> will not have private networking enabled, so the playbook cannot
>> run as is. To support a cloud like DreamHost, it would require some
>> major changes.
>>
>> Finding out about this issue lead my thoughts down a rabbit hole: does
>> this effort even make sense? I don't have an answer...
>>
>> My line of thoughts starts with what looks like a great promise: "take
>> this ansible playbook and run it on any OpenStack cloud unchanged".
>> Great promise, makes for a great demo on a stage.
>>
>> But this promise fails very very quickly because different clouds always
>> have different behaviors. DreamHost Cloud runs vanilla OpenStack and
>> yet, this stuff doesn't work out of the box. Sure, we can add some logic
>> to the script to take into consideration the absence of a private
>> network but is it worth it?
>>
>> What value is there in writing a script that covers a very specific use
>> case (LAMP stack+Wordpress on 4 nodes) and needs to be adapted slightly
>> to every single openstack cloud in order to run? Is the time spent in
>> developing such universally valid playbook a good investment?
>>
>> Would it be more valuable for the providers of openstack clouds to have
>> a pool of playbooks that would serve as source of inspiration, something
>> that could be adapted quickly and consumed in downstream documentation?
>>
>>
> My gut says it's going to take a stake in the ground, which this team has
> done, to get the conversations going. I'm pretty sure there's already a
> pool of playbooks, and no, they don't work universally, nor are they easy
> to find and run. By trying to make a universal one we get to have this
> conversation, so I think there is value in attempting a set of playbooks
> with the ability to turn knobs as needed.
>

I agree, the ideal result would be to run these playbooks without
modification on multiple clouds but that probably isn't realistic.  The
team is encouraging people to modify the scripts (if/when needed) but to
document what needed to change so that we can eventually have a list of
topics that can be discussed and we can build next steps around.  I guess
the goal, in my opinion, for this initial iteration of the challenge would
be to run the same workload with the least amount of modifications as
possible and document areas that caused deviation.  This might also help
identify/define the "knobs" as Anne mentioned in her response.

>
>
>> Again, I don't have an answer. I am just noticing that because of
>> different cloud behaviors, DreamHost has no use of most of the
>> community-contributed efforts in the Apps Developers space. This makes
>> me wonder if we as a community are putting our efforts in the wrong
>> places or it's just DreamHost facing these issue.
>>
>
> It's not just you. For a talk in Barcelona, I'm working on a list of all
> that is difficult for writing generic ansible templates -- such as when you
> have a different username for the image itself -- is the user name fedora
> or cloud when running the ansible playbook?
>
> So we need to keep putting these efforts in. To me, I realize there still
> is gap is in education and documentation.
>
+1

> For example, what are my best practices running an ansible playbook on two
> different images in two different clouds with two different user names?
>

> Thanks,
> Anne
>
>
>>
>> Thoughts?
>> /stef
>>
>> _______________________________________________
>> User-committee mailing list
>> User-committee at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>>
>
>
>
> --
> Anne Gentle
> www.justwriteclick.com
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20160919/078f25c9/attachment-0001.html>