plit('/templates/')" does not cause the trouble.
>
> Cheers,
> Mateusz
>
>> On 5 Feb 2018, at 14:44, Saverio Proto wrote:
>>
>> Hello,
>>
>> I have tried to find a fix to this:
>>
>> https://ask.openstack.org/en/question/107544/ocata-
.
- are we two operators hitting a corner case ?
- No one else uses Horizon with custom themes in production with
version newer than Newton ?
This is all food for your brainstorming about LTS,bugfix branches,
release cycle changes
Cheers,
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Hello !
thanks for accepting the patch :)
It looks like the best is always to send an email and have a short
discussion together, when we are not sure about a patch.
thank you
Cheers,
Saverio
__
OpenStack Development Mail
on.
>
>> But merging a patch that changes a log file in Nova back to Newton was
>> OKAY few weeks ago.
> Could you provide a link to that one ?
sure, here it is:
https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea
Thank you
Saverio
--
SWITCH
Saveri
>>> https://docs.openstack.org/project-team-guide/stable-branches.html for
>>> current policies.
>>>
>>> On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto
>>> wrote:
>>>>> Which stable policy does that patch violate? It's clearly a bug
>&g
> 3.34.0 is a queens series release, which makes it more likely that more
> other dependencies would need to be updated. Even backporting the
> changes to the Ocata branch and releasing it from there would require
> updating several other libraries.
>
That is what I was fearing. Consider that our
t;
>
> ch = logging.StreamHandler()
> ch.setLevel(logging.DEBUG)
>
> formatter = formatters.JSONFormatter()
> ch.setFormatter(formatter)
>
> LOG = logging.getLogger()
> LOG.setLevel(logging.DEBUG)
> LOG.addHandler(ch)
>
> ctx = context.RequestCon
uld be possible for you to update just oslo.log to a more
>>> recent (and supported), although to do so you would have to get the
>>> package separately or build your own and that may complicate your
>>> deployment.
>>>
>>> More recent versions of the JS
ther than that? If so, we probably want to wait to debug this
> until you hit the latest supported version you're planning to deploy,
> in case the problem is already fixed there.
>
> Doug
>
> ______
>
n eye on
> oslo.log bugs at this point, so be realistic in when it might get looked at.
>
> On 01/18/2018 03:06 AM, Saverio Proto wrote:
>> Hello Sean,
>> after the brief chat we had on IRC, do you think I should open a bug
>> about this issue ?
>>
>> tha
Hello Sean,
after the brief chat we had on IRC, do you think I should open a bug
about this issue ?
thank you
Saverio
On 13.01.18 07:06, Saverio Proto wrote:
>> I don't think this is a configuration problem.
>>
>> Which version of the oslo.log library do you have ins
> I don't think this is a configuration problem.
>
> Which version of the oslo.log library do you have installed?
Hello Doug,
I use the Ubuntu packages, at the moment I have this version:
python-oslo.log 3.16.0-0ubuntu1~cloud0
thank you
Saverio
_
at nova-api and I have the same problem. Anyway in my
Kibana I never so a req-UUID what so ever, so this looks like a problem
with all the openstack services.
Is it a problem with my logging configuration ?
thank you
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box,
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
http://www.switch.ch/stories
> Which stable policy does that patch violate? It's clearly a bug
> because the wrong information is being logged. I suppose it goes
> against the string freeze rule? Except that we've stopped translating
> log messages so maybe we don't need to worry about that in this case,
> since it isn't an
Hello,
here an example of a trivial patch that is important for people that
do operations, and they have to troubleshoot stuff.
with the old Stable Release thinking this patch would not be accepted
on old stable branches.
Let's see if this gets accepted back to stable/newton
https://review.open
/mailman/listinfo/openstack-operators
>
>
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje
> The ucast-mac-remote table is filled with information that don't match
> your comments. In my environment, I have created only one neutron
> network, one l2gw instance and one l2gw connection. However, the mac
> reflected in that table corresponds to the dhcp port of the Neutron
> network (I've c
> will be paused and nova will wait for info from neutron that port is active
> (You should also check credentials config in neutron server)
> If You will set also vif_plugging_is_fatal=True then nova will put instance
> in ERROR state if port will not be active after timeout time.
>
il port will be set to ACTIVE in
> Neutron.
>
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
http://
? It looks like a race condition where
nova boots the instance before the neutron port is really ready.
thank you for your feedback.
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...
Hello,
I try again. Any l2gw plugin user that wants to comment on my email ?
thank you
Saverio
On 29/05/17 16:54, Saverio Proto wrote:
> Hello,
>
> I have a question about the l2gw. I did a deployment, I described the
> steps here:
> https://review.openstack.org/#/c/453209/
&
of the game.
Is anyone running this in production and can shed some light ?
thanks
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
h
? How does it work ?
thank you
Saverio
On 13/04/17 09:52, Rabi Mishra wrote:
> On Thu, Apr 13, 2017 at 1:04 PM, Saverio Proto <mailto:saverio.pr...@switch.ch>> wrote:
>
> Hello,
>
> I am looking at a strange change in default behavior in heat, after the
&
hy it changed from Mitaka to Newton ? Is possible this is a
regression bug ?
Thank you
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saver
nks for the feedback
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
http://w
of thinking that the neutron-l2gw-agent had
to run on the switch where the actual briding happens.
thank you
Saverio
On 30/03/17 18:40, Armando M. wrote:
>
>
> On 30 March 2017 at 08:47, Saverio Proto <mailto:saverio.pr...@switch.ch>> wrote:
>
> Hello,
>
&
information
to make the all thing work ?
Saverio
On 30/03/17 18:40, Armando M. wrote:
>
>
> On 30 March 2017 at 08:47, Saverio Proto <mailto:saverio.pr...@switch.ch>> wrote:
>
> Hello,
>
> I am trying to use the neutron l2gw plugin, but I am not usin
vtep openvswitch is not able
to talk to the compute nodes ?
thank you
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
http://www.switch.ch/stories
l2gw_alembic_version;
I would strongly suggest to have a common prefix like l2gw_ for all the
tables that belong to the same neutron plugin.
How can I figure out if I missed a table without reading all the code ?
Thank you
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich
thank you
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
http://www.switch.
> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ______
> OpenStack Development Mailing List (not for u
On 10/03/17 17:49, Michael Johnson wrote:
> Yes, folks have recently deployed the dashboard with success. I think you
> had that discussion on the IRC channel, so I won't repeat it here.
>
> Please note, the neutron-lbaas-dashboard does not support LBaaS v1, you must
> have LBaaS v2 deployed for
:
https://ask.openstack.org/en/question/96790/lbaasv2-dashboard-issues/
Is there anyone that has a working setup ?
Should I open a bug here?
https://bugs.launchpad.net/octavia/+filebug
Thanks
Saverio
On 09/03/17 16:19, Saverio Proto wrote:
> Hello,
>
> I managed to do the database
the old tables from LBaaSV1 be dropped ?
Please give me feedback so I can fix the code and submit a review.
thank you
Saverio
On 09/03/17 13:38, Saverio Proto wrote:
>> I would recommend experimenting with the database-migration-from-v1-to-v2.py
>> script and working with your vendor
> I would recommend experimenting with the database-migration-from-v1-to-v2.py
> script and working with your vendor (if you are using a vendor load
> balancing engine) on a migration path.
Hello,
there is no vendor here to help us :)
I made a backup of the current DB.
I identified this folder
>
> To answer your original question, the LBaaS v1 API as removed in the newton
> release of neutron-lbaas
> (https://docs.openstack.org/releasenotes/neutron-lbaas/newton.html).
>
> Michael
>
>
> -Original Message-
> From: Saverio Proto [mailto:saverio.pr.
nstack.org/releasenotes/neutron/ocata.html
thank you
Saverio
--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch
http://www.switch.
Hello,
I just subscribed this list, usually I am on the operators list.
I have been reading the archives of this list:
http://lists.openstack.org/pipermail/openstack-dev/2016-June/097947.html
I am more than happy to hear that packages will be built in the
Openstack infra. Are we going to be able
39 matches
Mail list logo