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 <deas...@mirantis.com> 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 <manash...@mirantis.com> > Date: Thursday, September 4, 2014 at 9:35 PM > To: Meg McRoberts <mmcrobe...@mirantis.com> > > Cc: "fuel-dev@lists.launchpad.net" <fuel-dev@lists.launchpad.net> > 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 <mmcrobe...@mirantis.com> > 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 < >> manash...@mirantis.com> 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 <mmcrobe...@mirantis.com> >>> 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@lists.launchpad.net >>> > 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 >>> >>> manash...@mirantis.com >>> >> >> > > > -- > > *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 > > manash...@mirantis.com > > -- Mailing list: https://launchpad.net/~fuel-dev Post to : > fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : fuel-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp