Change against master merged.
Backport for Newton - https://review.openstack.org/#/c/419320/
On Tue, Jan 24, 2017 at 7:44 PM Davanum Srinivas wrote:
> Cool. Then i'd support a backport when the review against master
> merges. Thanks Ann and Kirill.
>
> -- Dims
>
> On Tue, Jan 24, 2017 at 10:33 A
On Mon, Jan 23, 2017 at 02:03:28PM -0500, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common
+1 Awesome!
On Wed, Jan 25, 2017 at 9:35 AM, Michele Baldessari
wrote:
> On Mon, Jan 23, 2017 at 02:03:28PM -0500, Emilien Macchi wrote:
> > Greeting folks,
> >
> > I would like to propose some changes in our core members:
> >
> > - Remove Jay Dobies who has not been active in TripleO for a whil
Hello Steve,
I do apologize for contacting you directly. I have also sent this
response to the official mailing list.
I was unable to find your email response to my question on the error
while setting up keystone.
I found it by chance in the january list while looking for an unrelated
solu
I prepared a patch that forces the use of 2.40 api version if it's
available for that particular endpoint. Instead of waiting for the
microversion patch, I simply copied the needed fragments from it -- we can
fix that later once we have proper microversion support implemented.
https://review.opens
Hi Kolla,
I would like to restart working on the following BP[0] and patch[1]. To
do so, I have to amend the patch and send to kolla-ansible since the
repository have been split into kolla and kolla-ansible, right?
[0] https://blueprints.launchpad.net/kolla-ansible/+spec/graceful-shutdown
[
+1, Nice!
On 24.1.2017 14:52, Emilien Macchi wrote:
I have been discussed with TripleO UI core reviewers and it's pretty
clear Honza's work has been valuable so we can propose him part of
Tripleo UI core team.
His quality of code and reviews make him a good candidate and it would
also help the
Chris Dent wrote:
> [...]
> That could very well be fine, but we have evidence that:
>
> * some projects don't yet use microversions in their APIs
> * some projects have no intention of using microversions or at least
> have internal conflict about doing so
> * some projects would like to chang
On Mon, Jan 23, 2017 at 8:03 PM, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and triple
On Tue, Jan 24, 2017 at 2:52 PM, Emilien Macchi wrote:
> I have been discussed with TripleO UI core reviewers and it's pretty
> clear Honza's work has been valuable so we can propose him part of
> Tripleo UI core team.
> His quality of code and reviews make him a good candidate and it would
> also
On 24 January 2017 at 17:03, Juan Antonio Osorio wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a
On 23 January 2017 at 19:03, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-he
On 24 January 2017 at 13:52, Emilien Macchi wrote:
> I have been discussed with TripleO UI core reviewers and it's pretty
> clear Honza's work has been valuable so we can propose him part of
> Tripleo UI core team.
> His quality of code and reviews make him a good candidate and it would
> also hel
> [Mooney, Sean K] I belive you are intended to be able to use the
ansible --limit and --tags flags,
> To restrict the plays executed and node processed by a deploy and
upgrade command.
> I have used the --tags flags successfully in the past, I have had
less success with the --limit flag.
> In t
Kevin Benton wrote:
> [...]
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever
> behavior they want. This is great for vendors beca
Hi,
I believe the scenario was as follows: firstly
TestNodeAttributes.test_hugepages_distribution failed with
2017-01-25 08:11:20.155868 | E ProgrammingError:
(psycopg2.ProgrammingError) relation "node_cluster_plugins" does not exist
and all other tests failed because of InternalError due t
Hi Hiroki,
To my knowledge it's not possible to change the target repository for an
open patch. What we've done so far is to abandon the in progress one,
cherry-pick to the correct repository and start a new review (adding the
original author as a co-author of course).
Hope that helps,
-Paul
Hi Michael,
On 25 January 2017 at 06:50, Michael Gale wrote:
> My biggest hurdle was around getting the devstack environment functioning, I
> was following the steps here:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
>
> I think the issues are related to using Ubuntu 16.04
Hi everyone,
The PTG is just a few weeks away, and I wanted to discuss logistics a
bit. As you probably know, we won't do any central scheduling, beyond
assigning rooms to teams and days. Each team is free to arrange their
time in their room in the way that is the most productive to them. You
can
Hi osa team,
i ‘ve got live migration issue in one direction but not in other.
I deploy openstack with OSA, ubuntu trusty, stable/newton branch, 14.0.5 tag.
My 2 compute node are same host type and have nova-compute and cinder-volume
(our ceph cluster as backend) services.
No problem to live mi
On Tue, Jan 24 2017, gordon chung wrote:
> you mean, keep alarm history in aodh and also in panko if needed? i'm ok
> with that.
Yeah, IIRC there's an expirer in Aodh for alarm history based on TTL –
that's enough. That should probably be replaced with just a hard limit on
the number of history
On 23.1.2017 20:03, Emilien Macchi wrote:
Greeting folks,
I would like to propose some changes in our core members:
- Remove Jay Dobies who has not been active in TripleO for a while
(thanks Jay for your hard work!).
- Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
docker
On 24.1.2017 14:52, Emilien Macchi wrote:
I have been discussed with TripleO UI core reviewers and it's pretty
clear Honza's work has been valuable so we can propose him part of
Tripleo UI core team.
His quality of code and reviews make him a good candidate and it would
also help the other 2 core
On 24.1.2017 18:03, Juan Antonio Osorio wrote:
Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
on the current CI solution and in getting tripleo-quickstart jobs for
it); So I would like to propose him as part of the TripleO CI core team.
+1
I think he'll make a great add
On Wed, 25 Jan 2017, Thierry Carrez wrote:
We were discussing this in the context of an "assert" tag, not a goal.
Yes, but it is often the case that changes are being evaluated as if
it was a goal. A couple of glance related changes experienced
reactions of "this doesn't meet compatibility gui
- Original Message -
> From: "Emilien Macchi"
> To: "OpenStack Development Mailing List"
> Sent: Tuesday, January 24, 2017 2:52:51 PM
> Subject: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui
>
> I have been discussed with TripleO UI core reviewers and it's pretty
Hello everyone,
I'm happy to announce my candidacy to be the Freezer PTL for the Pike
release
cycle.
The Freezer developers did a very good job over the past releases and I am
sure
they will continue doing an amazing job over the next release as well.
For the Pike release cycle, I think we need
Hi,
What domain name are you using?
Check for 'Traceback' and ' ERROR ' in the logs, maybe you will get a hint
2017-01-25 11:00:21.215 28309 INFO nova.compute.manager
[req-6f21e4a4-28a8-48e3-bf2f-2e1ad3b52470 0329776bd1634978a7fed35a70c77479
7531f209e3514e3f98eb58aafa480285 - - -] [instance:
And you have at least all my support : )
On Wed, Jan 25, 2017 at 12:56 PM, Saad Zaher wrote:
> Hello everyone,
>
> I'm happy to announce my candidacy to be the Freezer PTL for the Pike
> release
> cycle.
>
> The Freezer developers did a very good job over the past releases and I am
> sure
> they
Hi,
I did write a blueprint a while ago but did not start to implement it.
https://blueprints.launchpad.net/magnum/+spec/coreos-best-pratice
> Le 24 janv. 2017 à 23:16, Spyros Trigazis a écrit :
>
> Or start writing down (in the BP) what you want to put in the driver.
> Network, lbaas, script
On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez
wrote:
> Kevin Benton wrote:
> > [...]
> > The Neutron API is already very extensible and that's problematic. Right
> > now a vendor can write an out-of-tree service plugin or driver that adds
> > arbitrary fields and endpoints to the API that resul
Hi, as part of the composable upgrades workflow shaping up for Newton to
Ocata, we need to install the new hiera hook that was first added with
[1] and disable the old hook and data as part of the upgrade
initialization [2]. Most of the existing hieradata was ported to use the
new hook in [3]. The
On 23/01/17 21:03, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templa
>So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.
I stated that I am happy to develop new APIs in Neutron. "So I'm all for
developing new APIs *as a community*"...
The important distinction I am making is that we can make new APIs (and we
do with routed networks as you me
On Tue, Jan 24, 2017 at 6:43 AM, Corey Bryant
wrote:
>
> On Fri, Jan 20, 2017 at 6:34 PM, Alex Schultz wrote:
>>
>> Just FYI,
>>
>> We switched the Ubuntu scenario jobs to non-voting this week due to
>> the large amount of breakage caused by the ocata-proposed update to m2
>> based packages. The
Hi,
Alarm history and a database are definitely important, but they are not the
main issue here.
As we see it, alarms can be generated by different sources – Aodh, Vitrage,
Nagios, Zabbix, etc. Each source has its own expertise and internal
implementation. Nagios and Zabbix can raise alarms ab
On 01/24/2017 08:04 PM, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
>
> The Neutron API is alrea
On 25/01/17 08:39 AM, Afek, Ifat (Nokia - IL) wrote:
> As we see it, alarms can be generated by different sources – Aodh, Vitrage,
> Nagios, Zabbix, etc. Each source has its own expertise and internal
> implementation. Nagios and Zabbix can raise alarms about the physical layer,
> Aodh can rai
On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one
> of the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to addr
On 01/24/2017 12:39 PM, Chris Dent wrote:
> On Mon, 23 Jan 2017, Sean Dague wrote:
>
>> We all inherited a bunch of odd and poorly defined behaviors in the
>> system we're using. They were made because at the time they seemed like
>> reasonable tradeoffs, and a couple of years later we learned mor
Thanks peeps for responding to Kris. Kris, I had offered a response – do you
need further information answered? It looks to me like all the questions have
been answered by others in the community. If not, feel free to respond and
I’ll answer the remainders.
Sean when your around and I am ple
+1
On 23.1.2017 20:03, Emilien Macchi wrote:
Greeting folks,
I would like to propose some changes in our core members:
- Remove Jay Dobies who has not been active in TripleO for a while
(thanks Jay for your hard work!).
- Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
do
Hello OpenStack developers!
My name is Ian and I am now serving I18n PTL for Ocata cycle.
For previous releases, I18n team set higher priorities for translations
on Horizon and Horizon plugins
during Soft and Hard StringFreezes to include user-faced translated
strings as much as possible withi
On 25/01/2017 01:08, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
>
> The Neutron API is already v
Thanks for reply.
But « a priori » log say « this error can be safely ignore ». And therefore,
this log comes from the live migration that succeeded (compute 2 to compute 1).
The ERROR that questions me is (live migration compute 1 to 2), on compute 1:
2017-01-25 11:03:58.475 113231 ERROR nova.v
+1
Thanks Stephen! And welcome aboard Dharmendra!
Bob
On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote:
Tackers,
I'd like to propose following changes to the Tacker core team.
Stephen Wong
After being associated with Tacker project from its genesis, Stephen
Wong (irc: s3wong) has decided to s
On 01/25/2017 09:16 AM, Monty Taylor wrote:
> On 01/24/2017 12:39 PM, Chris Dent wrote:
>> On Mon, 23 Jan 2017, Sean Dague wrote:
>>
>>> We all inherited a bunch of odd and poorly defined behaviors in the
>>> system we're using. They were made because at the time they seemed like
>>> reasonable tra
Le 25/01/2017 05:10, Matt Riedemann a écrit :
> On 1/24/2017 2:57 PM, Matt Riedemann wrote:
>> On 1/24/2017 2:38 PM, Sylvain Bauza wrote:
>>>
>>> It's litterally 2 days before FeatureFreeze and we ask operators to
>>> change their cloud right now ? Looks difficult to me and like I said in
>>> mul
Hi all,
Brian kindly emailed the list last week [1] with our priorities for
python-glanceclient and glance.
The python-glanceclient priorities have all been effectively reviewed
and python-glanceclient has been released. The stable/ocata branch for
it now exists as well.
If you are reviewing Gla
On Wed, Jan 25 2017, Afek, Ifat (Nokia - IL) wrote:
> As we see it, alarms can be generated by different sources – Aodh, Vitrage,
> Nagios, Zabbix, etc.
I think "generated" is the wrong word here. Aodh does not generate any
alarms: it allows users to create them. And then it evaluates them and
tr
On Mon, Jan 23, 2017 at 02:03:28PM -0500, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common
On Tue, Jan 24, 2017 at 07:03:56PM +0200, Juan Antonio Osorio wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
> I thin
On Tue, Jan 24, 2017 at 08:52:51AM -0500, Emilien Macchi wrote:
> I have been discussed with TripleO UI core reviewers and it's pretty
> clear Honza's work has been valuable so we can propose him part of
> Tripleo UI core team.
> His quality of code and reviews make him a good candidate and it woul
On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote:
> Hi, as part of the composable upgrades workflow shaping up for Newton to
> Ocata, we need to install the new hiera hook that was first added with
> [1] and disable the old hook and data as part of the upgrade
> initialization [2]. Mo
I'm happy to announce my candidacy for Watcher PTL for the Pike release cycle.
I've been working on OpenStack for 2.5 years as engineer. My contributions
have been started in February 2016, they are related to Watcher and Rally
projects. I'm very proud of being one of core developers in Watcher pr
LBaaS is a little special since Octavia will have it's own API endpoint
completely that they will evolve on their own. The other spun-out projects
(e.g. VPNaaS) will have the API defined in neutron-lib[1].
The specific DVR issue you are referring to with roaming IPs being the
target of floating IP
On 01/25/2017 06:16 AM, Monty Taylor wrote:
I have quibble with the current microversions construct. It's mostly
semantic in nature, and I _think_ it's not valid/useful - but I'm going
to describe it here just so that I've said it and we can all acknowledge
it and move on.
My concern is with th
> Update on that agreement : I made the necessary modification in the
> proposal [1] for not verifying the filters. We now send a request to the
> Placement API by introspecting the flavor and we get a list of potential
> destinations.
Thanks!
> When I began doing that modification, I know there
Hi Team
Just a quick reminder that next Thursday marks our second bug day for the
year.
Please focus on triage and resolution of bugs across the openstack charms -
the new bugs URL is in the topic in #openstack-charms on Freenode IRC.
Happy bug hunting!
Cheers
James
___
Hello,
I would like to announce migration of openstack-salt to join remaining
formulas of the ecosystem.
Since today, openstack-salt and other formulas are living at
github.com/salt-formulas.
In the past few years this ecosystem has grown to more than 90 formulas
suitable for deployment of anythi
Filip,
Thanks for the announce. Can you please follow the steps below to
retire the projects in openstack git repo?
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
Thanks,
Dims
On Wed, Jan 25, 2017 at 11:39 AM, Filip Pytloun wrote:
> Hello,
>
> I would like to announce mi
As discussed in todays team meeting [0]:
* the vote is closed
* the deprecation is delayed
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-01-25-16.01.log.html
Christian.
--
Christian Berendt
Chief Executive Officer (CEO)
Mail: bere...@betacloud-solutions.de
Web: https://www.bet
I've started looking into what kind of request load the placement
API can expect when both the scheduler and the resource tracker are
talking to it. I think this is important to do now before we have
things widely relying on this stuff so we can give some reasonable
advice on deployment options a
> Hi,
>
> In RDO we are preparing for the incoming Ocata release. This means
> we'll create a new RDO Trunk builder "centos-ocata" in the next few
> days (It will be ready for next week). This builder will get content
> from stable/ocata branches of projects as they become available and
> fallback
On Tue, Jan 24, 2017 at 4:39 PM, Emilien Macchi wrote:
> OpenStack community decided to officially support Python 3.5 by the
> end of Pike cycle:
> https://governance.openstack.org/tc/goals/pike/python35.html
>
> To track this work in TripleO, I created a blueprint:
> https://blueprints.launchpad.
On Wed, Jan 25, 2017 at 12:13 PM, Javier Pena wrote:
>> Hi,
>>
>> In RDO we are preparing for the incoming Ocata release. This means
>> we'll create a new RDO Trunk builder "centos-ocata" in the next few
>> days (It will be ready for next week). This builder will get content
>> from stable/ocata b
On 01/25/2017 04:32 PM, Steven Hardy wrote:
> On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote:
>> Hi, as part of the composable upgrades workflow shaping up for Newton to
>> Ocata, we need to install the new hiera hook that was first added with
>> [1] and disable the old hook and dat
+1 for both.
Regards
Bharath T
Imaginea Technologies Inc.
On Wed, Jan 25, 2017 at 8:19 PM, HADDLETON, Robert W (Bob) <
bob.haddle...@nokia.com> wrote:
> +1
>
> Thanks Stephen! And welcome aboard Dharmendra!
>
> Bob
>
>
> On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote:
>
>> Tackers,
>>
>> I'd li
My sincere Thanks to every Glance core. You all have inspired
me right from day one. I hope to perform my duties as a Glance
Core to the best of my abilities and help make Glance great.
Thanks,
Dharini Chandrasekar.
On 1/24/17, 07:36, "Brian Rosmaita" wrote:
>I'd like to propose Dharini Ch
Catching up on the thread, lots of good thoughts.
I don't think there is disagreement here around how Networking API
should evolve in terms of vendor extensions. As Kevin suggested, we
don't want to advertise API extensibility without Neutron team
supervision.
One of the reasons behind current ap
Folks, this is a great discussion. I hope this leads us to some good
consensus and direction :-)
I would suggest that we discuss this in upcoming PTG meeting as well.
On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton wrote:
> >So I'm not sure that Kevin and Thierry's answers address Sukhdev's point
On Wed, Jan 25, 2017 at 7:45 AM, Kevin Benton wrote:
> LBaaS is a little special since Octavia will have it's own API endpoint
> completely that they will evolve on their own. The other spun-out projects
> (e.g. VPNaaS) will have the API defined in neutron-lib[1].
In a way, VPNaaS is also special
Folks,
This thread has gotten too long and hard to follow.
It is clear that we should discuss/address this.
My suggestion is that we organize a session in Atlanta PTG meeting and
discuss this.
I am going to add this on the Neutron etherpad - should this be included in
any other session as well?
+1 to Dharmendra, great addition.
Thank you very much Stephen for your contributions.
-Sripriya
On 1/24/17, 4:58 PM, "Sridhar Ramaswamy" wrote:
Tackers,
I'd like to propose following changes to the Tacker core team.
Stephen Wong
After being associated with Tacker
On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor
wrote:
> Given the latest issues related with the memory consumption[1] in CI jobs,
> I’m just wondering if you have a plan to deal and/or improve it in Neutron.
AFAIU the root cause is still not clear, and we don't know if it's
Neutron or job se
I've got this on my list of things to look at -- I don't know if it was you
I was talking with on IRC the other day about this issue, but I'm
definitely aware of it. As soon as we are past the Ocata feature freeze
crunch, I'll take a closer look.
My gut says that we should be calling the delete (w
On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday
wrote:
> Thanks for bringing this up!
>
> I was assuming that from Ocata everyone should switch from usage 'old'
> TunnelTypeDriver to updated one.
I am not sure. We haven't marked the 'old' one with any deprecation
warnings, did we? For Ocata at lea
On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton wrote:
> >I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions
>
> The Neutron API
o/
I'd like to request an FFE on
https://blueprints.launchpad.net/horizon/+spec/reorganise-access-and-security.
This blueprint splits up the access and security tabs into 4 distinct panels.
The first two patches are https://review.openstack.org/#/c/408247 and
https://review.openstack.org/#/c/4
Hi all,
Apologies for the late notice, but there won't be a cells meeting this
afternoon being that everyone is busy scrambling for the feature freeze
deadline this week. Let's catch up after FF.
Thanks,
-melanie
__
Open
Excerpts from Andreas Jaeger's message of 2017-01-25 08:40:16 +0100:
> On 2017-01-25 08:24, Andreas Jaeger wrote:
> > On 2017-01-25 05:03, Matthew Thode wrote:
> >> On 01/24/2017 09:57 PM, Matthew Thode wrote:
> >>> Basically I'd like to ask the docs people if they are fine with updating
> >>> th
On 01/23/2017 11:03 AM, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-t
Hi Ihar,
While doing the integration for vlanallocation [1] I found that OVO associated
with VlanAllocation throws “unhashable type” error with py35.
The associated stack trace is here [2].
To resolve this issue I added an equality and hash method in the vlanallocation
OVO [3].
My understanding
Looking at the code, I don't see a clear case to even use set() type
there. A list would seem to work just fine. Should we try to convert
to using lists there?
Nevertheless, we can look into extending the object base class for
hashing. I wonder though if it's something to tackle in Neutron scope.
+1We very much need this as the performance of that panel is awful. This solves that problem while being a fairly minor code change which also provides much better UX.On 26/01/2017 8:07 AM, Rob Cresswell wrote:
o/
I'd like to request an FFE on https://blueprints.launchpad.net/horizon/+spec/
I'm not experienced in reading these things, but it seems that nothing is
currently getting through the integrated gate, and from [1] it appears this
is because the gate-tempest-dsvm-neutron-full-ubuntu-xenial job of [2] has
hung.
[1] http://status.openstack.org/zuul/
[2] https://review.openstack.
On 2017-01-25 20:05:04 + (+), Neil Jerram wrote:
> I'm not experienced in reading these things, but it seems that nothing is
> currently getting through the integrated gate, and from [1] it appears this
> is because the gate-tempest-dsvm-neutron-full-ubuntu-xenial job of [2] has
> hung.
>
Thanks for the explanation. I agree that it has indeed moved now!
On Wed, Jan 25, 2017 at 8:18 PM Jeremy Stanley wrote:
> On 2017-01-25 20:05:04 + (+), Neil Jerram wrote:
> > I'm not experienced in reading these things, but it seems that nothing is
> > currently getting through the int
I would certainly be interested in dicussing this, though I'm not currently
signed up for the PTG. Obviously this is close to my interests, and I see
Kevin's raised Gluon as the bogeyman (which it isn't trying to be).
Setting aside all the above talk about how we might do things for a moment:
to
HI, all
I'd like to propose a bit different approach to run experimental jobs in
TripleO CI.
As you know we have OVB jobs and not-OVB jobs, and different pipelines for
running these two types of them.
What is current flow:
if you need to run experimental jobs, you write comment with "check
experi
On Wed, Jan 25, 2017 at 3:42 PM, Sagi Shnaidman wrote:
> HI, all
>
> I'd like to propose a bit different approach to run experimental jobs in
> TripleO CI.
> As you know we have OVB jobs and not-OVB jobs, and different pipelines for
> running these two types of them.
>
> What is current flow:
> if
On 01/25/2017 08:16 AM, Monty Taylor wrote:
> On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:
>>
>> Ihar and Kevin,
>>
>> As our potential future PTLs, I would like to draw your attention to one
>> of the critical issue regarding Neutron as "the" networking service in
>> OpenStack.
>>
>> I keep hear
Hi, Rob,
First, thanks for your work!
What's your plan for the other two tabs (security group, floatingip)? I
could see the split is very helpful no matter from performance perspective
and both useful from end user's perspective.
BTW, a huge +1 for this FFE!
Cheers,
Lingxian Kong (Larry)
On
Hi Rob, FFE granted for those two in-flight patches.
On 26 January 2017 at 09:23, Lingxian Kong wrote:
> Hi, Rob,
>
> First, thanks for your work!
>
> What's your plan for the other two tabs (security group, floatingip)? I
> could see the split is very helpful no matter from performance perspecti
I am preparing for PTG sessions.
How much capacity is in each room ? 30 people or more?
We might want to have different discussions or coding meetups in
parallel in the same room, because each developer concentrates on
different working topics (Tempest, Devstack, Grenade, Patrole, etc
under QA pro
On 18:16 Jan 24, Mikhail Fedosin wrote:
> Hey, Flavio :) Thanks for your questions!
>
> As you said currently only Nokia's adopting Glare for its own platform, but
> if we talk about OpenStack, that I believe Mistral will start to use it
> soon.
> In my opinion Glare's adoption is low due to the f
I think the keystone team is in the same spot.
We have an etherpad [0] for jotting down ideas, but we haven't parsed it or
grouped it in into topics yet. I think we were going to start working on
that next week since we're still in the middle of wrapping up the last few
bits for ocata-3. I was jus
On 25 January 2017 at 14:17, Monty Taylor wrote:
> > Adding an additional networking project to try to solve this will only
> > make things work. We need one API. If it needs to grow features, it
> > needs to grow features - but they should be features that all of
> > OpenStack users get.
>
> WOR
I would like to comment a little bit regarding usage of Glare in
Murano and Mirantis OpenStack:
> How much have these projects adopted Glare?
Glare is preferred backend for storing murano packages, which provides
versioning capabilities (they are not available without it)
>Is Glare being deployed
Big Thanks! from me too. The old UI here was very unintuitive, so I had to
field a lot of questions related to it. This is great. :)
Kevin
From: Lingxian Kong [anlin.k...@gmail.com]
Sent: Wednesday, January 25, 2017 2:23 PM
To: OpenStack Development Mailing List (
1 - 100 of 119 matches
Mail list logo
