hi, leyal,
I suppose the upgrade is backward compatible, right?
Cheers,
Lingxian Kong (Larry)
On Wed, Dec 13, 2017 at 8:51 PM, Eyal Leshem wrote:
> Hi all ,
>
> In order to use kubernetes client that support network-policies ,
> we plan to upgrade the python kubernetes package from 1.0.0 to
Hi Lingxian,
It's should - under the assumption of uses only the v1 models ( and not
v1_alpha or v1_beta).
see : https://kubernetes.io/docs/reference/api-overview/
thanks ,
leyal
On 13 December 2017 at 11:16, Lingxian Kong wrote:
> hi, leyal,
>
> I suppose the upgrade is backward compatible,
On Wed, 2017-12-13 at 09:51 +0200, Eyal Leshem wrote:
> Hi all ,
>
> In order to use kubernetes client that support network-policies ,
> we plan to upgrade the python kubernetes package from 1.0.0 to
> 4.0.0.
>
> any objections ?
There's a couple of issues ([1], [2]) introduced in 4.0.0 tha
cool, thanks!
Cheers,
Lingxian Kong (Larry)
On Wed, Dec 13, 2017 at 10:41 PM, Eyal Leshem wrote:
> Hi Lingxian,
>
> It's should - under the assumption of uses only the v1 models ( and not
> v1_alpha or v1_beta).
> see : https://kubernetes.io/docs/reference/api-overview/
>
> thanks ,
> leyal
>
3.0.0 is align with the kubernetes-1.7 api spec.
In 1.8 there is some fields that had been added to the k8s-network-policy.
so for me 4.0.0 will be much better.
thanks,
leyal
On 13 December 2017 at 11:49, wrote:
> On Wed, 2017-12-13 at 09:51 +0200, Eyal Leshem wrote:
> > Hi all ,
> >
> > In ord
On Wed, 2017-12-13 at 12:18 +0200, Eyal Leshem wrote:
> 3.0.0 is align with the kubernetes-1.7 api spec.
> In 1.8 there is some fields that had been added to the k8s-network-
> policy.
> so for me 4.0.0 will be much better.
Okay, then I don't see a point to block that, we can work around the
is
Hi folks,
The following commit[0] added support for SSL connections to NB and SB
databases. Now for enabling open ptcp communication to NB and SB dbs,
we need to do this:
# ovn-sbctl set-connection ptcp:6642
# ovn-nbctl set-connection ptcp:6641
For an OpenStack cloud deployment(TripleO), if open
Hi Rabi,
see below
On 12/13/17 11:03 AM, Rabi Mishra wrote:
if Heat will provide a way to choose provider (neutron-lbaas or octavia), then
customers will continue to use neutron-lbaas as long as
it will be required, with their specific drivers (haproxy, F5, A10,
etc), gradually migrating to O
Hi,
> Hi Martin,
>
> I met exactly the same issue with yours, could you please show some details
> about security groups deleting, resyncing and recreating? cause I cleared
> DEFAULT security group and add 'ovn-sync-mode=repair' in config file then
> restarted the neutron-server, but didn't work o
Through my work in networking-odl I've found what I believe is an issue
present in a majority of ML2 drivers. An issue I think needs awareness so
each project can decide a course of action.
The issue stems from the adopted practice of importing
`neutron.tests.unit.plugins.ml2.test_plugin` and crea
Hi guys,
We will have our weekly team meeting today on #openstack-cyborg starting
from UTC1500 .
I've been under the weather for the whole week so plz zhuli, Justin and
Rushil help lead the meeting.
The agenda is to sync up everyone's progress, zhuli will also provide a
summary of yesterday's Cy
Hi all,
The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, and the agenda, see the meeting
page:
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
Cheers,
pk
__
OpenS
On 2017-12-13 01:52 AM, Jaze Lee wrote:
> Hello,
>
> What about move transformer to compute pollster? If we do this, we
> do not need
> transformer any more
sorry, i don't understand. if you move the transformer, you still have a
transformer.
--
gord
__
Hi all,
As part of the effort of splitting tempest plugins to their own
repositories [0], we are calling all Manila 3rd party CI maintainers to
adjust their gate scripts to use the new tempest test repository
If the third party CIs are configured to run with DevStack Gate, they only
need to make
ok ... i changed all the domain related attributes in
/etc/masakarimonitors/masakarimonitors.conf to be set to ‘default’ .
I seemed to get further,
but now get the following error when instancemonitor tries to send a
notification:
Bad Request (HTTP 400) (Request-ID:
req-556c6c4d-0e12-414e-
Hi everyone,
Over the past year, it has become pretty obvious to me that our
self-imposed rhythm no longer matches our natural pace. It feels like we
are always running elections, feature freeze is always just around the
corner, we lose too much time to events, and generally the impression
that th
Thierry,
Thanks for starting this discussion.
I support move to 1 year cycle. With OpenStack maturity and adoption it is a
natural transformation.
However, we also need to consider previous releases, support for them and "."
release for them.
Also for projects that are "in early stages" they ca
Hey
On 13 December 2017 at 16:17, Thierry Carrez wrote:
> self-imposed rhythm no longer matches our natural pace. It feels like we
> are always running elections, feature freeze is always just around the
> corner, we lose too much time to events, and generally the impression
> that there is less
On 2017-12-13 16:45:14 + (+), Chris Jones wrote:
[...]
> For me the first thing that comes to mind with this proposal, is
> how would the milestones/FF/etc be arranged within that year?
[...]
Excellent point. If it's not too much work for the Release team, it
would be very helpful to have
On 12/13/2017 10:17 AM, Thierry Carrez wrote:
Hi everyone,
Over the past year, it has become pretty obvious to me that our
self-imposed rhythm no longer matches our natural pace. It feels like we
are always running elections, feature freeze is always just around the
corner, we lose too much time
On Thu, Dec 7, 2017 at 2:55 AM, Sławomir Kapłoński wrote:
> Hi,
>
> Thanks all of You for support. I'm very happy to be part of the team.
Congratulations Slawek, and job well done!
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>> Wiadomość napisana przez Miguel Lavalle w dni
===
#openstack-doc: docteam
===
Meeting started by pkovar at 16:01:40 UTC. The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-12-13-16.01.log.html
.
Meeting summary
---
* roll call (pkovar, 16:
Chris Jones wrote:
> [...]
> For me the first thing that comes to mind with this proposal, is how
> would the milestones/FF/etc be arranged within that year? As I've raised
> previously on this list [0], I would prefer more time for testing and
> stabilisation between Feature Freeze and Release. I
On 13 December 2017 at 16:49, Jeremy Stanley wrote:
> On 2017-12-13 16:45:14 + (+), Chris Jones wrote:
> [...]
>> For me the first thing that comes to mind with this proposal, is
>> how would the milestones/FF/etc be arranged within that year?
> [...]
>
> Excellent point. If it's not too m
Matt Riedemann wrote:
> On 12/13/2017 10:17 AM, Thierry Carrez wrote:
>> [...]
>> Why one year ?
>>
>> Why not switch to 9 months ? Beyond making the math a lot easier, this
>> has mostly to do with events organization. The Summits are already
>> locked for 2018/2019 with a pattern of happening in
There are definitely pros and cons to this approach but I think
considerable amount of time and concern went into this prior to being
posted on the ML and agree with JP there will be folks who agree and/or
disagree with some or all of this so TC vote is best. I think getting away
from the debatable
On Wed, Dec 13, 2017 at 9:59 AM, Thierry Carrez
wrote:
> Chris Jones wrote:
> > [...]
> > For me the first thing that comes to mind with this proposal, is how
> > would the milestones/FF/etc be arranged within that year? As I've raised
> > previously on this list [0], I would prefer more time for
Thierry Carrez wrote:
- It doesn't mean that teams can only meet in-person once a year.
Summits would still provide a venue for team members to have an
in-person meeting. I also expect a revival of the team-organized
midcycles to replace the second PTG for teams that need or want to meet
more o
A lot of great points.
If we are switching to 1 year cycle do we also move summits/forum to once a
year...
That impacts much more than developers.
-Original Message-
From: Matt Riedemann [mailto:mriede...@gmail.com]
Sent: Wednesday, December 13, 2017 10:52 AM
To: openstack-dev@lists.open
I think we should not mix summits/forum discussion with this and would
require a lot more open discussion as has been happening with this proposal
prior to it being formally introduced here.
On Wed, Dec 13, 2017 at 11:13 AM, wrote:
> A lot of great points.
> If we are switching to 1 year cycle d
On 13 December 2017 at 16:52, Matt Riedemann wrote:
> On 12/13/2017 10:17 AM, Thierry Carrez wrote:
>>
>> Hi everyone,
>>
>> Over the past year, it has become pretty obvious to me that our
>> self-imposed rhythm no longer matches our natural pace. It feels like we
>> are always running elections,
Hey
On 13 December 2017 at 17:12, Jimmy McArthur wrote:
> Thierry Carrez wrote:
>
>> - It doesn't mean that teams can only meet in-person once a year.
>> Summits would still provide a venue for team members to have an
>> in-person meeting. I also expect a revival of the team-organized
>> midcycl
On Wed, Dec 13, 2017 at 04:49:24PM +, Jeremy Stanley wrote:
> On 2017-12-13 16:45:14 + (+), Chris Jones wrote:
> [...]
> > For me the first thing that comes to mind with this proposal, is
> > how would the milestones/FF/etc be arranged within that year?
> [...]
>
> Excellent point. If
Sean,
If we are reworking the schedule it is a good idea to leave more
stabilization time at the end and try to wrap things up before the end
of the year when people disappear.
As far as releases go ... other teams have been doing frequent
intermediate releases and have benefited from it. J
On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote:
> Hey
>
> On 13 December 2017 at 17:12, Jimmy McArthur wrote:
>
> > Thierry Carrez wrote:
> >
> >> - It doesn't mean that teams can only meet in-person once a year.
> >> Summits would still provide a venue for team members to have an
>
Jay S Bryant wrote:
> If we are reworking the schedule it is a good idea to leave more
> stabilization time at the end and try to wrap things up before the end
> of the year when people disappear.
>
> As far as releases go ... other teams have been doing frequent
> intermediate releases and have b
On Wed, Dec 13, 2017 at 05:13:00PM +, arkady.kanev...@dell.com wrote:
> A lot of great points.
> If we are switching to 1 year cycle do we also move summits/forum to once a
> year...
> That impacts much more than developers.
>
The current plan is the Summit/Forum schedule would not change. T
Thierry,
Thank you for this well thought out note. I had kind-of felt like the
idea was crazy but as I read through this note I can see there could be
benefits for the community.
The Cinder team would need to decide if we still wanted to do a
mid-cycle in August/September. We used to benef
On 12/13/2017 11:16 AM, Jean-Philippe Evrard wrote:
On the other hand, without community-wide imposed deadlines and milestones,
we lose some motivation for getting things done by a specific time, which
could mean the bigger and more complicated things drag on longer because
there isn't a deadlin
On 12/13/2017 06:29 PM, Sean McGinnis wrote:
On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote:
Hey
On 13 December 2017 at 17:12, Jimmy McArthur wrote:
Thierry Carrez wrote:
- It doesn't mean that teams can only meet in-person once a year.
Summits would still provide a venue for
On 12/13/2017 11:29 AM, Sean McGinnis wrote:
On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote:
Hey
On 13 December 2017 at 17:12, Jimmy McArthur wrote:
Thierry Carrez wrote:
- It doesn't mean that teams can only meet in-person once a year.
Summits would still provide a venue fo
Hello Again :)
I know I had responded the other day, but I just wanted to check in and
make sure the setup was going well. We would love to chat with you on IRC
in #openstack-dev or in #openstack-women. Feel free to ping me once you get
connected and we can chat more about getting you connected wi
I share the same concerns that Matt and Dmitry have already spoken. One
year release process seems like a good plan, but I do feel that cuting the
PTG can directly affect the progress of the cycle.
It would take a great effort from PTLs and Core team to keep developement
going smoothly througout t
On Wed, Dec 13, 2017 at 8:52 AM, Matt Riedemann wrote:
[...]
> I personally don't expect anyone to pick up these intermediate releases. I
> expect most consumers are going to pick up a coordinated release (several
> months or years after it's released), especially if that's what the distro
> vendo
I think Sean has made some really good points with the PTG setting things
off in the start of the year and conversations carrying over to the Forums
and their importance. And having a gap at the end of the year as Jay
mentioned will give time for those still about to do finishing work if
needed and
2017-12-13 17:17 GMT+01:00 Thierry Carrez :
> - We'd only do one *coordinated* release of the OpenStack components per
> year, and maintain one stable branch per year
> - We'd elect PTLs for one year instead of every 6 months
> - We'd only have one set of community goals per year
> - We'd have onl
The forums would seem to provide a good opportunity for get togethers during
the release cycle. With these happening April/May and October/November, there
could be a good chance for productive team discussions and the opportunities to
interact with the user/operator community.
There is a risk t
On Sat, Dec 9, 2017 at 12:35 AM Alex Schultz wrote:
> Please take some time to review the list of blueprints currently
> associated with Rocky[0] to see if your efforts have been moved. If
> you believe you're close to implementing the feature in the next week
> or two, let me know and we can mov
We only have three projects covered at this point (QA, Monasca, and Swift),
would be nice to see some more volunteers from other projects.
Thanks Matt, Cristiano and Ghanshyam!
-Kendall (diablo_rojo)
On Mon, Dec 11, 2017 at 1:24 PM Kendall Nelson
wrote:
> Hello,
>
> As some of you may know the
On Wed, Dec 13, 2017 at 10:13 AM, Tim Bell wrote:
[...]
> There is a risk that deployment to production is delayed, and therefore
> feedback is delayed and the wait for the ‘initial bug fixes before we deploy
> to prod’ gets longer.
This is exactly what worries me with this proposal (it reflects
On Wed, Dec 13, 2017 at 06:13:41PM +, Tim Bell wrote:
> The forums would seem to provide a good opportunity for get togethers during
> the release cycle. With these happening April/May and October/November, there
> could be a good chance for productive team discussions and the opportunities
Dirk Müller wrote:
> 2017-12-13 17:17 GMT+01:00 Thierry Carrez :
>
> > - We'd only do one *coordinated* release of the OpenStack components per
> > year, and maintain one stable branch per year
> > - We'd elect PTLs for one year instead of every 6 months
> > - We'd only have one set of community g
Will do, thanks!
On Dec 13, 2017 6:37 PM, "Kendall Nelson" wrote:
> Hello Again :)
>
> I know I had responded the other day, but I just wanted to check in and
> make sure the setup was going well. We would love to chat with you on IRC
> in #openstack-dev or in #openstack-women. Feel free to ping
Do we continue to support the previous two releases as stable branches?
Doesn't that mean we double the amount of time we need to keep older CI
setups around? Isn't that already a pain point for the stable teams?
Michael
On Wed, Dec 13, 2017 at 8:17 AM, Thierry Carrez
wrote:
> Hi everyone,
>
>
And if we don't answer right away we will when we can!
Amy (spotz)
On Wed, Dec 13, 2017 at 11:37 AM, Kendall Nelson
wrote:
> Hello Again :)
>
> I know I had responded the other day, but I just wanted to check in and
> make sure the setup was going well. We would love to chat with you on IRC
> i
Ok!
On Dec 13, 2017 8:01 PM, "Amy Marrich" wrote:
> And if we don't answer right away we will when we can!
>
> Amy (spotz)
>
> On Wed, Dec 13, 2017 at 11:37 AM, Kendall Nelson
> wrote:
>
>> Hello Again :)
>>
>> I know I had responded the other day, but I just wanted to check in and
>> make sure
Hey
On 13 December 2017 at 17:31, Thierry Carrez wrote:
> See attached for the PDF strawman the release team came up with when
> considering how that change would roll out in practice...
>
[in which the final stage of the release is 8 weeks, therefore shorter than
the other 10/11 week stages]
I have two concerns.
1.) I'm hesitant to lose developer <---> operator communication more
than we already have. Outcomes and conversations from the PTGs are super
useful, but we don't exactly have rooms full of operators to bounce
ideas off of. We can summarize outcomes and socialize reports on ma
This is a much needed change. It will ease the effort required by operators
to maintain a current openstack environment.
+1 from me
Chris Krelle
On Dec 13, 2017 8:17 AM, "Thierry Carrez" wrote:
Hi everyone,
Over the past year, it has become pretty obvious to me that our
self-imposed rhythm
On 12/13/2017 12:26 PM, Sean McGinnis wrote:
On Wed, Dec 13, 2017 at 06:13:41PM +, Tim Bell wrote:
The forums would seem to provide a good opportunity for get togethers during
the release cycle. With these happening April/May and October/November, there
could be a good chance for product
Kendall,
I thought it was implied in my earlier replies but to be clear, I will
represent Cinder.
Jay (jungleboyj)
On 12/13/2017 12:17 PM, Kendall Nelson wrote:
We only have three projects covered at this point (QA, Monasca, and
Swift), would be nice to see some more volunteers from other
I didn't want to assume you would for Cinder or if you wanted to only be a
member of the SIG and maybe someone else would step up as the Cinder
project liaison.
I can add you as the Cinder Project Liaison now though. Thanks Jay!
-Kendall (diablo_rojo)
On Wed, Dec 13, 2017 at 12:09 PM Jay S Bryan
Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800:
> Do we continue to support the previous two releases as stable branches?
> Doesn't that mean we double the amount of time we need to keep older CI
> setups around? Isn't that already a pain point for the stable teams?
>
> Michael
Doug Hellmann wrote:
> Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800:
>> Do we continue to support the previous two releases as stable branches?
>> Doesn't that mean we double the amount of time we need to keep older CI
>> setups around? Isn't that already a pain point for the
On Wed, Dec 13, 2017 at 03:16:33PM -0500, Doug Hellmann wrote:
> Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800:
> > Do we continue to support the previous two releases as stable branches?
> > Doesn't that mean we double the amount of time we need to keep older CI
> > setups aro
Excerpts from Thierry Carrez's message of 2017-12-13 22:26:49 +0100:
> Doug Hellmann wrote:
> > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800:
> >> Do we continue to support the previous two releases as stable branches?
> >> Doesn't that mean we double the amount of time we nee
On Tue, Dec 12, 2017 at 5:50 PM, Tony Breeds wrote:
> On Fri, Dec 08, 2017 at 04:34:09PM -0700, Alex Schultz wrote:
>> Hey folks,
>>
>> So I went through the list of blueprints and moved some that were
>> either not updated or appeared to have a bunch of patches not in a
>> mergable state.
>>
>> P
On Wed, Dec 13, 2017 at 11:16 AM, Sven Anderson wrote:
>
> On Sat, Dec 9, 2017 at 12:35 AM Alex Schultz wrote:
>>
>> Please take some time to review the list of blueprints currently
>> associated with Rocky[0] to see if your efforts have been moved. If
>> you believe you're close to implementing
On Dec 13, 2017, at 12:13 PM, Tim Bell wrote:
> There is a risk that deployment to production is delayed, and therefore
> feedback is delayed and the wait for the ‘initial bug fixes before we deploy
> to prod’ gets longer.
There is always a rush at the Feature Freeze point in a cycle to get th
Doug Hellmann wrote:
> That said, I'm more interested in settling the question of whether
> changing the development cycle helps development teams in any way
> before we consider other effects. Because if it doesn't do any good
> then there's no reason to solve problems we won't have, and if we
> a
Ed Leafe wrote:
> On Dec 13, 2017, at 12:13 PM, Tim Bell wrote:
>
>> There is a risk that deployment to production is delayed, and therefore
>> feedback is delayed and the wait for the ‘initial bug fixes before we deploy
>> to prod’ gets longer.
>
> There is always a rush at the Feature Freeze
> I just need an understanding on the impact and the timeline. Replying
> here is sufficient.
>
> I assume since some of this work was sort of done earlier outside of
> tripleo and does not affect the default installation path that most
> folks will consume, it shouldn't be impacting to general te
Excerpts from Ed Leafe's message of 2017-12-13 16:07:50 -0600:
> On Dec 13, 2017, at 12:13 PM, Tim Bell wrote:
>
> > There is a risk that deployment to production is delayed, and therefore
> > feedback is delayed and the wait for the ‘initial bug fixes before we
> > deploy to prod’ gets longer.
On Wed, Dec 13, 2017 at 3:22 PM, Mark Hamzy wrote:
>> I just need an understanding on the impact and the timeline. Replying
>> here is sufficient.
>>
>> I assume since some of this work was sort of done earlier outside of
>> tripleo and does not affect the default installation path that most
>> fo
It looks like the implicit expectation is that devs also need to attend the
Forums at the summit in addition to the PTG. The Forums, though important,
hardly made it worthwhile for me to attend the summit (and in fact I skipped
Sydney). On the other hand some devs got together and hashed out som
Excerpts from Chris Jones's message of 2017-12-13 19:25:03 +:
> Hey
>
> On 13 December 2017 at 17:31, Thierry Carrez wrote:
>
> > See attached for the PDF strawman the release team came up with when
> > considering how that change would roll out in practice...
> >
>
> [in which the final st
Kendall,
I ran this by Sean and since I am covering the other On-Boarding work
for Cinder and am integrated with OUI and SIG it makes the most sense
for me to cover this as well.
Thanks for updating the list.
Jay
On 12/13/2017 2:15 PM, Kendall Nelson wrote:
I didn't want to assume you woul
Obviously, I'm interested and I voted.
Thanks,
Gilles
On 13/12/17 02:22, Ed Leafe wrote:
Re-sending this in the hope of getting more responses. If you’re in the APAC
region and interested in contributing to our discussions, please indicate your
preferences on the link below.
That brought u
Alex Schultz wrote on 12/13/2017 04:29:49 PM:
> On Wed, Dec 13, 2017 at 3:22 PM, Mark Hamzy wrote:
> > What I have done at a high level is to rename the images into
architecture
> > specific
> > images. For example,
> >
> > (undercloud) [stack@oscloud5 ~]$ openstack image list
> > +
Hello everyone,
Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Dec 14th at 8:00 UTC in the #openstack-meeting channel.
The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Dec_14th_2017_.280800_UTC.29
Any
2017-12-13 21:16 GMT+08:00 gordon chung :
>
>
> On 2017-12-13 01:52 AM, Jaze Lee wrote:
>> Hello,
>>
>> What about move transformer to compute pollster? If we do this, we
>> do not need
>> transformer any more
>
> sorry, i don't understand. if you move the transformer, you still have
Thanks edleafe,
I am interested to attend but it is little early for me(i am in
JST(UTC +9)), any chance we can make it to 23:00 UTC or 0:00 UTC ?
-gmann
On Wed, Dec 13, 2017 at 12:22 AM, Ed Leafe wrote:
> Re-sending this in the hope of getting more responses. If you’re in the APAC
> region
How about add to our biannual questionnaire how often customer upgrade their
openstack environment?
-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: Wednesday, December 13, 2017 4:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] S
On 12/13/2017 4:20 PM, Thierry Carrez wrote:
Is the "rush" at the end of the cycle still a thing those days ? From a
release management perspective it felt like the pressure was reduced in
recent cycles, with less and less FFEs. But that may be that PTLs have
gotten better at denying them, not th
On Wed, Dec 13, 2017 at 11:17 AM, Thierry Carrez
wrote:
> - It doesn't mean that teams can only meet in-person once a year.
> Summits would still provide a venue for team members to have an
> in-person meeting. I also expect a revival of the team-organized
> midcycles to replace the second PTG fo
Excerpts from Arkady.Kanevsky's message of 2017-12-14 02:44:24 +:
> How about add to our biannual questionnaire how often customer upgrade their
> openstack environment?
There is quite a bit of information about deployments in the latest
user survey [1], starting on page 24. Page 29 shows the
On 12/13/2017 4:15 PM, Thierry Carrez wrote:
Based on several discussions I had with developers working part-time on
OpenStack at various events lately, it sounded like slowing down our
pace could be helpful to them and generally reduce stress in OpenStack
development. I know people who can spend
On Wed, Dec 13, 2017 at 5:22 PM, pranab boruah
wrote:
> Hi folks,
> The following commit[0] added support for SSL connections to NB and SB
> databases. Now for enabling open ptcp communication to NB and SB dbs,
> we need to do this:
>
> # ovn-sbctl set-connection ptcp:6642
> # ovn-nbctl set-conne
On Wed, Dec 13, 2017 at 9:13 PM, Matt Riedemann wrote:
> On 12/13/2017 4:15 PM, Thierry Carrez wrote:
>
>> Based on several discussions I had with developers working part-time on
>> OpenStack at various events lately, it sounded like slowing down our
>> pace could be helpful to them and generally
Hi Greg,
Looks like you don’t have “devstack-masakari” host registered in Masakari
database.
Currently operator have to add all the hosts from failover-segment manually to
Masakari database.
You can use below command:
Register failover-segment to Masakari database:
openstack segment crea
Excerpts from Thierry Carrez's message of 2017-12-13 17:17:26 +0100:
> Hi everyone,
>
> Over the past year, it has become pretty obvious to me that our
> self-imposed rhythm no longer matches our natural pace. It feels like we
> are always running elections, feature freeze is always just around th
On Dec 13, 2017, at 4:31 PM, Doug Hellmann wrote:
> You're missing the key point that coupled with the change in the
> overall development cycle schedule we would be encouraging projects
> to release more often. I'd personally rather do away with milestones
> altogether and just tag everything m
On Dec 13, 2017, at 4:38 PM, German Eichberger
wrote:
> It looks like the implicit expectation is that devs also need to attend the
> Forums at the summit in addition to the PTG. The Forums, though important,
> hardly made it worthwhile for me to attend the summit (and in fact I skipped
> Syd
On Dec 13, 2017, at 5:44 PM, Clint Byrum wrote:
> One thing I've always admired about Swift was how immune to the cadence Swift
> appears to be.
As I've pointed out before [0], Swift is a whole 'nother thing.
It does not have API interdependencies with anything else in OpenStack. It is
free to
Hello.
I'm MinWookKim.
I have been discussing my proposal with the Vitrage PTL a while ago,
I want to get feedback from Vitrage contributors.
In conclusion, my suggestion is that when I right-click on the Entity Graph
provided by Vitrage, I want the user to perform various actions t
Excerpts from Ed Leafe's message of 2017-12-13 22:51:19 -0600:
> On Dec 13, 2017, at 4:31 PM, Doug Hellmann wrote:
>
> > You're missing the key point that coupled with the change in the
> > overall development cycle schedule we would be encouraging projects
> > to release more often. I'd persona
On 14 December 2017 at 17:36, Clint Byrum wrote:
> The batch size for "upgrade the whole cloud" is too big. Let's help our
> users advance components one at a time, and then we won't have to worry
> so much about doing the whole integrated release dance so often.
Is there any data about how opera
Excerpts from Ed Leafe's message of 2017-12-13 23:02:11 -0600:
> On Dec 13, 2017, at 5:44 PM, Clint Byrum wrote:
>
> > One thing I've always admired about Swift was how immune to the cadence
> > Swift
> > appears to be.
>
> As I've pointed out before [0], Swift is a whole 'nother thing.
>
> It
Maybe not exactly on the topic but I’d like to express some more thoughts on
OpenStack development rhythm being too harsh for newcomers and part time
developers.
Although I partially agree with the initial Thierry’s point I think the key
thing here itself is that they are part time developers.
Excerpts from Blair Bethwaite's message of 2017-12-14 17:44:53 +1100:
> On 14 December 2017 at 17:36, Clint Byrum wrote:
> > The batch size for "upgrade the whole cloud" is too big. Let's help our
> > users advance components one at a time, and then we won't have to worry
> > so much about doing t
1 - 100 of 101 matches
Mail list logo