+1
I'm against this on a theoretical basis as I don't think backporting
features/architectural changes is good practice for a stable branch.
People will say this will increase stability (no longer lose namespaces
on container restart), in reality the chances are it will decrease
stability on the branch at least for some time after it merges due to
the inherent nature of new features, combined with our limited ability
to verify new changes in the gate.
So far the evidence for needing to do this is anecdotal at best. While I
don't doubt some operators will complain about having to docker exec to
work with namespaces, it doesn't strike me as critical enough to shift
effort away from the Mitaka release.
All that being said if other cores strongly agree with the change and
commit to seeing it through, I trust them enough to make it work. Which
is why I'm +1.
On 21/02/16 16:18, Michał Jastrzębski wrote:
So for thin containers, as opposed to data containers, there is no
migration script needed whatsoever. All it takes is to tear down
neutron-agents and start thin containers.
On 21 February 2016 at 06:47, Jeffrey Zhang <zhang.lei....@gmail.com> wrote:
I like the thin container idea, and I am +1 too. But the only concern is
that we MUST provide a robust migrate script( or Ansible role task) to do
the convert stuff. Doesn't we have enough time for this?
On Sun, Feb 21, 2016 at 3:44 PM, Michal Rostecki <mroste...@mirantis.com>
wrote:
On 02/20/2016 05:39 PM, Steven Dake (stdake) wrote:
Sam,
I seem to recall Paul was not in favor, so there was not a majority of
cores there. There were 6 core reviewers at the midcycle, and if you
only count kolla-core (which at this time I do for policy changes) that
means we had a vote of 5. We have 11 core reviewers, so we need a vote
of 6+ for simple majority. I was also sort of –1 because it is an
exception, but I do agree the value is warranted. I believe I expressed
at the midcycle that I was –1 to the idea, atleast until the broader
core review team voted. If I wasn't clear on that, I apologize.
I'll roll with the community on this one unless I have to tie break –
then groan :)
That is why a decision was made by the group to take this to the mailing
list.
Regards
-steve
From: Sam Yaple <sam...@yaple.net <mailto:sam...@yaple.net>>
Reply-To: "s...@yaple.net <mailto:s...@yaple.net>" <s...@yaple.net
<mailto:s...@yaple.net>>, "OpenStack Development Mailing List (not for
usage questions)" <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, February 20, 2016 at 9:32 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote] port neutron thin containers
to stable/liberty
I was under the impression we did have a majority of cores in favor
of the idea at the midcycle. But if this is a vote-vote, then I am a
very strong +1 as well. This is something operators will absolutely
want and and need.
Sam Yaple
On Sat, Feb 20, 2016 at 4:27 PM, Michał Jastrzębski
<inc...@gmail.com <mailto:inc...@gmail.com>> wrote:
Strong +1 from me. This have multiple benefits:
Easier (aka possible) debugging of networking in running envs
(not
having tools like tcpdump at your disposal is a pain) - granted,
there
are ways to get this working without thin containers but require
fair
amount of docker knowledge.
Docker daemon restart will not break routers - currently with
docker
restart container with namespace dies and we lose our routers
(they
will migrate using HA, but well, still a networking downtime).
This
will no longer be the case so...
Upgrades with no vm downtime whatsoever depends on this one.
If we could deploy liberty code with all these nice stuff, I'd be
happier person;)
Cheers,
Michal
On 20 February 2016 at 07:40, Steven Dake (stdake)
<std...@cisco.com <mailto:std...@cisco.com>> wrote:
> Just clarifying, this is not a "revote" - there were not enough
core
> reviewers in favor of this idea at the Kolla midcycle, so we
need to have a
> vote on the mailing list to sort out this policy decision of
managing
> stable/liberty.
>
> Regards,
> -steve
>
>
> From: Steven Dake <std...@cisco.com <mailto:std...@cisco.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
> <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
> Date: Saturday, February 20, 2016 at 6:28 AM
> To: "OpenStack Development Mailing List (not for usage
questions)"
> <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] [kolla][vote] port neutron thin
containers to
> stable/liberty
>
> Folks,
>
> There were not enough core reviewers to pass a majority
approval of the
> neutron thin container backport idea, so we separated it out
from fixing
> stable/liberty itself.
>
> I am going to keep voting open for *2* weeks this time. The
reason for the
> two weeks is I would like a week of discussion before people
just blindly
> vote ;)
>
> Voting begins now and concludes March 4th. Since this is a
policy decision,
> no veto votes are permitted, just a +1 and a -1. Abstaining
is the same as
> voting –1.
>
I'm +1, but under condition that we will provide some script to migrate
from supervisord-container to thin-containers (even if such a script will
bring risk of downtime of the cloud).
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Jeffrey Zhang
Blog: http://xcodest.me
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
