On 01/10/2018 07:40 AM, Lingxian Kong wrote:
> I submitted an issue in github[1] the other day but didn't get any
> response, try my luck to attract attention here in case someone else has
> the same problem or already has a solution I didn't know, or hopefully, I
> missed something.
>
This is
Hi,
I'd like to announce that I'm leaving the Kolla core team and I will not
work on this project anymore (at least in the near future). I'm fully
focusing on working in Kubernetes upstream directly. That said, I want
to thank you for working together!
Cheers,
Michal
OK, looks like we have consensus on implementing that in the main kolla
repo.
Thanks,
Michal
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
+1
__
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
Hi,
Currently we have nice guide about setting up AIO k8s environment in
review. But at the same time I'm thinking also about automating this by
Vagrant, like we did in kolla-mesos.
Here comes the question - what repo is good for keeping the Vagrant
stuff for kolla-k8s? I see two options.
It seems for me that we have a dilemma between security (abstaining from
creating a core group which may overuse their rights in kolla repo) and
usability (not having multiple repos, which we experienced badly in the
kolla-mesos era).
I don't find the argument about having k8s ecosystem in
On Wed, 2016-04-20 at 06:57 +, Steven Dake (stdake) wrote:
> Grzegorz,
>
> This is a technical question about our roadmap and should be sent to
> the openstack-dev mailing list. As such, ccing openstack-dev so
> everyone can benefit from my thinking on this matter and others can
> weigh in.
I'm late to the party and probably my mail will be meaningless. ;)
But -1 from me. Because usually I'm against "oh, nvm, fix it later"
approaches at all. I don't see any significant problem of getting any
kind of patches (both docs and code) merged in Kolla, especially in
comparison to the
On 03/30/2016 09:51 AM, Steven Dake (stdake) wrote:
Michal,
We can't commit to that. We discussed it at midcycle and unable to commit
to it then. We are essentially abandoning the 1.0.0 release and replacing
it with 1.1.0 because of the documentation outlined here:
+1 under the condition that there will be a path of migration from "old"
Liberty to the "new" Liberty. At least in form of documentation.
If that wouldn't require any downtime of VM-s (except the Docker
upgrade, of course) and can be achieved just by running playbooks and
some script for
+1
__
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
+1
__
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
On 03/25/2016 07:57 AM, Jay Lau wrote:
Hi Magnum,
The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a
DCOS which focus on container service based on mesos.
For more detail, please refer to
On 03/07/2016 05:22 PM, Michał Jastrzębski wrote:
Upgrades are required, true, but not necessarily automatic ones.
People still can rebuild and redeploy containers using normal deploy.
It will be downtime causing and less optimal, but possible. Also with
backport of named volumes it won't be
+1
__
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
Please count me as well. I'd be interesting in joining the team, as well
as in introducing SELinux to kolla-mesos and/or helping in introducing
SELinux to kolla in general if that will be needed.
__
OpenStack Development
On 02/21/2016 05:18 PM, 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.
OK, so from what I understand, we need to do what you wrote here in
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.
On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote:
Angus is already in kolla-mesos-core but doesn't have broad ability to
approve changes for all of kolla-core. We agreed by majority vote in
Tokyo that folks in kolla-mesos-core that integrated well with the
project would be moved from
On 01/26/2016 11:32 AM, Gyorgy Szombathelyi wrote:
Hello!
I just want to announce a new installer for OpenStack:
https://github.com/DoclerLabs/openstack
It is GPLv3, uses Ansible (currently 1.9.x, 2.0.0.2 has some bugs which has to
be resolved), has lots of components integrated (of course
On 01/19/2016 10:20 AM, Paul Bourke wrote:
I was also thinking of adding Lei. He was a big help to me only recently
with fixing plugin support and adding unit test support to build.py. +1
from me.
-Paul
On 19/01/16 08:26, Steven Dake (stdake) wrote:
Hi folks,
I would like to propose Lei
On 01/17/2016 05:29 AM, Steven Dake (stdake) wrote:
Ryan,
I read your response and the idea of incubators is interesting, but the
risk there is we will end up with "two core teams" with different
objectives, purpose, focus, and most importantly a lack of coordinated
efforts and thinking. I'd
On 01/15/2016 11:14 AM, Simon Pasquier wrote:
My 2 cents on RabbitMQ logging...
On Fri, Jan 15, 2016 at 8:39 AM, Michal Rostecki <mroste...@mirantis.com
<mailto:mroste...@mirantis.com>> wrote:
I'd suggest to check the similar options in RabbitMQ and other
non-OpenStac
Hi,
Currently we're discussing stuff about kolla-mesos project on kolla IRC
meetings[1]. We have an idea of creating the separate meeting for
kolla-mesos. I see the following reasons for that:
- kolla-mesos has some contributors which aren't able to attend kolla
meeting because of timezone
On 01/15/2016 01:12 AM, Steven Dake (stdake) wrote:
Hi fellow core reviewers,
Harm joined Kolla early on with great enthusiasm and did a bang-up job
for several months working on Kolla. We voted unanimously to add him to
the core team. Over the last 6 months Harm hasn't really made much
On 01/12/2016 02:10 PM, Smigiel, Dariusz wrote:
Hello,
I'm trying to gather all the info necessary to migrate to keystone v3 in
Neutron.
When I've started to looking through possible problems with clients, it
occurred that 'neutron' and 'nova' clients do not want to operate with Keystone
v3.
On 01/14/2016 03:56 PM, Michał Jastrzębski wrote:
On 14 January 2016 at 04:46, Eric LEMOINE wrote:
On Wed, Jan 13, 2016 at 1:15 PM, Steven Dake (stdake) wrote:
Hey folks,
I'd like to have a mailing list discussion about logistics of the ELKSTACK
On 12/30/2015 11:07 AM, Canonical Calendar wrote:
The Mitaka 1 update is still in progress - it ran into the start of the
holiday period so right now will be a mix of releases.
I'd expect that to be sorted out by the end of next week when the
packaging team get back post new year
For
On 12/30/2015 03:17 AM, Lei Zhang wrote:
Why the package is still the nova 12.0.0 rather than 13.0.0 ? [0]
Most the package is updated at Nov 9, 2015. But it is almost 2016 now.
[0]
http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/pool/main/n/nova/
I see that the most of
On 12/07/2015 05:47 AM, Jay Pipes wrote:
Sorry, I guess I wasn't clear. I was not proposing to put all controller
services in a single container. I was proposing simply to build the
various container sets (nova-conductor, nova-api, etc) with the updated
code for that service and then "flip the
On 11/28/2015 01:01 AM, Egor Guz wrote:
Have you tested slave/agent inside container? I was under impression that it
doesn’t work until somebody from Kolla team pointed me to the
https://hub.docker.com/u/mesoscloud/.
Also I belive you can try your approach without any changes at existing
On 11/22/2015 04:17 PM, Steven Dake (stdake) wrote:
Michal,
Welcome to the Kolla core team. My apologies for being past deadline I
set of the 20th, dealing with some personal issues related to children
and wife traveling and –toomuchinput.
Regards
-steve
Thank you for the nomination and
On 11/03/2015 10:27 PM, Zane Bitter wrote:
I think we all agree that using something _like_ Kubernetes would be
extremely interesting for controller services, where you have a bunch of
heterogeneous services with scheduling constraints (HA), that may need
to be scaled out at different rates,
On 11/2/15, 22:44, "Michal Rostecki" <mroste...@mirantis.com> wrote:
Hi,
+1 to what Steven said about Kubernetes.
I'd like to add that these 3 things (pid=host, net=host, -v) are
supported by Marathon, so probably it's much less problematic for us
than Kubernetes at this moment.
On 11/03/2015 04:16 PM, Jeff Peeler wrote:
On Tue, Nov 3, 2015 at 1:44 AM, Michal Rostecki <mroste...@mirantis.com> wrote:
Hi,
+1 to what Steven said about Kubernetes.
I'd like to add that these 3 things (pid=host, net=host, -v) are supported
by Marathon, so probably it's muc
Hi,
+1 to what Steven said about Kubernetes.
I'd like to add that these 3 things (pid=host, net=host, -v) are
supported by Marathon, so probably it's much less problematic for us
than Kubernetes at this moment.
Regards,
Michal
On 11/03/2015 12:18 AM, Steven Dake (stdake) wrote:
Gosh,
On Wed, Oct 7, 2015 at 12:59 PM, Roman Prykhodchenko wrote:
> What I can extract now from this thread is that Fuel should switch to testr
> because of the following reasons:
>
> - Diversity of tools is a bad idea on a project scale
We already have diversity about frameworks (or
" is working perfectly for me. Please:
- ensure you have up-to-date repo
- try to remove .tox/ directory and run the command again
>
> But if i run "pip install -r requirements.txt", its giving no error.
Does "pip install -r test-requirements.txt" give no error a
38 matches
Mail list logo