fuel-dev team mailing list archive

[David Easter <deaster@xxxxxxxxxxxx>]

> - What is the succinct explanation for why one would upgrade to 5.0.2 instead
of 5.1?

The primary reason is that an environment deployed with the 5.0 architecture
cannot be updated to the 5.1 architecture.  Thus, the path for a customer
who initially deployed on 5.0.x would be to stay on that architectural
version, but update to later versions of that architecture to bring their
environment up to the latest OpenStack version.

In other words, if I deploy an environment using a 5.0 release choice, my
options for updating are to move to 5.0.1, 5.0.2, 5.0.3, 5.0.4, etc.   If I
deploy an environment an environment using the 5.1 release, my choices are
to update to 5.1.1, 5.1.2, 5.1.3, etc.   I cannot update from 5.0.1 to 5.1,
for example.

When deploying a new environment, the recommendation would be to deploy the
newest version of the newest architecture ­ I.e. in 5.1, that would be 5.1.
When 5.1.1 comes out, it would be 5.1.1, etc.  One would not typically
deploy 5.0.2 into a new environment.

> - What sort of presentation of this information is most useful?

My suggestion would be to have a section that details what is fixed in both
5.0.2 and 5.1, then have an additional section on issues only addressed in
5.1.

-Dave Easter

From:  Meg McRoberts <mmcroberts@xxxxxxxxxxxx>
Date:  Thursday, September 4, 2014 at 7:57 PM
To:  Miroslav Anashkin <manashkin@xxxxxxxxxxxx>
Cc:  "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
Subject:  Re: [Fuel-dev] Details about 5.0.2

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 <tel:%2B7%28495%29640-4944>  (office receptionist)
> +1(650)587-5200 <tel:%2B1%28650%29587-5200>  (office receptionist, call from
> US)
> 35b, Bld. 3, Vorontsovskaya St.
> Moscow, Russia, 109147.
> 
> www.mirantis.com <http://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