Re: [Openstack-operators] Openstack release compatibility

2017-11-03 Thread Jean-Philippe Evrard
Hello,

I think you'll face end user downtime anyway, due to _at least_
neutron agents flapping. But yes it can be fairly limited.
I can't say for restart or no restart. I think it's possible to do
without restarting, but I also think you should have plan for the
restarts, else how do you do your critical security updates for things
like kernel?

Just my 2 cents, it's probably good to have other opinions out there.

Best regards,
Jean-Philippe Evrard (evrardjp)

On 3 November 2017 at 13:19, haad  wrote:
> Hi,
>
> I have one additional question. What is your experience with updating
> OpenStack in place on compute nodes with out rebooting them. Can we update
> e.g. mitaka to newton and leave machines running on compute node running ?
> (if libvirt/kvm/os update is necessary we can do it after.)
>
> On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard
>  wrote:
>>
>> On 2 November 2017 at 18:17, Chris Friesen 
>> wrote:
>> > On 10/31/2017 01:13 AM, haad wrote:
>> >>
>> >> Hi,
>> >>
>> >> We have an OSA installation with 10-12 compute nodes running Mitaka on
>> >> Ubuntu
>> >> 16.04. As initially we have not prepared any long term update strategy
>> >> we
>> >> would
>> >> like to create one now. Plan would be to upgrade it to new OSA
>> >> release(Ocata/Pike/Queens) in near future.
>> >>
>> >> Our original plan was to update management/networking/backend at once
>> >> by
>> >> using
>> >> rolling updates to newer release and then upgrade compute nodes one by
>> >> one
>> >> to
>> >> new release.. I think that [2] provides a general upgrade manual. Is
>> >> there
>> >> any
>> >> document describing how are different OSA releases compatible ? Is
>> >> there
>> >> any
>> >> policy in place about backward compatibility ?
>> >
>> >
>> > As a general rule, OpenStack only supports an online upgrade of one
>> > version
>> > at a time.  That is, controller nodes running version N can talk to
>> > compute
>> > nodes running version N-1.
>> >
>> > If you can tolerate downtime of the API layer, there has been some
>> > discussion around "skip-level" upgrades.
>> >
>> > Chris
>> >
>> >
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> Hello,
>>
>> Having worked on "skip level" upgrades, I can tell you that it's
>> simpler to do the upgrades in a row, because it's a more tested path.
>>
>> Best regards,
>> Jean-Philippe Evrard (evrardjp)
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> --
>
>
> Regards.
>
> Adam

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] Openstack release compatibility

2017-11-03 Thread haad
Hi,

I have one additional question. What is your experience with updating
OpenStack in place on compute nodes with out rebooting them. Can we update
e.g. mitaka to newton and leave machines running on compute node running ?
(if libvirt/kvm/os update is necessary we can do it after.)

On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:

> On 2 November 2017 at 18:17, Chris Friesen 
> wrote:
> > On 10/31/2017 01:13 AM, haad wrote:
> >>
> >> Hi,
> >>
> >> We have an OSA installation with 10-12 compute nodes running Mitaka on
> >> Ubuntu
> >> 16.04. As initially we have not prepared any long term update strategy
> we
> >> would
> >> like to create one now. Plan would be to upgrade it to new OSA
> >> release(Ocata/Pike/Queens) in near future.
> >>
> >> Our original plan was to update management/networking/backend at once by
> >> using
> >> rolling updates to newer release and then upgrade compute nodes one by
> one
> >> to
> >> new release.. I think that [2] provides a general upgrade manual. Is
> there
> >> any
> >> document describing how are different OSA releases compatible ? Is there
> >> any
> >> policy in place about backward compatibility ?
> >
> >
> > As a general rule, OpenStack only supports an online upgrade of one
> version
> > at a time.  That is, controller nodes running version N can talk to
> compute
> > nodes running version N-1.
> >
> > If you can tolerate downtime of the API layer, there has been some
> > discussion around "skip-level" upgrades.
> >
> > Chris
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> Hello,
>
> Having worked on "skip level" upgrades, I can tell you that it's
> simpler to do the upgrades in a row, because it's a more tested path.
>
> Best regards,
> Jean-Philippe Evrard (evrardjp)
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 


Regards.

Adam
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] Centos Ocata fwaas v2 not working

2017-11-03 Thread Ignazio Cassano
Hi guys,
I installaed fwaas module on ocata on centos 7.3 but enabling the version 2
some
errors are reported in l3-agent.log:

Could not load
neutron_fwaas.services.firewall.drivers.linux.iptables_fwaas_v2.IptablesFwaasDriver

and then a lot of errors_

017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent
Traceback (most recent call last):
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent   File
"/usr/lib/python2.7/site-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py",
line 220, in add_router
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent
self._process_router_add(new_router)
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent   File
"/usr/lib/python2.7/site-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py",
line 195, in _process_router_add
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent
fw_list = self.fwplugin_rpc.get_firewalls_for_tenant(ctx)
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent   File
"/usr/lib/python2.7/site-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py",
line 46, in get_firewalls_for_tenant
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent
return cctxt.call(context, 'get_firewalls_for_tenant', host=self.host)
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent   File
"/usr/lib/python2.7/site-packages/neutron/common/rpc.py", line 151, in call
2017-11-03 10:36:59.292 12576 ERROR
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent
return self._original_context.call(ctxt, method, **kwargs)


Please, could anyone help me in this step ?

Regards
Ignazio
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] Openstack release compatibility

2017-11-03 Thread Jean-Philippe Evrard
On 2 November 2017 at 18:17, Chris Friesen  wrote:
> On 10/31/2017 01:13 AM, haad wrote:
>>
>> Hi,
>>
>> We have an OSA installation with 10-12 compute nodes running Mitaka on
>> Ubuntu
>> 16.04. As initially we have not prepared any long term update strategy we
>> would
>> like to create one now. Plan would be to upgrade it to new OSA
>> release(Ocata/Pike/Queens) in near future.
>>
>> Our original plan was to update management/networking/backend at once by
>> using
>> rolling updates to newer release and then upgrade compute nodes one by one
>> to
>> new release.. I think that [2] provides a general upgrade manual. Is there
>> any
>> document describing how are different OSA releases compatible ? Is there
>> any
>> policy in place about backward compatibility ?
>
>
> As a general rule, OpenStack only supports an online upgrade of one version
> at a time.  That is, controller nodes running version N can talk to compute
> nodes running version N-1.
>
> If you can tolerate downtime of the API layer, there has been some
> discussion around "skip-level" upgrades.
>
> Chris
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Hello,

Having worked on "skip level" upgrades, I can tell you that it's
simpler to do the upgrades in a row, because it's a more tested path.

Best regards,
Jean-Philippe Evrard (evrardjp)

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators