fuel-dev team mailing list archive

[Meg McRoberts <mmcroberts@xxxxxxxxxxxx>]

Yes, we definitely need clear and concise on this!  But we probably do not
need to subject
the entire mailing list to the discussions that aim to get us to that
point.  I'm going to cut the
mail thread down to a smaller group.  When I have drafted the docs, I'll
send notification to
the wider list for review.

meg


On Thu, Sep 4, 2014 at 1:49 PM, Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx
> wrote:

> 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
>>
>>
>