Open Stack

Steve,

Comments inline

On 2/3/16, 3:08 PM, "Steve Gordon" <sgordon at redhat.com> wrote:

>----- Original Message -----
>> From: "Hongbin Lu" <hongbin.lu at huawei.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>><openstack-dev at lists.openstack.org>
>> 
>> I would vote for a quick fix + a blueprint.
>> 
>> BTW, I think it is a general consensus that we should move away from
>>Atomic
>> for various reasons (painful image building, lack of document, hard to
>>use,
>> etc.). We are working on fixing the CoreOS templates which could replace
>> Atomic in the future.
>> 
>> Best regards,
>> Hongbin
>
>Hi Hongbin,
>
>I had heard this previously in Tokyo and again when I was asking around
>about the image support on IRC last week, is there a list of the exact
>issues with image building etc. with regards to Atomic? When I was
>following up on this it seemed like the main issue is that the docs in
>the magnum repo are quite out of date (versus the upstream fedora atomic
>docs) both with regards to the content of the image and the process used
>to (re)build it - there didn't seem to be anything quantifiable that's
>wrong with the current Atomic images but perhaps I was asking the wrong
>folks. I was able to rebuild fairly trivially using the Fedora built
>artefacts [1][2].

Steve,

I hope you can forgive my directness and lack of diplomacy in this
message. :)

At least when I was heavily involved with Magnum, building atomic images
resulted in a situation in which the binaries built did not work properly.
 I begged on the irc channels for help and begged on the mailing list for
help for _ months _ on end and nobody listened.  It is almost as if nobody
is actually working on Atomic.  If there are people, they do not maintain
any kind of support footprint upstream to make Atomic a viable platform
for Magnum.

I taught Tango how to build the images, who wrote the instructions down in
the Magnum documentation.  That documentation ends up producing images
that randomly don't always work. The binaries return some weird system
call error, ebadlink I think but not sure.  Tango may remember.

Perhaps the rpm-ostree defect has been resolved now.  I have to be clear
that I was told "please wait 6 months for us to fix the build system and
bugs" while Atomic was our only distro implemented.  It was very
maddening.  I was so frustrated with Atomic, at the start of Mitaka I was
going to propose deprecating Atomic because of a complete lack of upstream
responsiveness.  I decided to let other folks make the call about what
they wanted to do with Atomic since I was myself unresponsive with the
Magnum upstream because of my full-time Kolla commitment.

I am pretty sure a bug was filed about this issue in the Red Hat bugzilla,
but I can't find it.

Personally if I was running the Atomic project, I'd containerize all of
the etcd/flannel/kubernetes and only leave docker in the base image.  Next
up I'd get the distro being produced in a CI pipeline with atleast some
basic dead chicken testing.  I am pretty sure this would fit Magnum's use
case well.  This would make interacting with the 6 month release cycle of
Fedora much more viable.  But alas I'm not running Atomic, and I don't
have the bandwidth to make a contribution here other then to say Atomic
needs more attention from it's upstream if it is to have any hope.

Warm regards,
-steve


>
>So are the exact requirements of Magnum w.r.t. the image and how they
>aren't currently met listed somewhere? If there are quantifiable issues
>then I can get them in front of the atomic folks to address them.
>
>Thanks,
>
>Steve
>
>[1] https://git.fedorahosted.org/git/spin-kickstarts.git
>[2] https://git.fedorahosted.org/git/fedora-atomic.git
>
>
>> From: Corey O'Brien [mailto:coreypobrien at gmail.com]
>> Sent: February-03-16 2:53 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Magnum] Bug 1541105 options
>> 
>> As long as configurations for 2.2 and 2.0 are compatible we shouldn't
>>have an
>> issue I wouldn't think. I just don't know enough about etcd deployment
>>to be
>> sure about that.
>> 
>> If we want to quickly improve the gate, I can patch the problematic
>>areas in
>> the templates and then we can make a blueprint for upgrading to Atomic
>>23.
>> 
>> Corey
>> 
>> On Wed, Feb 3, 2016 at 1:47 PM Vilobh Meshram
>> 
>><vilobhmeshram.openstack at gmail.com<mailto:vilobhmeshram.openstack at gmail.c
>>om>>
>> wrote:
>> Hi Corey,
>> 
>> This is slowing down our merge rate and needs to be fixed IMHO.
>> 
>> What risk are you talking about when using newer version of etcd ? Is it
>> documented somewhere for the team to have a look ?
>> 
>> -Vilobh
>> 
>> On Wed, Feb 3, 2016 at 8:11 AM, Corey O'Brien
>> <coreypobrien at gmail.com<mailto:coreypobrien at gmail.com>> wrote:
>> Hey team,
>> 
>> I've been looking into https://bugs.launchpad.net/magnum/+bug/1541105
>>which
>> covers a bug with etcdctl, and I wanted opinions on how best to fix it.
>> 
>> Should we update the image to include the latest version of etcd? Or,
>>should
>> we temporarily install the latest version as a part of notify-heat (see
>>bug
>> for patch)?
>> 
>> I'm personally in favor of updating the image, but there is presumably
>>some
>> small risk with using a newer version of etcd.
>> 
>> Thanks,
>> Corey O'Brien
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev