fuel-dev team mailing list archive

[Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>]

David,

Thanks for clarifying. I believe there's been 100+ messages on that topic
in the mailing list already. We need a very concise description and visual
for the upgrade/patching process, so it can be included into docs/release
notes.

Thanks,
Roman


On Thu, Sep 4, 2014 at 1:39 PM, David Easter <deaster@xxxxxxxxxxxx> wrote:

> > Upgrading master node to 5.1 also automatically upgrades 5.0.x
> components to 5.0.2
>
> Just to clarify further, while it is correct that upgrading the Fuel
> Master Node to 5.1 makes 5.0.2 an available release for updating an
> existing 5.0 (or 5.0.1) environment, it does not execute the update of an
> existing environment automatically – the operator has to choose the action
> of updating.
>
> Thanks,
>
> - David J. Easter
>   Director of Product Management,   Mirantis, Inc.
>
> From: Miroslav Anashkin <manashkin@xxxxxxxxxxxx>
> Date: Thursday, September 4, 2014 at 9:35 PM
> To: Meg McRoberts <mmcroberts@xxxxxxxxxxxx>
>
> Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Fuel-dev] Details about 5.0.2
>
> What is the succinct explanation for why one would upgrade to 5.0.2
> instead of 5.1?
>
> One would not.
> Upgrading master node to 5.1 also automatically upgrades 5.0.x components
> to 5.0.2
>
>
> On Thu, Sep 4, 2014 at 9:57 PM, Meg McRoberts <mmcroberts@xxxxxxxxxxxx>
> wrote:
>
>> Thanks, Miroslav!  A couple more questions:
>>
>> - What is the succinct explanation for why one would upgrade to 5.0.2
>> instead of 5.1?
>> - What sort of presentation of this information is most useful?  Should
>> the Release Notes
>>   include a separate section called "Resolved issues in Fuel 5.0.2"?  Or
>> should the 5.1
>>   "Known Issues" list mark the appropriate issues as "also included in
>> 5.0.2"?  Some
>>   other option?
>>
>> meg
>>
>>
>> On Thu, Sep 4, 2014 at 10:33 AM, Miroslav Anashkin <
>> manashkin@xxxxxxxxxxxx> wrote:
>>
>>> Hi Meg,
>>>
>>> About 5.0.2.
>>>
>>> Since upcoming MOS 5.1 should include the released 5.0.1 fixes as well,
>>> the latest stable build from MOS 5.0.x branch will be included to 5.1
>>> And since 5.0.x have fixes, made after 5.0.1 release - this 5.0.x
>>> version, shipped with 5.1 will be newer than released 5.0.1.
>>> We called it 5.0.2
>>> Some of the fixes, listed below, were back ported from 5.1, some made in
>>> order to improve master node upgrade stability.
>>>
>>>
>>> What changes, made after 5.0.1 release does 5.0.2 include (sorry for
>>> post-copy/paste formatting issues):
>>>
>>> #######################################################################################
>>> 1.
>>> Multiple fixes to built-in tests.
>>> ------------------
>>> 2.
>>> Major improvement with full underlaying algorithm change to the Verify
>>> Network feature in order to get it more stable and scalable:
>>>
>>>
>>> 2.1
>>>
>>> Use tcpdump for traffic dumping in net_probe
>>>
>>> I found out that tcpdump much more reliable than
>>> python libpcap bindings, and works well under load
>>>
>>> - start tcpdump listeners for each iface
>>>   (will catch both tagged/untagged traffic)
>>> - deserealize pcap data with help of scapy rdpcap util
>>> - all pcap file will be stored in /var/run/pcap_dir by default
>>>   and maybe attached to diagnostic snapshot
>>>
>>> Closes-Bug: 1306705
>>>
>>>
>>> 2.2
>>> Sending predefined amount of packets for each interface:vlan pair
>>> can still result in random verify_networks failures on heavily loaded
>>> environments
>>>
>>> - sender will generate traffic based on time provided with --duration
>>> option
>>>   or from config file, defaults to 20 sec
>>> - repeat option will be used to configure amount of packets per
>>> iface:vlan
>>>   pair sended in each iteration, defaults to 2 packets
>>>
>>> Partial-Bug: 1306705
>>>
>>>
>>> 2.3
>>>
>>> Tune net_check generator params
>>>
>>> Huge load of traffic could not be processed under time
>>> constraints that we have either in system tests/orchestrator
>>>
>>> - change duration of traffic generation to 5 sec
>>> - send only 1 packets in each iteration
>>>
>>> Closes-Bug: #1306705
>>>
>>> ------------------
>>> 3.
>>>
>>> Add all neutron packages to requirements
>>>
>>> It has come up in several requests that we should have packages present
>>> for
>>>  all of the neutron components so that any patches we might have
>>> included are
>>>  present in the repos on the fuel-master.
>>>
>>> This is not intended to be a "fuel suppports ..." but rather enables
>>> users to
>>>  customize their deployment accordingly and not have to find packages
>>> that
>>>  where not built from the same sources which would cause more problems
>>> for
>>>  them.
>>>
>>> Closes-bug: #1330610
>>> Related-blueprint: ml2-neutron
>>> ------------------
>>>
>>> 4.
>>> Fixes to master node upgrade functionality
>>> ------------------
>>> 5.
>>> Fix idempotency issue for rabbit management plugin
>>>
>>> Closes-Bug: #1355708
>>> ------------------
>>>
>>> 6.
>>> Fixed setting GUID on cephjournals for ubuntu
>>>
>>>
>>> The issue was that pmanager created ceph-journal partitions (one for
>>> every ceph-osd) but guid was set for only one ceph-journal partition.
>>>
>>> Closes-Bug: #1355342
>>> ------------------
>>>
>>> 7.
>>> Fixed setting GUID on cephjournals for ubuntu
>>>
>>>
>>> The issue was that pmanager created ceph-journal partitions (one for
>>> every ceph-osd) but guid was set for only one ceph-journal partition.
>>>
>>> Closes-Bug: #1355342
>>> ------------------
>>>
>>> 8.
>>> "Fix logging to multiple remote rsyslog servers"
>>> ------------------
>>> 9.
>>> "Add modify_horizon_config script"
>>> ------------------
>>> 10.
>>> Use murano-db-manage to run upgrades
>>>
>>>
>>> In previous versions of Murano the command used to manage database was
>>> 'murano-manage'. Now it is changed to 'murano-db-manage', however,
>>> 'murano-manage' still exists. This patch fixes the name of the command, and
>>> renames variable used to store path to 'murano-db-manage' to avoid
>>> confusion between the two available commands.
>>>
>>> Closes-bug: #1358738
>>> ------------------
>>> 11.
>>> Wait for keystone to become ready for floatingip creation
>>>
>>> Wait for keystone service to become ready otherwise
>>> haproxy reload can lead to haproxy returning
>>> empty response and thus nova-floating-range provider
>>> can not authorize with nova.
>>>
>>> Closes-bug: 1351253
>>> Closes-bug: 1348171
>>> ------------------
>>> 12.
>>> Fix haproxy backend checks dependencies
>>>
>>>
>>> Openstack::Ha::Haproxy_service['keystone*'] should always be evaluated
>>> *before* any Exec['wait-for-keystone*'] backend checks.
>>>
>>> Closes-bug: 1352964
>>> ------------------
>>> 13.
>>> Ensure swift ring sync after its packages installed
>>>
>>> Closes-bug: #1360118
>>> ------------------
>>>
>>> 14.
>>> Fix HA mode troubles with Heat
>>>
>>>
>>> HAProxy configuration doesn't include Heat services CFN and
>>> Cloudwatch API (on port 8000 and 8003) as a result this services
>>> unavailable via public interface.
>>>
>>> Closes-bug: #1353348
>>> ------------------
>>> 15.
>>> Turned rabbitmq autoheal partitions on
>>> ------------------
>>> 16.
>>> Fix mysqld backend check dependency
>>> ------------------
>>> 17.
>>> Limit nova_floating_range to primary controller
>>> ------------------
>>> 18.
>>> Set vcenter_hash to empty hash for default
>>> ------------------
>>> 19.
>>> Drop all unmatched traffic in iptables
>>> ------------------
>>> 20.
>>> Add the iptables rule to allow GRE traffic
>>> ------------------
>>> 21.
>>> Fix rabbitmqctl status for rabbitmq container
>>> ------------------
>>> 22.
>>> Setup IP forwarding in base system for ns_IPaddr2 resources
>>>
>>>
>>> Closes-bug: #1342073
>>> Closes-bug: #1340968
>>> ------------------
>>> 23.
>>> Fix haproxy backend checks dependencies
>>> ------------------
>>> 24.
>>> Disabled sshd GSSAPI auth by default
>>> ------------------
>>> 25.
>>> Added more diagnostic tools to CentOS-based nodes
>>> ------------------
>>> 26.
>>> Fix dump_cib method for corosync service provider
>>> ------------------
>>> 27.
>>> Disable Openstack services startup on install
>>>
>>> Upstart makes services went off once installed.
>>> We're wanting them started only then configured.
>>> If ceph is used volumes, leave cinder-volume override
>>> on its own (rbd.pp will configure it).
>>>
>>> Closes-bug: #1348185
>>> Closes-bug: #1335804
>>> ------------------
>>>
>>> 28.
>>> more strong order in Neutron manifests
>>>
>>> between keystone roles and inserting 'service' tenant-ID to the neutron
>>> config.
>>>
>>> Closes-bug: #1328462
>>> ------------------
>>>
>>> 29.
>>> Configure haproxy keystone backend before keystone service
>>>
>>> Configure haproxy keystone backend before keystone service
>>> starts. This will fix ordering problem when we have keystone
>>> resources created before keystone is available. Service
>>> is already started before resources creation, so that
>>> puppet provider will receive a couple of 503|504 HTTP
>>> errors in the worst case and handle them.
>>>
>>> Closes-bug: #1357386
>>>
>>> ------------------
>>>
>>> 30.
>>> Fix the Neutron DB creation during deployment
>>>
>>> Neutron database should be created by the Neutron db migration scripts,
>>> but they are ignored during deployment of HA clusters. The problem is
>>> the migration scripts depends on neutron-server package installation,
>>> but it's installed as a dependency for the OVS server package, so no
>>> necessary event was produced by Puppet. Now it's installed separately.
>>>
>>> Closes-bug: #1361541
>>> ------------------
>>>
>>> 31.
>>> Reverted the following commit  "cron job to clean up rabbitmq
>>> connections"
>>>
>>> This reverts commit 27838
>>> Related-bug: #1341656
>>> ------------------
>>>
>>> 32.
>>> Add openstack dependencies installation for 5.0.2
>>>
>>> Add explicit 5.0.2 packages installation for 5.0.2
>>> Fuel release
>>>
>>> Closes-bug: #1359705
>>> ------------------
>>>
>>> 33.
>>> Add missing notify dependencies
>>>
>>> Packages should notify services to restart if package is updated
>>> Closes-Bug: 1362675
>>> ------------------
>>>
>>> 34.
>>> Refactor swift-account-replicator service
>>>
>>> Start service as a normal service instead of
>>> using exec.
>>>
>>> Closes-Bug: 1363163
>>> ------------------
>>>
>>> 35.
>>> Add hasrestart to some services
>>>
>>>
>>> (5.0.X backport)
>>> Hasrestart makes Puppet use restart instead of stop
>>> and start to manage a service and many init scripts
>>> would work better if used like this.
>>>
>>> Closes-Bug: 1364119
>>> ------------------
>>>
>>> 36.
>>> Fixed DB connection options
>>>
>>> Changed placement of database settings from DEFAULT to database section
>>> of the heat.conf * sql_connection option is deprecated
>>> Related-Bug: #1364026
>>>
>>>
>>> #####################################################################################################
>>>
>>> Kind regards,
>>>
>>> Miroslav Anashkin
>>>
>>> L2 Support Engineer
>>>
>>> Fuel Core Team
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 4, 2014 at 12:57 PM, Meg McRoberts <mmcroberts@xxxxxxxxxxxx>
>>> wrote:
>>> >
>>> > Do we have any sort of detailed description about what is in 5.0.2?
>>> > Or maybe what is in 5.1 that is not in 5.0.2?
>>> >
>>> > Thanks much!
>>> > meg
>>> >
>>> > --
>>> > Mailing list: https://launchpad.net/~fuel-dev
>>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~fuel-dev
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Kind Regards
>>> Miroslav Anashkin
>>> L2 support engineer,
>>> Mirantis Inc.
>>> +7(495)640-4944 (office receptionist)
>>> +1(650)587-5200 (office receptionist, call from US)
>>> 35b, Bld. 3, Vorontsovskaya St.
>>> Moscow, Russia, 109147.
>>>
>>> www.mirantis.com
>>>
>>> manashkin@xxxxxxxxxxxx
>>>
>>
>>
>
>
> --
>
> *Kind Regards*
>
> *Miroslav Anashkin**L2 support engineer**,*
> *Mirantis Inc.*
> *+7(495)640-4944 <%2B7%28495%29640-4944> (office receptionist)*
> *+1(650)587-5200 <%2B1%28650%29587-5200> (office receptionist, call from
> US)*
> *35b, Bld. 3, Vorontsovskaya St.*
> *Moscow**, Russia, 109147.*
>
> www.mirantis.com
>
> manashkin@xxxxxxxxxxxx
>
>  -- Mailing list: https://launchpad.net/~fuel-dev Post to :
> fuel-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~fuel-dev
> More help : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>