From me at gbraad.nl Fri Jul 1 01:14:02 2016 From: me at gbraad.nl (Gerard Braad) Date: Fri, 1 Jul 2016 09:14:02 +0800 Subject: [rdo-list] [CentOS-devel] [centos-ci] Artifacts server does not support ranges / resume of downloads? In-Reply-To: <20160630174308.GA27970@ender.bstinson.lan> References: <20160630174308.GA27970@ender.bstinson.lan> Message-ID: Hi, On Fri, Jul 1, 2016 at 1:43 AM, Brian Stinson wrote: > (perhaps a proxy in the middle?) > I did a few tests and got the usual response to http range requests. I was able to download the images again... and yes, it was able to do range requests. (In the situation of China it is impossible to know what it is in-between). regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] From me at gbraad.nl Fri Jul 1 03:15:22 2016 From: me at gbraad.nl (Gerard Braad) Date: Fri, 1 Jul 2016 11:15:22 +0800 Subject: [rdo-list] [tripleo] Baremetal introspection failing; missing required 'local_gb' Message-ID: Hi All, Donwloaded a new undercloud image for Mitaka, and performed a quickstart install to target two baremetal nodes. When performing introspection, the step fails with: + openstack baremetal configure boot + openstack baremetal introspection bulk start Setting nodes for introspection to manageable... Starting introspection of node: 7499cdf4-0f89-4250-a930-d7f927683ea6 Starting introspection of node: 07b94ab4-e4eb-4ea9-8b7a-e11983063135 Waiting for introspection to finish... Introspection for UUID 7499cdf4-0f89-4250-a930-d7f927683ea6 finished with error: The following required parameters are missing: ['local_gb'] Introspection for UUID 07b94ab4-e4eb-4ea9-8b7a-e11983063135 finished with error: The following required parameters are missing: ['local_gb'] Setting manageable nodes to available... Introspection completed with errors: 7499cdf4-0f89-4250-a930-d7f927683ea6: The following required parameters are missing: ['local_gb'] 07b94ab4-e4eb-4ea9-8b7a-e11983063135: The following required parameters are missing: ['local_gb'] This used to work previously... I created a bug for this at launchpad [1]. regards, Gerard [1] https://bugs.launchpad.net/tripleo-quickstart/+bug/1597982 -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] From marius at remote-lab.net Fri Jul 1 07:50:55 2016 From: marius at remote-lab.net (Marius Cornea) Date: Fri, 1 Jul 2016 09:50:55 +0200 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> Message-ID: Hi, For the stable branch you need the following, as mentioned in the docs[1] sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html#installing-the-undercloud On Thu, Jun 30, 2016 at 10:27 PM, Gunjan, Milind [CTO] wrote: > Hi Guys, > > I am still having issues while installing the undercloud. > > I have exhausted all the options and tried to do undercloud install as per > the tripleo guidelines. > > http://tripleo.org/installation/installation.html > > > > But, each time I hit the same errors: > > > > > > Error: > /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: > Could not evaluate: Execution of '/bin/openstack domain show --format shell > Default' returned 1: Could not find resource Default > > Error: > /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: > Could not evaluate: Execution of '/bin/openstack domain show --format shell > Default' returned 1: Could not find resource Default > > Error: Could not prefetch keystone_service provider 'openstack': Execution > of '/bin/openstack service list --quiet --format csv --long' returned 1: > Gateway Timeout (HTTP 504) > > Error: Not managing Keystone_service[glance] due to earlier Keystone API > failures. > > Error: > /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: > change from absent to present failed: Not managing Keystone_service[glance] > due to earlier Keystone API failures. > > Error: Could not prefetch keystone_role provider 'openstack': Execution of > '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout > (HTTP 504) > > Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API > failures. > > Error: > /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: > change from absent to present failed: Not managing > Keystone_role[ResellerAdmin] due to earlier Keystone API failures. > > Error: Not managing Keystone_service[ironic] due to earlier Keystone API > failures. > > Error: > /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: > change from absent to present failed: Not managing Keystone_service[ironic] > due to earlier Keystone API failures. > > > > Please suggest. > > > > > > > > > > From: Gunjan, Milind [CTO] > Sent: Wednesday, June 29, 2016 7:39 AM > To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o > deployment > > > > Okay . Updated the host file with shortname and fqdn. > > root at undercloud ~]# cat /etc/hosts > > 127.0.0.1 undercloud undercloud.poc > > I am looking to install stable release of Openstack kilo / liberty. Can you > please point me to the stable repo which I can pull for the install. > > > > Best Regards, > > Milind > > > > From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] > Sent: Wednesday, June 29, 2016 7:34 AM > To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o > deployment > > > > You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't > know if that's been fixed) > > On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: > > Thanks a lot for pointing out the mistakes. > > > > So, as suggested, I updated the hostname in the host file to match in > similar way as instructed in the docs: > > > > [root at undercloud ~]# cat /etc/hostname > > undercloud.poc > > > > [root at undercloud ~]# cat /etc/hosts > > 127.0.0.1 undercloud.poc > > > > Is there any stable kilo package which can be used for installation ? > > > > Best Regards, > > Milind Gunjan > > > > > > From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] > Sent: Wednesday, June 29, 2016 3:25 AM > To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o > deployment > > > > The hostname in the hosts file don't match. > > On Jun 29, 2016 8:58 AM, "Marius Cornea" wrote: > > On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: >> Hi All, >> >> Thanks a lot for continued support. >> >> I would just like to get clarity regarding the last recommendation. >> My current deployment is failing with following error : >> >> Error: Could not prefetch keystone_service provider 'openstack': Execution >> of '/bin/openstack service list --quiet --format csv --long' returned 1: >> Gateway Timeout (HTTP 504) >> Error: Could not prefetch keystone_role provider 'openstack': Execution of >> '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout >> (HTTP 504) >> Error: Could not prefetch keystone_endpoint provider 'openstack': >> Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: >> Gateway Timeout (HTTP 504) >> >> >> I have previously done RHEL OSP7 deployment and I verified the host file >> of RHEL OSP7 undercloud deployment and it was configured with host >> gateway used by pxe network. >> >> Similarly, we have set the current host gateway to 192.0.2.1 as shown >> below for rdo manager undercloud installation: >> [stack at rdo-undercloud etc]$ cat /etc/hosts >>> 127.0.0.1 localhost localhost.localdomain localhost4 >>> localhost4.localdomain4 >>> ::1 localhost localhost.localdomain localhost6 >>> localhost6.localdomain6 >>> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain >> >> I would like to know if it is required during rdo deployment to have it >> with the address of the public interface, e.g: >> $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. > > The reason I asked for it is because of: > > Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: > (pymysql.err.OperationalError) (1045, u"Access denied for user > 'heat'@'rdo-undercloud' (using password: YES)") > > Typically the undercloud's local_ip is used for these operations but > in your case it's added to the hosts files and maybe this ip name > mapping doesn't allow the installation to proceed. Please note that > the docs[1] point that you should have an FQDN entry in the hosts file > before the undercloud installation(when 192.0.2.1 isn't yet set on the > system), that's why I mentioned the ip address of the public nic. > > [1] > http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > >> >> Thanks again for your time and help. Really appreciate it. >> >> Best Regards, >> milind >> >> -----Original Message----- >> From: Marius Cornea [mailto:marius at remote-lab.net] >> Sent: Tuesday, June 28, 2016 4:28 AM >> To: Gunjan, Milind [CTO] >> Cc: rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o >> deployment >> >> On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] >> wrote: >>> Hi Dan, >>> Thanks a lot for your response. >>> >>> Even after properly updating the undercloud.conf file and checking the >>> network configuration, undercloud deployment still fails. >>> >>> To recreate the issue , I am mentioning all the configuration steps: >>> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >>> 2. created stack user and provided required permission to stack user . >>> 3. setting hostname >>> sudo hostnamectl set-hostname rdo-undercloud.mydomain >>> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >>> >>> [stack at rdo-undercloud etc]$ cat /etc/hosts >>> 127.0.0.1 localhost localhost.localdomain localhost4 >>> localhost4.localdomain4 >>> ::1 localhost localhost.localdomain localhost6 >>> localhost6.localdomain6 >>> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain >> >> Could you try removing the 192.0.2.1 entry from /etc/hosts and replace >> it with the address of the public interface, e.g: >> $ip_public_nic rdo-undercloud rdo-undercloud.mydomain >> >> then rerun openstack undercloud install >> >>> 4. enable required repositories >>> sudo yum -y install epel-release >>> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo >>> https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >>> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo >>> http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >>> >>> 5. install repos >>> >>> sudo yum -y install yum-plugin-priorities >>> sudo yum install -y python-tripleoclient >>> >>> 6. update undercloud.conf >>> >>> [stack at rdo-undercloud ~]$ cat undercloud.conf >>> [DEFAULT] >>> local_ip = 192.0.2.1/24 >>> undercloud_public_vip = 192.0.2.2 >>> undercloud_admin_vip = 192.0.2.3 >>> local_interface = enp6s0 >>> masquerade_network = 192.0.2.0/24 >>> dhcp_start = 192.0.2.150 >>> dhcp_end = 192.0.2.199 >>> network_cidr = 192.0.2.0/24 >>> network_gateway = 192.0.2.1 >>> discovery_iprange = 192.0.2.200,192.0.2.230 >>> discovery_runbench = false >>> [auth] >>> >>> 7. install undercloud >>> >>> openstack undercloud install >>> >>> install ends in error: >>> Error: >>> /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: >>> Could not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: >>> /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: >>> Could not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: Could not prefetch keystone_service provider 'openstack': >>> Execution of '/bin/openstack service list --quiet --format csv --long' >>> returned 1: Gateway Timeout (HTTP 504) >>> Error: Not managing Keystone_service[glance] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: >>> change from absent to present failed: Not managing Keystone_service[glance] >>> due to earlier Keystone API failures. >>> Error: Could not prefetch keystone_role provider 'openstack': Execution >>> of '/bin/openstack role list --quiet --format csv' returned 1: Gateway >>> Timeout (HTTP 504) >>> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone >>> API failures. >>> Error: >>> /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: >>> change from absent to present failed: Not managing >>> Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >>> Error: Not managing Keystone_service[ironic] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: >>> change from absent to present failed: Not managing Keystone_service[ironic] >>> due to earlier Keystone API failures. >>> Error: >>> /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova >>> service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of >>> '/bin/openstack domain show --format shell Default' returned 1: Could not >>> find resource Default >>> Error: >>> /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: >>> Could not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: Not managing Keystone_service[novav3] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova >>> v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change >>> from absent to present failed: Not managing Keystone_service[novav3] due to >>> earlier Keystone API failures. >>> Error: Not managing Keystone_role[heat_stack_user] due to earlier >>> Keystone API failures. >>> Error: >>> /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: >>> change from absent to present failed: Not managing >>> Keystone_role[heat_stack_user] due to earlier Keystone API failures. >>> Error: >>> /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: >>> Could not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: Not managing Keystone_service[nova] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova >>> service, user nova]/Keystone_service[nova::compute]/ensure: change from >>> absent to present failed: Not managing Keystone_service[nova] due to earlier >>> Keystone API failures. >>> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone >>> API failures. >>> Error: >>> /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: >>> change from absent to present failed: Not managing >>> Keystone_role[swiftoperator] due to earlier Keystone API failures. >>> Error: >>> /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: >>> Could not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: Not managing Keystone_service[neutron] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: >>> change from absent to present failed: Not managing Keystone_service[neutron] >>> due to earlier Keystone API failures. >>> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone >>> API failures. >>> Error: >>> /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: >>> change from absent to present failed: Not managing >>> Keystone_service[ceilometer] due to earlier Keystone API failures. >>> Error: Not managing Keystone_service[swift] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: >>> change from absent to present failed: Not managing Keystone_service[swift] >>> due to earlier Keystone API failures. >>> Error: Not managing Keystone_service[keystone] due to earlier Keystone >>> API failures. >>> Error: >>> /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: >>> change from absent to present failed: Not managing >>> Keystone_service[keystone] due to earlier Keystone API failures. >>> Error: Not managing Keystone_service[heat] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: >>> change from absent to present failed: Not managing Keystone_service[heat] >>> due to earlier Keystone API failures. >>> Error: Could not prefetch keystone_endpoint provider 'openstack': >>> Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: >>> Gateway Timeout (HTTP 504) >>> Error: >>> /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: >>> Could not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: Could not prefetch keystone_tenant provider 'openstack': Execution >>> of '/bin/openstack project list --quiet --format csv --long' returned 1: >>> Gateway Timeout (HTTP 504) >>> Error: Not managing Keystone_tenant[service] due to earlier Keystone API >>> failures. >>> Error: >>> /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change >>> from absent to present failed: Not managing Keystone_tenant[service] due to >>> earlier Keystone API failures. >>> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API >>> failures. >>> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: >>> change from absent to present failed: Not managing Keystone_tenant[admin] >>> due to earlier Keystone API failures. >>> Error: Not managing Keystone_role[admin] due to earlier Keystone API >>> failures. >>> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: >>> change from absent to present failed: Not managing Keystone_role[admin] due >>> to earlier Keystone API failures. >>> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could >>> not evaluate: Execution of '/bin/openstack domain show --format shell >>> Default' returned 1: Could not find resource Default >>> Error: Could not prefetch keystone_domain provider 'openstack': Execution >>> of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway >>> Timeout (HTTP 504) >>> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: >>> (pymysql.err.OperationalError) (1045, u"Access denied for user >>> 'heat'@'rdo-undercloud' (using password: YES)") >>> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call >>> refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 >>> instead of one of [0] >>> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage >>> --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >>> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure >>> phase. [Command '['dib-run-parts', >>> '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status >>> 1] >>> >>> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered >>> 'refresh' from 4 events >>> Notice: Finished catalog run in 5259.44 seconds >>> + rc=6 >>> + set -e >>> + echo 'puppet apply exited with exit code 6' >>> puppet apply exited with exit code 6 >>> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >>> + exit 6 >>> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure >>> phase. [Command '['dib-run-parts', >>> '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status >>> 1] >>> >>> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >>> Traceback (most recent call last): >>> File "", line 1, in >>> File >>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line >>> 815, in install >>> _run_orc(instack_env) >>> File >>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line >>> 699, in _run_orc >>> _run_live_command(args, instack_env, 'os-refresh-config') >>> File >>> "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line >>> 370, in _run_live_command >>> raise RuntimeError('%s failed. See log for details.' % name) >>> RuntimeError: os-refresh-config failed. See log for details. >>> Command 'instack-install-undercloud' returned non-zero exit status 1 >>> >>> >>> I am not able to understand the exact cause of undercloud install >>> failure. It would be really helpful if you guys can point be in direction to >>> understand the exact cause of issue and any possible resolution. >>> >>> Thanks a lot. >>> >>> Best Regards, >>> Milind >>> >>> >>> Best Regards, >>> Milind >>> -----Original Message----- >>> From: Dan Sneddon [mailto:dsneddon at redhat.com] >>> Sent: Monday, June 27, 2016 12:40 PM >>> To: Gunjan, Milind [CTO] ; rdo-list at redhat.com >>> Subject: Re: [rdo-list] Redeploying UnderCloud >>> >>> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>>> Hi All, >>>> >>>> Greeting. >>>> >>>> >>>> >>>> This is my first post and I am fairly new to RDO OpenStack. I am >>>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>>> values in undercloud.conf file , my undercloud deployment failed. I >>>> would like to redeploy undercloud and I am trying to understand what >>>> steps has to be taken before redeploying undercloud. All the >>>> deployment was under stack user . So first step will be to delete >>>> stack user. I am not sure what has to be done regarding the networking >>>> configuration autogenerated by os-net-config during the older install. >>>> >>>> Please advise. >>>> >>>> >>>> >>>> Best Regards, >>>> >>>> Milind >>> >>> No, definitely you don't want to delete the stack user, especially not as >>> your first step! That would get rid of the configuration files, etc. >>> that are in ~stack, and generally make your life harder than it needs to >>> be. >>> >>> Anyway, it isn't necessary. You can do a procedure very much like what >>> you do when upgrading the undercloud, with a couple of extra steps. >>> >>> As the stack user, edit your undercloud.conf, and make sure there are no >>> more typos. >>> >>> If the typos were in the network configuration, you should delete the >>> bridge and remove the ifcfg files: >>> >>> $ sudo ifdown br-ctlplane >>> $ sudo ovs-vsctl del-br br-ctlplane >>> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >>> >>> Next, run the underclound installation again: >>> >>> $ sudo yum update -y # Reboot after if kernel or core packages updated $ >>> openstack undercloud install >>> >>> Then proceed with the rest of the instructions. You may find that if you >>> already uploaded disk images or imported nodes that they will still be in >>> the database. That's OK, or you can delete and reimport. >>> >>> -- >>> Dan Sneddon | Principal OpenStack Engineer >>> dsneddon at redhat.com | redhat.com/openstack >>> 650.254.4025 | dsneddon:irc @dxs:twitter >>> >>> >>> >>> ________________________________ >>> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T >>> or T-Mobile rates. See sprint.com/50off for >>> details. >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for the >>> sole use of the recipient(s). Any use by others is prohibited. If you are >>> not the intended recipient, please contact the sender and delete all copies >>> of the message. >>> >>> _______________________________________________ >>> rdo-list mailing list >>> rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From marius at remote-lab.net Fri Jul 1 07:56:22 2016 From: marius at remote-lab.net (Marius Cornea) Date: Fri, 1 Jul 2016 09:56:22 +0200 Subject: [rdo-list] [tripleo] Baremetal introspection failing; missing required 'local_gb' In-Reply-To: References: Message-ID: Hi, I've seen the same issue reported in BZ#1328585, maybe the comments there can shed some light: https://bugzilla.redhat.com/show_bug.cgi?id=1328585 On Fri, Jul 1, 2016 at 5:15 AM, Gerard Braad wrote: > Hi All, > > > Donwloaded a new undercloud image for Mitaka, and performed a > quickstart install to target two baremetal nodes. When performing > introspection, the step fails with: > > > + openstack baremetal configure boot > + openstack baremetal introspection bulk start > Setting nodes for introspection to manageable... > Starting introspection of node: 7499cdf4-0f89-4250-a930-d7f927683ea6 > Starting introspection of node: 07b94ab4-e4eb-4ea9-8b7a-e11983063135 > Waiting for introspection to finish... > Introspection for UUID 7499cdf4-0f89-4250-a930-d7f927683ea6 finished > with error: The following required parameters are missing: > ['local_gb'] > Introspection for UUID 07b94ab4-e4eb-4ea9-8b7a-e11983063135 finished > with error: The following required parameters are missing: > ['local_gb'] > Setting manageable nodes to available... > Introspection completed with errors: > 7499cdf4-0f89-4250-a930-d7f927683ea6: The following required > parameters are missing: ['local_gb'] > 07b94ab4-e4eb-4ea9-8b7a-e11983063135: The following required > parameters are missing: ['local_gb'] > > > This used to work previously... > > I created a bug for this at launchpad [1]. > > > regards, > > > Gerard > > [1] https://bugs.launchpad.net/tripleo-quickstart/+bug/1597982 > > -- > > Gerard Braad | http://gbraad.nl > [ Doing Open Source Matters ] > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From me at gbraad.nl Fri Jul 1 08:01:09 2016 From: me at gbraad.nl (Gerard Braad) Date: Fri, 1 Jul 2016 16:01:09 +0800 Subject: [rdo-list] [tripleo] Baremetal introspection failing; missing required 'local_gb' In-Reply-To: References: Message-ID: Thanks On Fri, Jul 1, 2016 at 3:56 PM, Marius Cornea wrote: > Hi, > > I've seen the same issue reported in BZ#1328585, maybe the comments > there can shed some light: > https://bugzilla.redhat.com/show_bug.cgi?id=1328585 > > On Fri, Jul 1, 2016 at 5:15 AM, Gerard Braad wrote: >> Hi All, >> >> >> Donwloaded a new undercloud image for Mitaka, and performed a >> quickstart install to target two baremetal nodes. When performing >> introspection, the step fails with: >> >> >> + openstack baremetal configure boot >> + openstack baremetal introspection bulk start >> Setting nodes for introspection to manageable... >> Starting introspection of node: 7499cdf4-0f89-4250-a930-d7f927683ea6 >> Starting introspection of node: 07b94ab4-e4eb-4ea9-8b7a-e11983063135 >> Waiting for introspection to finish... >> Introspection for UUID 7499cdf4-0f89-4250-a930-d7f927683ea6 finished >> with error: The following required parameters are missing: >> ['local_gb'] >> Introspection for UUID 07b94ab4-e4eb-4ea9-8b7a-e11983063135 finished >> with error: The following required parameters are missing: >> ['local_gb'] >> Setting manageable nodes to available... >> Introspection completed with errors: >> 7499cdf4-0f89-4250-a930-d7f927683ea6: The following required >> parameters are missing: ['local_gb'] >> 07b94ab4-e4eb-4ea9-8b7a-e11983063135: The following required >> parameters are missing: ['local_gb'] >> >> >> This used to work previously... >> >> I created a bug for this at launchpad [1]. >> >> >> regards, >> >> >> Gerard >> >> [1] https://bugs.launchpad.net/tripleo-quickstart/+bug/1597982 >> >> -- >> >> Gerard Braad | http://gbraad.nl >> [ Doing Open Source Matters ] >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] From me at gbraad.nl Fri Jul 1 09:02:12 2016 From: me at gbraad.nl (Gerard Braad) Date: Fri, 1 Jul 2016 17:02:12 +0800 Subject: [rdo-list] [tripleo] Baremetal introspection failing; missing required 'local_gb' In-Reply-To: References: Message-ID: Hi, > On Fri, Jul 1, 2016 at 3:56 PM, Marius Cornea wrote: >> I've seen the same issue reported in BZ#1328585, maybe the comments >> there can shed some light: >> https://bugzilla.redhat.com/show_bug.cgi?id=1328585 >> On Fri, Jul 1, 2016 at 5:15 AM, Gerard Braad wrote: >>> with error: The following required parameters are missing: >>> ['local_gb'] >>> I created a bug for this at launchpad [1]. >>> [1] https://bugs.launchpad.net/tripleo-quickstart/+bug/1597982 Dimitry has looked at the Ramdisk logs and believes it looks very similar to the previously reported BZ issue. The images I used are dated: ironic-python-agent.tar 2016-06-24 03:47 373M ironic-python-agent.tar.md5 2016-06-24 03:47 58 overcloud-full.tar 2016-06-24 03:46 1.2G overcloud-full.tar.md5 2016-06-24 03:47 53 undercloud.qcow2 2016-06-24 03:46 2.7G undercloud.qcow2.md5 2016-06-24 03:46 51 from: http://artifacts.ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/ It is a little hard to track what is included in those images, but since Dimitry did not see any retry messages, it might be that the patch is not included. It might be helpful to mark this as a known issue. regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] From apevec at redhat.com Fri Jul 1 09:53:24 2016 From: apevec at redhat.com (Alan Pevec) Date: Fri, 1 Jul 2016 11:53:24 +0200 Subject: [rdo-list] Replacing the tripleo-quickstart HA job with a single controller pacemaker job In-Reply-To: <577568EC.8050802@redhat.com> References: <577568EC.8050802@redhat.com> Message-ID: On Thu, Jun 30, 2016 at 8:46 PM, John Trowbridge wrote: > Instead, we will test the pacemaker code path in tripleo by using a > single controller setup with pacemaker enabled. We were never actually > testing HA (ie failover scenarios) in the current job, so this should be > a pretty minimal loss in coverage. ACK let's do that asap. BTW I've disabled liberty and mitaka pipelines, until we sort out python2-* issue in RDO repos, all weirdo-openstack-puppet jobs are failing because allow_virtual fix [1] cannot be backported. Upstream openstack-puppet CI needs to keep jobs running Puppet < 3.6. Cheers, Alan [1] https://review.openstack.org/#/c/336045/5/manifests/init.pp From rasca at redhat.com Fri Jul 1 10:48:42 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Fri, 1 Jul 2016 12:48:42 +0200 Subject: [rdo-list] Replacing the tripleo-quickstart HA job with a single controller pacemaker job In-Reply-To: <577568EC.8050802@redhat.com> References: <577568EC.8050802@redhat.com> Message-ID: <32cf11c1-9c0b-0ff1-5849-a4d53aa5d76e@redhat.com> On 30/06/2016 20:46, John Trowbridge wrote: > Howdy folks, > > Just wanted to give a heads up that I plan to replace the > "high-availability" tripleo-quickstart job in the CI promotion > pipeline[1], with a job with a lower footprint. In CI, we get a virthost > with 32G of RAM and a mediocre CPU. It is really hard to fit 5 really > active VMs on that, and we have never had the HA job stable enough to > use as a gate for that reason. > > Instead, we will test the pacemaker code path in tripleo by using a > single controller setup with pacemaker enabled. We were never actually > testing HA (ie failover scenarios) in the current job, so this should be > a pretty minimal loss in coverage. > > Since this allows us to drop two CPU intensive nodes from the deploy, we > can add a ceph node to that job. This will end up with more code > coverage then the current HA job, and will hopefully will end up being > stable enough to use as a gate as well. > > Longer term, it would be good to restore an actual HA job, maybe even > adding some failure scenario tests to the job. I have a couple of ideas > about how we could do this, but none are feasible in the short term. > > 1. Use pre-existing servers for deploying[2] > > This would allow running the HA job against any cloud, where we could > size the nodes appropriately to make the job stable. > > 2. Use an OVB cloud for the HA job. > > Soon we should have an OVB (openstack virtual baremetal) cloud to run > tests in. OVB would have all of the benefits of the solution above > (unrestricted VM size), and would also provide us a way to test Ironic > in a more realistic way since it mocks IPMI rather than our current > method of using a fake ironic driver (which just does virsh commands > over SSH). > > 3. Add a feature to tripleo-quickstart to bridge multiple virthosts > > If we could deploy our virtual machines across 2 different hosts, we > would then have much more room to deploy the HA job. > > > If anyone has some better ideas, they are very welcome! Hi John, No better ideas here, I just want to add that all the work I've done in the last months about roles (ansible-role-tripleo-baremetal-undercloud) was made for having a physical environment in which test HA scenarios (using ansible-role-tripleo-overcloud-validate-ha). Not much of this is in place at the moment (in particular for the HA validation), since I got a lot of connected patches merged just yesterday, but I think we are on a good track. -- Raoul Scarazzini rasca at redhat.com > -- trown > > [1] https://ci.centos.org/view/rdo/view/promotion-pipeline/ > [2] https://review.openstack.org/#/c/324777/ > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From rasca at redhat.com Fri Jul 1 10:56:20 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Fri, 1 Jul 2016 12:56:20 +0200 Subject: [rdo-list] Replacing the tripleo-quickstart HA job with a single controller pacemaker job In-Reply-To: <32cf11c1-9c0b-0ff1-5849-a4d53aa5d76e@redhat.com> References: <577568EC.8050802@redhat.com> <32cf11c1-9c0b-0ff1-5849-a4d53aa5d76e@redhat.com> Message-ID: <0930d1a5-3ef7-599f-b727-1a35cf1e7d21@redhat.com> On 01/07/2016 12:48, Raoul Scarazzini wrote: > On 30/06/2016 20:46, John Trowbridge wrote: >> Howdy folks, >> >> Just wanted to give a heads up that I plan to replace the >> "high-availability" tripleo-quickstart job in the CI promotion >> pipeline[1], with a job with a lower footprint. In CI, we get a virthost >> with 32G of RAM and a mediocre CPU. It is really hard to fit 5 really >> active VMs on that, and we have never had the HA job stable enough to >> use as a gate for that reason. >> >> Instead, we will test the pacemaker code path in tripleo by using a >> single controller setup with pacemaker enabled. We were never actually >> testing HA (ie failover scenarios) in the current job, so this should be >> a pretty minimal loss in coverage. >> >> Since this allows us to drop two CPU intensive nodes from the deploy, we >> can add a ceph node to that job. This will end up with more code >> coverage then the current HA job, and will hopefully will end up being >> stable enough to use as a gate as well. >> >> Longer term, it would be good to restore an actual HA job, maybe even >> adding some failure scenario tests to the job. I have a couple of ideas >> about how we could do this, but none are feasible in the short term. >> >> 1. Use pre-existing servers for deploying[2] >> >> This would allow running the HA job against any cloud, where we could >> size the nodes appropriately to make the job stable. >> >> 2. Use an OVB cloud for the HA job. >> >> Soon we should have an OVB (openstack virtual baremetal) cloud to run >> tests in. OVB would have all of the benefits of the solution above >> (unrestricted VM size), and would also provide us a way to test Ironic >> in a more realistic way since it mocks IPMI rather than our current >> method of using a fake ironic driver (which just does virsh commands >> over SSH). >> >> 3. Add a feature to tripleo-quickstart to bridge multiple virthosts >> >> If we could deploy our virtual machines across 2 different hosts, we >> would then have much more room to deploy the HA job. >> >> >> If anyone has some better ideas, they are very welcome! > > Hi John, > No better ideas here, I just want to add that all the work I've done in > the last months about roles (ansible-role-tripleo-baremetal-undercloud) > was made for having a physical environment in which test HA scenarios > (using ansible-role-tripleo-overcloud-validate-ha). > Not much of this is in place at the moment (in particular for the HA > validation), since I got a lot of connected patches merged just > yesterday, but I think we are on a good track. One thing I did not mention above is that we're putting in place the jobs so they'll rely on our infrastructure, for what matters the HA part. So we're working exactly in that direction, because as you can imagine having HA tests on a single node pacemaker is like not having tests. -- Raoul Scarazzini rasca at redhat.com From bderzhavets at hotmail.com Fri Jul 1 12:46:06 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 1 Jul 2016 12:46:06 +0000 Subject: [rdo-list] HA overcloud-deploy.sh crashes again ( ControllerOvercloudServicesDeployment_Step4 ) In-Reply-To: References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> <2a4caf42c3b4471d9435dae86f201748@PREWE13M11.ad.sprint.com> <9e3942c3-6ebf-f4c6-41a2-23d11a1e8ffe@redhat.com> <57752963.6000209@redhat.com> , <57755B16.70706@redhat.com>, Message-ID: ________________________________ From: Boris Derzhavets Sent: Thursday, June 30, 2016 2:17 PM To: John Trowbridge; Dan Sneddon; rdo-list at redhat.com Subject: Re: [rdo-list] HA overcloud-deploy.sh crashes again ( ControllerOvercloudServicesDeployment_Step4 ) ________________________________ From: John Trowbridge Sent: Thursday, June 30, 2016 1:47 PM To: Boris Derzhavets; Dan Sneddon; rdo-list at redhat.com Subject: Re: [rdo-list] HA overcloud-deploy.sh crashes again ( ControllerOvercloudServicesDeployment_Step4 ) On 06/30/2016 12:56 PM, Boris Derzhavets wrote: > > > > ________________________________ > From: John Trowbridge > Sent: Thursday, June 30, 2016 10:14 AM > To: Boris Derzhavets; Dan Sneddon; rdo-list at redhat.com > Subject: Re: [rdo-list] HA overcloud-deploy.sh crashes again ( ControllerOvercloudServicesDeployment_Step4 ) > > > > On 06/30/2016 05:19 AM, Boris Derzhavets wrote: >> >> >> >> ________________________________ >> From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets >> Sent: Wednesday, June 29, 2016 5:14 PM >> To: Dan Sneddon; rdo-list at redhat.com >> Subject: Re: [rdo-list] HA overcloud-deploy.sh crashes again ( ControllerOvercloudServicesDeployment_Step4 ) >> >> Yes , attempt to deploy >> >> ######################## >> # HA +2xCompute >> ######################## >> control_memory: 6144 >> compute_memory: 6144 >> >> undercloud_memory: 8192 >> >> # Giving the undercloud additional CPUs can greatly improve heat's >> # performance (and result in a shorter deploy time). >> undercloud_vcpu: 4 > > Increasing this without also increasing the memory on the undercloud > will usually end in sadness, because more CPUs means more worker > processes means more memory consumption. In general straying from the > values in CI, is unlikely to work unless you have significantly better > hardware than what runs in CI (32G hosts with decent CPU). > > It will be verified tomorrow with > undercloud_vcpu: 2 Problem with introspection is gone. Config 3xController(HA) + 2xCompute maybe deployed with undecloud_vcpu: 2 or undecloud_vcpu: 4 doesn't matter. Thank you. Boris. > This test would be a fair . It will take about 2 hr. > But, I still believe that it is not root cause of issue with > Configuration - 3xController(HA) + 2xCompute having :- > undercloud_memory: 8192 > undercloud_vcpu: 4 > which was tested many times OK since 06/05 up to 06/24 > with no problems. Just realized that you are also deploying 2x compute nodes. Just FYI, even the basic HA setup barely fits on a 32G host. In fact on 3 of the 4 nodes in CI, we rarely get a pass of HA because the resources are so tight. Will actually be switching that job to a single controller job with pacemaker for exactly that reason (email to RDO list about that will come later this afternoon). How big is the virthost you are using? 32 GB . I am currently at VIRTHOST Console and made TOP's snapshot of running config 3xController(HA) + 1xCompute. Snapshot is attached ( Disregard previous message, it was sent occasionally ) Config :- 3xController(HA) + 2xCompute. I was monitoring via TOP many times . I didn't see big problems with RAM Current problem is most probably related with introspection nodes supposed to built overcloud. > > Thank you very much for feedback > Boris. > > https://github.com/openstack/tripleo-quickstart/blob/master/config/general_config/ha.yml#L13 > > It is not 100% that is the root cause of your issue, as the logs below > look like we hit issues either with Ironic deployment to the nodes, or > some issue with Nova scheduler. Note, that is definitely a different > problem (and possibly transient), than the one reported in the beginning > of this thread. > >> >> # Create three controller nodes and one compute node. >> overcloud_nodes: >> - name: control_0 >> flavor: control >> - name: control_1 >> flavor: control >> - name: control_2 >> flavor: control >> >> - name: compute_0 >> flavor: compute >> - name: compute_1 >> flavor: compute >> >> # We don't need introspection in a virtual environment (because we are >> # creating all the "hardware" we really know the necessary >> # information). >> introspect: false >> >> # Tell tripleo about our environment. >> network_isolation: true >> extra_args: >- >> --control-scale 3 --compute-scale 2 --neutron-network-type vxlan >> --neutron-tunnel-types vxlan >> -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml >> --ntp-server pool.ntp.org >> deploy_timeout: 75 >> tempest: false >> pingtest: true >> >> Results during overcloud deployment :- >> >> 2016-06-30 09:09:31 [NovaCompute]: CREATE_FAILED ResourceInError: resources.NovaCompute: Went to status ERROR due to "Message: No valid host was found. There are not enough hosts available., Code: 500" >> 2016-06-30 09:09:31 [NovaCompute]: DELETE_IN_PROGRESS state changed >> 2016-06-30 09:09:34 [NovaCompute]: DELETE_COMPLETE state changed >> 2016-06-30 09:09:44 [NovaCompute]: CREATE_IN_PROGRESS state changed >> 2016-06-30 09:09:48 [NovaCompute]: CREATE_FAILED ResourceInError: resources.NovaCompute: Went to status ERROR due to "Message: No valid host was found. There are not enough hosts available., Code: 500" >> . . . . . >> >> 2016-06-30 09:11:36 [overcloud]: CREATE_FAILED Resource CREATE failed: ResourceInError: resources.Compute.resources[0].resources.NovaCompute: Went to status ERROR due to "Message: Build of instance bf483c34-7010-48ea-8f58-fe192c91093f aborted: Failed to provision instance bf483c34-7010-48ea-8f58-fe192 >> 2016-06-30 09:11:36 [1]: SIGNAL_COMPLETE Unknown >> 2016-06-30 09:11:36 [ControllerDeployment]: SIGNAL_COMPLETE Unknown >> 2016-06-30 09:11:36 [1]: CREATE_COMPLETE state changed >> 2016-06-30 09:11:36 [overcloud-ControllerCephDeployment-62xh7uhtpjqp]: CREATE_COMPLETE Stack CREATE completed successfully >> 2016-06-30 09:11:37 [NetworkDeployment]: SIGNAL_COMPLETE Unknown >> 2016-06-30 09:11:37 [1]: SIGNAL_COMPLETE Unknown >> Stack overcloud CREATE_FAILED >> Deployment failed: Heat Stack create failed. >> + heat stack-list >> + grep -q CREATE_FAILED >> + deploy_status=1 >> ++ heat resource-list --nested-depth 5 overcloud >> ++ grep FAILED >> ++ grep 'StructuredDeployment ' >> ++ cut -d '|' -f3 >> + exit 1 >> >> >> Thanks. >> >> Boris >> >> >> ________________________________ >> From: rdo-list-bounces at redhat.com on behalf of Dan Sneddon >> Sent: Wednesday, June 29, 2016 1:46 PM >> To: rdo-list at redhat.com >> Subject: Re: [rdo-list] HA overcloud-deploy.sh crashes again ( ControllerOvercloudServicesDeployment_Step4 ) >> >> On 06/29/2016 10:42 AM, Dan Sneddon wrote: >>> On 06/29/2016 07:03 AM, Boris Derzhavets wrote: >>>> Boris Derzhavets has shared a?OneDrive?file with you. To view it, click >>>> the link below. >>>> >>>> >> [https://p.sfx.ms/icons/v2/Large/Default.png] >> >> HeatCrash2.txt 1.gz >> 1drv.ms >> GZ File >> >> >>>> >>>> HeatCrash2.txt 1.gz >>>> [HeatCrash2.txt 1.gz] >>>> >>>> Reattach gzip archive via One Drive >>>> >>>> >>>> >>>> ----------------------------------------------------------------------- >>>> *From:* rdo-list-bounces at redhat.com on >>>> behalf of Boris Derzhavets >>>> *Sent:* Wednesday, June 29, 2016 9:36 AM >>>> *To:* John Trowbridge; shardy at redhat.com >>>> *Cc:* rdo-list at redhat.com >>>> *Subject:* [rdo-list] HA overcloud-deploy.sh crashes again ( >>>> ControllerOvercloudServicesDeployment_Step4 ) >>>> >>>> >>>> Attempt to follow steps suggested >>>> in http://hardysteven.blogspot.ru/2016/06/tripleo-partial-stack-updates.html >>>> >>>> >>>> ./deploy-overstack crashes >>>> >>>> >>>> 2016-06-29 12:42:41 >>>> [overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk-ControllerOvercloudServicesDeployment_Step4-nzdoizlgrmx2]: >>>> CREATE_FAILED Resource CREATE failed: Error: resources[0]: Deployment >>>> to server failed: deploy_status_code : Deployment exited with non-zero >>>> status code: 6 >>>> 2016-06-29 12:42:42 [ControllerOvercloudServicesDeployment_Step4]: >>>> CREATE_FAILED Error: >>>> resources.ControllerOvercloudServicesDeployment_Step4.resources[0]: >>>> Deployment to server failed: deploy_status_code: Deployment exited with >>>> non-zero status code: 6 >>>> 2016-06-29 12:42:43 >>>> [overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk]: CREATE_FAILED >>>> Resource CREATE failed: Error: >>>> resources.ControllerOvercloudServicesDeployment_Step4.resources[0]: >>>> Deployment to server failed: deploy_status_code: Deployment exited with >>>> non-zero status code: 6 >>>> 2016-06-29 12:42:44 [ControllerNodesPostDeployment]: CREATE_FAILED >>>> Error: >>>> resources.ControllerNodesPostDeployment.resources.ControllerOvercloudServicesDeployment_Step4.resources[0]: >>>> Deployment to server failed: deploy_status_code: Deployment exited with >>>> non-zero status code: 6 >>>> 2016-06-29 12:42:44 [2]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:45 [2]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:45 [2]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:46 [overcloud]: CREATE_FAILED Resource CREATE failed: >>>> Error: >>>> resources.ControllerNodesPostDeployment.resources.ControllerOvercloudServicesDeployment_Step4.resources[0]: >>>> Deployment to server failed: deploy_status_code: Deployment exited with >>>> non-zero status code: 6 >>>> 2016-06-29 12:42:46 [2]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:47 [2]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:47 [ControllerDeployment]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:48 [NetworkDeployment]: SIGNAL_COMPLETE Unknown >>>> 2016-06-29 12:42:48 [2]: SIGNAL_COMPLETE Unknown >>>> Stack overcloud CREATE_FAILED >>>> Deployment failed: Heat Stack create failed. >>>> + heat stack-list >>>> + grep -q CREATE_FAILED >>>> + deploy_status=1 >>>> ++ heat resource-list --nested-depth 5 overcloud >>>> ++ grep FAILED >>>> ++ grep 'StructuredDeployment ' >>>> ++ cut -d '|' -f3 >>>> + for failed in '$(heat resource-list --nested-depth 5 >>>> overcloud | grep FAILED | >>>> grep '\''StructuredDeployment '\'' | cut -d '\''|'\'' -f3)' >>>> + heat deployment-show 655c77fc-6a78-4cca-b4b7-a153a3f4ad52 >>>> + for failed in '$(heat resource-list --nested-depth 5 >>>> overcloud | grep FAILED | >>>> grep '\''StructuredDeployment '\'' | cut -d '\''|'\'' -f3)' >>>> + heat deployment-show 1fe5153c-e017-4ee5-823a-3d1524430c1d >>>> + for failed in '$(heat resource-list --nested-depth 5 >>>> overcloud | grep FAILED | >>>> grep '\''StructuredDeployment '\'' | cut -d '\''|'\'' -f3)' >>>> + heat deployment-show bf6f25f4-d812-41e9-a7a8-122de619a624 >>>> + exit 1 >>>> >>>> ***************************** >>>> Troubleshooting steps :- >>>> ***************************** >>>> >>>> [stack at undercloud ~]$ . stackrc >>>> [stack at undercloud ~]$ heat resource-list overcloud | grep >>>> ControllerNodesPost >>>> | ControllerNodesPostDeployment | >>>> f1d6a474-c946-46bf-ab0c-2fdaeb55d0b3 | >>>> OS::TripleO::ControllerPostDeployment | CREATE_FAILED | >>>> 2016-06-29T12:11:21 | >>>> >>>> >>>> [stack at undercloud ~]$ heat stack-list -n | grep "^| >>>> f1d6a474-c946-46bf-ab0c-2fdaeb55d0b3" >>>> | f1d6a474-c946-46bf-ab0c-2fdaeb55d0b3 | >>>> overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk >>>> | CREATE_FAILED | 2016-06-29T12:31:11 | None | >>>> 17f82f6e-e0ca-44c6-9058-de82c00d4f79 | >>>> >>>> >>>> >>>> [stack at undercloud ~]$ heat event-list -m >>>> f1d6a474-c946-46bf-ab0c-2fdaeb55d0b3 >>>> overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk >>>> >>>> +------------------------------------------------------+--------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------+ >>>> | resource_name | >>>> id | >>>> resource_status_reason >>>> | resource_status | event_time | >>>> +------------------------------------------------------+--------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------+ >>>> | overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk | >>>> 10ec0cf9-b3c9-4191-9966-3f4d47f27e2a | Stack CREATE started >>>> . . . . . . . . . . . . . . . . . >>>> Step1,2,3 succeeded >>>> . . . . . . . . . . . . . . . . . >>>> >>>> | CREATE_IN_PROGRESS | 2016-06-29T12:31:14 | >>>> | ControllerPuppetConfig | >>>> a2a1df33-5106-425c-b16d-8d2df709b19f | state >>>> changed >>>> | CREATE_COMPLETE | 2016-06-29T12:35:02 | >>>> | ControllerOvercloudServicesDeployment_Step4 | >>>> 1e151333-4de5-4e7b-907c-ea0f42d31a47 | state >>>> changed >>>> | CREATE_IN_PROGRESS | 2016-06-29T12:35:03 | >>>> | ControllerOvercloudServicesDeployment_Step4 | >>>> 7bf36334-3d92-4554-b6c0-41294a072ab6 | Error: >>>> resources.ControllerOvercloudServicesDeployment_Step4.resources[0]: >>>> Deployment to server failed: deploy_status_code: Deployment exited with >>>> non-zero status code: 6 | CREATE_FAILED | >>>> 2016-06-29T12:42:42 | >>>> | overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk >>>> | e72fb6f4-c2aa-4fe8-9bd1-5f5ad152685c | Resource CREATE failed: >>>> Error: >>>> resources.ControllerOvercloudServicesDeployment_Step4.resources[0]: >>>> Deployment to server failed: deploy_status_code: Deployment exited with >>>> non-zero status code: 6 | CREATE_FAILED | 2016-06-29T12:42:43 | >>>> +------------------------------------------------------+--------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------+ >>>> >>>> [stack at undercloud ~]$ heat stack-show >>>> overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk | grep >>>> NodeConfigIdentifiers >>>> | | "NodeConfigIdentifiers": >>>> "{u'deployment_identifier': 1467202276, u'controller_config': {u'1': >>>> u'os-apply-config deployment 796df02a-7550-414b-a084-8b591a13e6db >>>> completed,Root CA cert injection not enabled.,TLS not enabled.,None,', >>>> u'0': u'os-apply-config deployment 613ec889-d852-470a-8e4c-6e243e1d2033 >>>> completed,Root CA cert injection not enabled.,TLS not enabled.,None,', >>>> u'2': u'os-apply-config deployment c8b099d0-3af4-4ba0-a056-a0ce60f40e2d >>>> completed,Root CA cert injection not enabled.,TLS not enabled.,None,'}, >>>> u'allnodes_extra': u'none'}" | >>>> >>>> However, when stack creating crashed update wouldn't help. >>>> >>>> [stack at undercloud ~]$ heat stack-update -x >>>> overcloud-ControllerNodesPostDeployment-2r4tlv5icaxk -e update_env.yaml >>>> ERROR: PATCH update to non-COMPLETE stack is not supported. >>>> >>>> DUE TO :- >>>> >>>> [stack at undercloud ~]$ heat stack-list >>>> +--------------------------------------+------------+---------------+---------------------+--------------+ >>>> | id | stack_name | stack_status | >>>> creation_time | updated_time | >>>> +--------------------------------------+------------+---------------+---------------------+--------------+ >>>> | 17f82f6e-e0ca-44c6-9058-de82c00d4f79 | overcloud | CREATE_FAILED | >>>> 2016-06-29T12:11:20 | None | >>>> +--------------------------------------+------------+---------------+---------------------+------ >>>> >>>> >>>> Complete error file `heat deployment-show >>>> 655c77fc-6a78-4cca-b4b7-a153a3f4ad52` is attached a gzip archive. >>>> >>>> >>>> Thanks. >>>> >>>> Boris. >>>> >>>> >>>> >>>> _______________________________________________ >>>> rdo-list mailing list >>>> rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >>>> >>> >>> The failure occurred during the post-deployment, which means that the >>> initial deployment succeeded, but then the steps that are done to the >>> completed overcloud failed. >>> >>> This is most commonly attributable to network problems between the >>> Undercloud and the Overcloud Public API. The Undercloud needs to reach >>> the Public API in order to do some of the post-configuration steps. If >>> this API isn't reachable, you end up with the error you saw above. >>> >>> You can test this connectivity by pinging the Public API VIP from the >>> Undercloud. Starting with the failed deployment, run "neutron >>> port-list" against the Underlcloud and look for the IP on the port >>> named "public_virtual_ip". You should be able to ping this address from >>> the Undercloud. If you can't reach that IP, then you need to check the >>> connectivity/routing between the Undercloud and the External network on >>> the Overcloud. >>> >> >> I should also mention common causes of this problem: >> >> * Incorrect value for ExternalInterfaceDefaultRoute in the network >> environment file. >> * Controllers do not have the default route on the External network in >> the NIC config templates (required for reachability from remote subnets). >> * Incorrect subnet mask on the ExternalNetCidr in the network environment. >> * Incorrect ExternalAllocationPools values in the network environment. >> * Incorrect Ethernet switch config for the Controllers. >> >> Issue has been reproduced with exactly same error 4 times >> starting since 06/25/16 on daily basis with exactly same error at Step4 >> of overcloud-ControllerNodesPostDeployment. >> In meantime I cannot reproduce the error. >> Config 3xNode HA Controller + 1xCompute works . >> There was one more issue 3xNode HA Controller + 2xCompute >> failed immediately when overcloud-deploy.sh started due to >> only 4 nodes could be introspected. I will test it tomorrow morning. >> >> Thanks a lot. >> Boris. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> >> >> This body part will be downloaded on demand. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imaslov at dispersivegroup.com Fri Jul 1 17:31:56 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 1 Jul 2016 17:31:56 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> Message-ID: <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I?ve also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Fri Jul 1 18:12:05 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 1 Jul 2016 18:12:05 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> , <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> Message-ID: ________________________________ From: rdo-list-bounces at redhat.com on behalf of Ilja Maslov Sent: Friday, July 1, 2016 1:31 PM To: Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I?ve also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Is this notice done regarding attempt to start openstack-nova-compute during `openstack undercloud install` with repos set to Mitaka trunks per http://docs.openstack.org/developer/tripleo-docs/installation/installing.html ? Thanks. Boris. Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html Undercloud Installation ? tripleo-docs 0.0.1.dev185 ... tripleo.org Undercloud Installation? This section contains instructions on how to install the undercloud and how to update components after installation. But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From imaslov at dispersivegroup.com Fri Jul 1 18:18:53 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 1 Jul 2016 18:18:53 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> , <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> Message-ID: <370acf4517cb4b3b9dc844940f0742b4@svr2-disp-exch.dispersive.local> I believe so, process list shows that systemctl start openstack-nova-compute never finishes, but I do not remember how exactly console logs looked like. Ilja From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 2:12 PM To: Ilja Maslov ; Gunjan, Milind [CTO] ; Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Ilja Maslov > Sent: Friday, July 1, 2016 1:31 PM To: Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I've also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Is this notice done regarding attempt to start openstack-nova-compute during `openstack undercloud install` with repos set to Mitaka trunks per http://docs.openstack.org/developer/tripleo-docs/installation/installing.html ? Thanks. Boris. Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html Undercloud Installation - tripleo-docs 0.0.1.dev185 ... tripleo.org Undercloud Installation? This section contains instructions on how to install the undercloud and how to update components after installation. But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Fri Jul 1 19:07:18 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 1 Jul 2016 19:07:18 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: <370acf4517cb4b3b9dc844940f0742b4@svr2-disp-exch.dispersive.local> References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> , <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> , <370acf4517cb4b3b9dc844940f0742b4@svr2-disp-exch.dispersive.local> Message-ID: ________________________________ From: Ilja Maslov Sent: Friday, July 1, 2016 2:18 PM To: Boris Derzhavets; Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment I believe so, process list shows that systemctl start openstack-nova-compute never finishes, but I do not remember how exactly console logs looked like. Ilja 1. /var/log/nova/nova-compute.log contains a bunch a rejected attempts to connect to 127.0.0.1:5672 2. If to verify status of port 5672 via ` netstat -antp | grep 5672` it appears to bind to only one IP - 192.0.2.1 and nothing else . 3. What causes `openstack underloud install` to hang at least via my experience ( case of Mitaka trunks ) I was working via instack-virt-setup not on bare metal. I believe that link http://docs.openstack.org/developer/tripleo-docs/installation/installing.html requires updates at least for instack-virt-setup (Mitaka) it doesn't work. I just cannot test http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html#upload-images because I cannot setup undercloud. TripleO Quickstart works fine, but I would like to make each step by myself working via instack-virt-setup, without any Ansible involvement Boris. From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 2:12 PM To: Ilja Maslov ; Gunjan, Milind [CTO] ; Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Ilja Maslov > Sent: Friday, July 1, 2016 1:31 PM To: Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I?ve also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Is this notice done regarding attempt to start openstack-nova-compute during `openstack undercloud install` with repos set to Mitaka trunks per http://docs.openstack.org/developer/tripleo-docs/installation/installing.html ? Thanks. Boris. Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html Undercloud Installation ? tripleo-docs 0.0.1.dev185 ... tripleo.org Undercloud Installation? This section contains instructions on how to install the undercloud and how to update components after installation. But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From imaslov at dispersivegroup.com Fri Jul 1 19:14:05 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 1 Jul 2016 19:14:05 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> , <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> , <370acf4517cb4b3b9dc844940f0742b4@svr2-disp-exch.dispersive.local> Message-ID: <174766503b2f42eda13dd9c8089ebf32@svr2-disp-exch.dispersive.local> Yep-yep, exactly the same experience here. I went back to centos-release-openstack-mitaka, because of the project priorities, but would love to revisit delorean trunk at a later date. Ilja From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 3:07 PM To: Ilja Maslov ; Gunjan, Milind [CTO] ; Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: Ilja Maslov > Sent: Friday, July 1, 2016 2:18 PM To: Boris Derzhavets; Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment I believe so, process list shows that systemctl start openstack-nova-compute never finishes, but I do not remember how exactly console logs looked like. Ilja 1. /var/log/nova/nova-compute.log contains a bunch a rejected attempts to connect to 127.0.0.1:5672 2. If to verify status of port 5672 via ` netstat -antp | grep 5672` it appears to bind to only one IP - 192.0.2.1 and nothing else . 3. What causes `openstack underloud install` to hang at least via my experience ( case of Mitaka trunks ) I was working via instack-virt-setup not on bare metal. I believe that link http://docs.openstack.org/developer/tripleo-docs/installation/installing.html requires updates at least for instack-virt-setup (Mitaka) it doesn't work. I just cannot test http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html#upload-images because I cannot setup undercloud. TripleO Quickstart works fine, but I would like to make each step by myself working via instack-virt-setup, without any Ansible involvement Boris. From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 2:12 PM To: Ilja Maslov >; Gunjan, Milind [CTO] >; Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Ilja Maslov > Sent: Friday, July 1, 2016 1:31 PM To: Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I've also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Is this notice done regarding attempt to start openstack-nova-compute during `openstack undercloud install` with repos set to Mitaka trunks per http://docs.openstack.org/developer/tripleo-docs/installation/installing.html ? Thanks. Boris. Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html Undercloud Installation - tripleo-docs 0.0.1.dev185 ... tripleo.org Undercloud Installation? This section contains instructions on how to install the undercloud and how to update components after installation. But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Fri Jul 1 19:19:48 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 1 Jul 2016 19:19:48 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: <174766503b2f42eda13dd9c8089ebf32@svr2-disp-exch.dispersive.local> References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> , <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> , <370acf4517cb4b3b9dc844940f0742b4@svr2-disp-exch.dispersive.local> , <174766503b2f42eda13dd9c8089ebf32@svr2-disp-exch.dispersive.local> Message-ID: ________________________________ From: Ilja Maslov Sent: Friday, July 1, 2016 3:14 PM To: Boris Derzhavets; Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Yep-yep, exactly the same experience here. I went back to centos-release-openstack-mitaka, because of the project priorities, but would love to revisit delorean trunk at a later date. Are you saying, that setting up stable Mitaka Repos works for TripleO deployment ? Ilja From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 3:07 PM To: Ilja Maslov ; Gunjan, Milind [CTO] ; Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: Ilja Maslov > Sent: Friday, July 1, 2016 2:18 PM To: Boris Derzhavets; Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment I believe so, process list shows that systemctl start openstack-nova-compute never finishes, but I do not remember how exactly console logs looked like. Ilja 1. /var/log/nova/nova-compute.log contains a bunch a rejected attempts to connect to 127.0.0.1:5672 2. If to verify status of port 5672 via ` netstat -antp | grep 5672` it appears to bind to only one IP - 192.0.2.1 and nothing else . 3. What causes `openstack underloud install` to hang at least via my experience ( case of Mitaka trunks ) I was working via instack-virt-setup not on bare metal. I believe that link http://docs.openstack.org/developer/tripleo-docs/installation/installing.html requires updates at least for instack-virt-setup (Mitaka) it doesn't work. I just cannot test http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html#upload-images because I cannot setup undercloud. TripleO Quickstart works fine, but I would like to make each step by myself working via instack-virt-setup, without any Ansible involvement Boris. From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 2:12 PM To: Ilja Maslov >; Gunjan, Milind [CTO] >; Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Ilja Maslov > Sent: Friday, July 1, 2016 1:31 PM To: Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I?ve also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Is this notice done regarding attempt to start openstack-nova-compute during `openstack undercloud install` with repos set to Mitaka trunks per http://docs.openstack.org/developer/tripleo-docs/installation/installing.html ? Thanks. Boris. Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html Undercloud Installation ? tripleo-docs 0.0.1.dev185 ... tripleo.org Undercloud Installation? This section contains instructions on how to install the undercloud and how to update components after installation. But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From imaslov at dispersivegroup.com Fri Jul 1 19:37:31 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 1 Jul 2016 19:37:31 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <08315fa5784d4cbe9cd93b1cd7a601fe@PREWE13M11.ad.sprint.com> <24755b61ab624c10bea2152601a0f67f@PREWE13M11.ad.sprint.com> , <82ecde4a60c946038017a47b15f157e2@svr2-disp-exch.dispersive.local> , <370acf4517cb4b3b9dc844940f0742b4@svr2-disp-exch.dispersive.local> , <174766503b2f42eda13dd9c8089ebf32@svr2-disp-exch.dispersive.local> Message-ID: <491234a99b0c406e95e6f032b5791299@svr2-disp-exch.dispersive.local> There was a thread on rdo-list around 6/6 about baremetal installation. So far, I've had semi-success when installing undercloud from centos-release-openstack-mitaka and mixing this with delorean images from http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/mitaka/delorean/ As far as this thread goes, undercloud installation was working fine and I believe that the problem that OP is having is stuck nova-compute service start during the undercloud deployment from the trunk. Ilja From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 3:20 PM To: Ilja Maslov ; Gunjan, Milind [CTO] ; Mohammed Arafa ; Marius Cornea ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: Ilja Maslov > Sent: Friday, July 1, 2016 3:14 PM To: Boris Derzhavets; Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Yep-yep, exactly the same experience here. I went back to centos-release-openstack-mitaka, because of the project priorities, but would love to revisit delorean trunk at a later date. Are you saying, that setting up stable Mitaka Repos works for TripleO deployment ? Ilja From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 3:07 PM To: Ilja Maslov >; Gunjan, Milind [CTO] >; Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: Ilja Maslov > Sent: Friday, July 1, 2016 2:18 PM To: Boris Derzhavets; Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment I believe so, process list shows that systemctl start openstack-nova-compute never finishes, but I do not remember how exactly console logs looked like. Ilja 1. /var/log/nova/nova-compute.log contains a bunch a rejected attempts to connect to 127.0.0.1:5672 2. If to verify status of port 5672 via ` netstat -antp | grep 5672` it appears to bind to only one IP - 192.0.2.1 and nothing else . 3. What causes `openstack underloud install` to hang at least via my experience ( case of Mitaka trunks ) I was working via instack-virt-setup not on bare metal. I believe that link http://docs.openstack.org/developer/tripleo-docs/installation/installing.html requires updates at least for instack-virt-setup (Mitaka) it doesn't work. I just cannot test http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html#upload-images because I cannot setup undercloud. TripleO Quickstart works fine, but I would like to make each step by myself working via instack-virt-setup, without any Ansible involvement Boris. From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 01, 2016 2:12 PM To: Ilja Maslov >; Gunjan, Milind [CTO] >; Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Ilja Maslov > Sent: Friday, July 1, 2016 1:31 PM To: Gunjan, Milind [CTO]; Mohammed Arafa; Marius Cornea; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi, Ideally, your /etc/hosts should list FQDN before the short name and retain localhost entries as many Linux services depend on the presence of the localhost entry: 127.0.0.1 undercloud.poc undercloud localhost localhost.localdomain localhost4 localhost4.localdomain I've also noticed that since about a week ago, undecloud rabbit started listening on br-ctlplane only, but nova tries to connect to it at 127.0.0.1, check if you have a lot of connection refused logs under /var/log/nova Is this notice done regarding attempt to start openstack-nova-compute during `openstack undercloud install` with repos set to Mitaka trunks per http://docs.openstack.org/developer/tripleo-docs/installation/installing.html ? Thanks. Boris. Ilja From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Gunjan, Milind [CTO] Sent: Thursday, June 30, 2016 4:27 PM To: Mohammed Arafa >; Marius Cornea >; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Hi Guys, I am still having issues while installing the undercloud. I have exhausted all the options and tried to do undercloud install as per the tripleo guidelines. http://tripleo.org/installation/installation.html Undercloud Installation - tripleo-docs 0.0.1.dev185 ... tripleo.org Undercloud Installation? This section contains instructions on how to install the undercloud and how to update components after installation. But, each time I hit the same errors: Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. Please suggest. From: Gunjan, Milind [CTO] Sent: Wednesday, June 29, 2016 7:39 AM To: 'Mohammed Arafa' > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment Okay . Updated the host file with shortname and fqdn. root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud undercloud.poc I am looking to install stable release of Openstack kilo / liberty. Can you please point me to the stable repo which I can pull for the install. Best Regards, Milind From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 7:34 AM To: Gunjan, Milind [CTO] > Cc: rdo-list at redhat.com; Marius Cornea > Subject: RE: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment You need both short name and fqdn in your hosts file. (Rabbitmq issue. Don't know if that's been fixed) On Jun 29, 2016 1:19 PM, "Gunjan, Milind [CTO]" > wrote: Thanks a lot for pointing out the mistakes. So, as suggested, I updated the hostname in the host file to match in similar way as instructed in the docs: [root at undercloud ~]# cat /etc/hostname undercloud.poc [root at undercloud ~]# cat /etc/hosts 127.0.0.1 undercloud.poc Is there any stable kilo package which can be used for installation ? Best Regards, Milind Gunjan From: Mohammed Arafa [mailto:mohammed.arafa at gmail.com] Sent: Wednesday, June 29, 2016 3:25 AM To: Marius Cornea > Cc: rdo-list at redhat.com; Gunjan, Milind [CTO] > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment The hostname in the hosts file don't match. On Jun 29, 2016 8:58 AM, "Marius Cornea" > wrote: On Tue, Jun 28, 2016 at 10:45 PM, Gunjan, Milind [CTO] > wrote: > Hi All, > > Thanks a lot for continued support. > > I would just like to get clarity regarding the last recommendation. > My current deployment is failing with following error : > > Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) > > > I have previously done RHEL OSP7 deployment and I verified the host file of RHEL OSP7 undercloud deployment and it was configured with host gateway used by pxe network. > > Similarly, we have set the current host gateway to 192.0.2.1 as shown below for rdo manager undercloud installation: > [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > I would like to know if it is required during rdo deployment to have it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain. The reason I asked for it is because of: Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") Typically the undercloud's local_ip is used for these operations but in your case it's added to the hosts files and maybe this ip name mapping doesn't allow the installation to proceed. Please note that the docs[1] point that you should have an FQDN entry in the hosts file before the undercloud installation(when 192.0.2.1 isn't yet set on the system), that's why I mentioned the ip address of the public nic. [1] http://docs.openstack.org/developer/tripleo-docs/installation/installation.html > > Thanks again for your time and help. Really appreciate it. > > Best Regards, > milind > > -----Original Message----- > From: Marius Cornea [mailto:marius at remote-lab.net] > Sent: Tuesday, June 28, 2016 4:28 AM > To: Gunjan, Milind [CTO] > > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment > > On Tue, Jun 28, 2016 at 5:18 AM, Gunjan, Milind [CTO] > > wrote: >> Hi Dan, >> Thanks a lot for your response. >> >> Even after properly updating the undercloud.conf file and checking the network configuration, undercloud deployment still fails. >> >> To recreate the issue , I am mentioning all the configuration steps: >> 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. >> 2. created stack user and provided required permission to stack user . >> 3. setting hostname >> sudo hostnamectl set-hostname rdo-undercloud.mydomain >> sudo hostnamectl set-hostname --transient rdo-undercloud.mydomain >> >> [stack at rdo-undercloud etc]$ cat /etc/hosts >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 >> 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > Could you try removing the 192.0.2.1 entry from /etc/hosts and replace > it with the address of the public interface, e.g: > $ip_public_nic rdo-undercloud rdo-undercloud.mydomain > > then rerun openstack undercloud install > >> 4. enable required repositories >> sudo yum -y install epel-release >> sudo curl -o /etc/yum.repos.d/delorean-liberty.repo https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo >> sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo >> >> 5. install repos >> >> sudo yum -y install yum-plugin-priorities >> sudo yum install -y python-tripleoclient >> >> 6. update undercloud.conf >> >> [stack at rdo-undercloud ~]$ cat undercloud.conf >> [DEFAULT] >> local_ip = 192.0.2.1/24 >> undercloud_public_vip = 192.0.2.2 >> undercloud_admin_vip = 192.0.2.3 >> local_interface = enp6s0 >> masquerade_network = 192.0.2.0/24 >> dhcp_start = 192.0.2.150 >> dhcp_end = 192.0.2.199 >> network_cidr = 192.0.2.0/24 >> network_gateway = 192.0.2.1 >> discovery_iprange = 192.0.2.200,192.0.2.230 >> discovery_runbench = false >> [auth] >> >> 7. install undercloud >> >> openstack undercloud install >> >> install ends in error: >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_service provider 'openstack': Execution of '/bin/openstack service list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: change from absent to present failed: Not managing Keystone_service[glance] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_role provider 'openstack': Execution of '/bin/openstack role list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: change from absent to present failed: Not managing Keystone_role[ResellerAdmin] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: change from absent to present failed: Not managing Keystone_service[ironic] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_user[nova]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: change from absent to present failed: Not managing Keystone_service[novav3] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: change from absent to present failed: Not managing Keystone_role[heat_stack_user] due to earlier Keystone API failures. >> Error: /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity[nova service, user nova]/Keystone_service[nova::compute]/ensure: change from absent to present failed: Not managing Keystone_service[nova] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: change from absent to present failed: Not managing Keystone_role[swiftoperator] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: change from absent to present failed: Not managing Keystone_service[neutron] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: change from absent to present failed: Not managing Keystone_service[ceilometer] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: change from absent to present failed: Not managing Keystone_service[swift] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: change from absent to present failed: Not managing Keystone_service[keystone] due to earlier Keystone API failures. >> Error: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: change from absent to present failed: Not managing Keystone_service[heat] due to earlier Keystone API failures. >> Error: Could not prefetch keystone_endpoint provider 'openstack': Execution of '/bin/openstack endpoint list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Error: /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_tenant provider 'openstack': Execution of '/bin/openstack project list --quiet --format csv --long' returned 1: Gateway Timeout (HTTP 504) >> Error: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: change from absent to present failed: Not managing Keystone_tenant[service] due to earlier Keystone API failures. >> Error: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: change from absent to present failed: Not managing Keystone_tenant[admin] due to earlier Keystone API failures. >> Error: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: change from absent to present failed: Not managing Keystone_role[admin] due to earlier Keystone API failures. >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could not evaluate: Execution of '/bin/openstack domain show --format shell Default' returned 1: Could not find resource Default >> Error: Could not prefetch keystone_domain provider 'openstack': Execution of '/bin/openstack domain list --quiet --format csv' returned 1: Gateway Timeout (HTTP 504) >> Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: (pymysql.err.OperationalError) (1045, u"Access denied for user 'heat'@'rdo-undercloud' (using password: YES)") >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call refresh: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of [0] >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered 'refresh' from 4 events >> Notice: Finished catalog run in 5259.44 seconds >> + rc=6 >> + set -e >> + echo 'puppet apply exited with exit code 6' >> puppet apply exited with exit code 6 >> + '[' 6 '!=' 2 -a 6 '!=' 0 ']' >> + exit 6 >> [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 1] >> >> [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install >> _run_orc(instack_env) >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc >> _run_live_command(args, instack_env, 'os-refresh-config') >> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command >> raise RuntimeError('%s failed. See log for details.' % name) >> RuntimeError: os-refresh-config failed. See log for details. >> Command 'instack-install-undercloud' returned non-zero exit status 1 >> >> >> I am not able to understand the exact cause of undercloud install failure. It would be really helpful if you guys can point be in direction to understand the exact cause of issue and any possible resolution. >> >> Thanks a lot. >> >> Best Regards, >> Milind >> >> >> Best Regards, >> Milind >> -----Original Message----- >> From: Dan Sneddon [mailto:dsneddon at redhat.com] >> Sent: Monday, June 27, 2016 12:40 PM >> To: Gunjan, Milind [CTO] >; rdo-list at redhat.com >> Subject: Re: [rdo-list] Redeploying UnderCloud >> >> On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >>> Hi All, >>> >>> Greeting. >>> >>> >>> >>> This is my first post and I am fairly new to RDO OpenStack. I am >>> working on RDO Triple-O deployment on baremetal. Due to incorrect >>> values in undercloud.conf file , my undercloud deployment failed. I >>> would like to redeploy undercloud and I am trying to understand what >>> steps has to be taken before redeploying undercloud. All the >>> deployment was under stack user . So first step will be to delete >>> stack user. I am not sure what has to be done regarding the networking >>> configuration autogenerated by os-net-config during the older install. >>> >>> Please advise. >>> >>> >>> >>> Best Regards, >>> >>> Milind >> >> No, definitely you don't want to delete the stack user, especially not as your first step! That would get rid of the configuration files, etc. >> that are in ~stack, and generally make your life harder than it needs to be. >> >> Anyway, it isn't necessary. You can do a procedure very much like what you do when upgrading the undercloud, with a couple of extra steps. >> >> As the stack user, edit your undercloud.conf, and make sure there are no more typos. >> >> If the typos were in the network configuration, you should delete the bridge and remove the ifcfg files: >> >> $ sudo ifdown br-ctlplane >> $ sudo ovs-vsctl del-br br-ctlplane >> $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane >> >> Next, run the underclound installation again: >> >> $ sudo yum update -y # Reboot after if kernel or core packages updated $ openstack undercloud install >> >> Then proceed with the rest of the instructions. You may find that if you already uploaded disk images or imported nodes that they will still be in the database. That's OK, or you can delete and reimport. >> >> -- >> Dan Sneddon | Principal OpenStack Engineer >> dsneddon at redhat.com | redhat.com/openstack >> 650.254.4025 | dsneddon:irc @dxs:twitter >> >> >> >> ________________________________ >> Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off for details. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Sat Jul 2 14:22:53 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 2 Jul 2016 14:22:53 +0000 Subject: [rdo-list] Testing 3xNode Controller (HA) + 2xCompute as of 07/02/16 Message-ID: ************************ Status on 07/02/16 ************************ Overcloud deployment :- Error as of 06/30/16 is back again CREATE_FAILED ResourceInError: resources.NovaCompute: Went to status ERROR due to "Message: No valid host was found. There are not enough hosts available., Code: 500" Overcoud deployment crashes again *********************** Status on 07/01/16 *********************** Template for deployment by QuickStart # Deploy an HA openstack environment. # control_memory: 6144 compute_memory: 6144 undercloud_memory: 8192 # Giving the undercloud additional CPUs can greatly improve heat's # performance (and result in a shorter deploy time). undercloud_vcpu: 4 # Create three controller nodes and one compute node. overcloud_nodes: - name: control_0 flavor: control - name: control_1 flavor: control - name: control_2 flavor: control - name: compute_0 flavor: compute - name: compute_1 flavor: compute # We don't need introspection in a virtual environment (because we are # creating all the "hardware" we really know the necessary # information). introspect: false # Tell tripleo about our environment. network_isolation: true extra_args: >- --control-scale 3 --compute-scale 2 --neutron-network-type vxlan --neutron-tunnel-types vxlan --ntp-server pool.ntp.org test_tempest: false test_ping: true enable_pacemaker: true VIRTHOST was under pressure during business day running on each Compute Node per one VM ( VMs F24 and U1604 getting 5 GB ISOS from the Net ) Top and `nova list` snapshots are attached. Might be pressure was not high enough. Thanks. Boris [cid:b5f8e245-9d7f-4dea-9b68-1357aff576c6][cid:22aa15df-5ebc-4791-affa-cd8c2819b725] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2016-07-02 01-29-28.png Type: image/png Size: 200212 bytes Desc: Screenshot from 2016-07-02 01-29-28.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2016-07-02 01-27-52.png Type: image/png Size: 119809 bytes Desc: Screenshot from 2016-07-02 01-27-52.png URL: From dmesser at redhat.com Mon Jul 4 08:04:20 2016 From: dmesser at redhat.com (Daniel Messer) Date: Mon, 4 Jul 2016 10:04:20 +0200 Subject: [rdo-list] RDO AiO on Fedora 24 Message-ID: Hi rdo-list, I was wondering what is the best way to get an all-in-one install of RDO Mitaka stood up on Fedora 24. I am looking to setup RDO on my workstation as an automation interface instead of plain libvirt so it will stay there for a while. Hence I pursued the following routes: 1. packstack - currently broken as it seems on Fedora because there is no CI/CD testing (only exists for RHEL/CentOS) - the answer file is interpreted differently (CONFIG_AMQP_ENABLE_SSL=y needed for proper self-signed certificates, errors because of puppet4 incompatibilities etc etc) 2. openstack-ansible - quite elaborate and no true AiO install - it always seems to come with the 3-way galera cluster which is not easily surviving a system reboot event 3. openstack-kolla - looks promising but apparently not supported currently on anything newer than F22 because of supermin defficients for compressed kernel modules in the CentOS Containers Any thoughts? Regards, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasca at redhat.com Mon Jul 4 13:25:46 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Mon, 4 Jul 2016 15:25:46 +0200 Subject: [rdo-list] Having an upstream patch in RDO: when and how? Message-ID: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> Hi everybody, while testing RDO master in CI i discovered this bug [1] and posted upstream the patch to solve it [2]. Since the patch got merged this morning, now I was wondering how to understand when this will be available in RDO. At the moment my CI jobs take the repos from [3], so is there a way (or a place) to follow the path of this modification and have an idea of when this will be available in RDO? Many thanks, [1] https://bugzilla.redhat.com/show_bug.cgi?id=1351547 [2] https://review.openstack.org/#/c/336072/ [3] /etc/yum.repos.d/delorean.repo http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-{{ release }}-tested/delorean.repo -- Raoul Scarazzini rasca at redhat.com From mrunge at redhat.com Mon Jul 4 13:50:05 2016 From: mrunge at redhat.com (Matthias Runge) Date: Mon, 4 Jul 2016 15:50:05 +0200 Subject: [rdo-list] RDO AiO on Fedora 24 In-Reply-To: References: Message-ID: <4adc4184-07b1-609f-571b-8b7b7af2ab4a@redhat.com> On 04/07/16 10:04, Daniel Messer wrote: > Hi rdo-list, > > I was wondering what is the best way to get an all-in-one install of RDO > Mitaka stood up on Fedora 24. I am looking to setup RDO on my > workstation as an automation interface instead of plain libvirt so it > will stay there for a while. OpenStack server packages were removed from Fedora. For current Mitaka setup, you should use CentOS and follow the steps on https://www.rdoproject.org/install/quickstart/ That's not really what you asked for, but the best we can do for now. -- Matthias Runge Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From me at gbraad.nl Mon Jul 4 13:51:15 2016 From: me at gbraad.nl (Gerard Braad) Date: Mon, 4 Jul 2016 21:51:15 +0800 Subject: [rdo-list] Having an upstream patch in RDO: when and how? In-Reply-To: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> References: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> Message-ID: Hi, On Mon, Jul 4, 2016 at 9:25 PM, Raoul Scarazzini wrote: > so is there a way (or a place) to follow the > path of this modification and have an idea of when this will be > available in RDO? AFAIR, the process of selecting a build for stable is a manual procedure. Therefore it is hard to estimate the time before a patch will be available in stable. I am sure someone else can explain in more detail about the other release repos. Regards, Gerard From javier.pena at redhat.com Mon Jul 4 13:58:35 2016 From: javier.pena at redhat.com (Javier Pena) Date: Mon, 4 Jul 2016 09:58:35 -0400 (EDT) Subject: [rdo-list] Having an upstream patch in RDO: when and how? In-Reply-To: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> References: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> Message-ID: <1566643779.4942598.1467640715313.JavaMail.zimbra@redhat.com> > Hi everybody, > while testing RDO master in CI i discovered this bug [1] and posted > upstream the patch to solve it [2]. > Since the patch got merged this morning, now I was wondering how to > understand when this will be available in RDO. At the moment my CI jobs > take the repos from [3], so is there a way (or a place) to follow the > path of this modification and have an idea of when this will be > available in RDO? > Hi Raoul, I'm glad you asked that question, so we can write down the answer somewhere :). We have 3 main steps: 1- Once your patch is merged, DLRN will catch it and build an updated openstack-tripleo-heat-templates RPM. Using the merge commit id (043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9), you can find it at https://trunk.rdoproject.org/centos7/report.html . Actually, it's built already -> https://trunk.rdoproject.org/centos7/04/3d/043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9_cbd0900e/ 2- The CI promotion pipeline will check if a repository is "consistent", which means there are no failed-to-build packages, and then take the latest consistent repo through a number of tests. You can check the CI pipeline at https://ci.centos.org/view/rdo/view/promotion-pipeline/ 3- After the CI job promotes a repository, it will create an internal symlink in the DLRN system. There is a job that synchronizes this symlink to http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-master-tested every two hours, and then it is distributed through the CentOS CDN. Regards, Javier > Many thanks, > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1351547 > [2] https://review.openstack.org/#/c/336072/ > [3] /etc/yum.repos.d/delorean.repo > http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-{{ release > }}-tested/delorean.repo > > -- > Raoul Scarazzini > rasca at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From rasca at redhat.com Mon Jul 4 14:49:58 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Mon, 4 Jul 2016 16:49:58 +0200 Subject: [rdo-list] Having an upstream patch in RDO: when and how? In-Reply-To: <1566643779.4942598.1467640715313.JavaMail.zimbra@redhat.com> References: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> <1566643779.4942598.1467640715313.JavaMail.zimbra@redhat.com> Message-ID: <805d4441-96eb-610c-0e93-ea46b191a9c8@redhat.com> On 04/07/2016 15:58, Javier Pena wrote: > >> Hi everybody, >> while testing RDO master in CI i discovered this bug [1] and posted >> upstream the patch to solve it [2]. >> Since the patch got merged this morning, now I was wondering how to >> understand when this will be available in RDO. At the moment my CI jobs >> take the repos from [3], so is there a way (or a place) to follow the >> path of this modification and have an idea of when this will be >> available in RDO? >> > > Hi Raoul, > > I'm glad you asked that question, so we can write down the answer somewhere :). We have 3 main steps: Happy to have made something useful. > 1- Once your patch is merged, DLRN will catch it and build an updated openstack-tripleo-heat-templates RPM. Using the merge commit id (043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9), you can find it at https://trunk.rdoproject.org/centos7/report.html . Actually, it's built already -> https://trunk.rdoproject.org/centos7/04/3d/043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9_cbd0900e/ Crystal clear, looking inside all the builds I see that all the repos associated with a project (in this case openstack-tripleo-heat-templates) have in common the last part after the underscore (in this case _cbd0900e). What's the criteria with this? Which rules define which modifications should be in a repo? And, most of all, how different repos are put together to be tested by a promotion pipeline? Are they always tested as single? Hope this questions are clear :) > 2- The CI promotion pipeline will check if a repository is "consistent", which means there are no failed-to-build packages, and then take the latest consistent repo through a number of tests. You can check the CI pipeline at https://ci.centos.org/view/rdo/view/promotion-pipeline/ In the promotion pipeline how can one search for the status of his repo? > 3- After the CI job promotes a repository, it will create an internal symlink in the DLRN system. There is a job that synchronizes this symlink to http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-master-tested every two hours, and then it is distributed through the CentOS CDN. That's clear too. > Regards, > Javier Many thanks, Raoul >> Many thanks, >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1351547 >> [2] https://review.openstack.org/#/c/336072/ >> [3] /etc/yum.repos.d/delorean.repo >> http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-{{ release >> }}-tested/delorean.repo >> >> -- >> Raoul Scarazzini >> rasca at redhat.com >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> -- Raoul Scarazzini rasca at redhat.com From hguemar at fedoraproject.org Mon Jul 4 15:00:03 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 4 Jul 2016 15:00:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20160704150003.97B1260A4009@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-07-06 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From javier.pena at redhat.com Mon Jul 4 15:05:19 2016 From: javier.pena at redhat.com (Javier Pena) Date: Mon, 4 Jul 2016 11:05:19 -0400 (EDT) Subject: [rdo-list] Having an upstream patch in RDO: when and how? In-Reply-To: <805d4441-96eb-610c-0e93-ea46b191a9c8@redhat.com> References: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> <1566643779.4942598.1467640715313.JavaMail.zimbra@redhat.com> <805d4441-96eb-610c-0e93-ea46b191a9c8@redhat.com> Message-ID: <410495579.4950288.1467644719967.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 04/07/2016 15:58, Javier Pena wrote: > > > >> Hi everybody, > >> while testing RDO master in CI i discovered this bug [1] and posted > >> upstream the patch to solve it [2]. > >> Since the patch got merged this morning, now I was wondering how to > >> understand when this will be available in RDO. At the moment my CI jobs > >> take the repos from [3], so is there a way (or a place) to follow the > >> path of this modification and have an idea of when this will be > >> available in RDO? > >> > > > > Hi Raoul, > > > > I'm glad you asked that question, so we can write down the answer somewhere > > :). We have 3 main steps: > > Happy to have made something useful. > > > 1- Once your patch is merged, DLRN will catch it and build an updated > > openstack-tripleo-heat-templates RPM. Using the merge commit id > > (043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9), you can find it at > > https://trunk.rdoproject.org/centos7/report.html . Actually, it's built > > already -> > > https://trunk.rdoproject.org/centos7/04/3d/043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9_cbd0900e/ > > Crystal clear, looking inside all the builds I see that all the repos > associated with a project (in this case > openstack-tripleo-heat-templates) have in common the last part after the > underscore (in this case _cbd0900e). This is expected, because there are several RPM packages created from a single source GitHub repo. The last part after the underscore is the short git hash for the distgit (a.k.a. repo where the spec file is), in this case https://github.com/rdo-packages/tripleo-heat-templates-distgit/commits/rpm-master. > What's the criteria with this? Which rules define which modifications > should be in a repo? And, most of all, how different repos are put > together to be tested by a promotion pipeline? Are they always tested as > single? In DLRN, repos are incrementally updated, something like: - The repo mentioned above includes the last version of openstack-tripleo-heat-templates (let's assume it is 1.0.1), and the last versions of every other package built before (let's assume we have foo 1.0.0 and bar 1.1.0) - When the next package is built (let's say foo 1.0.1), its repo will include the latest version of every package (so foo 1.0.1, bar 1.1.0 and t-h-t 1.0.1). So, every repo created after building the package we're interested in, includes the package version we want (or a later one). Finally, the promotion pipeline takes the latest consistent repo, which includes the latest version of every package already. > Hope this questions are clear :) > Absolutely :). > > 2- The CI promotion pipeline will check if a repository is "consistent", > > which means there are no failed-to-build packages, and then take the > > latest consistent repo through a number of tests. You can check the CI > > pipeline at https://ci.centos.org/view/rdo/view/promotion-pipeline/ > > In the promotion pipeline how can one search for the status of his repo? > In the Jenkins promotion pipeline, the first job is named "rdo-promote-get-hash-master", and it finds the hash. For the latest (failed) execution, it was https://ci.centos.org/job/rdo-promote-get-hash-master/461/console, and the value we see assigned as NEW_HASH includes the commit we were trying to promote. > > 3- After the CI job promotes a repository, it will create an internal > > symlink in the DLRN system. There is a job that synchronizes this symlink > > to > > http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-master-tested > > every two hours, and then it is distributed through the CentOS CDN. > > That's clear too. > > > Regards, > > Javier > > Many thanks, > > Raoul > > >> Many thanks, > >> > >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1351547 > >> [2] https://review.openstack.org/#/c/336072/ > >> [3] /etc/yum.repos.d/delorean.repo > >> http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-{{ release > >> }}-tested/delorean.repo > >> > >> -- > >> Raoul Scarazzini > >> rasca at redhat.com > >> > >> _______________________________________________ > >> rdo-list mailing list > >> rdo-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/rdo-list > >> > >> To unsubscribe: rdo-list-unsubscribe at redhat.com > >> > > -- > Raoul Scarazzini > rasca at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From rasca at redhat.com Mon Jul 4 15:12:55 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Mon, 4 Jul 2016 17:12:55 +0200 Subject: [rdo-list] Having an upstream patch in RDO: when and how? In-Reply-To: <410495579.4950288.1467644719967.JavaMail.zimbra@redhat.com> References: <74317d93-817d-f8cb-f82a-1465a53c1bac@redhat.com> <1566643779.4942598.1467640715313.JavaMail.zimbra@redhat.com> <805d4441-96eb-610c-0e93-ea46b191a9c8@redhat.com> <410495579.4950288.1467644719967.JavaMail.zimbra@redhat.com> Message-ID: <1b5c3cd2-5fc5-c6f9-a1ef-55a76ea1ad1c@redhat.com> I can say now I have the whole picture. Many thanks Javier! -- Raoul Scarazzini rasca at redhat.com On 04/07/2016 17:05, Javier Pena wrote: > > > ----- Original Message ----- >> On 04/07/2016 15:58, Javier Pena wrote: >>> >>>> Hi everybody, >>>> while testing RDO master in CI i discovered this bug [1] and posted >>>> upstream the patch to solve it [2]. >>>> Since the patch got merged this morning, now I was wondering how to >>>> understand when this will be available in RDO. At the moment my CI jobs >>>> take the repos from [3], so is there a way (or a place) to follow the >>>> path of this modification and have an idea of when this will be >>>> available in RDO? >>>> >>> >>> Hi Raoul, >>> >>> I'm glad you asked that question, so we can write down the answer somewhere >>> :). We have 3 main steps: >> >> Happy to have made something useful. >> >>> 1- Once your patch is merged, DLRN will catch it and build an updated >>> openstack-tripleo-heat-templates RPM. Using the merge commit id >>> (043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9), you can find it at >>> https://trunk.rdoproject.org/centos7/report.html . Actually, it's built >>> already -> >>> https://trunk.rdoproject.org/centos7/04/3d/043d71d5ce6a1d7c3fc3a8da78ac4ea5622bb6b9_cbd0900e/ >> >> Crystal clear, looking inside all the builds I see that all the repos >> associated with a project (in this case >> openstack-tripleo-heat-templates) have in common the last part after the >> underscore (in this case _cbd0900e). > > This is expected, because there are several RPM packages created from a single source GitHub repo. The last part after the underscore is the short git hash for the distgit (a.k.a. repo where the spec file is), in this case https://github.com/rdo-packages/tripleo-heat-templates-distgit/commits/rpm-master. > >> What's the criteria with this? Which rules define which modifications >> should be in a repo? And, most of all, how different repos are put >> together to be tested by a promotion pipeline? Are they always tested as >> single? > > In DLRN, repos are incrementally updated, something like: > > - The repo mentioned above includes the last version of openstack-tripleo-heat-templates (let's assume it is 1.0.1), and the last versions of every other package built before (let's assume we have foo 1.0.0 and bar 1.1.0) > - When the next package is built (let's say foo 1.0.1), its repo will include the latest version of every package (so foo 1.0.1, bar 1.1.0 and t-h-t 1.0.1). > > So, every repo created after building the package we're interested in, includes the package version we want (or a later one). > > Finally, the promotion pipeline takes the latest consistent repo, which includes the latest version of every package already. > >> Hope this questions are clear :) >> > > Absolutely :). > >>> 2- The CI promotion pipeline will check if a repository is "consistent", >>> which means there are no failed-to-build packages, and then take the >>> latest consistent repo through a number of tests. You can check the CI >>> pipeline at https://ci.centos.org/view/rdo/view/promotion-pipeline/ >> >> In the promotion pipeline how can one search for the status of his repo? >> > > In the Jenkins promotion pipeline, the first job is named "rdo-promote-get-hash-master", and it finds the hash. For the latest (failed) execution, it was https://ci.centos.org/job/rdo-promote-get-hash-master/461/console, and the value we see assigned as NEW_HASH includes the commit we were trying to promote. > >>> 3- After the CI job promotes a repository, it will create an internal >>> symlink in the DLRN system. There is a job that synchronizes this symlink >>> to >>> http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-master-tested >>> every two hours, and then it is distributed through the CentOS CDN. >> >> That's clear too. >> >>> Regards, >>> Javier >> >> Many thanks, >> >> Raoul >> >>>> Many thanks, >>>> >>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1351547 >>>> [2] https://review.openstack.org/#/c/336072/ >>>> [3] /etc/yum.repos.d/delorean.repo >>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-{{ release >>>> }}-tested/delorean.repo >>>> >>>> -- >>>> Raoul Scarazzini >>>> rasca at redhat.com >>>> >>>> _______________________________________________ >>>> rdo-list mailing list >>>> rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >>>> >> >> -- >> Raoul Scarazzini >> rasca at redhat.com >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> From tdecacqu at redhat.com Mon Jul 4 16:18:20 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 4 Jul 2016 16:18:20 +0000 Subject: [rdo-list] Scheduled maintenance of review.rdoproject.org: 2016-07-06 13:30 UTC Message-ID: <577A8C4C.7040903@redhat.com> Hello folks, We plan to upgrade review.rdoproject.org on 2016-07-06 13:30 UTC (this Wednesday). The downtime will be about 1 hour approximately. This is a maintenance upgrade to the last stable version of Software Factory 2.2.2, the changelog is: http://softwarefactory-project.io/r/gitweb?p=software-factory.git;a=blob_plain;f=CHANGELOG.md Regards, Software Factory Team, on behalf of rdo-infra -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From hguemar at fedoraproject.org Mon Jul 4 17:32:29 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 4 Jul 2016 19:32:29 +0200 Subject: [rdo-list] RDO AiO on Fedora 24 In-Reply-To: References: Message-ID: 2016-07-04 10:04 GMT+02:00 Daniel Messer : > Hi rdo-list, > > I was wondering what is the best way to get an all-in-one install of RDO > Mitaka stood up on Fedora 24. I am looking to setup RDO on my workstation as > an automation interface instead of plain libvirt so it will stay there for a > while. > > Hence I pursued the following routes: > > packstack - currently broken as it seems on Fedora because there is no CI/CD > testing (only exists for RHEL/CentOS) - the answer file is interpreted > differently (CONFIG_AMQP_ENABLE_SSL=y needed for proper self-signed > certificates, errors because of puppet4 incompatibilities etc etc) > > openstack-ansible - quite elaborate and no true AiO install - it always > seems to come with the 3-way galera cluster which is not easily surviving a > system reboot event > > openstack-kolla - looks promising but apparently not supported currently on > anything newer than F22 because of supermin defficients for compressed > kernel modules in the CentOS Containers > > > Any thoughts? > > Regards, > Daniel > Maintaining RDO on Fedora has proven to be really hard for multiple reasons: * new dependencies: some reviews gets stalled for long time. * curating dependencies with compatible versions was difficult and almost impossible. * desynchronized cycle, sometimes, new Fedora has to be released with an OpenStack release entering phase 2 of support, which means that we have to update EOLed versions for Fedora without being able to update it. This is a very bad idea to try deploying a stable release of OpenStack on a stable Fedora, as you'll likely need to pin some packages, and will need to rebuild newer ones. So Fedora support is now limited to clients with the nice benefit that you always get latest versions of clients. Moreover, it makes more sense to focus our effort to have a rock-solid distribution on EL7. Regards, H. From rbowen at redhat.com Tue Jul 5 15:34:10 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 5 Jul 2016 11:34:10 -0400 Subject: [rdo-list] Unanswered 'RDO' questions on ask.openstack.org Message-ID: <1512976a-ecc7-5d89-4962-04c1ee9dcb3c@redhat.com> 41 unanswered questions: RDO all in one memory usage and slowness issue https://ask.openstack.org/en/question/94279/rdo-all-in-one-memory-usage-and-slowness-issue/ Tags: slowrdo How to set quota for domain and have it shared with all the projects/tenants in domain https://ask.openstack.org/en/question/94105/how-to-set-quota-for-domain-and-have-it-shared-with-all-the-projectstenants-in-domain/ Tags: domainquotadriver rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Are following links considered by RH as official guide lines in meantime for TripleO instack-virt-setup RDO Liberty Stable? https://ask.openstack.org/en/question/93751/are-following-links-considered-by-rh-as-official-guide-lines-in-meantime-for-tripleo-instack-virt-setup-rdo-liberty-stable/ Tags: rdo, tripleo, instack Add new compute node for TripleO deployment in virtual environment https://ask.openstack.org/en/question/93703/add-new-compute-node-for-tripleo-deployment-in-virtual-environment/ Tags: compute, tripleo, liberty, virtual, baremetal Unable to start Ceilometer services https://ask.openstack.org/en/question/93600/unable-to-start-ceilometer-services/ Tags: ceilometer, ceilometer-api Adding hard drive space to RDO installation https://ask.openstack.org/en/question/93412/adding-hard-drive-space-to-rdo-installation/ Tags: cinder, openstack, space, add AWS Ec2 inst Eth port loses IP when attached to linux bridge in Openstack https://ask.openstack.org/en/question/92271/aws-ec2-inst-eth-port-loses-ip-when-attached-to-linux-bridge-in-openstack/ Tags: openstack, networking, aws ceilometer: I've installed openstack mitaka. but swift stops working when i configured the pipeline and ceilometer filter https://ask.openstack.org/en/question/92035/ceilometer-ive-installed-openstack-mitaka-but-swift-stops-working-when-i-configured-the-pipeline-and-ceilometer-filter/ Tags: ceilometer, openstack-swift, mitaka Fail on installing the controller on Cent OS 7 https://ask.openstack.org/en/question/92025/fail-on-installing-the-controller-on-cent-os-7/ Tags: installation, centos7, controller the error of service entity and API endpoints https://ask.openstack.org/en/question/91702/the-error-of-service-entity-and-api-endpoints/ Tags: service, entity, and, api, endpoints Running delorean fails: Git won't fetch sources https://ask.openstack.org/en/question/91600/running-delorean-fails-git-wont-fetch-sources/ Tags: delorean, rdo Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: stack, resource, topology, dashboard Build of instance aborted: Block Device Mapping is Invalid. https://ask.openstack.org/en/question/91205/build-of-instance-aborted-block-device-mapping-is-invalid/ Tags: cinder, lvm, centos7 No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack how to use chef auto manage openstack in RDO? https://ask.openstack.org/en/question/90992/how-to-use-chef-auto-manage-openstack-in-rdo/ Tags: chef, rdo Separate Cinder storage traffic from management https://ask.openstack.org/en/question/90405/separate-cinder-storage-traffic-from-management/ Tags: cinder, separate, nic, iscsi Openstack installation fails using packstack, failure is in installation of openstack-nova-compute. Error: Dependency Package[nova-compute] has failures https://ask.openstack.org/en/question/88993/openstack-installation-fails-using-packstack-failure-is-in-installation-of-openstack-nova-compute-error-dependency-packagenova-compute-has-failures/ Tags: novacompute, rdo, packstack, dependency, failure CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Can't create volume with cinder https://ask.openstack.org/en/question/86670/cant-create-volume-with-cinder/ Tags: cinder, glusterfs, nfs Sahara SSHException: Error reading SSH protocol banner https://ask.openstack.org/en/question/84710/sahara-sshexception-error-reading-ssh-protocol-banner/ Tags: sahara, icehouse, ssh, vanila Error Sahara create cluster: 'Error attach volume to instance https://ask.openstack.org/en/question/84651/error-sahara-create-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, vanila, icehouse Creating Sahara cluster: Error attach volume to instance https://ask.openstack.org/en/question/84650/creating-sahara-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, hadoop, icehouse, vanilla Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing redhat RDO enable access to swift via S3 https://ask.openstack.org/en/question/83607/redhat-rdo-enable-access-to-swift-via-s3/ Tags: swift, s3 -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdocommunity.org @RDOCommunity From marcin.juszkiewicz at linaro.org Tue Jul 5 15:49:03 2016 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Tue, 5 Jul 2016 17:49:03 +0200 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: <577BC402.6020308@centos.org> References: <577BC402.6020308@centos.org> Message-ID: <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> W dniu 05.07.2016 o 16:28, Jim Perrin pisze: > With the work that Marcin has done for openstack on aarch64, as well > as the ceph builds, we need to begin working a plan for publishing > these builds to a mirror. I'd like to identify the steps needed, and > the ownership for those steps. > > Thomas please correct/update these as needed Added few people to Cc: from pre-RH summit threads. > 1. new tag in cbs for aarch64 build, with modified dist for mitaka. > Will ceph need this as well? > 2. If we wish to re-use the centos-release-openstack-mitaka noarch, > dependencies of centos-release-ceph-hammer, centos-release-qemu-ev, > centos-release-storage-common, and centos-release-virt-common need > to be addressed. It would be good to populate all those repositories. I opened bugs for all tags: https://bugs.centos.org/view.php?id=11084 (openstack) https://bugs.centos.org/view.php?id=11085 (ceph) https://bugs.centos.org/view.php?id=11086 (virt/kvm-common) I looked at requirements of OpenStack Mitaka packages and turns out that none of them require ceph. But I could be wrong. The only requirement is from centos-release-openstack-mitaka one which depends on centos-release-ceph one. > Alternately we could create a > centos-release-openstack-mitaka-experimental for now if it can work > stand-alone. > 3. Mirror locations on buildlogs and mirrors need to be created and > tested. > Possible adjustments to existing -release files due to the /altarch/ > vs centos path differences. centos-release-* files would need changes to cover altarch paths. > 4. Package signing. This should already work with existing infra, but > need to test and validate. From apevec at redhat.com Tue Jul 5 15:52:08 2016 From: apevec at redhat.com (Alan Pevec) Date: Tue, 5 Jul 2016 17:52:08 +0200 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> References: <577BC402.6020308@centos.org> <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> Message-ID: > I looked at requirements of OpenStack Mitaka packages and turns out > that none of them require ceph. But I could be wrong. It is an optional storage backend, so dependency is implicit, via installer/puppet. Alan From rbowen at redhat.com Tue Jul 5 16:51:54 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 5 Jul 2016 12:51:54 -0400 Subject: [rdo-list] Upcoming OpenStack Meetups Message-ID: <584cdc64-0315-4dbc-0e3c-2fa7b25fc208@redhat.com> The following are the meetups I'm aware of in the coming week where OpenStack and/or RDO enthusiasts are likely to be present. If you know of others, please let me know, and/or add them to http://rdoproject.org/events If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Tuesday July 05 in Paris, FR: Meetup#21 Anniversaire 6 ans OpenStack - Analyse r?seau - Legacy apps - http://www.meetup.com/OpenStack-France/events/232023867/ * Wednesday July 06 in Tokyo, JP: The 2nd Japan Ops Workshop @ OpenStack Days Tokyo 2016 - http://www.meetup.com/Japan-OpenStack-User-Group/events/231907986/ * Wednesday July 06 in Tokyo, JP: Upstream Training in Japan #4 - http://www.meetup.com/Japan-OpenStack-User-Group/events/231744095/ * Wednesday July 06 in Stockholm, SE: OpenStack 6th Birthday - http://www.meetup.com/OpenStack-User-Group-Sweden/events/231914563/ * Thursday July 07 in Fort Lauderdale, FL, US: Monthly SFOUG Meeting - http://www.meetup.com/South-Florida-OpenStack-Users-Group/events/231083862/ * Thursday July 07 in Pleasanton, CA, US: Lets explore Containers in OpenStack - http://www.meetup.com/EastBay-OpenStack/events/231799565/ * Thursday July 07 in Z?rich, CH: 13th Swiss OpenStack User Group Meetup - http://www.meetup.com/openstack-ch/events/231069308/ * Friday July 08 in Lagos, NG: OpenStack 6th Birthday, Nigeria - http://www.meetup.com/OpenStack-User-Group-Nigeria/events/232340607/ * Friday July 08 in Durban, ZA: Celebrate OpenStack 6th Birthday! - http://www.meetup.com/Durban-OpenStack-User-Group/events/232048093/ * Tuesday July 12 in Hong Kong, HK: OpenStack 6th Birthday Celebration cum OpenStackers Meetup - http://www.meetup.com/Hong-Kong-OpenStack-User-Group/events/232273354/ -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdocommunity.org @RDOCommunity From tdecacqu at redhat.com Wed Jul 6 15:38:10 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 6 Jul 2016 15:38:10 +0000 Subject: [rdo-list] Scheduled maintenance of review.rdoproject.org: 2016-07-06 13:30 UTC In-Reply-To: <577A8C4C.7040903@redhat.com> References: <577A8C4C.7040903@redhat.com> Message-ID: <577D25E2.5070806@redhat.com> Hello folks, the upgrade is now COMPLETED! It took longer than expected because when we snapshot the instance, some dirty page were not completely written to the Ceph backend, resulting in some zero size files. Hopefully we were able to continue the upgrade with a fresh software factory image and the process went fine. What does software-factory version 2.2.2 brings to review.rdoproject.org (beside the usual batch of known bug fixes): * Gerritbot and gerrit replication is now managed by the config repo * Github user email are now properly retrieved * Smtp Greylisting 2 hours delay should be fixed * Better gitweb theme, e.g.: https://review.rdoproject.org/r/gitweb?p=config.git;a=blob;f=gerritbot/channels.yaml Last but not least: * Upgrade jenkins to version 1.651.2 to mitigate Jenkins Security Advisory 2016-05-11. Regards, Software Factory Team, on behalf of rdo-infra -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From rbowen at redhat.com Wed Jul 6 15:43:19 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 6 Jul 2016 11:43:19 -0400 Subject: [rdo-list] [Rdo-newsletter] July 2016 RDO Community Newsletter Message-ID: <3b1e4faf-6ead-b2cf-8db0-6663e64cbd78@redhat.com> Having trouble with the formatting? Read the newsletter at https://www.rdoproject.org/newsletter/2016-july/ Quick links: * Quick Start * Mailing Lists * RDO release packages * Review.RDOProject.org * RDO blog * Q&A * Open Tickets * Twitter * Newton release schedule Thanks for being part of the RDO community! It's been a very busy summer so far, and there's still a lot coming up. The very best ways to keep up with what's happening in RDO is to get on the mailing list and to follow us on Twitter . Red Hat Summit We just came back from Red Hat Summit, where we had a presence in the Community Central pavilion in the expo hall. We shared that space with our friends at Ansible, CentOS, Atomic, Ceph, and many other community projects . Highlights of the week included Rain Leander's presentation on becoming a contributor to the TripleO project , and Cumulus Networks' demo of their Rack On A Laptop OpenStack setup . We also had a USB drive containing the TripleO QuickStart image, so that one can get a single-node OpenStack installation up and running in just minutes. You'll soon be able to download the image from the RDO website , or you can come get one from me at LinuxCon next month on Toronto . Upcoming Events July is OpenStack Birthday month, and so you'll see birthday meetups cropping up all over the world. Check on Meetup.com for OpenStack meetups near you, or watch the calendar on the RDO events site . There's also a number of OpenStack Days events where Red Hat is sponsoring, or where we'll have an RDO presence of some kind: * OpenStack Days Tokyo (July 6-7) * OpenStack Days Taiwan (July 12) * OpenStack Day China (July 14-15) * OpenStack Days Silicon Valley (August 9-10) * OpenStack Days East (August 23-24) We'd love to see you there. Come, and bring your RDO questions and stories to share. Other RDO events, including the many OpenStack meetups around the world, are always listed on the RDO events page If you have an RDO-related event, please feel free to add it by submitting a pull request to https://github.com/rbowen/rh-events/blob/master/2016/RDO-Meetups.yml Test Day, July 21, 22 Newton Milestone 2 is due next week , and so we'll be having an RDO test day, July 21 and 22 , to verify that the RDO packages, produced from that milestone, are ready. Please join us in the #rdo channel on Freenode IRC as we test, so that we can ensure that Newton is the best release of RDO yet. Keep in touch There's lots of ways to stay in in touch with what's going on in the RDO community. The best ways are ? WWW * RDO * OpenStack Q&A Mailing Lists: * rdo-list mailing list * This newsletter IRC * IRC - #rdo on Freenode.irc.net * Puppet module development - #rdo-puppet Social Media * Follow us on Twitter * Google+ * Facebook Finally, every Wednesday at 15:00 UTC, we have the weekly RDO community meeting on the #RDO channel on Freenode IRC. And at 15:00 UTC Thursdays, we have the CentOS Cloud SIG Meeting on #centos-devel. Attending these is one of the best ways for your voice to be heard in the direction that RDO takes. Thanks again for being part of the RDO community! -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdocommunity.org @RDOCommunity -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rdo-newsletter mailing list Rdo-newsletter at redhat.com https://www.redhat.com/mailman/listinfo/rdo-newsletter From hguemar at fedoraproject.org Wed Jul 6 15:46:09 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 6 Jul 2016 17:46:09 +0200 Subject: [rdo-list] Scheduled maintenance of review.rdoproject.org: 2016-07-06 13:30 UTC In-Reply-To: <577D25E2.5070806@redhat.com> References: <577A8C4C.7040903@redhat.com> <577D25E2.5070806@redhat.com> Message-ID: 2016-07-06 17:38 GMT+02:00 Tristan Cacqueray : > Hello folks, > > the upgrade is now COMPLETED! > > It took longer than expected because when we snapshot the instance, > some dirty page were not completely written to the Ceph backend, > resulting in some zero size files. Hopefully we were able to continue > the upgrade with a fresh software factory image and the process went fine. > > What does software-factory version 2.2.2 brings to review.rdoproject.org > (beside the usual batch of known bug fixes): > > * Gerritbot and gerrit replication is now managed by the config repo > * Github user email are now properly retrieved > * Smtp Greylisting 2 hours delay should be fixed > * Better gitweb theme, e.g.: > > https://review.rdoproject.org/r/gitweb?p=config.git;a=blob;f=gerritbot/channels.yaml > > Last but not least: > * Upgrade jenkins to version 1.651.2 to mitigate Jenkins Security > Advisory 2016-05-11. > > Regards, > Software Factory Team, on behalf of rdo-infra > I'd like to thank the Software Factory team for helping us to maintain and upgrade the server. Thanks to them, we have a consistent and more reliable platform to maintain RDO. Thank you C?dric, Christian, Fabien, Matthieu and Tristan for your excellent job and patience! Regards, H. From amoralej at redhat.com Wed Jul 6 16:02:34 2016 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Wed, 6 Jul 2016 18:02:34 +0200 Subject: [rdo-list] [Meeting] RDO meeting (2016-07-06) Minutes Message-ID: ============================== #rdo: RDO meeting (2016-07-06) ============================== Meeting started by amoralej at 15:00:45 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-07-06/rdo_meeting_(2016-07-06).2016-07-06-15.00.log.html . Meeting summary --------------- * roll call (amoralej, 15:02:02) * move all openstack-* logging to systemd journal only (apevec) (amoralej, 15:04:49) * ACTION: apevec start thread about logging defaults in openstack RPMS (apevec, 15:10:44) * packaging exception request: bundling JARs in sahara-tests https://bugzilla.redhat.com/show_bug.cgi?id=1318765#c13 (apevec) (amoralej, 15:11:55) * ACTION: apevec to check with tosky about jar files in sahara-tests (amoralej, 15:15:35) * puppet packaging status (hguemar) (amoralej, 15:16:41) * puppet 3.x packages in RDO enable allow_virtual by default (number80, 15:17:17) * ACTION: hguemar document RDO puppet 3.x package deviation from standard (number80, 15:20:37) * postpone puppet-4.x to Ocata release (number80, 15:22:08) * stable branch maintenance upcoming changes (hguemar) (amoralej, 15:23:30) * LINK: https://trello.com/c/URAtrhLU/86-automate-stable-packages-releases (amoralej, 15:23:43) * DLRN will be building from STABLE-rdo branches (rpm-STABLE branches will be removed) (number80, 15:26:05) * rpm-master branch stays for DLRN only master packages (RDO Trunk master) (amoralej, 15:31:34) * no changes are expected in DLRN to support new model (amoralej, 15:34:22) * ACTION: hguemar review, sync, fix rpm-STABLE/STABLE-rdo branches (number80, 15:36:02) * old dlrn server will be used for tests (http://trunk-primary-old.rdoproject.org) (amoralej, 15:38:47) * ACTION: amoralej remove https redirection from old server (amoralej, 15:39:24) * ACTION: amoralej remove symlinks from old dlrn server (amoralej, 15:39:50) * review.rdoproject.org platform upgrade (amoralej, 15:41:49) * upgrade is DONE (number80, 15:42:03) * ACTION: hguemar and fbo will migrate project replications to new method (number80, 15:42:24) * thanks to Software Factory folks for helping us in the migration (number80, 15:42:49) * ODL packages in RDO? (amoralej, 15:44:56) * pending MEAD in CBS discussion on centos-devel (for opstools SIG) (amoralej, 15:45:21) * RDO proposal is to share a SIG (Cloud SIG) but with different repos and tags for OpenStack and ODL (amoralej, 15:51:22) * Upcoming dates (amoralej, 15:52:03) * OpenStack Summit CFP closes July 15th (amoralej, 15:52:20) * Newton M2 July 11-15 (amoralej, 15:52:31) * Newton M2 test day July 21-22 - https://www.rdoproject.org/testday/newton/milestone2 (amoralej, 15:52:46) * ACTION: hguemar add test case to enable people testing puppet 3.8.7 for M2 test days (number80, 15:54:07) * open floor (amoralej, 15:54:29) * chair for next meeting (amoralej, 15:55:24) * chandankumar to chair next meeting (amoralej, 15:55:48) Meeting ended at 15:56:19 UTC. Action Items ------------ * apevec start thread about logging defaults in openstack RPMS * apevec to check with tosky about jar files in sahara-tests * hguemar document RDO puppet 3.x package deviation from standard * hguemar review, sync, fix rpm-STABLE/STABLE-rdo branches * amoralej remove https redirection from old server * amoralej remove symlinks from old dlrn server * hguemar and fbo will migrate project replications to new method * hguemar add test case to enable people testing puppet 3.8.7 for M2 test days Action Items, by person ----------------------- * amoralej * amoralej remove https redirection from old server * amoralej remove symlinks from old dlrn server * apevec * apevec start thread about logging defaults in openstack RPMS * apevec to check with tosky about jar files in sahara-tests * openstack * apevec start thread about logging defaults in openstack RPMS * **UNASSIGNED** * hguemar document RDO puppet 3.x package deviation from standard * hguemar review, sync, fix rpm-STABLE/STABLE-rdo branches * hguemar and fbo will migrate project replications to new method * hguemar add test case to enable people testing puppet 3.8.7 for M2 test days People Present (lines said) --------------------------- * apevec (98) * number80 (83) * amoralej (68) * rbowen (21) * EmilienM (19) * dmsimard (14) * jpena (13) * zodbot (12) * jschlueter (8) * jjoyce (6) * trown (4) * openstack (3) * imcsk8 (2) * flepied (1) * eggmaster (1) * chandankumar (1) * rdobot (1) * rdogerrit (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot Thanks, Alfredo From rbowen at redhat.com Wed Jul 6 16:54:47 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 6 Jul 2016 12:54:47 -0400 Subject: [rdo-list] Fwd: Upcoming Deadline: OpenStack Summit Barcelona CFP In-Reply-To: <12FF2FFE-774C-4F81-BCF2-841FA6E14646@openstack.org> References: <12FF2FFE-774C-4F81-BCF2-841FA6E14646@openstack.org> Message-ID: <78c3ae4c-b72e-764e-3f0d-9d27235fc099@redhat.com> FYI, if you're thinking of submitting a talk to OpenStack Summit, the deadline is one week from today. -------- Forwarded Message -------- Subject: [OpenStack Marketing] Upcoming Deadline: OpenStack Summit Barcelona CFP Date: Wed, 29 Jun 2016 10:49:54 -0500 From: Erin Disney To: marketing at lists.openstack.org, women-of-openstack at lists.openstack.org, foundation-board at lists.openstack.org, openstack at lists.openstack.org, foundation at lists.openstack.org, openstack-operators at lists.openstack.org Just a friendly reminder that we are two weeks out from the deadline for the OpenStack Summit Barcelona Call for Presentations . *Deadline*: July 13th at 11:59pmPST (July 14th at 6:59am UTC) Submit here . Please contact speakersupport at openstack.org with any submission questions. Thanks! Erin Disney OpenStack Marketing erin at openstack.org > On Jun 6, 2016, at 3:56 AM, Erin Disney > wrote: > > Hi Everyone- > > The Call for Presentations is NOW OPEN > for > the upcoming OpenStack Summit in Barcelona, October 25-28! > > Hurry - the submission deadline is July 13th at 11:59pm PST (July 14th > at 6:59 UTC). > > Details on the selection process and track chair information can be > found here > . > June 17th is the deadline for track chair nominations. > > New: > Proposed sessions must indicate a format: Panel or Presentation. Each > format has a maximum number of speakers associated. Panels are allowed > a total of four speakers plus one moderator, whereas Presentations are > limited to two speakers. > > As a reminder, speakers are limited to a maximum of three presentation > submissions total. > > Contact > speakersupport at openstack.org > with any submission questions. > > REGISTRATION > Registration is now open > . Purchase your > discounted early bird passes now. Prices will increase in early September. > > SPONSORSHIP SALES > Sponsorship sales will open Wednesday, June 15, at 8:00am PST (15:00 > UTC). At that time the executable electronic contract will be made > available for signature HERE > . > All sponsorships will be sold on a first-come basis determined by the > time stamp on completed electronic agreements. The top level > sponsorships and limited quantity add-ons always sell out quickly so > please be mindful of that. > > Full details of the sponsorship signing process are outlined here > and > on page 4 of the Prospectus > . > Once you execute the Barcelona Summit contract you will receive a > confirmation email from Echosign, you must click the link in that > email to complete the signing process. Don?t forget that last step! If > you have any overdue balances owed to the Foundation then these must > be paid in full before you sign the Summit contract. > > AUSTIN SESSION FEEDBACK > During the OpenStack Summit in Austin we did not receive as many > sessions ratings as we'd have liked via the mobile app. Here?s another > chance to provide feedback to speakers. You'll find that the session > list is based on your personal schedule. If you didn't attend one of > the sessions listed, just skip it. We will also be improving the > in-app feedback mechanism for future Summits. Please note that all > feedback will be publicly viewable including your name. Click here > to rate the > Summit sessions that you attended in Austin. > > If you have any general Summit questions, contact us at > summit at openstack.org . > > Erin Disney > OpenStack Marketing > erin at openstack.org > -------------- next part -------------- _______________________________________________ Marketing mailing list Marketing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing From marcin.juszkiewicz at linaro.org Thu Jul 7 08:26:29 2016 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Thu, 7 Jul 2016 10:26:29 +0200 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: References: <577BC402.6020308@centos.org> <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> Message-ID: <743b47ac-f15d-d6a1-6861-b410cc5b0916@linaro.org> W dniu 05.07.2016 o 18:38, George Dunlap pisze: > On 05/07/16 16:49, Marcin Juszkiewicz wrote: >> W dniu 05.07.2016 o 16:28, Jim Perrin pisze: >>> With the work that Marcin has done for openstack on aarch64, as well >>> as the ceph builds, we need to begin working a plan for publishing >>> these builds to a mirror. I'd like to identify the steps needed, and >>> the ownership for those steps. >>> >>> Thomas please correct/update these as needed >> >> Added few people to Cc: from pre-RH summit threads. >> >>> 1. new tag in cbs for aarch64 build, with modified dist for mitaka. >>> Will ceph need this as well? >> >>> 2. If we wish to re-use the centos-release-openstack-mitaka noarch, >>> dependencies of centos-release-ceph-hammer, centos-release-qemu-ev, >>> centos-release-storage-common, and centos-release-virt-common need >>> to be addressed. >> >> It would be good to populate all those repositories. I opened bugs for >> all tags: >> >> https://bugs.centos.org/view.php?id=11084 (openstack) >> https://bugs.centos.org/view.php?id=11085 (ceph) >> https://bugs.centos.org/view.php?id=11086 (virt/kvm-common) > > I looked at this bug, but I couldn't tell exactly what packages you > wanted in here, and why the existing KVM packages weren't sufficient. > Could you just sketch out a brief summary? You are right. I am sometimes still lost in CentOS repository structure. What is in x86-64 virt/kvm-common repository is present in os/ one for aarch64 already. Only qemu-kvm-ev update (2.7.1 -> 2.10.1) would be nice to have. So we can kill that dependency from centos-release-openstack-mitaka package. Added note to the bug (I lack permissions to close it as notabug). From jperrin at centos.org Thu Jul 7 15:41:37 2016 From: jperrin at centos.org (Jim Perrin) Date: Thu, 7 Jul 2016 10:41:37 -0500 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: <743b47ac-f15d-d6a1-6861-b410cc5b0916@linaro.org> References: <577BC402.6020308@centos.org> <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> <743b47ac-f15d-d6a1-6861-b410cc5b0916@linaro.org> Message-ID: <577E7831.4030007@centos.org> On 07/07/2016 03:26 AM, Marcin Juszkiewicz wrote: > W dniu 05.07.2016 o 18:38, George Dunlap pisze: >> On 05/07/16 16:49, Marcin Juszkiewicz wrote: >>> W dniu 05.07.2016 o 16:28, Jim Perrin pisze: >>>> With the work that Marcin has done for openstack on aarch64, as well >>>> as the ceph builds, we need to begin working a plan for publishing >>>> these builds to a mirror. I'd like to identify the steps needed, and >>>> the ownership for those steps. >>>> >>>> Thomas please correct/update these as needed >>> >>> Added few people to Cc: from pre-RH summit threads. >>> >>>> 1. new tag in cbs for aarch64 build, with modified dist for mitaka. >>>> Will ceph need this as well? >>> >>>> 2. If we wish to re-use the centos-release-openstack-mitaka noarch, >>>> dependencies of centos-release-ceph-hammer, centos-release-qemu-ev, >>>> centos-release-storage-common, and centos-release-virt-common need >>>> to be addressed. >>> >>> It would be good to populate all those repositories. I opened bugs for >>> all tags: >>> >>> https://bugs.centos.org/view.php?id=11084 (openstack) >>> https://bugs.centos.org/view.php?id=11085 (ceph) >>> https://bugs.centos.org/view.php?id=11086 (virt/kvm-common) >> >> I looked at this bug, but I couldn't tell exactly what packages you >> wanted in here, and why the existing KVM packages weren't sufficient. >> Could you just sketch out a brief summary? > > You are right. I am sometimes still lost in CentOS repository structure. > > What is in x86-64 virt/kvm-common repository is present in os/ one for > aarch64 already. Only qemu-kvm-ev update (2.7.1 -> 2.10.1) would be nice > to have. We can pull this in. > So we can kill that dependency from centos-release-openstack-mitaka > package. Added note to the bug (I lack permissions to close it as notabug). I might suggest that for now (until we get the mirror bits sorted), we create a centos-release-mitaka-altarch package. This would avoid needing to mess with the existing x86_64 bits. once everything is aligned, then we can obsolete/provides the replacement and use the standard package across all architectures. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From hguemar at fedoraproject.org Fri Jul 8 02:00:01 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Fri, 8 Jul 2016 04:00:01 +0200 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: <577E7831.4030007@centos.org> References: <577BC402.6020308@centos.org> <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> <743b47ac-f15d-d6a1-6861-b410cc5b0916@linaro.org> <577E7831.4030007@centos.org> Message-ID: 2016-07-07 17:41 GMT+02:00 Jim Perrin : > > > On 07/07/2016 03:26 AM, Marcin Juszkiewicz wrote: >> W dniu 05.07.2016 o 18:38, George Dunlap pisze: >>> On 05/07/16 16:49, Marcin Juszkiewicz wrote: >>>> W dniu 05.07.2016 o 16:28, Jim Perrin pisze: >>>>> With the work that Marcin has done for openstack on aarch64, as well >>>>> as the ceph builds, we need to begin working a plan for publishing >>>>> these builds to a mirror. I'd like to identify the steps needed, and >>>>> the ownership for those steps. >>>>> >>>>> Thomas please correct/update these as needed >>>> >>>> Added few people to Cc: from pre-RH summit threads. >>>> >>>>> 1. new tag in cbs for aarch64 build, with modified dist for mitaka. >>>>> Will ceph need this as well? >>>> >>>>> 2. If we wish to re-use the centos-release-openstack-mitaka noarch, >>>>> dependencies of centos-release-ceph-hammer, centos-release-qemu-ev, >>>>> centos-release-storage-common, and centos-release-virt-common need >>>>> to be addressed. >>>> >>>> It would be good to populate all those repositories. I opened bugs for >>>> all tags: >>>> >>>> https://bugs.centos.org/view.php?id=11084 (openstack) >>>> https://bugs.centos.org/view.php?id=11085 (ceph) >>>> https://bugs.centos.org/view.php?id=11086 (virt/kvm-common) >>> >>> I looked at this bug, but I couldn't tell exactly what packages you >>> wanted in here, and why the existing KVM packages weren't sufficient. >>> Could you just sketch out a brief summary? >> >> You are right. I am sometimes still lost in CentOS repository structure. >> >> What is in x86-64 virt/kvm-common repository is present in os/ one for >> aarch64 already. Only qemu-kvm-ev update (2.7.1 -> 2.10.1) would be nice >> to have. > > We can pull this in. > >> So we can kill that dependency from centos-release-openstack-mitaka >> package. Added note to the bug (I lack permissions to close it as notabug). > > > I might suggest that for now (until we get the mirror bits sorted), we > create a centos-release-mitaka-altarch package. This would avoid needing > to mess with the existing x86_64 bits. once everything is aligned, then > we can obsolete/provides the replacement and use the standard package > across all architectures. > Works for me. > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From apevec at redhat.com Fri Jul 8 08:35:05 2016 From: apevec at redhat.com (Alan Pevec) Date: Fri, 8 Jul 2016 10:35:05 +0200 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: References: <577BC402.6020308@centos.org> <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> <743b47ac-f15d-d6a1-6861-b410cc5b0916@linaro.org> <577E7831.4030007@centos.org> Message-ID: On Fri, Jul 8, 2016 at 4:00 AM, Ha?kel wrote: > 2016-07-07 17:41 GMT+02:00 Jim Perrin : ... >> I might suggest that for now (until we get the mirror bits sorted), we >> create a centos-release-mitaka-altarch package. This would avoid needing >> to mess with the existing x86_64 bits. once everything is aligned, then >> we can obsolete/provides the replacement and use the standard package >> across all architectures. > > Works for me. I didn't understand why we need separate release -altarch package. I understand we do need separate CBS tags but they could be still mapped into the same per-arch locations under http://buildlogs.centos.org/centos/7/cloud/ and http://mirror.centos.org/centos/7/cloud/ so that current OpenStack CloudSIG .repo [1] which uses $basearch will work. Mappings for testing repo request (e.g. for RDO Newton [2]) would be: aarch64-cloud7-openstack-mitaka-testing|7/cloud/aarch64/openstack-mitaka/|7/cloud/aarch64/openstack-mitaka/|7/cloud/aarch64/openstack-mitaka/ aarch64-cloud7-openstack-common-testing|7/cloud/aarch64/openstack-mitaka/common/|7/cloud/aarch64/openstack-mitaka/|7/cloud/aarch64/openstack-mitaka/ Cheers, Alan [1] https://github.com/apevec/centos-release-openstack/blob/rdo-mitaka/CentOS-OpenStack.repo [2] https://bugs.centos.org/view.php?id=10985 From imaslov at dispersivegroup.com Fri Jul 8 11:46:14 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 8 Jul 2016 11:46:14 +0000 Subject: [rdo-list] tripleo centos7 images missing linux-firmware package Message-ID: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> Hi, I've noticed that tripleo built/CI images do not have linux-firmware package installed since they are based on the Centos 7 generic cloud image. This causes a lot of pain with the baremetal deployments that depend on the firmware to be present (in my case, bnx2 firmware is missing which causes introspection and overcloud deployment to fail, because PXE-booted images lose all network connectivity the moment networking is initialized from the image with messages like "bnx2: Can't load firmware file "bnx2/bnx2-rv2p-09ax-6.0.17.fw". Is there a good overview of the typical decision tree on where to open a bug, for which component, etc? Thanks, Ilja -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Fri Jul 8 12:59:45 2016 From: jperrin at centos.org (Jim Perrin) Date: Fri, 8 Jul 2016 07:59:45 -0500 Subject: [rdo-list] [Arm-dev] next steps for altarch with ceph and openstack In-Reply-To: References: <577BC402.6020308@centos.org> <6cfab514-db91-5ce5-bcfd-0799a72fb584@linaro.org> <743b47ac-f15d-d6a1-6861-b410cc5b0916@linaro.org> <577E7831.4030007@centos.org> Message-ID: <577FA3C1.2060100@centos.org> On 07/08/2016 03:35 AM, Alan Pevec wrote: > On Fri, Jul 8, 2016 at 4:00 AM, Ha?kel wrote: >> 2016-07-07 17:41 GMT+02:00 Jim Perrin : > ... >>> I might suggest that for now (until we get the mirror bits sorted), we >>> create a centos-release-mitaka-altarch package. This would avoid needing >>> to mess with the existing x86_64 bits. once everything is aligned, then >>> we can obsolete/provides the replacement and use the standard package >>> across all architectures. >> >> Works for me. > > I didn't understand why we need separate release -altarch package. I > understand we do need separate CBS tags but they could be still mapped > into the same per-arch locations under > http://buildlogs.centos.org/centos/7/cloud/ and > http://mirror.centos.org/centos/7/cloud/ so that current OpenStack > CloudSIG .repo [1] which uses $basearch will work. Mappings for > testing repo request (e.g. for RDO Newton [2]) would be: > The problem here is that the aarch64 builds are currently at mirror.centos.org/altarch/ not at /centos/, so either way we'll end up with split repositories for the architecture. I'm only suggesting a second package as a short term solution until we come up with a better way to manage this. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From bderzhavets at hotmail.com Fri Jul 8 14:21:11 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 8 Jul 2016 14:21:11 +0000 Subject: [rdo-list] tripleo centos7 images missing linux-firmware package In-Reply-To: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> References: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> Message-ID: ________________________________ From: rdo-list-bounces at redhat.com on behalf of Ilja Maslov Sent: Friday, July 8, 2016 7:46 AM To: rdo-list at redhat.com Subject: [rdo-list] tripleo centos7 images missing linux-firmware package Hi, I've noticed that tripleo built/CI images do not have linux-firmware package installed since they are based on the Centos 7 generic cloud image. This causes a lot of pain with the baremetal deployments that depend on the firmware to be present (in my case, bnx2 firmware is missing which causes introspection and overcloud deployment to fail, because PXE-booted images lose all network connectivity the moment networking is initialized from the image with messages like "bnx2: Can't load firmware file "bnx2/bnx2-rv2p-09ax-6.0.17.fw". Is there a good overview of the typical decision tree on where to open a bug, for which component, etc? File bug against openstack-tripleo at https://bugzilla.redhat.com/ Select version ( the one affected ) Hardware Severity Just follow instructions on bug's blank Boris. BTW. Here is a sample https://bugzilla.redhat.com/show_bug.cgi?id=1330289 Bug 1330289 - Failure to install Controller/Network ... bugzilla.redhat.com Red Hat Bugzilla - Bug 1330289. Failure to install Controller/Network&&Compute Cluster on RDO Mitaka with keystone API V3. Last modified: 2016-05-21 17:20:31 EDT Thanks, Ilja -------------- next part -------------- An HTML attachment was scrubbed... URL: From imaslov at dispersivegroup.com Fri Jul 8 15:14:23 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 8 Jul 2016 15:14:23 +0000 Subject: [rdo-list] tripleo centos7 images missing linux-firmware package In-Reply-To: References: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> Message-ID: Thank you! In case anyone is interested in following this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1353976 Ilja From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] Sent: Friday, July 08, 2016 10:21 AM To: Ilja Maslov ; rdo-list at redhat.com Subject: Re: tripleo centos7 images missing linux-firmware package ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Ilja Maslov > Sent: Friday, July 8, 2016 7:46 AM To: rdo-list at redhat.com Subject: [rdo-list] tripleo centos7 images missing linux-firmware package Hi, I've noticed that tripleo built/CI images do not have linux-firmware package installed since they are based on the Centos 7 generic cloud image. This causes a lot of pain with the baremetal deployments that depend on the firmware to be present (in my case, bnx2 firmware is missing which causes introspection and overcloud deployment to fail, because PXE-booted images lose all network connectivity the moment networking is initialized from the image with messages like "bnx2: Can't load firmware file "bnx2/bnx2-rv2p-09ax-6.0.17.fw". Is there a good overview of the typical decision tree on where to open a bug, for which component, etc? File bug against openstack-tripleo at https://bugzilla.redhat.com/ Select version ( the one affected ) Hardware Severity Just follow instructions on bug's blank Boris. BTW. Here is a sample https://bugzilla.redhat.com/show_bug.cgi?id=1330289 Bug 1330289 - Failure to install Controller/Network ... bugzilla.redhat.com Red Hat Bugzilla - Bug 1330289. Failure to install Controller/Network&&Compute Cluster on RDO Mitaka with keystone API V3. Last modified: 2016-05-21 17:20:31 EDT Thanks, Ilja -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrown2 at ocf.co.uk Fri Jul 8 15:42:44 2016 From: cbrown2 at ocf.co.uk (Christopher Brown) Date: Fri, 8 Jul 2016 16:42:44 +0100 Subject: [rdo-list] tripleo centos7 images missing linux-firmware package In-Reply-To: References: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> Message-ID: <1467992564.4818.29.camel@ocf.co.uk> Hi Ilja, Whilst it doesn't help fix the underlying issue, as a workaround you can use virt-customize to add this package in prior to uploading the overcloud image which is a fairly trivial task. E.g. $ virt-customize -a overcloud-full.qcow2 --install linux-firmware ... $ openstack overcloud image upload --update-existing This article is a good reference although it requires a Red Hat account: https://access.redhat.com/articles/1556833 Regards On Fri, 2016-07-08 at 16:14 +0100, Ilja Maslov wrote: > Thank you! > > In case anyone is interested in following this bug: https://bugzilla. > redhat.com/show_bug.cgi?id=1353976 > > Ilja > > From: Boris Derzhavets [mailto:bderzhavets at hotmail.com]? > Sent: Friday, July 08, 2016 10:21 AM > To: Ilja Maslov ; rdo-list at redhat.com > Subject: Re: tripleo centos7 images missing linux-firmware package > > > > > From: rdo-list-bounces at redhat.com on > behalf of Ilja Maslov > Sent: Friday, July 8, 2016 7:46 AM > To: rdo-list at redhat.com > Subject: [rdo-list] tripleo centos7 images missing linux-firmware > package > > Hi, > > I?ve noticed that tripleo built/CI images do not have linux-firmware > package installed since they are based on the Centos 7 generic cloud > image. > > This causes a lot of pain with the baremetal deployments that depend > on the firmware to be present (in my case, bnx2 firmware is missing > which causes introspection and overcloud deployment to fail, because > PXE-booted images lose all network connectivity the moment networking > is initialized from the image with messages like ?bnx2: Can?t load > firmware file ?bnx2/bnx2-rv2p-09ax-6.0.17.fw?. > > Is there a good overview of the typical decision tree on where to > open a bug, for which component, etc? > > File bug against openstack-tripleo at https://bugzilla.redhat.com/ > Select version ( the one affected ) > Hardware > Severity > Just follow instructions on bug's blank > > Boris. > BTW. Here is a sample > https://bugzilla.redhat.com/show_bug.cgi?id=1330289 > > > Bug 1330289 ? Failure to install Controller/Network ... > > bugzilla.redhat.com > > Red Hat Bugzilla ? Bug 1330289. Failure to install > Controller/Network&&Compute Cluster on RDO Mitaka with keystone API > V3. Last modified: 2016-05-21 17:20:31 EDT > > > Thanks, > Ilja -- Regards, Christopher Brown OpenStack Engineer OCF plc Tel: +44 (0)114 257 2200 Web: www.ocf.co.uk Blog: blog.ocf.co.uk Twitter: @ocfplc Please note, any emails relating to an OCF Support request must always be sent to support at ocf.co.uk for a ticket number to be generated or existing support ticket to be updated. Should this not be done then OCF cannot be held responsible for requests not dealt with in a timely manner. OCF plc is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG. This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system. From imaslov at dispersivegroup.com Fri Jul 8 15:51:26 2016 From: imaslov at dispersivegroup.com (Ilja Maslov) Date: Fri, 8 Jul 2016 15:51:26 +0000 Subject: [rdo-list] tripleo centos7 images missing linux-firmware package In-Reply-To: <1467992564.4818.29.camel@ocf.co.uk> References: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> <1467992564.4818.29.camel@ocf.co.uk> Message-ID: <276677f82a8546879cbf6ead4b697a08@svr2-disp-exch.dispersive.local> Thanks! I've been using guestmount + chroot to achieve the same :) How do I install linux-firmware in the IPA ramdisk? I do not think that libguestfs tools work with these and if I gunzip -c | cpio -id and then re-assemble, the image is not working anymore (kernel crashes). Ilja -----Original Message----- From: Christopher Brown [mailto:cbrown2 at ocf.co.uk] Sent: Friday, July 08, 2016 11:43 AM To: rdo-list at redhat.com; Ilja Maslov ; bderzhavets at hotmail.com Subject: Re: [rdo-list] tripleo centos7 images missing linux-firmware package Hi Ilja, Whilst it doesn't help fix the underlying issue, as a workaround you can use virt-customize to add this package in prior to uploading the overcloud image which is a fairly trivial task. E.g. $ virt-customize -a overcloud-full.qcow2 --install linux-firmware ... $ openstack overcloud image upload --update-existing This article is a good reference although it requires a Red Hat account: https://access.redhat.com/articles/1556833 Regards On Fri, 2016-07-08 at 16:14 +0100, Ilja Maslov wrote: > Thank you! > > In case anyone is interested in following this bug: https://bugzilla. > redhat.com/show_bug.cgi?id=1353976 > > Ilja > > From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] > Sent: Friday, July 08, 2016 10:21 AM > To: Ilja Maslov ; rdo-list at redhat.com > Subject: Re: tripleo centos7 images missing linux-firmware package > > > > > From: rdo-list-bounces at redhat.com on > behalf of Ilja Maslov > Sent: Friday, July 8, 2016 7:46 AM > To: rdo-list at redhat.com > Subject: [rdo-list] tripleo centos7 images missing linux-firmware > package > > Hi, > > I?ve noticed that tripleo built/CI images do not have linux-firmware > package installed since they are based on the Centos 7 generic cloud > image. > > This causes a lot of pain with the baremetal deployments that depend > on the firmware to be present (in my case, bnx2 firmware is missing > which causes introspection and overcloud deployment to fail, because > PXE-booted images lose all network connectivity the moment networking > is initialized from the image with messages like ?bnx2: Can?t load > firmware file ?bnx2/bnx2-rv2p-09ax-6.0.17.fw?. > > Is there a good overview of the typical decision tree on where to open > a bug, for which component, etc? > > File bug against openstack-tripleo at https://bugzilla.redhat.com/ > Select version ( the one affected ) > Hardware > Severity > Just follow instructions on bug's blank > > Boris. > BTW. Here is a sample > https://bugzilla.redhat.com/show_bug.cgi?id=1330289 > > > Bug 1330289 ? Failure to install Controller/Network ... > > bugzilla.redhat.com > > Red Hat Bugzilla ? Bug 1330289. Failure to install > Controller/Network&&Compute Cluster on RDO Mitaka with keystone API > V3. Last modified: 2016-05-21 17:20:31 EDT > > > Thanks, > Ilja -- Regards, Christopher Brown OpenStack Engineer OCF plc Tel: +44 (0)114 257 2200 Web: www.ocf.co.uk Blog: blog.ocf.co.uk Twitter: @ocfplc Please note, any emails relating to an OCF Support request must always be sent to support at ocf.co.uk for a ticket number to be generated or existing support ticket to be updated. Should this not be done then OCF cannot be held responsible for requests not dealt with in a timely manner. OCF plc is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG. This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system. From cbrown2 at ocf.co.uk Fri Jul 8 16:08:21 2016 From: cbrown2 at ocf.co.uk (Christopher Brown) Date: Fri, 8 Jul 2016 17:08:21 +0100 Subject: [rdo-list] tripleo centos7 images missing linux-firmware package In-Reply-To: <276677f82a8546879cbf6ead4b697a08@svr2-disp-exch.dispersive.local> References: <43645a1fd9dd45df8761b8ca4c923d6c@svr2-disp-exch.dispersive.local> <1467992564.4818.29.camel@ocf.co.uk> <276677f82a8546879cbf6ead4b697a08@svr2-disp-exch.dispersive.local> Message-ID: <1467994101.4818.35.camel@ocf.co.uk> I'd just be inclined to build my own images then and add linux-firmware to the downloaded image it builds everything else from. Located in ~/.cache after download. http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic _deployment_cli.html#get-images or you can check the docs on just building the ramdisk: http://docs.openstack.org/developer/ironic-python-agent/ On Fri, 2016-07-08 at 16:51 +0100, Ilja Maslov wrote: > Thanks! I've been using guestmount + chroot to achieve the same :) > > How do I install linux-firmware in the IPA ramdisk? I do not think > that libguestfs tools work with these and if I gunzip -c | cpio -id > and then re-assemble, the image is not working anymore (kernel > crashes). > > Ilja > > -----Original Message----- > From: Christopher Brown [mailto:cbrown2 at ocf.co.uk] > Sent: Friday, July 08, 2016 11:43 AM > To: rdo-list at redhat.com; Ilja Maslov ; b > derzhavets at hotmail.com > Subject: Re: [rdo-list] tripleo centos7 images missing linux-firmware > package > > Hi Ilja, > > Whilst it doesn't help fix the underlying issue, as a workaround you > can use virt-customize to add this package in prior to uploading the > overcloud image which is a fairly trivial task. > > E.g. > > $ virt-customize -a overcloud-full.qcow2 --install linux-firmware > > ... > > $ openstack overcloud image upload --update-existing > > This article is a good reference although it requires a Red Hat > account: > > https://access.redhat.com/articles/1556833 > > Regards > > On Fri, 2016-07-08 at 16:14 +0100, Ilja Maslov wrote: > > Thank you! > > > > In case anyone is interested in following this bug: https://bugzill > > a. > > redhat.com/show_bug.cgi?id=1353976 > > > > Ilja > > > > From: Boris Derzhavets [mailto:bderzhavets at hotmail.com] > > Sent: Friday, July 08, 2016 10:21 AM > > To: Ilja Maslov ; rdo-list at redhat.com > > Subject: Re: tripleo centos7 images missing linux-firmware package > > > > > > > > > > From: rdo-list-bounces at redhat.com on > > behalf of Ilja Maslov > > Sent: Friday, July 8, 2016 7:46 AM > > To: rdo-list at redhat.com > > Subject: [rdo-list] tripleo centos7 images missing linux-firmware > > package > > > > Hi, > > > > I?ve noticed that tripleo built/CI images do not have linux- > > firmware > > package installed since they are based on the Centos 7 generic > > cloud > > image. > > > > This causes a lot of pain with the baremetal deployments that > > depend > > on the firmware to be present (in my case, bnx2 firmware is missing > > which causes introspection and overcloud deployment to fail, > > because > > PXE-booted images lose all network connectivity the moment > > networking > > is initialized from the image with messages like ?bnx2: Can?t load > > firmware file ?bnx2/bnx2-rv2p-09ax-6.0.17.fw?. > > > > Is there a good overview of the typical decision tree on where to > > open > > a bug, for which component, etc? > > > > File bug against openstack-tripleo at https://bugzilla.redhat.co > > m/ > > Select version ( the one affected ) > > Hardware > > Severity > > Just follow instructions on bug's blank > > > > Boris. > > BTW. Here is a sample > > https://bugzilla.redhat.com/show_bug.cgi?id=1330289 > > > > > > Bug 1330289 ? Failure to install Controller/Network ... > > > > bugzilla.redhat.com > > > > Red Hat Bugzilla ? Bug 1330289. Failure to install > > Controller/Network&&Compute Cluster on RDO Mitaka with keystone API > > V3. Last modified: 2016-05-21 17:20:31 EDT > > > > > > Thanks, > > Ilja > -- > > Regards, > > Christopher Brown > OpenStack Engineer > OCF plc > > Tel: +44 (0)114 257 2200 > Web: www.ocf.co.uk > Blog: blog.ocf.co.uk > Twitter: @ocfplc > > Please note, any emails relating to an OCF Support request must > always be sent to support at ocf.co.uk for a ticket number to be > generated or existing support ticket to be updated. Should this not > be done then OCF cannot be held responsible for requests not dealt > with in a timely manner. > > OCF plc is a company registered in England and Wales. Registered > number 4132533, VAT number GB 780 6803 14. Registered office address: > OCF plc, > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield > S35 2PG. > > This message is private and confidential. If you have received this > message in error, please notify us immediately and remove it from > your system. -- Regards, Christopher Brown OpenStack Engineer OCF plc Tel: +44 (0)114 257 2200 Web: www.ocf.co.uk Blog: blog.ocf.co.uk Twitter: @ocfplc Please note, any emails relating to an OCF Support request must always be sent to support at ocf.co.uk for a ticket number to be generated or existing support ticket to be updated. Should this not be done then OCF cannot be held responsible for requests not dealt with in a timely manner. OCF plc is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG. This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system. From mengxiandong at gmail.com Mon Jul 11 07:15:07 2016 From: mengxiandong at gmail.com (Xiandong Meng) Date: Mon, 11 Jul 2016 15:15:07 +0800 Subject: [rdo-list] [CentOS-devel] Rebuilding RDO for ppc64le Message-ID: In RDO Austin BOF meeting, I have proposed to rebuild RDO packages for ppc64le. And a few discussions have been carried over since then. Now with the power builders up and running on cbs (http://cbs.centos.org/koji/hosts), I'd like to write to the mailinglist for more broad discussing. The goal is to rebuild RDO packages for ppc64le in CBS. And we will start with Mitaka release as it is a recent stable release. And one of the idea was to 1. create a new tag (cloud7-openstack-mitaka-candidate-ppc64le?) 2. import all 'noarch' builds from cloud7-openstack-mitaka-* tags 3. send all required packages to the builder 4. test resulting packages for installation & function validation (via ci pipeline?) 5. import/merge all of them to propose cloud7-openstack-* tag I think we need to proceed with this work without touching x86 tags until it is ready for merge. I have experience building the packages with local mock build environment, but i may need help to initiate that build work in CBS. Any comments/suggestions are welcome. Regards, Alex Meng mengxiandong at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Mon Jul 11 15:00:05 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 11 Jul 2016 15:00:05 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20160711150005.E72FA60A4009@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-07-13 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From hguemar at fedoraproject.org Mon Jul 11 15:22:44 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 11 Jul 2016 17:22:44 +0200 Subject: [rdo-list] [release] openstack-utils 2016.1 Message-ID: We are delighted to announce the release of openstack-utils 2016.1-1 With source available at: https://github.com/redhat-openstack/openstack-utils/releases/tag/2016.1-1 With package available in RDO repositories. Please report issues through github: http://github.com/redhat-openstack.org/openstack-utils/issues For more details, please see below. - openstack-status: autodetect MySQL variants (MariaDB) - openstack-status: add LBaaSv2 agent status check - openstack-db: drop out-of-date utility Regards, The RDO Community. From dtantsur at redhat.com Mon Jul 11 15:44:10 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Mon, 11 Jul 2016 17:44:10 +0200 Subject: [rdo-list] [release] openstack-utils 2016.1 In-Reply-To: References: Message-ID: On 07/11/2016 05:22 PM, Ha?kel wrote: > We are delighted to announce the release of openstack-utils 2016.1-1 > > With source available at: > > https://github.com/redhat-openstack/openstack-utils/releases/tag/2016.1-1 > > With package available in RDO repositories. > > Please report issues through github: > > http://github.com/redhat-openstack.org/openstack-utils/issues s/\.org// > > For more details, please see below. > - openstack-status: autodetect MySQL variants (MariaDB) > - openstack-status: add LBaaSv2 agent status check > - openstack-db: drop out-of-date utility > > Regards, > The RDO Community. > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From chkumar246 at gmail.com Mon Jul 11 15:48:17 2016 From: chkumar246 at gmail.com (Chandan kumar) Date: Mon, 11 Jul 2016 21:18:17 +0530 Subject: [rdo-list] [release] openstack-utils 2016.1 In-Reply-To: References: Message-ID: Hello, On Mon, Jul 11, 2016 at 8:52 PM, Ha?kel wrote: > We are delighted to announce the release of openstack-utils 2016.1-1 > > With source available at: > > https://github.com/redhat-openstack/openstack-utils/releases/tag/2016.1-1 > > With package available in RDO repositories. > > Please report issues through github: > > http://github.com/redhat-openstack.org/openstack-utils/issues > A small typo here: Please report issues through github: https://github.com/redhat-openstack/openstack-utils/issues Thanks, Chandan Kumar From rbowen at redhat.com Mon Jul 11 18:32:37 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 11 Jul 2016 14:32:37 -0400 Subject: [rdo-list] Unanswered RDO questions on ask.openstack.org Message-ID: <3dce94d3-b0bf-9d1a-3614-3f7c6bce304f@redhat.com> 41 unanswered questions: How to configure a flat network with OpenVswitch on Openstack mitaka https://ask.openstack.org/en/question/94439/how-to-configure-a-flat-network-with-openvswitch-on-openstack-mitaka/ Tags: mitaka, neutron, openvswitch, flatnetwork RDO all in one memory usage and slowness issue https://ask.openstack.org/en/question/94279/rdo-all-in-one-memory-usage-and-slowness-issue/ Tags: slowrdo How to set quota for domain and have it shared with all the projects/tenants in domain https://ask.openstack.org/en/question/94105/how-to-set-quota-for-domain-and-have-it-shared-with-all-the-projectstenants-in-domain/ Tags: domainquotadriver rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Are following links considered by RH as official guide lines in meantime for TripleO instack-virt-setup RDO Liberty Stable? https://ask.openstack.org/en/question/93751/are-following-links-considered-by-rh-as-official-guide-lines-in-meantime-for-tripleo-instack-virt-setup-rdo-liberty-stable/ Tags: rdo, tripleo, instack Add new compute node for TripleO deployment in virtual environment https://ask.openstack.org/en/question/93703/add-new-compute-node-for-tripleo-deployment-in-virtual-environment/ Tags: compute, tripleo, liberty, virtual, baremetal Unable to start Ceilometer services https://ask.openstack.org/en/question/93600/unable-to-start-ceilometer-services/ Tags: ceilometer, ceilometer-api Adding hard drive space to RDO installation https://ask.openstack.org/en/question/93412/adding-hard-drive-space-to-rdo-installation/ Tags: cinder, openstack, space, add AWS Ec2 inst Eth port loses IP when attached to linux bridge in Openstack https://ask.openstack.org/en/question/92271/aws-ec2-inst-eth-port-loses-ip-when-attached-to-linux-bridge-in-openstack/ Tags: openstack, networking, aws ceilometer: I've installed openstack mitaka. but swift stops working when i configured the pipeline and ceilometer filter https://ask.openstack.org/en/question/92035/ceilometer-ive-installed-openstack-mitaka-but-swift-stops-working-when-i-configured-the-pipeline-and-ceilometer-filter/ Tags: ceilometer, openstack-swift, mitaka Fail on installing the controller on Cent OS 7 https://ask.openstack.org/en/question/92025/fail-on-installing-the-controller-on-cent-os-7/ Tags: installation, centos7, controller the error of service entity and API endpoints https://ask.openstack.org/en/question/91702/the-error-of-service-entity-and-api-endpoints/ Tags: service, entity, and, api, endpoints Running delorean fails: Git won't fetch sources https://ask.openstack.org/en/question/91600/running-delorean-fails-git-wont-fetch-sources/ Tags: delorean, rdo Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: stack, resource, topology, dashboard Build of instance aborted: Block Device Mapping is Invalid. https://ask.openstack.org/en/question/91205/build-of-instance-aborted-block-device-mapping-is-invalid/ Tags: cinder, lvm, centos7 No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack how to use chef auto manage openstack in RDO? https://ask.openstack.org/en/question/90992/how-to-use-chef-auto-manage-openstack-in-rdo/ Tags: chef, rdo Separate Cinder storage traffic from management https://ask.openstack.org/en/question/90405/separate-cinder-storage-traffic-from-management/ Tags: cinder, separate, nic, iscsi Openstack installation fails using packstack, failure is in installation of openstack-nova-compute. Error: Dependency Package[nova-compute] has failures https://ask.openstack.org/en/question/88993/openstack-installation-fails-using-packstack-failure-is-in-installation-of-openstack-nova-compute-error-dependency-packagenova-compute-has-failures/ Tags: novacompute, rdo, packstack, dependency, failure CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Can't create volume with cinder https://ask.openstack.org/en/question/86670/cant-create-volume-with-cinder/ Tags: cinder, glusterfs, nfs Sahara SSHException: Error reading SSH protocol banner https://ask.openstack.org/en/question/84710/sahara-sshexception-error-reading-ssh-protocol-banner/ Tags: sahara, icehouse, ssh, vanila Error Sahara create cluster: 'Error attach volume to instance https://ask.openstack.org/en/question/84651/error-sahara-create-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, vanila, icehouse Creating Sahara cluster: Error attach volume to instance https://ask.openstack.org/en/question/84650/creating-sahara-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, hadoop, icehouse, vanilla Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From guanwen at ualberta.ca Mon Jul 11 20:47:29 2016 From: guanwen at ualberta.ca (Guanwen Zhang) Date: Mon, 11 Jul 2016 14:47:29 -0600 Subject: [rdo-list] RDO-release for OpenStack Mitaka Message-ID: hi, We had a OpenStack Swift Cluster consisting of a keystone node, a Swift proxy node, and 6 Swift storage nodes. All of them run in CentOS 7 x86_64. Just a few days ago, we tried to upgrade from our current Juno release to Mitaka. We found out that to get MySQL database on keystone node to be migrated is a huge pain. At first, I migrated the database from Juno to Kilo, and then from Kilo to Liberty, and then finally tried to migrate from Liberty to Mitaka, but failed. The famous error message is "Can't DROP 'ixu_user_name_domain_id'; check that column/key exists") [SQL: u'ALTER TABLE user DROP INDEX ixu_user_name_domain_id']", which was reported by someone else as a bug https://bugs.launchpad.net/keystone/+bug/1572341. This bug was fixed on July 7, 2016 which is after the rdo release. I am wondering if it is possible to have a new rdo-release for Mitaka to include these bug fixes, otherwise, the existing production Keystone database couldn't be migrated without great pain. Thanks a lot for your attention, and your suggestions are highly appreciated regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at gbraad.nl Tue Jul 12 06:23:48 2016 From: me at gbraad.nl (Gerard Braad) Date: Tue, 12 Jul 2016 14:23:48 +0800 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: Message-ID: Hi, On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang wrote: > > At first, I migrated the database from Juno to Kilo, and then from Kilo to > Liberty, and then finally tried to > migrate from Liberty to Mitaka, but failed. > Interesting. You're performing upgrade scenarios. > I am wondering if it is possible to have a new rdo-release for Mitaka to > include these bug fixes, otherwise, the existing production Keystone > database couldn't > be migrated without great pain. > To my knowledge the upgrade path is exactly a testing scenario that is not considered in the gates (and manual steps?) before promoting to stable. regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From guanwen at ualberta.ca Tue Jul 12 13:55:08 2016 From: guanwen at ualberta.ca (Guanwen Zhang) Date: Tue, 12 Jul 2016 07:55:08 -0600 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: Message-ID: The following is the reply from rdo-list. My message is in red, the reply is in green. I have a fresh installation of OpenStack version Mitaka, but upgrading is not working. On Tue, Jul 12, 2016 at 12:23 AM, Gerard Braad wrote: > Hi, > > > On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang > wrote: >> >> At first, I migrated the database from Juno to Kilo, and then from Kilo >> to Liberty, and then finally tried to >> migrate from Liberty to Mitaka, but failed. >> > > Interesting. You're performing upgrade scenarios. > > >> I am wondering if it is possible to have a new rdo-release for Mitaka to >> include these bug fixes, otherwise, the existing production Keystone >> database couldn't >> be migrated without great pain. >> > > To my knowledge the upgrade path is exactly a testing scenario that is not > considered in the gates (and manual steps?) before promoting to stable. > > regards, > > > Gerard > > -- > > Gerard Braad | http://gbraad.nl > [ Doing Open Source Matters ] > -- Henry Zhang Sr. Sys. admin and Storage Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Jul 12 14:35:20 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 12 Jul 2016 10:35:20 -0400 Subject: [rdo-list] Recent blog posts (July 12, 2016) Message-ID: <1fea350d-d219-9c7c-0e21-af4b35bbbde0@redhat.com> I was a few weeks behind on the recent blog posts update, so there's a LOT of great stuff in here. We also have a new addition to the list of bloggers - Carlos Camacho - who is blogging at http://www.anstack.com/ Who is Testing Your Cloud? by Maria Bracho With test driven development, continuous integration/continuous deployment and devops practices now the norm, most organizations understand the importance of testing their applications. ? read more at http://tm3.org/7k Clearing the Keystone Environment By Adam Young If you spend a lot of time switching between different cloud, different users, or even different projects for the same user when working with openstack, you?ve come across the problem where one environment variable from an old sourceing pollutes the current environment. I?ve been hit by that enough times that I wrote a small script to clear the environment. Read more at http://tm3.org/7l Connecting from your local machine to the TripleO overcloud horizon dashboard by Carlos Camacho The goal of this post is to show how to chain multiple ssh tunnels to browse into the horizon dashboard, deployed in a TripleO environment. ? read more at http://tm3.org/7m Improving the RDO Trunk infrastructure by Javier Pena Quite often, projects tend to to outgrow their initial expectations, and in those cases we face issues as they grow. This has been the case with our RDO Trunk repositories and the DLRN tool that builds them. ? read more at http://tm3.org/7n TripleO manual deployment of 'master' branch by Carlos Comacho This is a brief recipe about how to manually install TripleO in a remote 32GB RAM box. ? read more at http://tm3.org/7o Launching a Centos VM in Tripleo Overcloud by Adam Young My Overcloud deploy does not have any VM images associates with it. I want to test launching a VM. ? read more at http://tm3.org/7p Red Hat Summit in Review by Rich Bowen Despite my best intentions of blogging every day at Red Hat Summit, time got away from me, as it often does at these events. There?s always 3 things going on, and it?s hard to find a moment between that first cup of coffee, and stumbling into bed at the end of the night. ? read more at http://tm3.org/7q Openstack & TripleO deployment using Inlunch by Carlos Camacho Today I?m going to speak about the first Openstack installer I used to deploy TripleO. Inlunch, as its name aims it should make you ?Get an Instack environment prepared for you while you head out for lunch.? ? read more at http://tm3.org/7r Networking sessions in Red Hat Summit 2016 by Nir Yechiel I recently attended the Red Hat Summit 2016 event that took place at San Francisco, CA, on June 27-30. Red Hat Summit is a great place to interact with customers, partners, and product leads, and learn about Red Hat and the company?s direction. ? read more at http://tm3.org/7s Merging FreeIPA and Tripleo Undercloud Apache installs by Adam Young My Experiment yesterday left me with a broken IPA install. I aim to fix that. ? read more at http://tm3.org/7t Tokens without revocation by Adam Young PKI tokens in Keystone suffered from many things, most essentially the trials due to the various forms of revocation. I never wanted revocation in the first place. What could we have done differently? It just (I mean moments ago) came to me. ? read more at http://tm3.org/7u Liveness by Adam Young The term Liveness here refers to the need to ensure that the data used to make an authorization check is valid at the time of the check. ? read more at http://tm3.org/7v TripleO Deep dive sessions #1 (Quickstart deployment) by Carlos Camacho This is the first video from a series of ?Deep Dive? sessions related to TripleO deployments. ? read more at http://tm3.org/7w -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From bderzhavets at hotmail.com Tue Jul 12 18:30:11 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 12 Jul 2016 18:30:11 +0000 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: , Message-ID: ________________________________ From: rdo-list-bounces at redhat.com on behalf of Guanwen Zhang Sent: Tuesday, July 12, 2016 9:55 AM To: LIB-ITS Cc: rdo-list Subject: Re: [rdo-list] RDO-release for OpenStack Mitaka The following is the reply from rdo-list. My message is in red, the reply is in green. I have a fresh installation of OpenStack version Mitaka, but upgrading is not working. Please, post # rpm -qa \*openstack-keystone\* Boris. On Tue, Jul 12, 2016 at 12:23 AM, Gerard Braad > wrote: Hi, On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang > wrote: At first, I migrated the database from Juno to Kilo, and then from Kilo to Liberty, and then finally tried to migrate from Liberty to Mitaka, but failed. Interesting. You're performing upgrade scenarios. I am wondering if it is possible to have a new rdo-release for Mitaka to include these bug fixes, otherwise, the existing production Keystone database couldn't be migrated without great pain. To my knowledge the upgrade path is exactly a testing scenario that is not considered in the gates (and manual steps?) before promoting to stable. regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] -- Henry Zhang Sr. Sys. admin and Storage Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at redhat.com Tue Jul 12 20:02:34 2016 From: apevec at redhat.com (Alan Pevec) Date: Tue, 12 Jul 2016 22:02:34 +0200 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: Message-ID: > The famous error message is "Can't DROP 'ixu_user_name_domain_id'; check > that column/key exists") [SQL: u'ALTER TABLE user DROP INDEX > ixu_user_name_domain_id']", which was reported by someone else as a bug > https://bugs.launchpad.net/keystone/+bug/1572341. This bug was fixed on July > 7, 2016 which is after the rdo release. This fix is included in Keystone 9.1.0, I've built it now, until it reaches repositories you can take it from Koji: http://cbs.centos.org/koji/buildinfo?buildID=11451 We're working on automated Koji builds triggered by upstream release tags, for now it's a manual action. > I am wondering if it is possible to have a new rdo-release for Mitaka to > include these bug fixes, otherwise, the existing production Keystone > database couldn't be migrated without great pain. Please note that since Liberty there aren't coordinated upstream stable point releases, it is up to each project to releases asynchronously[1]. Cheers, Alan From guanwen at ualberta.ca Tue Jul 12 20:07:17 2016 From: guanwen at ualberta.ca (Guanwen Zhang) Date: Tue, 12 Jul 2016 14:07:17 -0600 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: Message-ID: The openstack-keystone package I used is openstack-keystone-9.0.2-1.el7.noarch Thanks a lot for your reply On Tue, Jul 12, 2016 at 12:30 PM, Boris Derzhavets wrote: > > > > ------------------------------ > *From:* rdo-list-bounces at redhat.com on > behalf of Guanwen Zhang > *Sent:* Tuesday, July 12, 2016 9:55 AM > *To:* LIB-ITS > *Cc:* rdo-list > *Subject:* Re: [rdo-list] RDO-release for OpenStack Mitaka > > The following is the reply from rdo-list. My message is in red, the reply > is in green. I have a fresh installation of OpenStack version Mitaka, but > upgrading is not working. > > Please, post > # rpm -qa \*openstack-keystone\* > > Boris. > > On Tue, Jul 12, 2016 at 12:23 AM, Gerard Braad wrote: > >> Hi, >> >> >> On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang >> wrote: >>> >>> At first, I migrated the database from Juno to Kilo, and then from Kilo >>> to Liberty, and then finally tried to >>> migrate from Liberty to Mitaka, but failed. >>> >> >> Interesting. You're performing upgrade scenarios. >> >> >>> I am wondering if it is possible to have a new rdo-release for Mitaka to >>> include these bug fixes, otherwise, the existing production Keystone >>> database couldn't >>> be migrated without great pain. >>> >> >> To my knowledge the upgrade path is exactly a testing scenario that is >> not considered in the gates (and manual steps?) before promoting to stable. >> >> regards, >> >> >> Gerard >> >> -- >> >> Gerard Braad | http://gbraad.nl >> [ Doing Open Source Matters ] >> > > > > -- > Henry Zhang > Sr. Sys. admin and Storage Specialist > -- Henry Zhang Sr. Sys. admin and Storage Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Jul 12 20:24:01 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 12 Jul 2016 20:24:01 +0000 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: , Message-ID: ________________________________ From: Guanwen Zhang Sent: Tuesday, July 12, 2016 4:07 PM To: Boris Derzhavets; rdo-list Subject: Re: [rdo-list] RDO-release for OpenStack Mitaka > The openstack-keystone package I used is > openstack-keystone-9.0.2-1.el7.noarch Actually . my intend was setup Mitaka trunk yum -y install yum-plugin-priorities cd /etc/yum.repos.d/ wget https://trunk.rdoproject.org/centos7-master/delorean-deps.repo wget https://trunk.rdoproject.org/centos7-master/current/delorean.repo due to openstack-keystone-10.0.0-0.20160712055536.5122632.el7.centos.noarch.rpm is in https://trunk.rdoproject.org/centos7-master/current/ At the moment the best option for you ( less risky ) is to install openstack-keystone 9.1.0 rpms just been built by Alan Pevec. See https://www.redhat.com/archives/rdo-list/2016-July/msg00061.html Boris. Thanks a lot for your reply On Tue, Jul 12, 2016 at 12:30 PM, Boris Derzhavets > wrote: ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Guanwen Zhang > Sent: Tuesday, July 12, 2016 9:55 AM To: LIB-ITS Cc: rdo-list Subject: Re: [rdo-list] RDO-release for OpenStack Mitaka The following is the reply from rdo-list. My message is in red, the reply is in green. I have a fresh installation of OpenStack version Mitaka, but upgrading is not working. Please, post # rpm -qa \*openstack-keystone\* Boris. On Tue, Jul 12, 2016 at 12:23 AM, Gerard Braad > wrote: Hi, On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang > wrote: At first, I migrated the database from Juno to Kilo, and then from Kilo to Liberty, and then finally tried to migrate from Liberty to Mitaka, but failed. Interesting. You're performing upgrade scenarios. I am wondering if it is possible to have a new rdo-release for Mitaka to include these bug fixes, otherwise, the existing production Keystone database couldn't be migrated without great pain. To my knowledge the upgrade path is exactly a testing scenario that is not considered in the gates (and manual steps?) before promoting to stable. regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] -- Henry Zhang Sr. Sys. admin and Storage Specialist -- Henry Zhang Sr. Sys. admin and Storage Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From guanwen at ualberta.ca Tue Jul 12 20:31:26 2016 From: guanwen at ualberta.ca (Guanwen Zhang) Date: Tue, 12 Jul 2016 14:31:26 -0600 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: Message-ID: Thank you Boris, is it possible to upgrade my keystone directly from Juno to Mitaka? What I tried before is "Upgrading from Juno to Kilo, and then from Kilo to Liberty, and then from Liberty to Mitaka". There is a problem to upgrade from Juno to Kilo, it complains about missing "url" column in the "region" table. After I did "alter table region add url varchar(255)", and then ran "keysonte-manage db_sync", it worked. regards On Tue, Jul 12, 2016 at 2:24 PM, Boris Derzhavets wrote: > > > > ------------------------------ > *From:* Guanwen Zhang > *Sent:* Tuesday, July 12, 2016 4:07 PM > *To:* Boris Derzhavets; rdo-list > *Subject:* Re: [rdo-list] RDO-release for OpenStack Mitaka > > > > The openstack-keystone package I used is > > > openstack-keystone-9.0.2-1.el7.noarch > > Actually . my intend was setup Mitaka trunk > > yum -y install yum-plugin-priorities > cd /etc/yum.repos.d/ > wget https://trunk.rdoproject.org/centos7-master/delorean-deps.repo > wget https://trunk.rdoproject.org/centos7-master/current/delorean.repo > due to > openstack-keystone-10.0.0-0.20160712055536.5122632.el7.centos.noarch.rpm > is in https://trunk.rdoproject.org/centos7-master/current/ > > At the moment the best option for you ( less risky ) is to install > openstack-keystone 9.1.0 rpms > just been built by Alan Pevec. > See https://www.redhat.com/archives/rdo-list/2016-July/msg00061.html > > Boris. > > > > > > Thanks a lot for your reply > > On Tue, Jul 12, 2016 at 12:30 PM, Boris Derzhavets < > bderzhavets at hotmail.com> wrote: > >> >> >> >> ------------------------------ >> *From:* rdo-list-bounces at redhat.com on >> behalf of Guanwen Zhang >> *Sent:* Tuesday, July 12, 2016 9:55 AM >> *To:* LIB-ITS >> *Cc:* rdo-list >> *Subject:* Re: [rdo-list] RDO-release for OpenStack Mitaka >> >> The following is the reply from rdo-list. My message is in red, the reply >> is in green. I have a fresh installation of OpenStack version Mitaka, but >> upgrading is not working. >> >> Please, post >> # rpm -qa \*openstack-keystone\* >> >> Boris. >> >> On Tue, Jul 12, 2016 at 12:23 AM, Gerard Braad wrote: >> >>> Hi, >>> >>> >>> On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang >>> wrote: >>>> >>>> At first, I migrated the database from Juno to Kilo, and then from Kilo >>>> to Liberty, and then finally tried to >>>> migrate from Liberty to Mitaka, but failed. >>>> >>> >>> Interesting. You're performing upgrade scenarios. >>> >>> >>>> I am wondering if it is possible to have a new rdo-release for Mitaka >>>> to include these bug fixes, otherwise, the existing production Keystone >>>> database couldn't >>>> be migrated without great pain. >>>> >>> >>> To my knowledge the upgrade path is exactly a testing scenario that is >>> not considered in the gates (and manual steps?) before promoting to stable. >>> >>> regards, >>> >>> >>> Gerard >>> >>> -- >>> >>> Gerard Braad | http://gbraad.nl >>> [ Doing Open Source Matters ] >>> >> >> >> >> -- >> Henry Zhang >> Sr. Sys. admin and Storage Specialist >> > > > > -- > Henry Zhang > Sr. Sys. admin and Storage Specialist > -- Henry Zhang Sr. Sys. admin and Storage Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Jul 12 20:50:14 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 12 Jul 2016 20:50:14 +0000 Subject: [rdo-list] RDO-release for OpenStack Mitaka In-Reply-To: References: , Message-ID: ________________________________ From: Guanwen Zhang Sent: Tuesday, July 12, 2016 4:31 PM To: Boris Derzhavets Cc: rdo-list Subject: Re: [rdo-list] RDO-release for OpenStack Mitaka Thank you Boris, is it possible to upgrade my keystone directly from Juno to Mitaka? Personally, I never do such kind of things in prod. So, I cannot advise. Fix you have mentioned in yours original message is packaged by Alan in mentioned build from Koji http://cbs.centos.org/koji/buildinfo?buildID=11451 Boris. What I tried before is "Upgrading from Juno to Kilo, and then from Kilo to Liberty, and then from Liberty to Mitaka". There is a problem to upgrade from Juno to Kilo, it complains about missing "url" column in the "region" table. After I did "alter table region add url varchar(255)", and then ran "keysonte-manage db_sync", it worked. regards On Tue, Jul 12, 2016 at 2:24 PM, Boris Derzhavets > wrote: ________________________________ From: Guanwen Zhang > Sent: Tuesday, July 12, 2016 4:07 PM To: Boris Derzhavets; rdo-list Subject: Re: [rdo-list] RDO-release for OpenStack Mitaka > The openstack-keystone package I used is > openstack-keystone-9.0.2-1.el7.noarch Actually . my intend was setup Mitaka trunk yum -y install yum-plugin-priorities cd /etc/yum.repos.d/ wget https://trunk.rdoproject.org/centos7-master/delorean-deps.repo wget https://trunk.rdoproject.org/centos7-master/current/delorean.repo due to openstack-keystone-10.0.0-0.20160712055536.5122632.el7.centos.noarch.rpm is in https://trunk.rdoproject.org/centos7-master/current/ At the moment the best option for you ( less risky ) is to install openstack-keystone 9.1.0 rpms just been built by Alan Pevec. See https://www.redhat.com/archives/rdo-list/2016-July/msg00061.html Boris. Thanks a lot for your reply On Tue, Jul 12, 2016 at 12:30 PM, Boris Derzhavets > wrote: ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Guanwen Zhang > Sent: Tuesday, July 12, 2016 9:55 AM To: LIB-ITS Cc: rdo-list Subject: Re: [rdo-list] RDO-release for OpenStack Mitaka The following is the reply from rdo-list. My message is in red, the reply is in green. I have a fresh installation of OpenStack version Mitaka, but upgrading is not working. Please, post # rpm -qa \*openstack-keystone\* Boris. On Tue, Jul 12, 2016 at 12:23 AM, Gerard Braad > wrote: Hi, On Tue, Jul 12, 2016 at 4:47 AM, Guanwen Zhang > wrote: At first, I migrated the database from Juno to Kilo, and then from Kilo to Liberty, and then finally tried to migrate from Liberty to Mitaka, but failed. Interesting. You're performing upgrade scenarios. I am wondering if it is possible to have a new rdo-release for Mitaka to include these bug fixes, otherwise, the existing production Keystone database couldn't be migrated without great pain. To my knowledge the upgrade path is exactly a testing scenario that is not considered in the gates (and manual steps?) before promoting to stable. regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] -- Henry Zhang Sr. Sys. admin and Storage Specialist -- Henry Zhang Sr. Sys. admin and Storage Specialist -- Henry Zhang Sr. Sys. admin and Storage Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From Milind.Gunjan at sprint.com Tue Jul 12 20:57:50 2016 From: Milind.Gunjan at sprint.com (Gunjan, Milind [CTO]) Date: Tue, 12 Jul 2016 20:57:50 +0000 Subject: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment In-Reply-To: <5a1c2f8a259365b157d98a32dfcfcf9b@dalarmor.org> References: <39b7c1ff61f54d9484df7c305145b5af@PREWE13M11.ad.sprint.com> <5a1c2f8a259365b157d98a32dfcfcf9b@dalarmor.org> Message-ID: Hi , Just an update on this mail chain. Undercloud deployment is still failing but I feel I know the reason why. Admin VIP and Public VIP are not getting configured on the br-ctlplane during the undercloud install and because of that keystone service while trying to reach service endpoints throws out "503 service unavailable" resulting in undercloud install fail. What can be the possible reasons of that ? Is there any networking configuration on interfaces which has to be done before running the install ? Any suggestions / guidance is highly appreciated. Best Regards, Milind -----Original Message----- From: Ced [mailto:ced at dalarmor.org] Sent: Friday, July 01, 2016 7:25 PM To: Gunjan, Milind [CTO] Cc: Dan Sneddon ; rdo-list at redhat.com Subject: Re: [rdo-list] Redeploying UnderCloud for baremetal triple-o deployment --- Ced 14 rue de tahiti 29000 Quimper tel : 06 60 68 08 27 Le 2016-06-28 05:18, Gunjan, Milind [CTO] a ?crit : > Hi Dan, > Thanks a lot for your response. > > Even after properly updating the undercloud.conf file and checking the > network configuration, undercloud deployment still fails. > > To recreate the issue , I am mentioning all the configuration steps: > 1. Installed CentOS Linux release 7.2.1511 (Core) image on baremetal. > 2. created stack user and provided required permission to stack user . > 3. setting hostname > sudo hostnamectl set-hostname rdo-undercloud.mydomain sudo hostnamectl > set-hostname --transient rdo-undercloud.mydomain > > [stack at rdo-undercloud etc]$ cat /etc/hosts > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > 192.0.2.1 rdo-undercloud undercloud-rdo.mydomain > > 4. enable required repositories > sudo yum -y install epel-release > sudo curl -o /etc/yum.repos.d/delorean-liberty.repo > https://trunk.rdoproject.org/centos7-liberty/current/delorean.repo > sudo curl -o /etc/yum.repos.d/delorean-deps-liberty.repo > http://trunk.rdoproject.org/centos7-liberty/delorean-deps.repo > > 5. install repos > > sudo yum -y install yum-plugin-priorities sudo yum install -y > python-tripleoclient > > 6. update undercloud.conf > > [stack at rdo-undercloud ~]$ cat undercloud.conf [DEFAULT] local_ip = > 192.0.2.1/24 undercloud_public_vip = 192.0.2.2 undercloud_admin_vip = > 192.0.2.3 local_interface = enp6s0 masquerade_network = 192.0.2.0/24 > dhcp_start = 192.0.2.150 dhcp_end = 192.0.2.199 network_cidr = > 192.0.2.0/24 network_gateway = 192.0.2.1 discovery_iprange = > 192.0.2.200,192.0.2.230 discovery_runbench = false [auth] > > 7. install undercloud > > openstack undercloud install > > install ends in error: > Error: > /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]: > Could not evaluate: Execution of '/bin/openstack domain show --format > shell Default' returned 1: Could not find resource Default > Error: > /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_user[heat]: > Could not evaluate: Execution of '/bin/openstack domain show --format > shell Default' returned 1: Could not find resource Default > Error: Could not prefetch keystone_service provider 'openstack': > Execution of '/bin/openstack service list --quiet --format csv --long' > returned 1: Gateway Timeout (HTTP 504) > Error: Not managing Keystone_service[glance] due to earlier Keystone > API failures. > Error: > /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_service[glance::image]/ensure: > change from absent to present failed: Not managing > Keystone_service[glance] due to earlier Keystone API failures. > Error: Could not prefetch keystone_role provider 'openstack': > Execution of '/bin/openstack role list --quiet --format csv' returned > 1: Gateway Timeout (HTTP 504) > Error: Not managing Keystone_role[ResellerAdmin] due to earlier > Keystone API failures. > Error: > /Stage[main]/Ceilometer::Keystone::Auth/Keystone_role[ResellerAdmin]/ensure: > change from absent to present failed: Not managing > Keystone_role[ResellerAdmin] due to earlier Keystone API failures. > Error: Not managing Keystone_service[ironic] due to earlier Keystone > API failures. > Error: > /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_service[ironic::baremetal]/ensure: > change from absent to present failed: Not managing > Keystone_service[ironic] due to earlier Keystone API failures. > Error: > /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity > [nova service, user nova]/Keystone_user[nova]: Could not evaluate: > Execution of '/bin/openstack domain show --format shell Default' > returned 1: > Could not find resource Default > Error: > /Stage[main]/Glance::Keystone::Auth/Keystone::Resource::Service_identity[glance]/Keystone_user[glance]: > Could not evaluate: Execution of '/bin/openstack domain show --format > shell Default' returned 1: Could not find resource Default > Error: Not managing Keystone_service[novav3] due to earlier Keystone > API failures. > Error: > /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity > [nova > v3 service, user novav3]/Keystone_service[novav3::computev3]/ensure: > change from absent to present failed: Not managing > Keystone_service[novav3] due to earlier Keystone API failures. > Error: Not managing Keystone_role[heat_stack_user] due to earlier > Keystone API failures. > Error: > /Stage[main]/Heat::Keystone::Auth/Keystone_role[heat_stack_user]/ensure: > change from absent to present failed: Not managing > Keystone_role[heat_stack_user] due to earlier Keystone API failures. > Error: > /Stage[main]/Ironic::Keystone::Auth/Keystone::Resource::Service_identity[ironic]/Keystone_user[ironic]: > Could not evaluate: Execution of '/bin/openstack domain show --format > shell Default' returned 1: Could not find resource Default > Error: Not managing Keystone_service[nova] due to earlier Keystone API > failures. > Error: > /Stage[main]/Nova::Keystone::Auth/Keystone::Resource::Service_identity > [nova service, user nova]/Keystone_service[nova::compute]/ensure: > change from absent to present failed: Not managing > Keystone_service[nova] due to earlier Keystone API failures. > Error: Not managing Keystone_role[swiftoperator] due to earlier > Keystone API failures. > Error: > /Stage[main]/Swift::Keystone::Auth/Keystone_role[swiftoperator]/ensure: > change from absent to present failed: Not managing > Keystone_role[swiftoperator] due to earlier Keystone API failures. > Error: > /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_user[ceilometer]: > Could not evaluate: Execution of '/bin/openstack domain show --format > shell Default' returned 1: Could not find resource Default > Error: Not managing Keystone_service[neutron] due to earlier Keystone > API failures. > Error: > /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_service[neutron::network]/ensure: > change from absent to present failed: Not managing > Keystone_service[neutron] due to earlier Keystone API failures. > Error: Not managing Keystone_service[ceilometer] due to earlier > Keystone API failures. > Error: > /Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_service[ceilometer::metering]/ensure: > change from absent to present failed: Not managing > Keystone_service[ceilometer] due to earlier Keystone API failures. > Error: Not managing Keystone_service[swift] due to earlier Keystone > API failures. > Error: > /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_service[swift::object-store]/ensure: > change from absent to present failed: Not managing > Keystone_service[swift] due to earlier Keystone API failures. > Error: Not managing Keystone_service[keystone] due to earlier Keystone > API failures. > Error: > /Stage[main]/Keystone::Endpoint/Keystone::Resource::Service_identity[keystone]/Keystone_service[keystone::identity]/ensure: > change from absent to present failed: Not managing > Keystone_service[keystone] due to earlier Keystone API failures. > Error: Not managing Keystone_service[heat] due to earlier Keystone API > failures. > Error: > /Stage[main]/Heat::Keystone::Auth/Keystone::Resource::Service_identity[heat]/Keystone_service[heat::orchestration]/ensure: > change from absent to present failed: Not managing > Keystone_service[heat] due to earlier Keystone API failures. > Error: Could not prefetch keystone_endpoint provider 'openstack': > Execution of '/bin/openstack endpoint list --quiet --format csv' > returned 1: Gateway Timeout (HTTP 504) > Error: > /Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]: > Could not evaluate: Execution of '/bin/openstack domain show --format > shell Default' returned 1: Could not find resource Default > Error: Could not prefetch keystone_tenant provider 'openstack': > Execution of '/bin/openstack project list --quiet --format csv --long' > returned 1: Gateway Timeout (HTTP 504) > Error: Not managing Keystone_tenant[service] due to earlier Keystone > API failures. > Error: > /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[service]/ensure: > change from absent to present failed: Not managing > Keystone_tenant[service] due to earlier Keystone API failures. > Error: Not managing Keystone_tenant[admin] due to earlier Keystone API > failures. > Error: > /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]/ensure: > change from absent to present failed: Not managing > Keystone_tenant[admin] due to earlier Keystone API failures. > Error: Not managing Keystone_role[admin] due to earlier Keystone API > failures. > Error: > /Stage[main]/Keystone::Roles::Admin/Keystone_role[admin]/ensure: > change from absent to present failed: Not managing > Keystone_role[admin] due to earlier Keystone API failures. > Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: Could > not evaluate: Execution of '/bin/openstack domain show --format shell > Default' returned 1: Could not find resource Default > Error: Could not prefetch keystone_domain provider 'openstack': > Execution of '/bin/openstack domain list --quiet --format csv' > returned 1: Gateway Timeout (HTTP 504) > Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]/returns: ERROR: > (pymysql.err.OperationalError) (1045, u"Access denied for user > 'heat'@'rdo-undercloud' (using password: YES)") > Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Failed to call > refresh: heat-manage --config-file /etc/heat/heat.conf db_sync > returned 1 instead of one of [0] > Error: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: heat-manage > --config-file /etc/heat/heat.conf db_sync returned 1 instead of one of > [0] > [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure > phase. [Command '['dib-run-parts', > '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit > status 1] > > Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Triggered > 'refresh' from 4 events > Notice: Finished catalog run in 5259.44 seconds > + rc=6 > + set -e > + echo 'puppet apply exited with exit code 6' > puppet apply exited with exit code 6 > + '[' 6 '!=' 2 -a 6 '!=' 0 ']' > + exit 6 > [2016-06-27 18:54:04,092] (os-refresh-config) [ERROR] during configure > phase. [Command '['dib-run-parts', > '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit > status 1] > > [2016-06-27 18:54:04,093] (os-refresh-config) [ERROR] Aborting... > Traceback (most recent call last): > File "", line 1, in > File > "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", > line 815, in install > _run_orc(instack_env) > File > "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", > line 699, in _run_orc > _run_live_command(args, instack_env, 'os-refresh-config') > File > "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", > line 370, in _run_live_command > raise RuntimeError('%s failed. See log for details.' % name) > RuntimeError: os-refresh-config failed. See log for details. > Command 'instack-install-undercloud' returned non-zero exit status 1 > > > I am not able to understand the exact cause of undercloud install > failure. It would be really helpful if you guys can point be in > direction to understand the exact cause of issue and any possible > resolution. > > Thanks a lot. > > Best Regards, > Milind > > > Best Regards, > Milind > -----Original Message----- > From: Dan Sneddon [mailto:dsneddon at redhat.com] > Sent: Monday, June 27, 2016 12:40 PM > To: Gunjan, Milind [CTO] ; > rdo-list at redhat.com > Subject: Re: [rdo-list] Redeploying UnderCloud > > On 06/27/2016 06:41 AM, Gunjan, Milind [CTO] wrote: >> Hi All, >> >> Greeting. >> >> >> >> This is my first post and I am fairly new to RDO OpenStack. I am >> working on RDO Triple-O deployment on baremetal. Due to incorrect >> values in undercloud.conf file , my undercloud deployment failed. I >> would like to redeploy undercloud and I am trying to understand what >> steps has to be taken before redeploying undercloud. All the >> deployment was under stack user . So first step will be to delete >> stack user. I am not sure what has to be done regarding the >> networking configuration autogenerated by os-net-config during the older install. >> >> Please advise. >> >> >> >> Best Regards, >> >> Milind > > No, definitely you don't want to delete the stack user, especially not > as your first step! That would get rid of the configuration files, > etc. > that are in ~stack, and generally make your life harder than it needs > to be. > > Anyway, it isn't necessary. You can do a procedure very much like what > you do when upgrading the undercloud, with a couple of extra steps. > > As the stack user, edit your undercloud.conf, and make sure there are > no more typos. > > If the typos were in the network configuration, you should delete the > bridge and remove the ifcfg files: > > $ sudo ifdown br-ctlplane > $ sudo ovs-vsctl del-br br-ctlplane > $ sudo rm /etc/sysconfig/network-scripts/*br-ctlplane > > Next, run the underclound installation again: > > $ sudo yum update -y # Reboot after if kernel or core packages > updated $ openstack undercloud install > > Then proceed with the rest of the instructions. You may find that if > you already uploaded disk images or imported nodes that they will > still be in the database. That's OK, or you can delete and reimport. > > -- > Dan Sneddon | Principal OpenStack Engineer > dsneddon at redhat.com | redhat.com/openstack > 650.254.4025 | dsneddon:irc @dxs:twitter > > > > ________________________________ > Learn more on how to switch to Sprint and save 50% on most Verizon, > AT&T or T-Mobile rates. See sprint.com/50off > for details. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If > you are not the intended recipient, please contact the sender and > delete all copies of the message. > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From rasca at redhat.com Wed Jul 13 12:26:51 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Wed, 13 Jul 2016 14:26:51 +0200 Subject: [rdo-list] Documenting RDO Stable and workarounds In-Reply-To: References: <1465247338.16318.11.camel@ocf.co.uk> Message-ID: <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> On 07/06/2016 13:38, Wesley Hayutin wrote: [...] > Couple notes.. > We are closing out some work at the moment that will enable > tripleo-quickstart to deploy on bare metal. > There are two methods in play here. > 1. Use a virtualized undercloud node on the bare metal undercloud > physical box. > 2. Install the undercloud directly on the bare metal undercloud node. > I'll let Ronelle and Rasca update the status on that. [...] Sorry for this late response on this, but finally we got merged all the modifications needed to deploy a baremetal undercloud with quickstart. All the details, with a complete readme that suggests how to implement everything are here https://github.com/redhat-openstack/ansible-role-tripleo-baremetal-undercloud Bye, -- Raoul Scarazzini rasca at redhat.com From cbrown2 at ocf.co.uk Wed Jul 13 13:07:19 2016 From: cbrown2 at ocf.co.uk (Christopher Brown) Date: Wed, 13 Jul 2016 14:07:19 +0100 Subject: [rdo-list] Documenting RDO Stable and workarounds In-Reply-To: <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> References: <1465247338.16318.11.camel@ocf.co.uk> <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> Message-ID: <1468415239.1975.39.camel@ocf.co.uk> Thanks for the update. This is great news. Virtualized undercloud mounted to shared storage will be a great improvement to the resiliency of the deployed cloud and I imagine will allow operators to even migrate to another server to perform maintenance on the host. On Wed, 2016-07-13 at 13:26 +0100, Raoul Scarazzini wrote: > On 07/06/2016 13:38, Wesley Hayutin wrote: > [...] > > Couple notes.. > > We are closing out some work at the moment that will enable > > tripleo-quickstart to deploy on bare metal. > > There are two methods in play here. > > 1. Use a virtualized undercloud node on the bare metal undercloud > > physical box. > > 2. Install the undercloud directly on the bare metal undercloud > > node. > > I'll let Ronelle and Rasca update the status on that. > [...] > > Sorry for this late response on this, but finally we got merged all > the > modifications needed to deploy a baremetal undercloud with > quickstart. > All the details, with a complete readme that suggests how to > implement > everything are here > https://github.com/redhat-openstack/ansible-role-tripleo-baremetal-un > dercloud > > Bye, > > -- > Raoul Scarazzini > rasca at redhat.com -- Regards, Christopher Brown OpenStack Engineer OCF plc Tel: +44 (0)114 257 2200 Web: www.ocf.co.uk Blog: blog.ocf.co.uk Twitter: @ocfplc Please note, any emails relating to an OCF Support request must always be sent to support at ocf.co.uk for a ticket number to be generated or existing support ticket to be updated. Should this not be done then OCF cannot be held responsible for requests not dealt with in a timely manner. OCF plc is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG. If you have received this message in error, please notify us immediately and remove it from your system. From me at gbraad.nl Wed Jul 13 15:16:23 2016 From: me at gbraad.nl (Gerard Braad) Date: Wed, 13 Jul 2016 23:16:23 +0800 Subject: [rdo-list] Documenting RDO Stable and workarounds In-Reply-To: <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> References: <1465247338.16318.11.camel@ocf.co.uk> <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> Message-ID: On Wed, Jul 13, 2016 at 8:26 PM, Raoul Scarazzini wrote: > All the details, with a complete readme that suggests how to implement > everything are here > https://github.com/redhat-openstack/ansible-role-tripleo-baremetal-undercloud Thanks for the follow-up. After (and maybe during) the OpenStack Days China I will spend some time to review this. -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] From chkumar246 at gmail.com Wed Jul 13 15:35:24 2016 From: chkumar246 at gmail.com (Chandan kumar) Date: Wed, 13 Jul 2016 21:05:24 +0530 Subject: [rdo-list] [Meeting] RDO meeting (2016-07-13) Minutes Message-ID: ============================== #rdo: RDO meeting - 2016-07-13 ============================== Meeting started by chandankumar at 15:01:08 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-07-13/rdo_meeting_-_2016-07-13.2016-07-13-15.01.log.html . Meeting summary --------------- * Roll Call (chandankumar, 15:01:39) * RDU2 network outage (chandankumar, 15:05:00) * Integration testing distgit reviews (!) with in-flight DLRN repositories (chandankumar, 15:08:58) * LINK: https://review.rdoproject.org/r/gitweb?p=config.git;a=blob;f=jobs/DLRN.yaml;h=d737c991e801b2ed955c9017d18681a98f50e575;hb=HEAD#l1 (dmsimard, 15:13:45) * LINK: https://dmsimard.com/2016/07/13/improving-rdo-packaging-testing-coverage/ (dmsimard, 15:15:02) * Upcoming dates (chandankumar, 15:18:38) * OpenStack Summit CFP closes TODAY AT MIDNIGHT PACIFIC (chandankumar, 15:19:04) * Newton M2 this week (chandankumar, 15:19:33) * Newton M2 test day next week - July 21, 22 (chandankumar, 15:19:52) * LINK: https://www.rdoproject.org/testday/newton/milestone2/ (chandankumar, 15:20:00) * chair for next meeting (chandankumar, 15:22:24) * ACTION: imcsk8 to chair for next meeting (chandankumar, 15:22:53) * Open Floor (chandankumar, 15:23:19) Meeting ended at 15:31:26 UTC. Action Items ------------ * imcsk8 to chair for next meeting Action Items, by person ----------------------- * imcsk8 * imcsk8 to chair for next meeting * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * chandankumar (41) * dmsimard (35) * number80 (23) * zodbot (11) * imcsk8 (7) * jruzicka (7) * trown (6) * openstack (3) * myoung (2) * rbowen (1) * hrybacki (1) * weshay (1) * coolsvap (1) * trown|lunchlearn (1) * trown|lunchnlear (1) * rdogerrit (1) * adarazs (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot Thanks, Chandan Kumar From rasca at redhat.com Wed Jul 13 15:36:41 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Wed, 13 Jul 2016 17:36:41 +0200 Subject: [rdo-list] Documenting RDO Stable and workarounds In-Reply-To: References: <1465247338.16318.11.camel@ocf.co.uk> <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> Message-ID: That would be great. Many thanks, -- Raoul Scarazzini rasca at redhat.com On 13/07/2016 17:16, Gerard Braad wrote: > On Wed, Jul 13, 2016 at 8:26 PM, Raoul Scarazzini wrote: >> All the details, with a complete readme that suggests how to implement >> everything are here >> https://github.com/redhat-openstack/ansible-role-tripleo-baremetal-undercloud > > Thanks for the follow-up. After (and maybe during) the OpenStack Days > China I will spend some time to review this. > From rasca at redhat.com Wed Jul 13 15:41:33 2016 From: rasca at redhat.com (Raoul Scarazzini) Date: Wed, 13 Jul 2016 17:41:33 +0200 Subject: [rdo-list] Documenting RDO Stable and workarounds In-Reply-To: <1468415239.1975.39.camel@ocf.co.uk> References: <1465247338.16318.11.camel@ocf.co.uk> <3a61f4cf-9d0d-78e2-5b6b-1cd12ba66593@redhat.com> <1468415239.1975.39.camel@ocf.co.uk> Message-ID: <194d801c-4c5e-0d8e-f73f-216762fc109e@redhat.com> Yes, I feel like this is the right path to follow to obtain some kind of undercloud HA, at least from a machine perspective. Having the HA on the services well, is totally another story :) -- Raoul Scarazzini rasca at redhat.com On 13/07/2016 15:07, Christopher Brown wrote: > Thanks for the update. This is great news. > > Virtualized undercloud mounted to shared storage will be a great > improvement to the resiliency of the deployed cloud and I imagine will > allow operators to even migrate to another server to perform > maintenance on the host. > > On Wed, 2016-07-13 at 13:26 +0100, Raoul Scarazzini wrote: >> On 07/06/2016 13:38, Wesley Hayutin wrote: >> [...] >>> Couple notes.. >>> We are closing out some work at the moment that will enable >>> tripleo-quickstart to deploy on bare metal. >>> There are two methods in play here. >>> 1. Use a virtualized undercloud node on the bare metal undercloud >>> physical box. >>> 2. Install the undercloud directly on the bare metal undercloud >>> node. >>> I'll let Ronelle and Rasca update the status on that. >> [...] >> >> Sorry for this late response on this, but finally we got merged all >> the >> modifications needed to deploy a baremetal undercloud with >> quickstart. >> All the details, with a complete readme that suggests how to >> implement >> everything are here >> https://github.com/redhat-openstack/ansible-role-tripleo-baremetal-un >> dercloud >> >> Bye, >> >> -- >> Raoul Scarazzini >> rasca at redhat.com > -- > > Regards, > > Christopher Brown > OpenStack Engineer > OCF plc > > Tel: +44 (0)114 257 2200 > Web: www.ocf.co.uk > Blog: blog.ocf.co.uk > Twitter: @ocfplc > > Please note, any emails relating to an OCF Support request must always > be sent to support at ocf.co.uk for a ticket number to be generated or > existing support ticket to be updated. Should this not be done then OCF > > cannot be held responsible for requests not dealt with in a timely > manner. > > OCF plc is a company registered in England and Wales. Registered number > > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, > > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 > 2PG. > > If you have received this message in error, please notify us > immediately and remove it from your system. > From guanwen at ualberta.ca Wed Jul 13 16:06:34 2016 From: guanwen at ualberta.ca (Guanwen Zhang) Date: Wed, 13 Jul 2016 10:06:34 -0600 Subject: [rdo-list] python-keystone-9.1.0-1.el7 Message-ID: I tried to install openstack-keystone-9.1.0-1.el7.noarch.rpm, it complains about python-keystone = 1:9.1.0-1.el7 is needed by openstack-keystone-1:9.1.0-1.el7.noarch Just wondering where to get the version of python-keystone-9.1.0 Thanks Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at redhat.com Wed Jul 13 16:45:25 2016 From: apevec at redhat.com (Alan Pevec) Date: Wed, 13 Jul 2016 18:45:25 +0200 Subject: [rdo-list] python-keystone-9.1.0-1.el7 In-Reply-To: References: Message-ID: On Wed, Jul 13, 2016 at 6:06 PM, Guanwen Zhang wrote: > I tried to install openstack-keystone-9.1.0-1.el7.noarch.rpm, it complains > about > > python-keystone = 1:9.1.0-1.el7 is needed by > openstack-keystone-1:9.1.0-1.el7.noarch You need to update all subpackages from the build, or at this point enable openstack-mitaka-testing repo, it is now available at http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-mitaka/ Alan From rbowen at redhat.com Thu Jul 14 13:34:36 2016 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 14 Jul 2016 09:34:36 -0400 Subject: [rdo-list] Newton Milestone 2 test day: July 21, 22 Message-ID: Please join us for RDO Newton Milestone 2 test day, on July 21st and 22nd. Details, and test instructions, are at https://www.rdoproject.org/testday/newton/milestone2/ Leading up to the test day, we encourage you to help us improve the test case instructions: https://www.rdoproject.org/testday/newton/testedsetups2 If you are aware of any workarounds to known problems, please document them - https://www.rdoproject.org/testday/newton/workarounds2 - so that others don't have to struggle with already-solved problems. We hope to see you on #rdo (on Freenode IRC) next Thursday. --Rich -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From jrist at redhat.com Fri Jul 15 14:56:08 2016 From: jrist at redhat.com (Jason Rist) Date: Fri, 15 Jul 2016 15:56:08 +0100 Subject: [rdo-list] TripleO UI Packaging Strategy Message-ID: Hey everyone - we are trying to think about our packaging strategy for the TripleO UI and would like some feedback. Feel free to yell regarding the details as this is high priority. The plan: 1.) Create a spec file for the RPM that includes the pre-compiled (minified, production ready) javascript application. 2.) Push new repository to review RDO repositories RTFM: https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk 3.) Have people review said package here: https://review.rdoproject.org/r/#/q/status:open 4.) Add info to https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml 5.) Package appears in trunk delorean We talked a little and we are thinking that the UI will be able to be installed without the dependency of mistral and zaqar since those are connected services rather than binary dependencies. We are going to try that as a first pass and then iterate. We are targeting next week for this work and already have the beginning of #1, so I am confident we'll be able to begin iterating on the packaging setup. Please let me know if you have any questions. Thanks! Jason -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen From dms at redhat.com Fri Jul 15 15:27:53 2016 From: dms at redhat.com (David Moreau Simard) Date: Fri, 15 Jul 2016 11:27:53 -0400 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: I think TripleO-UI can draw from a lot of the work that has been done in Horizon packaging [1] (adding mrunge). You can see that most of the libraries are made available through xstatic python packages, for example jquery. If there are missing libraries they need to be highlighted so we can package them. [1]: https://github.com/rdo-packages/horizon-distgit David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: > Hey everyone - we are trying to think about our packaging strategy for > the TripleO UI and would like some feedback. Feel free to yell > regarding the details as this is high priority. > > The plan: > > 1.) Create a spec file for the RPM that includes the pre-compiled > (minified, production ready) javascript application. > 2.) Push new repository to review RDO repositories > RTFM: > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk > 3.) Have people review said package here: > https://review.rdoproject.org/r/#/q/status:open > 4.) Add info to > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml > 5.) Package appears in trunk delorean > > > We talked a little and we are thinking that the UI will be able to be > installed without the dependency of mistral and zaqar since those are > connected services rather than binary dependencies. > > We are going to try that as a first pass and then iterate. > > We are targeting next week for this work and already have the beginning > of #1, so I am confident we'll be able to begin iterating on the > packaging setup. > > Please let me know if you have any questions. > > Thanks! > Jason > -- > Jason E. Rist > Senior Software Engineer > OpenStack User Interfaces > Red Hat, Inc. > openuc: +1.972.707.6408 > mobile: +1.720.256.3933 > Freenode: jrist > github/twitter: knowncitizen > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From dougal at redhat.com Fri Jul 15 15:31:42 2016 From: dougal at redhat.com (Dougal Matthews) Date: Fri, 15 Jul 2016 16:31:42 +0100 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: On 15 July 2016 at 16:27, David Moreau Simard wrote: > I think TripleO-UI can draw from a lot of the work that has been done > in Horizon packaging [1] (adding mrunge). > > You can see that most of the libraries are made available through > xstatic python packages, for example jquery. > If there are missing libraries they need to be highlighted so we can > package them. > Due to the UI being built in react and using the npm ecosystem I think it has over 800 dependent packages. I'm not sure that doing them all individually is realistic. [1]: https://github.com/rdo-packages/horizon-distgit > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: > > Hey everyone - we are trying to think about our packaging strategy for > > the TripleO UI and would like some feedback. Feel free to yell > > regarding the details as this is high priority. > > > > The plan: > > > > 1.) Create a spec file for the RPM that includes the pre-compiled > > (minified, production ready) javascript application. > > 2.) Push new repository to review RDO repositories > > RTFM: > > > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk > > 3.) Have people review said package here: > > https://review.rdoproject.org/r/#/q/status:open > > 4.) Add info to > > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml > > 5.) Package appears in trunk delorean > > > > > > We talked a little and we are thinking that the UI will be able to be > > installed without the dependency of mistral and zaqar since those are > > connected services rather than binary dependencies. > > > > We are going to try that as a first pass and then iterate. > > > > We are targeting next week for this work and already have the beginning > > of #1, so I am confident we'll be able to begin iterating on the > > packaging setup. > > > > Please let me know if you have any questions. > > > > Thanks! > > Jason > > -- > > Jason E. Rist > > Senior Software Engineer > > OpenStack User Interfaces > > Red Hat, Inc. > > openuc: +1.972.707.6408 > > mobile: +1.720.256.3933 > > Freenode: jrist > > github/twitter: knowncitizen > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrist at redhat.com Fri Jul 15 16:05:28 2016 From: jrist at redhat.com (Jason Rist) Date: Fri, 15 Jul 2016 17:05:28 +0100 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: <5f861975-b824-291e-7e4b-bacfc128dba6@redhat.com> On 07/15/2016 04:31 PM, Dougal Matthews wrote: > On 15 July 2016 at 16:27, David Moreau Simard wrote: > > > I think TripleO-UI can draw from a lot of the work that has been done > > in Horizon packaging [1] (adding mrunge). > > > > You can see that most of the libraries are made available through > > xstatic python packages, for example jquery. > > If there are missing libraries they need to be highlighted so we can > > package them. > > > > Due to the UI being built in react and using the npm ecosystem I think it > has over 800 dependent packages. I'm not sure that doing them all > individually is realistic. > > > [1]: https://github.com/rdo-packages/horizon-distgit > > > > David Moreau Simard > > Senior Software Engineer | Openstack RDO > > > > dmsimard = [irc, github, twitter] > > > > > > On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: > >> Hey everyone - we are trying to think about our packaging strategy for > >> the TripleO UI and would like some feedback. Feel free to yell > >> regarding the details as this is high priority. > >> > >> The plan: > >> > >> 1.) Create a spec file for the RPM that includes the pre-compiled > >> (minified, production ready) javascript application. > >> 2.) Push new repository to review RDO repositories > >> RTFM: > >> > > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk > >> 3.) Have people review said package here: > >> https://review.rdoproject.org/r/#/q/status:open > >> 4.) Add info to > >> https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml > >> 5.) Package appears in trunk delorean > >> > >> > >> We talked a little and we are thinking that the UI will be able to be > >> installed without the dependency of mistral and zaqar since those are > >> connected services rather than binary dependencies. > >> > >> We are going to try that as a first pass and then iterate. > >> > >> We are targeting next week for this work and already have the beginning > >> of #1, so I am confident we'll be able to begin iterating on the > >> packaging setup. > >> > >> Please let me know if you have any questions. > >> > >> Thanks! > >> Jason > >> -- > >> Jason E. Rist > >> Senior Software Engineer > >> OpenStack User Interfaces > >> Red Hat, Inc. > >> openuc: +1.972.707.6408 > >> mobile: +1.720.256.3933 > >> Freenode: jrist > >> github/twitter: knowncitizen > >> > >> _______________________________________________ > >> rdo-list mailing list > >> rdo-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/rdo-list > >> > >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > Yeah, let me be a little more clear. A very large amount of the packages are primarily used for development. We are planning on releasing something that is compiled down in a sort of production form, with a longer term plan to release more of the pre-compile dependencies, similar to Horizon. Thanks, Jason -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen From hguemar at fedoraproject.org Fri Jul 15 16:29:46 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Fri, 15 Jul 2016 18:29:46 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: 2016-07-15 17:31 GMT+02:00 Dougal Matthews : > On 15 July 2016 at 16:27, David Moreau Simard wrote: >> >> I think TripleO-UI can draw from a lot of the work that has been done >> in Horizon packaging [1] (adding mrunge). >> >> You can see that most of the libraries are made available through >> xstatic python packages, for example jquery. >> If there are missing libraries they need to be highlighted so we can >> package them. > > > Due to the UI being built in react and using the npm ecosystem I think it > has over 800 dependent packages. I'm not sure that doing them all > individually is realistic. > Realistic or not, we are *compelled* to review licensing for each dependencies we ship. I'm not sure we'll be able to ship this in time for GA, considering that we passed M2. We can relax unbunding rules to a certain point but we also need to review the minifying toolchain even if it's not yet packaged. We're not allowed to ship minified javascript through minifiers that are not acceptable (e.g Google Closure compiler). There's a limit of how we can reduce the reviewing churn. Regards, H. > >> [1]: https://github.com/rdo-packages/horizon-distgit >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> >> On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: >> > Hey everyone - we are trying to think about our packaging strategy for >> > the TripleO UI and would like some feedback. Feel free to yell >> > regarding the details as this is high priority. >> > >> > The plan: >> > >> > 1.) Create a spec file for the RPM that includes the pre-compiled >> > (minified, production ready) javascript application. >> > 2.) Push new repository to review RDO repositories >> > RTFM: >> > >> > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk >> > 3.) Have people review said package here: >> > https://review.rdoproject.org/r/#/q/status:open >> > 4.) Add info to >> > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml >> > 5.) Package appears in trunk delorean >> > >> > >> > We talked a little and we are thinking that the UI will be able to be >> > installed without the dependency of mistral and zaqar since those are >> > connected services rather than binary dependencies. >> > >> > We are going to try that as a first pass and then iterate. >> > >> > We are targeting next week for this work and already have the beginning >> > of #1, so I am confident we'll be able to begin iterating on the >> > packaging setup. >> > >> > Please let me know if you have any questions. >> > >> > Thanks! >> > Jason >> > -- >> > Jason E. Rist >> > Senior Software Engineer >> > OpenStack User Interfaces >> > Red Hat, Inc. >> > openuc: +1.972.707.6408 >> > mobile: +1.720.256.3933 >> > Freenode: jrist >> > github/twitter: knowncitizen >> > >> > _______________________________________________ >> > rdo-list mailing list >> > rdo-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/rdo-list >> > >> > To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From bderzhavets at hotmail.com Fri Jul 15 20:28:48 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 15 Jul 2016 20:28:48 +0000 Subject: [rdo-list] How to recover just one of three HA Controllers been generated via TripleO QuickStart ? In-Reply-To: <5f861975-b824-291e-7e4b-bacfc128dba6@redhat.com> References: , <5f861975-b824-291e-7e4b-bacfc128dba6@redhat.com> Message-ID: Details here :- https://bugzilla.redhat.com/show_bug.cgi?id=1353915 Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgaisford at punagroup.com Sat Jul 16 00:45:07 2016 From: bgaisford at punagroup.com (Brandon Gaisford) Date: Fri, 15 Jul 2016 14:45:07 -1000 Subject: [rdo-list] RDO Message-ID: <1EFE51E5-5AF0-41C8-8993-97810F4A2330@punagroup.com> Hello, Just attempted my first RDO TripleO installation - thank you in advance for all your hard work to make this a simple process!! Environment: Server: blade0 is the target host, CentOS7 32GB RAM, 1TB HDD, SSH trust with server: maui Server: maui is the ansible server executing the TripleO quickstart.sh script Results: PLAY RECAP ********************************************************************* blade0.punagroup.com : ok=77 changed=49 unreachable=0 failed=0 localhost : ok=15 changed=7 unreachable=0 failed=0 undercloud : ok=5 changed=3 unreachable=0 failed=1 Please see attached log. It looks as if the setup went pretty well, but given the playlist recap and since there was?t any info at the end of the run explaining how to connect to the new system, I have my suspicions. Brandon -------------- next part -------------- A non-text attachment was scrubbed... Name: RDO-TripleO-install.log Type: application/octet-stream Size: 236109 bytes Desc: not available URL: -------------- next part -------------- From bgaisford at punagroup.com Sat Jul 16 02:44:14 2016 From: bgaisford at punagroup.com (Brandon Gaisford) Date: Fri, 15 Jul 2016 16:44:14 -1000 Subject: [rdo-list] RDO In-Reply-To: <1EFE51E5-5AF0-41C8-8993-97810F4A2330@punagroup.com> References: <1EFE51E5-5AF0-41C8-8993-97810F4A2330@punagroup.com> Message-ID: Digging deeper?searched maui: /root/quickstart.sh Toward the end: ################################## Virtual Environment Setup Complete ################################## Access the undercloud by: ssh -F $OPT_WORKDIR/ssh.config.ansible undercloud There are scripts in the home directory to continue the deploy: overcloud-deploy.sh will deploy the overcloud overcloud-deploy-post.sh will do any post-deploy configuration overcloud-validate.sh will run post-deploy validation Alternatively, you can ignore these scripts and follow the upstream docs, starting from the overcloud deploy section: http://ow.ly/1Vc1301iBlb ################################## Virtual Environment Setup Complete ################################## Note: In this case, $OPT_WORKDIR = /root/.quickstart on the maui box [root at maui ~]# cd .quickstart/ [root at maui .quickstart]# ssh -F ssh.config.ansible undercloud [stack at undercloud ~]$ ll total 1534224 -rw-rw-r--. 1 1001 1001 10804 Jul 15 23:44 instackenv.json -rw-r--r--. 1 root root 343696519 Jul 14 17:25 ironic-python-agent.initramfs -rwxr-xr-x. 1 root root 5158704 Jul 14 17:25 ironic-python-agent.kernel -rw-r--r--. 1 root root 36456036 Jul 14 17:25 overcloud-full.initrd -rw-r--r--. 1 root root 1179742720 Jul 14 17:25 overcloud-full.qcow2 -rwxr-xr-x. 1 root root 5158704 Jul 14 17:26 overcloud-full.vmlinuz -rw-------. 1 stack stack 6559 Jul 15 23:49 undercloud.conf -rw-rw-r--. 1 stack stack 785510 Jul 16 00:14 undercloud_install.log -rwxr-xr-x. 1 stack stack 83 Jul 15 23:49 undercloud-install.sh -rw-rw-r--. 1 stack stack 1579 Jul 15 23:49 undercloud-passwords.conf -rwxr-xr-x. 1 stack stack 2865 Jul 15 23:49 undercloud-post-install.sh Seems to be a disconnect here between the ?setup complete? instructions and reality. I?m wondering if the installation failure caused the discrepancy. Thanks in advance for your eyes and any advice. Brandon > On Jul 15, 2016, at 2:45 PM, Brandon Gaisford wrote: > > Hello, > > Just attempted my first RDO TripleO installation - thank you in advance for all your hard work to make this a simple process!! > > Environment: > > Server: blade0 is the target host, CentOS7 32GB RAM, 1TB HDD, SSH trust with server: maui > Server: maui is the ansible server executing the TripleO quickstart.sh script > > Results: > > PLAY RECAP ********************************************************************* > blade0.punagroup.com : ok=77 changed=49 unreachable=0 failed=0 > localhost : ok=15 changed=7 unreachable=0 failed=0 > undercloud : ok=5 changed=3 unreachable=0 failed=1 > > Please see attached log. It looks as if the setup went pretty well, but given the playlist recap and since there was?t any info at the end of the run explaining how to connect to the new system, I have my suspicions. > > Brandon > > > > > > > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From bderzhavets at hotmail.com Sat Jul 16 15:19:41 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 16 Jul 2016 15:19:41 +0000 Subject: [rdo-list] How to recover just one of three HA Controllers been generated via TripleO QuickStart ? In-Reply-To: References: , <5f861975-b824-291e-7e4b-bacfc128dba6@redhat.com>, Message-ID: I should apply a kind of http://docs.openstack.org/developer/tripleo-docs/post_deployment/replace_controller.html ________________________________ From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets Sent: Friday, July 15, 2016 4:28 PM To: rdo-list Subject: [rdo-list] How to recover just one of three HA Controllers been generated via TripleO QuickStart ? Details here :- https://bugzilla.redhat.com/show_bug.cgi?id=1353915 Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgaisford at punagroup.com Sun Jul 17 17:35:47 2016 From: bgaisford at punagroup.com (Brandon Gaisford) Date: Sun, 17 Jul 2016 07:35:47 -1000 Subject: [rdo-list] RDO In-Reply-To: References: <1EFE51E5-5AF0-41C8-8993-97810F4A2330@punagroup.com> Message-ID: <0A49DD10-995D-4F54-B97B-39F9B38932EF@punagroup.com> Hello, I was able the resolve this issue by tracing back through the installation logs and ansible scripts. I created a PR that was subsequently closed by Gerrit as I am unfamiliar with the code submission process with OpenStack. I?ll work through that and get this PR submitted properly. See: https://github.com/openstack/tripleo-quickstart/pull/3 Cheers, Brandon > On Jul 15, 2016, at 4:44 PM, Brandon Gaisford wrote: > > > > Digging deeper?searched maui: /root/quickstart.sh > > Toward the end: > > ################################## > Virtual Environment Setup Complete > ################################## > > Access the undercloud by: > > ssh -F $OPT_WORKDIR/ssh.config.ansible undercloud > > There are scripts in the home directory to continue the deploy: > > overcloud-deploy.sh will deploy the overcloud > overcloud-deploy-post.sh will do any post-deploy configuration > overcloud-validate.sh will run post-deploy validation > > Alternatively, you can ignore these scripts and follow the upstream docs, > starting from the overcloud deploy section: > > http://ow.ly/1Vc1301iBlb > > ################################## > Virtual Environment Setup Complete > ################################## > > Note: In this case, $OPT_WORKDIR = /root/.quickstart on the maui box > > [root at maui ~]# cd .quickstart/ > [root at maui .quickstart]# ssh -F ssh.config.ansible undercloud > > [stack at undercloud ~]$ ll > total 1534224 > -rw-rw-r--. 1 1001 1001 10804 Jul 15 23:44 instackenv.json > -rw-r--r--. 1 root root 343696519 Jul 14 17:25 ironic-python-agent.initramfs > -rwxr-xr-x. 1 root root 5158704 Jul 14 17:25 ironic-python-agent.kernel > -rw-r--r--. 1 root root 36456036 Jul 14 17:25 overcloud-full.initrd > -rw-r--r--. 1 root root 1179742720 Jul 14 17:25 overcloud-full.qcow2 > -rwxr-xr-x. 1 root root 5158704 Jul 14 17:26 overcloud-full.vmlinuz > -rw-------. 1 stack stack 6559 Jul 15 23:49 undercloud.conf > -rw-rw-r--. 1 stack stack 785510 Jul 16 00:14 undercloud_install.log > -rwxr-xr-x. 1 stack stack 83 Jul 15 23:49 undercloud-install.sh > -rw-rw-r--. 1 stack stack 1579 Jul 15 23:49 undercloud-passwords.conf > -rwxr-xr-x. 1 stack stack 2865 Jul 15 23:49 undercloud-post-install.sh > > > Seems to be a disconnect here between the ?setup complete? instructions and reality. I?m wondering if the installation failure caused the discrepancy. > > Thanks in advance for your eyes and any advice. > > Brandon > > >> On Jul 15, 2016, at 2:45 PM, Brandon Gaisford wrote: >> >> Hello, >> >> Just attempted my first RDO TripleO installation - thank you in advance for all your hard work to make this a simple process!! >> >> Environment: >> >> Server: blade0 is the target host, CentOS7 32GB RAM, 1TB HDD, SSH trust with server: maui >> Server: maui is the ansible server executing the TripleO quickstart.sh script >> >> Results: >> >> PLAY RECAP ********************************************************************* >> blade0.punagroup.com : ok=77 changed=49 unreachable=0 failed=0 >> localhost : ok=15 changed=7 unreachable=0 failed=0 >> undercloud : ok=5 changed=3 unreachable=0 failed=1 >> >> Please see attached log. It looks as if the setup went pretty well, but given the playlist recap and since there was?t any info at the end of the run explaining how to connect to the new system, I have my suspicions. >> >> Brandon >> >> >> >> >> >> >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From alon.dotan at hpe.com Sun Jul 17 17:47:06 2016 From: alon.dotan at hpe.com (Dotan, Alon) Date: Sun, 17 Jul 2016 17:47:06 +0000 Subject: [rdo-list] tripelo installation Message-ID: Few questions about tripleo: I got a requirement from my boss to create a production environment of openstack, usually I'm using packstack since he is very easy and robust installer, The issue is that the repos of the release kept for 3 versions only which breaks packstack My questions is: * Can I freeze versions with tripleo or there is any downloads from the net in the deployments? * How difficult is to upgrade versions * Can someone redirect me to a guide that explain how to build the topology and how to add compute / publish configuration change to the environment? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Mon Jul 18 15:00:03 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 18 Jul 2016 15:00:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20160718150003.05B1260A4009@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-07-20 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From rbowen at redhat.com Mon Jul 18 17:32:35 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 18 Jul 2016 13:32:35 -0400 Subject: [rdo-list] Unanswered RDO questions on ask.openstack.org Message-ID: <18e5be8c-a01e-a0f3-2d29-3d5ba51b2303@redhat.com> Thanks to all of you for your help on this. This is the lowest we've had the list in more than a year, I think. 39 unanswered questions: Adding a compute node https://ask.openstack.org/en/question/94747/adding-a-compute-node/ Tags: nova-compute, liberty How to set quota for domain and have it shared with all the projects/tenants in domain https://ask.openstack.org/en/question/94105/how-to-set-quota-for-domain-and-have-it-shared-with-all-the-projectstenants-in-domain/ Tags: domainquotadriver rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Are following links considered by RH as official guide lines in meantime for TripleO instack-virt-setup RDO Liberty Stable? https://ask.openstack.org/en/question/93751/are-following-links-considered-by-rh-as-official-guide-lines-in-meantime-for-tripleo-instack-virt-setup-rdo-liberty-stable/ Tags: rdo, tripleo, instack Add new compute node for TripleO deployment in virtual environment https://ask.openstack.org/en/question/93703/add-new-compute-node-for-tripleo-deployment-in-virtual-environment/ Tags: compute, tripleo, liberty, virtual, baremetal Unable to start Ceilometer services https://ask.openstack.org/en/question/93600/unable-to-start-ceilometer-services/ Tags: ceilometer, ceilometer-api Adding hard drive space to RDO installation https://ask.openstack.org/en/question/93412/adding-hard-drive-space-to-rdo-installation/ Tags: cinder, openstack, space, add AWS Ec2 inst Eth port loses IP when attached to linux bridge in Openstack https://ask.openstack.org/en/question/92271/aws-ec2-inst-eth-port-loses-ip-when-attached-to-linux-bridge-in-openstack/ Tags: openstack, networking, aws ceilometer: I've installed openstack mitaka. but swift stops working when i configured the pipeline and ceilometer filter https://ask.openstack.org/en/question/92035/ceilometer-ive-installed-openstack-mitaka-but-swift-stops-working-when-i-configured-the-pipeline-and-ceilometer-filter/ Tags: ceilometer, openstack-swift, mitaka Fail on installing the controller on Cent OS 7 https://ask.openstack.org/en/question/92025/fail-on-installing-the-controller-on-cent-os-7/ Tags: installation, centos7, controller the error of service entity and API endpoints https://ask.openstack.org/en/question/91702/the-error-of-service-entity-and-api-endpoints/ Tags: service, entity, and, api, endpoints Running delorean fails: Git won't fetch sources https://ask.openstack.org/en/question/91600/running-delorean-fails-git-wont-fetch-sources/ Tags: delorean, rdo Keystone authentication: Failed to contact the endpoint. https://ask.openstack.org/en/question/91517/keystone-authentication-failed-to-contact-the-endpoint/ Tags: keystone, authenticate, endpoint, murano Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: stack, resource, topology, dashboard Build of instance aborted: Block Device Mapping is Invalid. https://ask.openstack.org/en/question/91205/build-of-instance-aborted-block-device-mapping-is-invalid/ Tags: cinder, lvm, centos7 No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack how to use chef auto manage openstack in RDO? https://ask.openstack.org/en/question/90992/how-to-use-chef-auto-manage-openstack-in-rdo/ Tags: chef, rdo Separate Cinder storage traffic from management https://ask.openstack.org/en/question/90405/separate-cinder-storage-traffic-from-management/ Tags: cinder, separate, nic, iscsi Openstack installation fails using packstack, failure is in installation of openstack-nova-compute. Error: Dependency Package[nova-compute] has failures https://ask.openstack.org/en/question/88993/openstack-installation-fails-using-packstack-failure-is-in-installation-of-openstack-nova-compute-error-dependency-packagenova-compute-has-failures/ Tags: novacompute, rdo, packstack, dependency, failure CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Sahara SSHException: Error reading SSH protocol banner https://ask.openstack.org/en/question/84710/sahara-sshexception-error-reading-ssh-protocol-banner/ Tags: sahara, icehouse, ssh, vanila Error Sahara create cluster: 'Error attach volume to instance https://ask.openstack.org/en/question/84651/error-sahara-create-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, vanila, icehouse Creating Sahara cluster: Error attach volume to instance https://ask.openstack.org/en/question/84650/creating-sahara-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, hadoop, icehouse, vanilla Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing redhat RDO enable access to swift via S3 https://ask.openstack.org/en/question/83607/redhat-rdo-enable-access-to-swift-via-s3/ Tags: swift, s3 openstack baremetal introspection internal server error https://ask.openstack.org/en/question/82790/openstack-baremetal-introspection-internal-server-error/ Tags: rdo, ironic-inspector, tripleo -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From hpokorny at redhat.com Mon Jul 18 17:36:17 2016 From: hpokorny at redhat.com (Honza Pokorny) Date: Mon, 18 Jul 2016 14:36:17 -0300 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: <20160718173617.n645hmbsuuhwzdfr@localhost.localdomain> On 2016-07-15 18:29, Ha?kel wrote: > 2016-07-15 17:31 GMT+02:00 Dougal Matthews : > > On 15 July 2016 at 16:27, David Moreau Simard wrote: > >> > >> I think TripleO-UI can draw from a lot of the work that has been done > >> in Horizon packaging [1] (adding mrunge). > >> > >> You can see that most of the libraries are made available through > >> xstatic python packages, for example jquery. > >> If there are missing libraries they need to be highlighted so we can > >> package them. > > > > > > Due to the UI being built in react and using the npm ecosystem I think it > > has over 800 dependent packages. I'm not sure that doing them all > > individually is realistic. > > > > Realistic or not, we are *compelled* to review licensing for each > dependencies we ship. I have just reviewed all of our direct and indirect dependencies and their licenses. There are only two indirect dependencies that could cause problems. Both of these are released under the GPL. One of them is a dependency of gulp, and we're in the process of removing gulp. The other is actually dually licensed under the GPL and MIT. Ha?kel, is there a formal process for ensuring that all licensing matters are in order? Surely, my say-so isn't going to be enough. > I'm not sure we'll be able to ship this in time for GA, considering > that we passed M2. > > We can relax unbunding rules to a certain point but we also need to > review the minifying toolchain even if it's not yet packaged. > We're not allowed to ship minified javascript through minifiers that > are not acceptable (e.g Google Closure compiler). > There's a limit of how we can reduce the reviewing churn. > > Regards, > H. > > > > >> [1]: https://github.com/rdo-packages/horizon-distgit > >> > >> David Moreau Simard > >> Senior Software Engineer | Openstack RDO > >> > >> dmsimard = [irc, github, twitter] > >> > >> > >> On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: > >> > Hey everyone - we are trying to think about our packaging strategy for > >> > the TripleO UI and would like some feedback. Feel free to yell > >> > regarding the details as this is high priority. > >> > > >> > The plan: > >> > > >> > 1.) Create a spec file for the RPM that includes the pre-compiled > >> > (minified, production ready) javascript application. > >> > 2.) Push new repository to review RDO repositories > >> > RTFM: > >> > > >> > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk > >> > 3.) Have people review said package here: > >> > https://review.rdoproject.org/r/#/q/status:open > >> > 4.) Add info to > >> > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml > >> > 5.) Package appears in trunk delorean > >> > > >> > > >> > We talked a little and we are thinking that the UI will be able to be > >> > installed without the dependency of mistral and zaqar since those are > >> > connected services rather than binary dependencies. > >> > > >> > We are going to try that as a first pass and then iterate. > >> > > >> > We are targeting next week for this work and already have the beginning > >> > of #1, so I am confident we'll be able to begin iterating on the > >> > packaging setup. > >> > > >> > Please let me know if you have any questions. > >> > > >> > Thanks! > >> > Jason > >> > -- > >> > Jason E. Rist > >> > Senior Software Engineer > >> > OpenStack User Interfaces > >> > Red Hat, Inc. > >> > openuc: +1.972.707.6408 > >> > mobile: +1.720.256.3933 > >> > Freenode: jrist > >> > github/twitter: knowncitizen > >> > > >> > _______________________________________________ > >> > rdo-list mailing list > >> > rdo-list at redhat.com > >> > https://www.redhat.com/mailman/listinfo/rdo-list > >> > > >> > To unsubscribe: rdo-list-unsubscribe at redhat.com > >> > >> _______________________________________________ > >> rdo-list mailing list > >> rdo-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/rdo-list > >> > >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Mon Jul 18 18:32:29 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 18 Jul 2016 20:32:29 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160718173031.jyrxsn66lb7adkmq@localhost.localdomain> References: <20160718173031.jyrxsn66lb7adkmq@localhost.localdomain> Message-ID: 2016-07-18 19:30 GMT+02:00 Honza Pokorny : > On 2016-07-15 18:29, Ha?kel wrote: >> 2016-07-15 17:31 GMT+02:00 Dougal Matthews : >> > On 15 July 2016 at 16:27, David Moreau Simard wrote: >> >> >> >> I think TripleO-UI can draw from a lot of the work that has been done >> >> in Horizon packaging [1] (adding mrunge). >> >> >> >> You can see that most of the libraries are made available through >> >> xstatic python packages, for example jquery. >> >> If there are missing libraries they need to be highlighted so we can >> >> package them. >> > >> > >> > Due to the UI being built in react and using the npm ecosystem I think it >> > has over 800 dependent packages. I'm not sure that doing them all >> > individually is realistic. >> > >> >> Realistic or not, we are *compelled* to review licensing for each >> dependencies we ship. > > I have just reviewed all of our direct and indirect dependencies and > their licenses. There are only two indirect dependencies that could > cause problems. Both of these are released under the GPL. > > One of them is a dependency of gulp, and we're in the process of > removing gulp. > > The other is actually dually licensed under the GPL and MIT. > > Ha?kel, is there a formal process for ensuring that all licensing > matters are in order? Surely, my say-so isn't going to be enough. > First step is to open a package review in RHBZ under the RDO product. Then, we'll use licensecheck to check license and some manual check. We can relax unbundling rules to a certain extent, so it should not be a problem. Providing a dependency list with licenses as Jason did on irc does help. http://paste.fedoraproject.org/392229/14688610/ GPLv3 (or later) is compatible with ASL 2.0, so it should not be a problem. And the only GPLv2 dependency is also MIT licensed so it's ok. What I'm worried about is the minification/compression toolchain that may rely on non-free tools. Removing gulp may help reducing hazard in that area. Regards, H. >> I'm not sure we'll be able to ship this in time for GA, considering >> that we passed M2. >> >> We can relax unbunding rules to a certain point but we also need to >> review the minifying toolchain even if it's not yet packaged. >> We're not allowed to ship minified javascript through minifiers that >> are not acceptable (e.g Google Closure compiler). >> There's a limit of how we can reduce the reviewing churn. >> >> Regards, >> H. >> >> > >> >> [1]: https://github.com/rdo-packages/horizon-distgit >> >> >> >> David Moreau Simard >> >> Senior Software Engineer | Openstack RDO >> >> >> >> dmsimard = [irc, github, twitter] >> >> >> >> >> >> On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: >> >> > Hey everyone - we are trying to think about our packaging strategy for >> >> > the TripleO UI and would like some feedback. Feel free to yell >> >> > regarding the details as this is high priority. >> >> > >> >> > The plan: >> >> > >> >> > 1.) Create a spec file for the RPM that includes the pre-compiled >> >> > (minified, production ready) javascript application. >> >> > 2.) Push new repository to review RDO repositories >> >> > RTFM: >> >> > >> >> > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk >> >> > 3.) Have people review said package here: >> >> > https://review.rdoproject.org/r/#/q/status:open >> >> > 4.) Add info to >> >> > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml >> >> > 5.) Package appears in trunk delorean >> >> > >> >> > >> >> > We talked a little and we are thinking that the UI will be able to be >> >> > installed without the dependency of mistral and zaqar since those are >> >> > connected services rather than binary dependencies. >> >> > >> >> > We are going to try that as a first pass and then iterate. >> >> > >> >> > We are targeting next week for this work and already have the beginning >> >> > of #1, so I am confident we'll be able to begin iterating on the >> >> > packaging setup. >> >> > >> >> > Please let me know if you have any questions. >> >> > >> >> > Thanks! >> >> > Jason >> >> > -- >> >> > Jason E. Rist >> >> > Senior Software Engineer >> >> > OpenStack User Interfaces >> >> > Red Hat, Inc. >> >> > openuc: +1.972.707.6408 >> >> > mobile: +1.720.256.3933 >> >> > Freenode: jrist >> >> > github/twitter: knowncitizen >> >> > >> >> > _______________________________________________ >> >> > rdo-list mailing list >> >> > rdo-list at redhat.com >> >> > https://www.redhat.com/mailman/listinfo/rdo-list >> >> > >> >> > To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> >> >> _______________________________________________ >> >> rdo-list mailing list >> >> rdo-list at redhat.com >> >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> > >> > >> > >> > _______________________________________________ >> > rdo-list mailing list >> > rdo-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/rdo-list >> > >> > To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From rbowen at redhat.com Mon Jul 18 18:58:00 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 18 Jul 2016 14:58:00 -0400 Subject: [rdo-list] This week's RDO/OpenStack meetups Message-ID: The following are the meetups I'm aware of in the coming week where OpenStack and/or RDO enthusiasts are likely to be present. If you know of others, please let me know, and/or add them to http://rdoproject.org/events If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Monday July 18 in Roma, RM, IT: OpenStack 6th Birthday Party Italy - http://www.meetup.com/OpenStack-User-Group-Italia/events/232050225/ * Monday July 18 in Washington, DC, US: OpenStack's 6th Birthday Celebration - http://www.meetup.com/OpenStackDC/events/231785648/ * Monday July 18 in Guadalajara, MX: Desplegando una Nube de OpenStack con Ansible - http://www.meetup.com/OpenStack-GDL/events/232287872/ * Monday July 18 in Orlando, FL, US: How to customize the OpenStack Horizon Dashboard - http://www.meetup.com/Orlando-Central-Florida-OpenStack-Meetup/events/232612876/ * Tuesday July 19 in Tehran, IR: OpenShift in a Nutshell - Step 4 - http://www.meetup.com/Iran-OpenStack/events/232702743/ * Tuesday July 19 in Richardson, TX, US: UX TV Show Taping: Data Visualization Episode - http://www.meetup.com/OpenStack-DFW/events/232521746/ * Tuesday July 19 in M?nchen, DE: OpenStack's 6th birthday Meetup - Munich - http://www.meetup.com/OpenStack-Munich/events/232274294/ * Tuesday July 19 in M?nchen, DE: [OpenStack Meetup] Join us for OpenStack's 6th birthday! - http://www.meetup.com/stylight/events/232274378/ * Tuesday July 19 in Orlando, FL, US: OpenStack Birthday #!/Bash/ - http://www.meetup.com/Orlando-Central-Florida-OpenStack-Meetup/events/232291280/ * Wednesday July 20 in Hamburg, DE: OpenStack Meetup #2 powered by Windcloud - http://www.meetup.com/Openstack-Hamburg/events/231934715/ * Wednesday July 20 in San Francisco, CA, US: Advanced Network Services in OpenStack: Load-Balancing as a Service (LBaaS) - http://www.meetup.com/openstack/events/231959281/ * Wednesday July 20 in Orlando, FL, US: OpenStack Administration with Ansible - http://www.meetup.com/Orlando-Central-Florida-OpenStack-Meetup/events/232612935/ * Thursday July 21 in Durham, NC, US: OpenStack 6th Birthday Party - http://www.meetup.com/Triangle-OpenStack-Meetup/events/232278718/ * Thursday July 21 in Fort Lauderdale, FL, US: SFOUG Presentations - http://www.meetup.com/South-Florida-OpenStack-Users-Group/events/232450735/ * Thursday July 21 in Santa Clara, CA, US: NFV on Intel ONP, Openstack, KVM and Breaking the Terabit Barrier With Sandvine - http://www.meetup.com/Out-Of-The-Box-Network-Developers/events/232398910/ * Thursday July 21 in Santa Clara, CA, US: NFV on Intel ONP, Openstack, KVM and Breaking the Terabit Barrier With Sandvine - http://www.meetup.com/SDN-Switching-Group/events/232568625/ * Thursday July 21 in Portland, OR, US: OpenStack PDX Meetup - http://www.meetup.com/openstack-pdx/events/231959323/ * Thursday July 21 in Austin, TX, US: Federating Keystone Trust across OpenStack clouds - http://www.meetup.com/OpenStack-Austin/events/232587107/ * Thursday July 21 in Chesterfield, MO, US: OpenStack 6th birthday Party - http://www.meetup.com/OpenStack-STL/events/232316868/ * Thursday July 21 in Atlanta, GA, US: OpenStack 6th Birthday Party - http://www.meetup.com/openstack-atlanta/events/231925100/ * Friday July 22 in Bangalore, IN: MegaMeetup : Working with OpenSource - OpenDaylight & OpenStack - http://www.meetup.com/Bangalore-SDN-and-NFV-meetup/events/232660911/ * Friday July 22 in Manila, PH: OpenStack PHUG 6th Anniversary - http://www.meetup.com/OpenStack-Philippines/events/232055773/ * Monday July 25 in Saint Paul, MN, US: OpenStack 6th Birthday Celebration! - http://www.meetup.com/Minnesota-OpenStack-Meetup/events/232535058/ -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From tshefi at redhat.com Mon Jul 18 19:49:25 2016 From: tshefi at redhat.com (Tzach Shefi) Date: Mon, 18 Jul 2016 22:49:25 +0300 Subject: [rdo-list] tripelo installation In-Reply-To: References: Message-ID: Hi Dotan, What do you mean by freeze versions with triple0? How difficult it is to upgrade depends on your deployment. Is it going to be HA or not how many nodes which components do you use, which storage backend. It's hard to say without looking at the whole picture. >From my experience upgrading has improved greatly since I started Packstack based Havana to Icehouse upgrades. Check these guides: https://www.rdoproject.org/tripleo/ https://keithtenzer.com/2016/05/30/red-hat-openstack-platform-8-lab-configuration-using-openstack-director/ https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/director-installation-and-usage/director-installation-and-usage. Tzach On Sun, Jul 17, 2016 at 8:47 PM, Dotan, Alon wrote: > Few questions about tripleo: > > I got a requirement from my boss to create a production environment of > openstack, usually I?m using packstack since he is very easy and robust > installer, > > The issue is that the repos of the release kept for 3 versions only which > breaks packstack > > > > My questions is: > > ? Can I freeze versions with tripleo or there is any downloads > from the net in the deployments? > > ? How difficult is to upgrade versions > > ? Can someone redirect me to a guide that explain how to build > the topology and how to add compute / publish configuration change to the > environment? > > > > Thanks, > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -- *Tzach Shefi* Quality Engineer, Redhat OSP +972-54-4701080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alon.dotan at hpe.com Tue Jul 19 07:38:46 2016 From: alon.dotan at hpe.com (Dotan, Alon) Date: Tue, 19 Jul 2016 07:38:46 +0000 Subject: [rdo-list] tripelo installation In-Reply-To: References: Message-ID: I?m using local or hp lefthand storage, about 400 instances currently not using HA but sure thinking about it.. I tried to create environment from scratch in tripleo without success.. The important things that Im looking for are: ? Long term support in terms of availability of packages ? offline installation to isolated labs Thanks, From: Tzach Shefi [mailto:tshefi at redhat.com] Sent: Monday, July 18, 2016 22:49 To: Dotan, Alon Cc: rdo-list at redhat.com Subject: Re: [rdo-list] tripelo installation Hi Dotan, What do you mean by freeze versions with triple0? How difficult it is to upgrade depends on your deployment. Is it going to be HA or not how many nodes which components do you use, which storage backend. It's hard to say without looking at the whole picture. From my experience upgrading has improved greatly since I started Packstack based Havana to Icehouse upgrades. Check these guides: https://www.rdoproject.org/tripleo/ https://keithtenzer.com/2016/05/30/red-hat-openstack-platform-8-lab-configuration-using-openstack-director/ https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/director-installation-and-usage/director-installation-and-usage. Tzach On Sun, Jul 17, 2016 at 8:47 PM, Dotan, Alon > wrote: Few questions about tripleo: I got a requirement from my boss to create a production environment of openstack, usually I?m using packstack since he is very easy and robust installer, The issue is that the repos of the release kept for 3 versions only which breaks packstack My questions is: ? Can I freeze versions with tripleo or there is any downloads from the net in the deployments? ? How difficult is to upgrade versions ? Can someone redirect me to a guide that explain how to build the topology and how to add compute / publish configuration change to the environment? Thanks, _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -- Tzach Shefi Quality Engineer, Redhat OSP +972-54-4701080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Tue Jul 19 10:37:16 2016 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 19 Jul 2016 12:37:16 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: On Fri, Jul 15, 2016 at 6:29 PM, Ha?kel wrote: > 2016-07-15 17:31 GMT+02:00 Dougal Matthews : >> On 15 July 2016 at 16:27, David Moreau Simard wrote: >>> >>> I think TripleO-UI can draw from a lot of the work that has been done >>> in Horizon packaging [1] (adding mrunge). >>> >>> You can see that most of the libraries are made available through >>> xstatic python packages, for example jquery. >>> If there are missing libraries they need to be highlighted so we can >>> package them. >> >> >> Due to the UI being built in react and using the npm ecosystem I think it >> has over 800 dependent packages. I'm not sure that doing them all >> individually is realistic. >> > > Realistic or not, we are *compelled* to review licensing for each > dependencies we ship. > I'm not sure we'll be able to ship this in time for GA, considering > that we passed M2. > > We can relax unbunding rules to a certain point but we also need to > review the minifying toolchain even if it's not yet packaged. > We're not allowed to ship minified javascript through minifiers that > are not acceptable (e.g Google Closure compiler). > There's a limit of how we can reduce the reviewing churn. What can be interesting in situations like this is to attempt to explain what's an absolute requirement versus where exceptions might be acceptable. For everyone's reference, RDO's packaging guidelines are here: https://www.rdoproject.org/documentation/rdo-packaging-guidelines/ and there is a brief mention of RDO allowing for exceptions to Fedora's strict unbundling guidelines: https://fedoraproject.org/wiki/Bundled_Libraries Some more reading on Fedora's unbundling policy: https://lwn.net/Articles/660429/ Anyway, taking a step back beyond unbundling for one minute, we should always require that packages are built in an entirely reproducible way from source so that, for example, we always have the ability to rebuilt the package with a minor fix and know that there won't be side-effects other than the change we intended to make. Some of the implications of that: * The toolchain you use to build the package must also follow this basic rule - because fixing an issue might entail fixing the toolchain and rebuilding the package * Everything[1] must be rebuilt from source that is uploaded to the build system - we don't use pre-built artifacts supplied by upstream. * It should be possible to review (e.g. from a security POV) all of the source used to build the final package, and know that everything was built from that source code. If you can't imagine us actually doing this detailed a review, then think of it as us requiring the ability to do a spot-check review. * The buildsystem should not have access to the internet during a build, helping to ensure that the build process isn't using source files from outside of the buildsystem. Many of Fedora's packaging guidelines are very useful to achieve consistency for the user, like those around how packages are named or versioned, or where files should be installed. Other guidelines enforce a policies like Fedora should be built "exclusively from Free and Open Source software", and to ensure the wishes of the original copyright holders are respected. Back to unbundling ... as Haikel says, this is the one area where a relaxing of the Fedora packaging guidelines might make sense in this case, particularly for expediency. Having each dependency individually packaged has a number of benefits: * The correlation between package version and upstream dependency version is clear * It's easier to track when a a new upstream version is available * It's easier to identify whether a given package is affected by a published security issue * Updates for users are smaller - they may only have to download and update a small individual package rather than a large package containing everything * Package maintenance can be shared with others - if multiple applications all use the same dependency, it's better if they don't each package that dependency * On-disk and in-memory space can be reduced if multiple applications share the same dependency However, many of these benefits are probably quite small in the case of TripleO UI compared to the likely overhead of individually packaging everyting, and compared to the benefit of including TripleO UI in the distribution. The exception to this argument that individual packaging is of little benefit is that AIUI we are moving away from openstack-puppet-modules being one giant package with many puppet modules bundled, towards individual packages? The reason for this is that the maintenance overhead with a single giant o-p-m package was actually greater than using automation to maintain the individual packages? Is this likely to also be true in the TripleO UI case? I guess I don't even have a basic understanding of what's going on here - for example, it looks like Horizon bundles the Angular framework in its upstream git and tarball, but TripleO UI doesn't do anything like that with React? The starting point for the thread was that the package users install would just contain the minified version of the javascript ... which I guess would be fine so long as the minification happened in the buildsystem, using only "source" artifacts or artifacts built from source. Hope that helps, Mark. [1] - there are interesting nuances to this - e.g. for C projects, the upstream maintainer will usually include configure.in, Makefile.in, etc. files in their tarballs. These are likely generated with a different version of autoconf and automake that are in the build system. If, in future, we had to modify configure.ac and Makefile.am, and then regenerate configure.in and Makefile.in using autoconf and automake, we run the risk of introducing changes caused by differences in the autotools versions. AIUI, this is still an unresolved debate in Fedora, and left to discretion of packagers: https://fedoraproject.org/wiki/PackagingDrafts/AutoConf >>> [1]: https://github.com/rdo-packages/horizon-distgit >>> >>> David Moreau Simard >>> Senior Software Engineer | Openstack RDO >>> >>> dmsimard = [irc, github, twitter] >>> >>> >>> On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: >>> > Hey everyone - we are trying to think about our packaging strategy for >>> > the TripleO UI and would like some feedback. Feel free to yell >>> > regarding the details as this is high priority. >>> > >>> > The plan: >>> > >>> > 1.) Create a spec file for the RPM that includes the pre-compiled >>> > (minified, production ready) javascript application. >>> > 2.) Push new repository to review RDO repositories >>> > RTFM: >>> > >>> > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk >>> > 3.) Have people review said package here: >>> > https://review.rdoproject.org/r/#/q/status:open >>> > 4.) Add info to >>> > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml >>> > 5.) Package appears in trunk delorean >>> > >>> > >>> > We talked a little and we are thinking that the UI will be able to be >>> > installed without the dependency of mistral and zaqar since those are >>> > connected services rather than binary dependencies. >>> > >>> > We are going to try that as a first pass and then iterate. >>> > >>> > We are targeting next week for this work and already have the beginning >>> > of #1, so I am confident we'll be able to begin iterating on the >>> > packaging setup. >>> > >>> > Please let me know if you have any questions. >>> > >>> > Thanks! >>> > Jason >>> > -- >>> > Jason E. Rist >>> > Senior Software Engineer >>> > OpenStack User Interfaces >>> > Red Hat, Inc. >>> > openuc: +1.972.707.6408 >>> > mobile: +1.720.256.3933 >>> > Freenode: jrist >>> > github/twitter: knowncitizen >>> > >>> > _______________________________________________ >>> > rdo-list mailing list >>> > rdo-list at redhat.com >>> > https://www.redhat.com/mailman/listinfo/rdo-list >>> > >>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>> >>> _______________________________________________ >>> rdo-list mailing list >>> rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From fjansen at redhat.com Tue Jul 19 12:39:12 2016 From: fjansen at redhat.com (Frank Jansen) Date: Tue, 19 Jul 2016 08:39:12 -0400 Subject: [rdo-list] tripelo installation In-Reply-To: References: Message-ID: HI Dotan, From my experience, following the Keith Tenzer blog post listen in Tzach?s second link is a great way to get the whole process right. If you?re running into issues during the installation, I would like to hear about the details, such as which installation path you followed, your network topology, etc. If you can also include what documentation you are following in your installation, we can be on the same page. We?re always interested in making improvements to the entire installation experience, so I?ll be glad to provide whatever help I can. Thanks, Frank Jansen Senior Manager | Global Quality Engineering Red Hat, Inc. > On Jul 19, 2016, at 3:38 AM, Dotan, Alon wrote: > > I?m using local or hp lefthand storage, > about 400 instances > currently not using HA but sure thinking about it.. > I tried to create environment from scratch in tripleo without success.. > > The important things that Im looking for are: > ? Long term support in terms of availability of packages > ? offline installation to isolated labs > ? <> > Thanks, > From: Tzach Shefi [mailto:tshefi at redhat.com] > Sent: Monday, July 18, 2016 22:49 > To: Dotan, Alon > Cc: rdo-list at redhat.com > Subject: Re: [rdo-list] tripelo installation > > Hi Dotan, > > What do you mean by freeze versions with triple0? > > How difficult it is to upgrade depends on your deployment. > Is it going to be HA or not how many nodes which components do you use, which storage backend. > It's hard to say without looking at the whole picture. > From my experience upgrading has improved greatly since I started Packstack based Havana to Icehouse upgrades. > > Check these guides: > https://www.rdoproject.org/tripleo/ > https://keithtenzer.com/2016/05/30/red-hat-openstack-platform-8-lab-configuration-using-openstack-director/ > https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/director-installation-and-usage/director-installation-and-usage . > > Tzach > > > On Sun, Jul 17, 2016 at 8:47 PM, Dotan, Alon > wrote: > Few questions about tripleo: > I got a requirement from my boss to create a production environment of openstack, usually I?m using packstack since he is very easy and robust installer, > The issue is that the repos of the release kept for 3 versions only which breaks packstack > > My questions is: > ? Can I freeze versions with tripleo or there is any downloads from the net in the deployments? > > ? How difficult is to upgrade versions > > ? Can someone redirect me to a guide that explain how to build the topology and how to add compute / publish configuration change to the environment? > > > Thanks, > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > -- > Tzach Shefi > Quality Engineer, Redhat OSP > +972-54-4701080 _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Tue Jul 19 13:02:14 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 19 Jul 2016 15:02:14 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: 2016-07-19 12:37 GMT+02:00 Mark McLoughlin : > On Fri, Jul 15, 2016 at 6:29 PM, Ha?kel wrote: >> 2016-07-15 17:31 GMT+02:00 Dougal Matthews : >>> On 15 July 2016 at 16:27, David Moreau Simard wrote: >>>> >>>> I think TripleO-UI can draw from a lot of the work that has been done >>>> in Horizon packaging [1] (adding mrunge). >>>> >>>> You can see that most of the libraries are made available through >>>> xstatic python packages, for example jquery. >>>> If there are missing libraries they need to be highlighted so we can >>>> package them. >>> >>> >>> Due to the UI being built in react and using the npm ecosystem I think it >>> has over 800 dependent packages. I'm not sure that doing them all >>> individually is realistic. >>> >> >> Realistic or not, we are *compelled* to review licensing for each >> dependencies we ship. >> I'm not sure we'll be able to ship this in time for GA, considering >> that we passed M2. >> >> We can relax unbunding rules to a certain point but we also need to >> review the minifying toolchain even if it's not yet packaged. >> We're not allowed to ship minified javascript through minifiers that >> are not acceptable (e.g Google Closure compiler). >> There's a limit of how we can reduce the reviewing churn. > > What can be interesting in situations like this is to attempt to > explain what's an absolute requirement versus where exceptions might > be acceptable. > > > For everyone's reference, RDO's packaging guidelines are here: > > https://www.rdoproject.org/documentation/rdo-packaging-guidelines/ > > and there is a brief mention of RDO allowing for exceptions to > Fedora's strict unbundling guidelines: > > https://fedoraproject.org/wiki/Bundled_Libraries > > Some more reading on Fedora's unbundling policy: > https://lwn.net/Articles/660429/ > First, thanks for this complete summary. This is a must-read, FESCO relaxed a bit Fedora's unbundling policy while keeping balance between sanity and pragmatism. Declaring bundled libraries allows tracking them more effectively for security issues. > > Anyway, taking a step back beyond unbundling for one minute, we should > always require that packages are built in an entirely reproducible way > from source so that, for example, we always have the ability to > rebuilt the package with a minor fix and know that there won't be > side-effects other than the change we intended to make. > *nods* > Some of the implications of that: > > * The toolchain you use to build the package must also follow this > basic rule - because fixing an issue might entail fixing the toolchain > and rebuilding the package > > * Everything[1] must be rebuilt from source that is uploaded to the > build system - we don't use pre-built artifacts supplied by upstream. > > * It should be possible to review (e.g. from a security POV) all of > the source used to build the final package, and know that everything > was built from that source code. If you can't imagine us actually > doing this detailed a review, then think of it as us requiring the > ability to do a spot-check review. > > * The buildsystem should not have access to the internet during a > build, helping to ensure that the build process isn't using source > files from outside of the buildsystem. > > Many of Fedora's packaging guidelines are very useful to achieve > consistency for the user, like those around how packages are named or > versioned, or where files should be installed. Other guidelines > enforce a policies like Fedora should be built "exclusively from Free > and Open Source software", and to ensure the wishes of the original > copyright holders are respected. > Yes, we still lean back on those guidelines, as they were designed by the very same legal team behind RDO. We can have exceptions, but this has to be reviewed by lawyers. > > Back to unbundling ... as Haikel says, this is the one area where a > relaxing of the Fedora packaging guidelines might make sense in this > case, particularly for expediency. > > Having each dependency individually packaged has a number of benefits: > > * The correlation between package version and upstream dependency > version is clear > * It's easier to track when a a new upstream version is available > * It's easier to identify whether a given package is affected by a > published security issue > * Updates for users are smaller - they may only have to download and > update a small individual package rather than a large package > containing everything > * Package maintenance can be shared with others - if multiple > applications all use the same dependency, it's better if they don't > each package that dependency > * On-disk and in-memory space can be reduced if multiple applications > share the same dependency > > However, many of these benefits are probably quite small in the case > of TripleO UI compared to the likely overhead of individually > packaging everyting, and compared to the benefit of including TripleO > UI in the distribution. > > The exception to this argument that individual packaging is of little > benefit is that AIUI we are moving away from openstack-puppet-modules > being one giant package with many puppet modules bundled, towards > individual packages? The reason for this is that the maintenance > overhead with a single giant o-p-m package was actually greater than > using automation to maintain the individual packages? Is this likely > to also be true in the TripleO UI case? > > > I guess I don't even have a basic understanding of what's going on > here - for example, it looks like Horizon bundles the Angular > framework in its upstream git and tarball, but TripleO UI doesn't do > anything like that with React? > Mattias can probably explain it better than I do, but Horizon relies on Xstatic project. Xstatic wraps web assets in lightweight python modules for easier consumption by python applications. https://xstatic.readthedocs.io/en/latest/https://xstatic.readthedocs.io/en/latest/ So the angular library in the git repo is likely for development purpose and is not used in the RPM package. Web assets packaging is quite painful, so their bundling has been tolerated by most distributions, anyway. Maybe it's worth that Tripleo-UI tries to see how Horizon handles web assets, but it could already be the case. > The starting point for the thread was that the package users install > would just contain the minified version of the javascript ... which I > guess would be fine so long as the minification happened in the > buildsystem, using only "source" artifacts or artifacts built from > source. > > > Hope that helps, > Mark. > Yes, that's the goal. Depending the schedule, we may tolerate to use minified sources if we haven't finished by Newton GA for a very limited time But it requires that we're actively working on packaging and fixing the minification toolchain to use alternative component with proper licensing (if needed). I suspect that non-free component in the minification toolchain would also conflict with OpenStack licensing, but web assets are not tracked as well as python requirements by release team. So there's little to no licensing check upstream. H. > [1] - there are interesting nuances to this - e.g. for C projects, the > upstream maintainer will usually include configure.in, Makefile.in, > etc. files in their tarballs. These are likely generated with a > different version of autoconf and automake that are in the build > system. If, in future, we had to modify configure.ac and Makefile.am, > and then regenerate configure.in and Makefile.in using autoconf and > automake, we run the risk of introducing changes caused by differences > in the autotools versions. AIUI, this is still an unresolved debate in > Fedora, and left to discretion of packagers: > https://fedoraproject.org/wiki/PackagingDrafts/AutoConf > > > >>>> [1]: https://github.com/rdo-packages/horizon-distgit >>>> >>>> David Moreau Simard >>>> Senior Software Engineer | Openstack RDO >>>> >>>> dmsimard = [irc, github, twitter] >>>> >>>> >>>> On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: >>>> > Hey everyone - we are trying to think about our packaging strategy for >>>> > the TripleO UI and would like some feedback. Feel free to yell >>>> > regarding the details as this is high priority. >>>> > >>>> > The plan: >>>> > >>>> > 1.) Create a spec file for the RPM that includes the pre-compiled >>>> > (minified, production ready) javascript application. >>>> > 2.) Push new repository to review RDO repositories >>>> > RTFM: >>>> > >>>> > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk >>>> > 3.) Have people review said package here: >>>> > https://review.rdoproject.org/r/#/q/status:open >>>> > 4.) Add info to >>>> > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml >>>> > 5.) Package appears in trunk delorean >>>> > >>>> > >>>> > We talked a little and we are thinking that the UI will be able to be >>>> > installed without the dependency of mistral and zaqar since those are >>>> > connected services rather than binary dependencies. >>>> > >>>> > We are going to try that as a first pass and then iterate. >>>> > >>>> > We are targeting next week for this work and already have the beginning >>>> > of #1, so I am confident we'll be able to begin iterating on the >>>> > packaging setup. >>>> > >>>> > Please let me know if you have any questions. >>>> > >>>> > Thanks! >>>> > Jason >>>> > -- >>>> > Jason E. Rist >>>> > Senior Software Engineer >>>> > OpenStack User Interfaces >>>> > Red Hat, Inc. >>>> > openuc: +1.972.707.6408 >>>> > mobile: +1.720.256.3933 >>>> > Freenode: jrist >>>> > github/twitter: knowncitizen >>>> > >>>> > _______________________________________________ >>>> > rdo-list mailing list >>>> > rdo-list at redhat.com >>>> > https://www.redhat.com/mailman/listinfo/rdo-list >>>> > >>>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>>> >>>> _______________________________________________ >>>> rdo-list mailing list >>>> rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >>> >>> >>> >>> _______________________________________________ >>> rdo-list mailing list >>> rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From zaitcev at redhat.com Tue Jul 19 13:57:37 2016 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 19 Jul 2016 07:57:37 -0600 Subject: [rdo-list] Our "blog" has no feed (no RSS) Message-ID: <20160719075737.1e6b56b6@lembas.zaitcev.lan> I would like to contact someone in the infrastructure who runs these things, because 1) We appear to have 2 places and the distinction between them is unclear. URLs are: http://blogs.rdoproject.org/ and https://www.rdoproject.org/blog/ The latter is way more interesting and useful to me as a developer, while former is way snazzier. 2) the https://www.rdoproject.org/blog/ does not appear to have a feed, which saddens me a great deal So, anyone have a contact for it? Thanks, -- Pete From flfuchs at redhat.com Tue Jul 19 14:08:28 2016 From: flfuchs at redhat.com (Florian Fuchs) Date: Tue, 19 Jul 2016 16:08:28 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: Message-ID: <20160719140828.GA11108@linux.fritz.box> On Tue, Jul 19, 2016 at 15:02:14PM +0200, Ha?kel wrote: >2016-07-19 12:37 GMT+02:00 Mark McLoughlin : >> On Fri, Jul 15, 2016 at 6:29 PM, Ha?kel wrote: >>> 2016-07-15 17:31 GMT+02:00 Dougal Matthews : >>>> On 15 July 2016 at 16:27, David Moreau Simard wrote: >>>>> >>>>> I think TripleO-UI can draw from a lot of the work that has been done >>>>> in Horizon packaging [1] (adding mrunge). >>>>> >>>>> You can see that most of the libraries are made available through >>>>> xstatic python packages, for example jquery. >>>>> If there are missing libraries they need to be highlighted so we can >>>>> package them. >>>> >>>> >>>> Due to the UI being built in react and using the npm ecosystem I think it >>>> has over 800 dependent packages. I'm not sure that doing them all >>>> individually is realistic. >>>> >>> >>> Realistic or not, we are *compelled* to review licensing for each >>> dependencies we ship. >>> I'm not sure we'll be able to ship this in time for GA, considering >>> that we passed M2. >>> >>> We can relax unbunding rules to a certain point but we also need to >>> review the minifying toolchain even if it's not yet packaged. >>> We're not allowed to ship minified javascript through minifiers that >>> are not acceptable (e.g Google Closure compiler). >>> There's a limit of how we can reduce the reviewing churn. >> >> What can be interesting in situations like this is to attempt to >> explain what's an absolute requirement versus where exceptions might >> be acceptable. >> >> >> For everyone's reference, RDO's packaging guidelines are here: >> >> https://www.rdoproject.org/documentation/rdo-packaging-guidelines/ >> >> and there is a brief mention of RDO allowing for exceptions to >> Fedora's strict unbundling guidelines: >> >> https://fedoraproject.org/wiki/Bundled_Libraries >> >> Some more reading on Fedora's unbundling policy: >> https://lwn.net/Articles/660429/ >> > >First, thanks for this complete summary. > >This is a must-read, FESCO relaxed a bit Fedora's unbundling policy >while keeping balance between sanity and pragmatism. >Declaring bundled libraries allows tracking them more effectively for >security issues. > >> >> Anyway, taking a step back beyond unbundling for one minute, we should >> always require that packages are built in an entirely reproducible way >> from source so that, for example, we always have the ability to >> rebuilt the package with a minor fix and know that there won't be >> side-effects other than the change we intended to make. >> > >*nods* > > >> Some of the implications of that: >> >> * The toolchain you use to build the package must also follow this >> basic rule - because fixing an issue might entail fixing the toolchain >> and rebuilding the package >> >> * Everything[1] must be rebuilt from source that is uploaded to the >> build system - we don't use pre-built artifacts supplied by upstream. >> >> * It should be possible to review (e.g. from a security POV) all of >> the source used to build the final package, and know that everything >> was built from that source code. If you can't imagine us actually >> doing this detailed a review, then think of it as us requiring the >> ability to do a spot-check review. >> >> * The buildsystem should not have access to the internet during a >> build, helping to ensure that the build process isn't using source >> files from outside of the buildsystem. >> >> Many of Fedora's packaging guidelines are very useful to achieve >> consistency for the user, like those around how packages are named or >> versioned, or where files should be installed. Other guidelines >> enforce a policies like Fedora should be built "exclusively from Free >> and Open Source software", and to ensure the wishes of the original >> copyright holders are respected. >> > >Yes, we still lean back on those guidelines, as they were designed by >the very same legal team behind RDO. >We can have exceptions, but this has to be reviewed by lawyers. > >> >> Back to unbundling ... as Haikel says, this is the one area where a >> relaxing of the Fedora packaging guidelines might make sense in this >> case, particularly for expediency. >> >> Having each dependency individually packaged has a number of benefits: >> >> * The correlation between package version and upstream dependency >> version is clear >> * It's easier to track when a a new upstream version is available >> * It's easier to identify whether a given package is affected by a >> published security issue >> * Updates for users are smaller - they may only have to download and >> update a small individual package rather than a large package >> containing everything >> * Package maintenance can be shared with others - if multiple >> applications all use the same dependency, it's better if they don't >> each package that dependency >> * On-disk and in-memory space can be reduced if multiple applications >> share the same dependency >> >> However, many of these benefits are probably quite small in the case >> of TripleO UI compared to the likely overhead of individually >> packaging everyting, and compared to the benefit of including TripleO >> UI in the distribution. >> >> The exception to this argument that individual packaging is of little >> benefit is that AIUI we are moving away from openstack-puppet-modules >> being one giant package with many puppet modules bundled, towards >> individual packages? The reason for this is that the maintenance >> overhead with a single giant o-p-m package was actually greater than >> using automation to maintain the individual packages? Is this likely >> to also be true in the TripleO UI case? >> >> >> I guess I don't even have a basic understanding of what's going on >> here - for example, it looks like Horizon bundles the Angular >> framework in its upstream git and tarball, but TripleO UI doesn't do >> anything like that with React? >> > >Mattias can probably explain it better than I do, but Horizon relies >on Xstatic project. >Xstatic wraps web assets in lightweight python modules for easier >consumption by python applications. >https://xstatic.readthedocs.io/en/latest/https://xstatic.readthedocs.io/en/latest/ > >So the angular library in the git repo is likely for development >purpose and is not used in the RPM package. >Web assets packaging is quite painful, so their bundling has been >tolerated by most distributions, anyway. > > >Maybe it's worth that Tripleo-UI tries to see how Horizon handles web >assets, but it could already be the case. > >> The starting point for the thread was that the package users install >> would just contain the minified version of the javascript ... which I >> guess would be fine so long as the minification happened in the >> buildsystem, using only "source" artifacts or artifacts built from >> source. >> >> >> Hope that helps, >> Mark. >> > >Yes, that's the goal. >Depending the schedule, we may tolerate to use minified sources if we >haven't finished by Newton GA for a very limited time >But it requires that we're actively working on packaging and fixing >the minification toolchain to use alternative component with proper >licensing (if needed). So a couple of questions, assuming/suggesting the following workflow: 1. In a first step, we make sure the build tools and dependencies exist as node modules on the build system, so it can compile the target JS files from it. We make sure all dependencies have compatible licenses. 2. On each new tripleo-ui release, the build system compiles new target JS files using the dependencies from step 1. 3. The build system adds the compiled files to the new package (which is otherwise based on the tripleo-ui distgit repo). Questions: - Is this workflow plausible/acceptable/feasible? - If it is, would that flow be good acceptable for now only, or even permanently, given that all sources are free software and the build is transparent and reproducible? - Would version changes for dependencies have to be reviewed separately or could they be updated with each new build based on the version information in the upstream repo's package.json file? - Could steps 1. and 2. be combined, so tools and dependencies are updated and installed on each new release? (Assuming dependency changes are reviewed beforehand.) Thanks for clarifying! Florian > >I suspect that non-free component in the minification toolchain would >also conflict with OpenStack licensing, but web assets are not tracked >as well as python requirements by release team. >So there's little to no licensing check upstream. > >H. > > >> [1] - there are interesting nuances to this - e.g. for C projects, the >> upstream maintainer will usually include configure.in, Makefile.in, >> etc. files in their tarballs. These are likely generated with a >> different version of autoconf and automake that are in the build >> system. If, in future, we had to modify configure.ac and Makefile.am, >> and then regenerate configure.in and Makefile.in using autoconf and >> automake, we run the risk of introducing changes caused by differences >> in the autotools versions. AIUI, this is still an unresolved debate in >> Fedora, and left to discretion of packagers: >> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf >> >> >> >>>>> [1]: https://github.com/rdo-packages/horizon-distgit >>>>> >>>>> David Moreau Simard >>>>> Senior Software Engineer | Openstack RDO >>>>> >>>>> dmsimard = [irc, github, twitter] >>>>> >>>>> >>>>> On Fri, Jul 15, 2016 at 10:56 AM, Jason Rist wrote: >>>>> > Hey everyone - we are trying to think about our packaging strategy for >>>>> > the TripleO UI and would like some feedback. Feel free to yell >>>>> > regarding the details as this is high priority. >>>>> > >>>>> > The plan: >>>>> > >>>>> > 1.) Create a spec file for the RPM that includes the pre-compiled >>>>> > (minified, production ready) javascript application. >>>>> > 2.) Push new repository to review RDO repositories >>>>> > RTFM: >>>>> > >>>>> > https://www.rdoproject.org/documentation/rdo-packaging/#how-to-add-a-new-package-to-rdo-trunk >>>>> > 3.) Have people review said package here: >>>>> > https://review.rdoproject.org/r/#/q/status:open >>>>> > 4.) Add info to >>>>> > https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml >>>>> > 5.) Package appears in trunk delorean >>>>> > >>>>> > >>>>> > We talked a little and we are thinking that the UI will be able to be >>>>> > installed without the dependency of mistral and zaqar since those are >>>>> > connected services rather than binary dependencies. >>>>> > >>>>> > We are going to try that as a first pass and then iterate. >>>>> > >>>>> > We are targeting next week for this work and already have the beginning >>>>> > of #1, so I am confident we'll be able to begin iterating on the >>>>> > packaging setup. >>>>> > >>>>> > Please let me know if you have any questions. >>>>> > >>>>> > Thanks! >>>>> > Jason >>>>> > -- >>>>> > Jason E. Rist >>>>> > Senior Software Engineer >>>>> > OpenStack User Interfaces >>>>> > Red Hat, Inc. >>>>> > openuc: +1.972.707.6408 >>>>> > mobile: +1.720.256.3933 >>>>> > Freenode: jrist >>>>> > github/twitter: knowncitizen >>>>> > >>>>> > _______________________________________________ >>>>> > rdo-list mailing list >>>>> > rdo-list at redhat.com >>>>> > https://www.redhat.com/mailman/listinfo/rdo-list >>>>> > >>>>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>>>> >>>>> _______________________________________________ >>>>> rdo-list mailing list >>>>> rdo-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>>> >>>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> rdo-list mailing list >>>> rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >>> >>> _______________________________________________ >>> rdo-list mailing list >>> rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com > >_______________________________________________ >rdo-list mailing list >rdo-list at redhat.com >https://www.redhat.com/mailman/listinfo/rdo-list > >To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Tue Jul 19 14:29:18 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 19 Jul 2016 16:29:18 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160719140828.GA11108@linux.fritz.box> References: <20160719140828.GA11108@linux.fritz.box> Message-ID: 2016-07-19 16:08 GMT+02:00 Florian Fuchs : > > > So a couple of questions, assuming/suggesting the following workflow: > > > 1. In a first step, we make sure the build tools and dependencies exist as > node modules on the build system, so it can compile the target JS files from > it. We make sure all dependencies have compatible licenses. > > 2. On each new tripleo-ui release, the build system compiles new target JS > files using the dependencies from step 1. > > 3. The build system adds the compiled files to the new package (which is > otherwise based on the tripleo-ui distgit repo). > > > Questions: > > - Is this workflow plausible/acceptable/feasible? > Yes, though I'm not sure what you understand as build system. Build system has no internet access, and except baseOS, only things available are provided sources + dependencies declared as BuildRequires (must be packaged) > - If it is, would that flow be good acceptable for now only, or even > permanently, given that all sources are free software and the build is > transparent and reproducible? > That's the stable state we want to reach. Depending the amount of work needed, we may tolerate temporary exceptions, but they have to be approved by RDO maintainers in our weekly meeting. > - Would version changes for dependencies have to be reviewed separately or > could they be updated with each new build based on the version information > in the upstream repo's package.json file? > Process is: * initial review when you introduce new package (except if it's packaged in Fedora as they have exemption from legal team) * update bumps are done directly without peer reviewing (well release wranglers and CI are checking sanity) > - Could steps 1. and 2. be combined, so tools and dependencies are updated > and installed on each new release? (Assuming dependency changes are > reviewed beforehand.) > > > Thanks for clarifying! > Florian > Up to a certain extent, while we tolerate bundling web assets, I prefer that we don't bundle the toolchain and try to keep it stable. Not that we'd enforce strict constraints on that, but remember that we have limited ressources to maintain the whole distribution. Regards, H. From hpokorny at redhat.com Tue Jul 19 14:53:34 2016 From: hpokorny at redhat.com (Honza Pokorny) Date: Tue, 19 Jul 2016 11:53:34 -0300 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160719140828.GA11108@linux.fritz.box> Message-ID: <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> On 2016-07-19 16:29, Ha?kel wrote: > 2016-07-19 16:08 GMT+02:00 Florian Fuchs : > > > > > > So a couple of questions, assuming/suggesting the following workflow: > > > > > > 1. In a first step, we make sure the build tools and dependencies exist as > > node modules on the build system, so it can compile the target JS files from > > it. We make sure all dependencies have compatible licenses. > > > > 2. On each new tripleo-ui release, the build system compiles new target JS > > files using the dependencies from step 1. > > > > 3. The build system adds the compiled files to the new package (which is > > otherwise based on the tripleo-ui distgit repo). > > > > > > Questions: > > > > - Is this workflow plausible/acceptable/feasible? > > > > Yes, though I'm not sure what you understand as build system. > Build system has no internet access, and except baseOS, only things > available are provided sources + dependencies declared as > BuildRequires (must be packaged) I guess this is the biggest problem: our build system is responsible for both fetching any dependencies and for actually building the project. Preferably, we'd like to run "npm install" from the RPM spec. This step requires internet access, and therefore violates one of the rules. Since our dependencies are fixed/pinned, there is a fair degree of certainty that the dependencies will be the same each time the build is run[1]. Npm install brings in sources, not artifacts. What would be your preferred solution? Should we try and use xstatic? We could also bundle our dependencies along with the source tarball --- would that ease your mind? [1]: Yes, I know about the leftpad fiasco :) > > > - If it is, would that flow be good acceptable for now only, or even > > permanently, given that all sources are free software and the build is > > transparent and reproducible? > > > > That's the stable state we want to reach. > Depending the amount of work needed, we may tolerate temporary > exceptions, but they have to be approved by RDO maintainers in our > weekly meeting. > > > - Would version changes for dependencies have to be reviewed separately or > > could they be updated with each new build based on the version information > > in the upstream repo's package.json file? > > > > Process is: > * initial review when you introduce new package (except if it's > packaged in Fedora as they have exemption from legal team) > * update bumps are done directly without peer reviewing (well release > wranglers and CI are checking sanity) > > > - Could steps 1. and 2. be combined, so tools and dependencies are updated > > and installed on each new release? (Assuming dependency changes are > > reviewed beforehand.) > > > > > > Thanks for clarifying! > > Florian > > > > Up to a certain extent, while we tolerate bundling web assets, I > prefer that we don't bundle the toolchain and try to keep it stable. > Not that we'd enforce strict constraints on that, but remember that we > have limited ressources to maintain the whole distribution. > > Regards, > H. > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Tue Jul 19 15:34:46 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 19 Jul 2016 17:34:46 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> Message-ID: 2016-07-19 16:53 GMT+02:00 Honza Pokorny : > On 2016-07-19 16:29, Ha?kel wrote: >> 2016-07-19 16:08 GMT+02:00 Florian Fuchs : >> > >> > >> > So a couple of questions, assuming/suggesting the following workflow: >> > >> > >> > 1. In a first step, we make sure the build tools and dependencies exist as >> > node modules on the build system, so it can compile the target JS files from >> > it. We make sure all dependencies have compatible licenses. >> > >> > 2. On each new tripleo-ui release, the build system compiles new target JS >> > files using the dependencies from step 1. >> > >> > 3. The build system adds the compiled files to the new package (which is >> > otherwise based on the tripleo-ui distgit repo). >> > >> > >> > Questions: >> > >> > - Is this workflow plausible/acceptable/feasible? >> > >> >> Yes, though I'm not sure what you understand as build system. >> Build system has no internet access, and except baseOS, only things >> available are provided sources + dependencies declared as >> BuildRequires (must be packaged) > > I guess this is the biggest problem: our build system is responsible for > both fetching any dependencies and for actually building the project. > Preferably, we'd like to run "npm install" from the RPM spec. This step > requires internet access, and therefore violates one of the rules. Since > our dependencies are fixed/pinned, there is a fair degree of certainty > that the dependencies will be the same each time the build is run[1]. > Npm install brings in sources, not artifacts. > There's an ongoing work to integrate language "native" packages with RPM ecosystem (so-called modularity workgroup in Fedora) In the future, build system will have access to an internal npm registry mirror (and pypi for python, etc.), but that's still an ongoing work and there are many issues to solve (notably reproducibility). For now, we either have to package dependencies or bundle them. Our build and delivery infrastructure is provided by CentOS, these are not constraints that we can bypass, nor we can maintain on our own. The landscape of software engineering was very different when GNU/Linux packaging and distributions were created, and it'll take time to adapt to modern software engineering (for the better or the worst) > What would be your preferred solution? Should we try and use xstatic? > We could also bundle our dependencies along with the source tarball --- > would that ease your mind? > xstatic would be nice but I'd prefer that you check with our horizon developers, first. They have more experience on that topic, especially Mattias who also maintained horizon packaging. Yes, direct dependencies can be bundled, we can tolerate minification toolchain (provided it complies with our licensing terms) bundling but that'd be temporary exception. > [1]: Yes, I know about the leftpad fiasco :) > >> >> > - If it is, would that flow be good acceptable for now only, or even >> > permanently, given that all sources are free software and the build is >> > transparent and reproducible? >> > >> >> That's the stable state we want to reach. >> Depending the amount of work needed, we may tolerate temporary >> exceptions, but they have to be approved by RDO maintainers in our >> weekly meeting. >> >> > - Would version changes for dependencies have to be reviewed separately or >> > could they be updated with each new build based on the version information >> > in the upstream repo's package.json file? >> > >> >> Process is: >> * initial review when you introduce new package (except if it's >> packaged in Fedora as they have exemption from legal team) >> * update bumps are done directly without peer reviewing (well release >> wranglers and CI are checking sanity) >> >> > - Could steps 1. and 2. be combined, so tools and dependencies are updated >> > and installed on each new release? (Assuming dependency changes are >> > reviewed beforehand.) >> > >> > >> > Thanks for clarifying! >> > Florian >> > >> >> Up to a certain extent, while we tolerate bundling web assets, I >> prefer that we don't bundle the toolchain and try to keep it stable. >> Not that we'd enforce strict constraints on that, but remember that we >> have limited ressources to maintain the whole distribution. >> >> Regards, >> H. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Tue Jul 19 16:12:10 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 19 Jul 2016 18:12:10 +0200 Subject: [rdo-list] Our "blog" has no feed (no RSS) In-Reply-To: <20160719075737.1e6b56b6@lembas.zaitcev.lan> References: <20160719075737.1e6b56b6@lembas.zaitcev.lan> Message-ID: 2016-07-19 15:57 GMT+02:00 Pete Zaitcev : > I would like to contact someone in the infrastructure who runs these things, > because > > 1) We appear to have 2 places and the distinction between them is unclear. > URLs are: > http://blogs.rdoproject.org/ This is the former enovance planet that has been transferred to us, I agree that the name is a bit confusing (planet could be clearer) > and > https://www.rdoproject.org/blog/ > RDO shared blog > The latter is way more interesting and useful to me as a developer, while > former is way snazzier. > I don't have exact status, but Rich likely knows. > 2) the https://www.rdoproject.org/blog/ does not appear to have a feed, > which saddens me a great deal > > So, anyone have a contact for it? > Creating a ticket here: https://github.com/redhat-openstack/website/issues Website is maintained by RDO community and Red Hat OSAS team, Garrett is likely the right person to fix it. Regards, H. > Thanks, > -- Pete > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Tue Jul 19 16:43:22 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 19 Jul 2016 18:43:22 +0200 Subject: [rdo-list] Our "blog" has no feed (no RSS) In-Reply-To: References: <20160719075737.1e6b56b6@lembas.zaitcev.lan> Message-ID: Well, it wasn't too hard to fix middleman to have a proper atom feed. https://github.com/redhat-openstack/website/pull/661 Regards, H. From whayutin at redhat.com Tue Jul 19 18:20:32 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 19 Jul 2016 14:20:32 -0400 Subject: [rdo-list] [tripleo][ci] oooq role changes Message-ID: FYI, Per some discussion in the RDO-CI meeting today I have very quickly created some launchpad bugs to track some changes for tripleo-quickstart. I plan on updating the bugs w/ more details but there should be enough there to start the conversation. Replace oooq inventory w/ external role: https://bugs.launchpad.net/tripleo-quickstart/+bug/1604517 Remove overcloud deployment from oooq native and use external role https://bugs.launchpad.net/tripleo-quickstart/+bug/1604518 Remove overcloud validation from oooq native and use external role https://bugs.launchpad.net/tripleo-quickstart/+bug/1604520 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Tue Jul 19 18:39:53 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 19 Jul 2016 14:39:53 -0400 Subject: [rdo-list] [tripleo][ci] Message-ID: Greetings, We've all been making great use of [1] the known master issues etherpad. I'd like to propose that people add their names to items they report and a name to the person or people working the issue. Something like: [ reporter: joe at acme.org ] [ assigned: tom at redhat.com , tom at myspace.com ] So for example: 15. Overcloud deploy fails due to Gnocchi dbsync failing [ reporter: joe at acme.org ] [ assigned: tom at redhat.com , tom at myspace.com ] - This is a different issue then 12 If you are assigned and get pulled into something else, you would remove your name. Thoughts? [1]https://etherpad.openstack.org/p/delorean_master_current_issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at redhat.com Tue Jul 19 19:03:16 2016 From: apevec at redhat.com (Alan Pevec) Date: Tue, 19 Jul 2016 21:03:16 +0200 Subject: [rdo-list] [tripleo][ci] In-Reply-To: References: Message-ID: I'm not sure about emulating a bug tracker in the etherpad, let's require everbody append his name when adding entries but also require bz or lp to be filed immediately after initial triage. If no better clues, file bz against RDO/distribution. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From trown at redhat.com Tue Jul 19 19:39:17 2016 From: trown at redhat.com (John Trowbridge) Date: Tue, 19 Jul 2016 15:39:17 -0400 Subject: [rdo-list] [tripleo][ci] In-Reply-To: References: Message-ID: <578E81E5.7020409@redhat.com> On 07/19/2016 03:03 PM, Alan Pevec wrote: > I'm not sure about emulating a bug tracker in the etherpad, let's require > everbody append his name when adding entries but also require bz or lp to > be filed immediately after initial triage. If no better clues, file bz > against RDO/distribution. > +1 to filing an actual bug as soon as there is enough information to be useful. The person(s) working on the bug should assign themselves there. The etherpad is really meant to be a meta-tracker of open bugs and patches that are blocking promote. I do like the idea of the reporter putting their name down though. From rbowen at redhat.com Tue Jul 19 20:21:59 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 19 Jul 2016 16:21:59 -0400 Subject: [rdo-list] RDO blogs, week of July 18th Message-ID: <590f80fd-6ce5-859d-5242-b3fccfbe57c3@redhat.com> Here's what RDO enthusiasts have been blogging about in the last week. OpenStack 2016.1-1 release Ha?kel Gu?mar The RDO Community is pleased to announce a new release of openstack-utils. ? read more at http://tm3.org/7x Improving RDO packaging testing coverage by David Simard DLRN builds packages and generates repositories in which these packages will be hosted. It is the tool that is developed and used by the RDO community to provide the repositories on trunk.rdoproject.org. It continuously builds packages for every commit for projects packaged in RDO. ? read more at http://tm3.org/7y TripleO deep dive session #2 (TripleO Heat Templates by Carlos Camacho This is the second video from a series of ?Deep Dive? sessions related to TripleO deployments. ? watch at http://tm3.org/7z How to build new OpenStack packages by Chandan Kumar Building new OpenStack packages for RDO is always tough. Let's use DLRN to make our life simpler. ? read more at http://tm3.org/7- OpenStack Swift mid-cycle hackathon summary by cschwede Last week more than 30 people from all over the world met at the Rackspace office in San Antonio, TX for the Swift mid-cycle hackathon. All major companies contributing to Swift sent people, including Fujitsu, HPE, IBM, Intel, NTT, Rackspace, Red Hat, and Swiftstack. As always it was a packed week with a lot of deep technical discussions around current and future changes within Swift. ? read more at http://tm3.org/80 -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Tue Jul 19 20:36:10 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 19 Jul 2016 16:36:10 -0400 Subject: [rdo-list] Our "blog" has no feed (no RSS) In-Reply-To: <20160719075737.1e6b56b6@lembas.zaitcev.lan> References: <20160719075737.1e6b56b6@lembas.zaitcev.lan> Message-ID: <6d42211d-7303-e1bd-fa55-63539576bef5@redhat.com> On 07/19/2016 09:57 AM, Pete Zaitcev wrote: > I would like to contact someone in the infrastructure who runs these things, > because > > 1) We appear to have 2 places and the distinction between them is unclear. > URLs are: > http://blogs.rdoproject.org/ > and > https://www.rdoproject.org/blog/ > > The latter is way more interesting and useful to me as a developer, while > former is way snazzier. > > 2) the https://www.rdoproject.org/blog/ does not appear to have a feed, > which saddens me a great deal > > So, anyone have a contact for it? Many thanks to Haikel for fixing this. :-) On the other issue of blogs.rdoproject.org vs rdoproject.org/blog, the former used to be the eNovance developer blog, and is now open to anybody that wants to blog about RDO topics. Just ask me, and I'll set you up with an account. The latter is part of the RDO website itself, and you can publish to it by adding content to the the /blog subdirectory of the website, in the right format, and sending a pull request. I'd be glad to help anyone use that as a place to post their RDO-related content. There are two, purely due to historical reasons. It's been on my list for some time to merge the two into one place, but there are some logistical issues in doing this, and I simply have never gotten around to it yet. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Tue Jul 19 20:40:14 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 19 Jul 2016 16:40:14 -0400 Subject: [rdo-list] [Cloud SIG] CentOS Cloud SIG meeting, Thursday, 15:00 UTC Message-ID: A reminder that we hold the CentOS Cloud SIG meeting each week on #centos-devel, on the Freenode IRC network, Thursdays at 15:00 UTC. The agenda for this meeting may be found here: https://etherpad.openstack.org/p/centos-cloud-sig We welcome everyone to attend this meeting, where we discuss open source cloud infrastructure platforms packaged for CentOS Thanks! -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From dsneddon at redhat.com Tue Jul 19 21:28:21 2016 From: dsneddon at redhat.com (Dan Sneddon) Date: Tue, 19 Jul 2016 14:28:21 -0700 Subject: [rdo-list] tripelo installation In-Reply-To: References: Message-ID: <2301f0d6-ddbc-7b47-ffb6-024c2da45e92@redhat.com> On 07/17/2016 10:47 AM, Dotan, Alon wrote: > Few questions about tripleo: > > I got a requirement from my boss to create a production environment of > openstack, usually I?m using packstack since he is very easy and robust > installer, > > The issue is that the repos of the release kept for 3 versions only > which breaks packstack > > > > My questions is: > > ? Can I freeze versions with tripleo or there is any downloads > from the net in the deployments? > > ? How difficult is to upgrade versions > > ? Can someone redirect me to a guide that explain how to build > the topology and how to add compute / publish configuration change to > the environment? > > > > Thanks, > > > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > The upgrade process for RDO is documented here. I assume it will be updated for upgrades from Mitaka to Newton when the time comes. https://www.rdoproject.org/install/upgrading-rdo/ As far as finding documentation on topology, scaling (adding computes), and configuration management, you may want to look at the Red Hat OpenStack Platform documentation. RH OSP is just the commercially released version of the RDO source code, so almost everything documented for OSP is applicable for RDO: https://access.redhat.com/documentation/en/red-hat-openstack-platform/ I'm not exactly sure what you mean by freezing versions. RPM upgrades are not automatic once the nodes are deployed. If you want complete control over the versions of RPMs on your systems, you can set up your own RPM repository and use that instead of letting yum connect to the Internet for downloads. When you are building overcloud images, you can set the value of DIB_YUM_REPO_CONF to point at yum repo files that will be used to create the overcloud images. If you point at local repos, you can control which RPMs are used for the deployment. -- Dan Sneddon | Principal OpenStack Engineer dsneddon at redhat.com | redhat.com/openstack 650.254.4025 | dsneddon:irc @dxs:twitter From ichavero at redhat.com Wed Jul 20 20:52:11 2016 From: ichavero at redhat.com (Ivan Chavero) Date: Wed, 20 Jul 2016 16:52:11 -0400 (EDT) Subject: [rdo-list] [Minute] RDO meeting (2016-07-20) Minutes In-Reply-To: <1117772737.7686364.1469047907272.JavaMail.zimbra@redhat.com> Message-ID: <1265408615.7686375.1469047931553.JavaMail.zimbra@redhat.com> ============================== #rdo: RDO meeting - 2016-07-20 ============================== Meeting started by imcsk8 at 15:00:30 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-07-20/rdo_meeting_-_2016-07-20.2016-07-20-15.00.log.html . Meeting summary --------------- * roll call (imcsk8, 15:00:39) * newton2 testday readiness (imcsk8, 15:02:55) * ACTION: dmsimard to investigate if removing firewalld and networkmanager from the default centos installations can help alleviate flapping results (dmsimard, 15:09:41) * ACTION: trown babysit instack-undercloud patch (trown, 15:15:04) * RDO CI: POWER nodes sizing (w/ mengxd) (imcsk8, 15:17:30) * LINK: https://ci.centos.org/view/rdo/view/all/ (mengxd, 15:18:29) * LINK: http://docs.openstack.org/developer/tripleo-docs/environments/virtual.html (weshay, 15:27:21) * LINK: https://ci.centos.org/view/rdo/view/promotion-pipeline/ (weshay, 15:40:30) * LINK: https://ci.centos.org/view/rdo/view/tripleo-gate/ are triggered off of changes to CI src.. (weshay, 15:40:48) * LINK: https://ci.centos.org/view/rdo/view/tripleo-periodic/ (weshay, 15:41:02) * ACTION: mengxd to send a message to the Mailing List about CI requirements (imcsk8, 15:45:23) * tripleo-ui packaging (imcsk8, 15:45:48) * rdopkg 0.38 released (imcsk8, 15:58:54) * Chair for next meetup (imcsk8, 16:00:38) * ACTION: chandankumar to chair next meeting (imcsk8, 16:01:36) * open floor (imcsk8, 16:01:57) Meeting ended at 16:03:20 UTC. Action Items ------------ * dmsimard to investigate if removing firewalld and networkmanager from the default centos installations can help alleviate flapping results * trown babysit instack-undercloud patch * mengxd to send a message to the Mailing List about CI requirements * chandankumar to chair next meeting Action Items, by person ----------------------- * chandankumar * chandankumar to chair next meeting * dmsimard * dmsimard to investigate if removing firewalld and networkmanager from the default centos installations can help alleviate flapping results * mengxd * mengxd to send a message to the Mailing List about CI requirements * trown * trown babysit instack-undercloud patch * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * weshay (56) * imcsk8 (44) * dmsimard (43) * mengxd (26) * jrist (26) * number80 (20) * apevec (19) * zodbot (15) * trown (13) * jtomasek (12) * jruzicka (10) * chandankumar (5) * florianf (3) * openstack (3) * honza (3) * sshnaidm (2) * rdogerrit (1) * rbowen (1) * jjoyce (1) * coolsvap (1) * eggmaster (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From honza at redhat.com Thu Jul 21 14:23:29 2016 From: honza at redhat.com (Honza Pokorny) Date: Thu, 21 Jul 2016 11:23:29 -0300 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> Message-ID: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> There still seems to be some confusion about what we're saying, so let me attempt to summarize: 1. bundling of npm dependencies (sources) undesirable but temporarily tolerated 2. bundling of build toolchain even more undesirable 3. all bundling of sources tolerated temporarily 4. start working on packaging build toolchain as soon as possible A modern javascript application (both frontend and nodejs) uses npm to manage its dependencies and to build production/release versions from sources. All of this configuration information is contained in the package.json file. The "dependencies" section of that file contains a list of direct application dependencies; the "devDependencies" section contains a list of build/minification dependencies. Typically, one will run "npm install" to fetch all dependencies: these will be placed in the node_modules/ directory --- npm downloads sources along with artifacts (e.g. if the package is written in coffee-script, it will contain both the coffee-script sources and the compiled js). And, we plan to use npm to also build the minified code (e.g. "npm run build"). What I propose to do is: 1. On release, run "npm install" to bring in all dependencies 2. Create a tarball of node_modules 3. Run "npm pack" to create a release package 4. The tripleo-ui RPM spec will receive the package from 3. as Source0 5. The RPM build system has all of the application and build dependencies in the node_modules.tar.gz file; it can build minified dist files (release, production) without internet access Once we have this system in place and we can actually ship our code, we can start working on unbundling those dependencies (i.e removing them from the node_modules tarball, and publishing them as rpms that the tripleo-ui.spec can request). How does this sound? Do I understand this correctly? Honza Pokorny On 2016-07-19 17:34, Ha?kel wrote: > 2016-07-19 16:53 GMT+02:00 Honza Pokorny : > > On 2016-07-19 16:29, Ha?kel wrote: > >> 2016-07-19 16:08 GMT+02:00 Florian Fuchs : > >> > > >> > > >> > So a couple of questions, assuming/suggesting the following workflow: > >> > > >> > > >> > 1. In a first step, we make sure the build tools and dependencies exist as > >> > node modules on the build system, so it can compile the target JS files from > >> > it. We make sure all dependencies have compatible licenses. > >> > > >> > 2. On each new tripleo-ui release, the build system compiles new target JS > >> > files using the dependencies from step 1. > >> > > >> > 3. The build system adds the compiled files to the new package (which is > >> > otherwise based on the tripleo-ui distgit repo). > >> > > >> > > >> > Questions: > >> > > >> > - Is this workflow plausible/acceptable/feasible? > >> > > >> > >> Yes, though I'm not sure what you understand as build system. > >> Build system has no internet access, and except baseOS, only things > >> available are provided sources + dependencies declared as > >> BuildRequires (must be packaged) > > > > I guess this is the biggest problem: our build system is responsible for > > both fetching any dependencies and for actually building the project. > > Preferably, we'd like to run "npm install" from the RPM spec. This step > > requires internet access, and therefore violates one of the rules. Since > > our dependencies are fixed/pinned, there is a fair degree of certainty > > that the dependencies will be the same each time the build is run[1]. > > Npm install brings in sources, not artifacts. > > > > There's an ongoing work to integrate language "native" packages with > RPM ecosystem (so-called modularity workgroup in Fedora) > In the future, build system will have access to an internal npm > registry mirror (and pypi for python, etc.), but that's still an > ongoing work and there are many issues to solve (notably > reproducibility). > > For now, we either have to package dependencies or bundle them. Our > build and delivery infrastructure is provided by CentOS, these are not > constraints that we can bypass, nor we can maintain on our own. > > The landscape of software engineering was very different when > GNU/Linux packaging and distributions were created, and it'll take > time to adapt to modern software engineering (for the better or the > worst) > > > What would be your preferred solution? Should we try and use xstatic? > > We could also bundle our dependencies along with the source tarball --- > > would that ease your mind? > > > > xstatic would be nice but I'd prefer that you check with our horizon > developers, first. They have more experience on that topic, especially > Mattias who also maintained horizon packaging. > Yes, direct dependencies can be bundled, we can tolerate minification > toolchain (provided it complies with our licensing terms) bundling but > that'd be temporary exception. > > > [1]: Yes, I know about the leftpad fiasco :) > > > >> > >> > - If it is, would that flow be good acceptable for now only, or even > >> > permanently, given that all sources are free software and the build is > >> > transparent and reproducible? > >> > > >> > >> That's the stable state we want to reach. > >> Depending the amount of work needed, we may tolerate temporary > >> exceptions, but they have to be approved by RDO maintainers in our > >> weekly meeting. > >> > >> > - Would version changes for dependencies have to be reviewed separately or > >> > could they be updated with each new build based on the version information > >> > in the upstream repo's package.json file? > >> > > >> > >> Process is: > >> * initial review when you introduce new package (except if it's > >> packaged in Fedora as they have exemption from legal team) > >> * update bumps are done directly without peer reviewing (well release > >> wranglers and CI are checking sanity) > >> > >> > - Could steps 1. and 2. be combined, so tools and dependencies are updated > >> > and installed on each new release? (Assuming dependency changes are > >> > reviewed beforehand.) > >> > > >> > > >> > Thanks for clarifying! > >> > Florian > >> > > >> > >> Up to a certain extent, while we tolerate bundling web assets, I > >> prefer that we don't bundle the toolchain and try to keep it stable. > >> Not that we'd enforce strict constraints on that, but remember that we > >> have limited ressources to maintain the whole distribution. > >> > >> Regards, > >> H. > >> > >> _______________________________________________ > >> rdo-list mailing list > >> rdo-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/rdo-list > >> > >> To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Thu Jul 21 15:47:23 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 21 Jul 2016 17:47:23 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> Message-ID: 2016-07-21 16:23 GMT+02:00 Honza Pokorny : > There still seems to be some confusion about what we're saying, so let > me attempt to summarize: > > 1. bundling of npm dependencies (sources) undesirable but temporarily tolerated > > 2. bundling of build toolchain even more undesirable > > 3. all bundling of sources tolerated temporarily > > 4. start working on packaging build toolchain as soon as possible > > A modern javascript application (both frontend and nodejs) uses npm to > manage its dependencies and to build production/release versions from > sources. All of this configuration information is contained in the > package.json file. The "dependencies" section of that file contains a > list of direct application dependencies; the "devDependencies" section > contains a list of build/minification dependencies. Typically, one will > run "npm install" to fetch all dependencies: these will be placed in the > node_modules/ directory --- npm downloads sources along with artifacts > (e.g. if the package is written in coffee-script, it will contain both > the coffee-script sources and the compiled js). And, we plan to use npm > to also build the minified code (e.g. "npm run build"). > > What I propose to do is: > > 1. On release, run "npm install" to bring in all dependencies > 2. Create a tarball of node_modules > 3. Run "npm pack" to create a release package > 4. The tripleo-ui RPM spec will receive the package from 3. as Source0 > 5. The RPM build system has all of the application and build > dependencies in the node_modules.tar.gz file; it can build minified > dist files (release, production) without internet access > > Once we have this system in place and we can actually ship our code, we > can start working on unbundling those dependencies (i.e removing them > from the node_modules tarball, and publishing them as rpms that the > tripleo-ui.spec can request). > > How does this sound? Do I understand this correctly? > > Honza Pokorny > Looks ok as a first step. Difficulty is that as long as we have this bundling, we won't be able to build TripleO UI in DLRN (except by introducing a specific workaround). H. > On 2016-07-19 17:34, Ha?kel wrote: >> 2016-07-19 16:53 GMT+02:00 Honza Pokorny : >> > On 2016-07-19 16:29, Ha?kel wrote: >> >> 2016-07-19 16:08 GMT+02:00 Florian Fuchs : >> >> > >> >> > >> >> > So a couple of questions, assuming/suggesting the following workflow: >> >> > >> >> > >> >> > 1. In a first step, we make sure the build tools and dependencies exist as >> >> > node modules on the build system, so it can compile the target JS files from >> >> > it. We make sure all dependencies have compatible licenses. >> >> > >> >> > 2. On each new tripleo-ui release, the build system compiles new target JS >> >> > files using the dependencies from step 1. >> >> > >> >> > 3. The build system adds the compiled files to the new package (which is >> >> > otherwise based on the tripleo-ui distgit repo). >> >> > >> >> > >> >> > Questions: >> >> > >> >> > - Is this workflow plausible/acceptable/feasible? >> >> > >> >> >> >> Yes, though I'm not sure what you understand as build system. >> >> Build system has no internet access, and except baseOS, only things >> >> available are provided sources + dependencies declared as >> >> BuildRequires (must be packaged) >> > >> > I guess this is the biggest problem: our build system is responsible for >> > both fetching any dependencies and for actually building the project. >> > Preferably, we'd like to run "npm install" from the RPM spec. This step >> > requires internet access, and therefore violates one of the rules. Since >> > our dependencies are fixed/pinned, there is a fair degree of certainty >> > that the dependencies will be the same each time the build is run[1]. >> > Npm install brings in sources, not artifacts. >> > >> >> There's an ongoing work to integrate language "native" packages with >> RPM ecosystem (so-called modularity workgroup in Fedora) >> In the future, build system will have access to an internal npm >> registry mirror (and pypi for python, etc.), but that's still an >> ongoing work and there are many issues to solve (notably >> reproducibility). >> >> For now, we either have to package dependencies or bundle them. Our >> build and delivery infrastructure is provided by CentOS, these are not >> constraints that we can bypass, nor we can maintain on our own. >> >> The landscape of software engineering was very different when >> GNU/Linux packaging and distributions were created, and it'll take >> time to adapt to modern software engineering (for the better or the >> worst) >> >> > What would be your preferred solution? Should we try and use xstatic? >> > We could also bundle our dependencies along with the source tarball --- >> > would that ease your mind? >> > >> >> xstatic would be nice but I'd prefer that you check with our horizon >> developers, first. They have more experience on that topic, especially >> Mattias who also maintained horizon packaging. >> Yes, direct dependencies can be bundled, we can tolerate minification >> toolchain (provided it complies with our licensing terms) bundling but >> that'd be temporary exception. >> >> > [1]: Yes, I know about the leftpad fiasco :) >> > >> >> >> >> > - If it is, would that flow be good acceptable for now only, or even >> >> > permanently, given that all sources are free software and the build is >> >> > transparent and reproducible? >> >> > >> >> >> >> That's the stable state we want to reach. >> >> Depending the amount of work needed, we may tolerate temporary >> >> exceptions, but they have to be approved by RDO maintainers in our >> >> weekly meeting. >> >> >> >> > - Would version changes for dependencies have to be reviewed separately or >> >> > could they be updated with each new build based on the version information >> >> > in the upstream repo's package.json file? >> >> > >> >> >> >> Process is: >> >> * initial review when you introduce new package (except if it's >> >> packaged in Fedora as they have exemption from legal team) >> >> * update bumps are done directly without peer reviewing (well release >> >> wranglers and CI are checking sanity) >> >> >> >> > - Could steps 1. and 2. be combined, so tools and dependencies are updated >> >> > and installed on each new release? (Assuming dependency changes are >> >> > reviewed beforehand.) >> >> > >> >> > >> >> > Thanks for clarifying! >> >> > Florian >> >> > >> >> >> >> Up to a certain extent, while we tolerate bundling web assets, I >> >> prefer that we don't bundle the toolchain and try to keep it stable. >> >> Not that we'd enforce strict constraints on that, but remember that we >> >> have limited ressources to maintain the whole distribution. >> >> >> >> Regards, >> >> H. >> >> >> >> _______________________________________________ >> >> rdo-list mailing list >> >> rdo-list at redhat.com >> >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From whayutin at redhat.com Thu Jul 21 15:54:26 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 21 Jul 2016 11:54:26 -0400 Subject: [rdo-list] rdo-infra mtg notes Message-ID: https://review.rdoproject.org/etherpad/p/rdo-infra -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Thu Jul 21 20:50:50 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 21 Jul 2016 16:50:50 -0400 Subject: [rdo-list] tempest failure in packstack Message-ID: FYI.. https://ci.centos.org/job/weirdo-mitaka-promote-packstack-scenario001/373/consoleFull https://etherpad.openstack.org/p/delorean_mitaka_current_issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Fri Jul 22 06:05:56 2016 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 22 Jul 2016 08:05:56 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> Message-ID: On Tue, Jul 19, 2016 at 4:53 PM, Honza Pokorny wrote: > On 2016-07-19 16:29, Ha?kel wrote: >> Yes, though I'm not sure what you understand as build system. >> Build system has no internet access, and except baseOS, only things >> available are provided sources + dependencies declared as >> BuildRequires (must be packaged) > > I guess this is the biggest problem: our build system is responsible for > both fetching any dependencies and for actually building the project. > Preferably, we'd like to run "npm install" from the RPM spec. This step > requires internet access, and therefore violates one of the rules. Since > our dependencies are fixed/pinned, there is a fair degree of certainty > that the dependencies will be the same each time the build is run[1]. > Npm install brings in sources, not artifacts. It's really important that we all see the value of this "rule" and not see it as some sort of hindrance imposed on us by a legacy view of software development :) The system is designed so that, in 18 months (or 10 years!) if we isolate a bug to in one of the lower level dependencies in this dependency stack, that we can fix that bug (think of something as isolated as e.g. a missing i++ statement in a loop) and rebuild the package with a high degree of confidence that the only thing that has changed is the bugfix you made. And that all of this can happen really quickly and predictably in a high-pressure crisis situation where the bug is causing very serious, real-world problems. If, the first time we built the package, 'npm install' in the build system downloaded a source tarball from the internet, will it still be there at that exact moment in 18 months time? Maybe not, so we have the lookaside cache for tarballs. If 'npm install' downloads the 'latest' version of some dependency or tool, will it be a problem in 18 months time if there's a newer version now being used? Maybe, so the dependencies and tools are installed from packages, and we can reproduce an install of that exact set of packages later. Maven is a build tool known for "downloading the internet", yet we have managed to integrate it with our build system to a point that "maven install" is perfectly aligned with these principles. See https://fedoraproject.org/wiki/KojiMavenSupport Distros like Fedora and Debian take this concept very seriously, and for good reason. Distro developers are the type of people who yearn for "reproducible build" to mean that in my example above, if you rebuilt the package with the example i++ fix above, the *only* change to the binary package would be the addition of that opcode. See https://lwn.net/Articles/630074/ which I'll admit to finding mind-blowing when I Lunar's FOSEM talk a couple of years ago: https://archive.fosdem.org/2014/schedule/event/reproducibledebian/ Thanks, Mark. From markmc at redhat.com Fri Jul 22 06:17:22 2016 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 22 Jul 2016 08:17:22 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> Message-ID: On Thu, Jul 21, 2016 at 4:23 PM, Honza Pokorny wrote: > There still seems to be some confusion about what we're saying, so let > me attempt to summarize: > > 1. bundling of npm dependencies (sources) undesirable but temporarily tolerated > > 2. bundling of build toolchain even more undesirable > > 3. all bundling of sources tolerated temporarily > > 4. start working on packaging build toolchain as soon as possible > > A modern javascript application (both frontend and nodejs) uses npm to > manage its dependencies and to build production/release versions from > sources. All of this configuration information is contained in the > package.json file. The "dependencies" section of that file contains a > list of direct application dependencies; the "devDependencies" section > contains a list of build/minification dependencies. Typically, one will > run "npm install" to fetch all dependencies: these will be placed in the > node_modules/ directory --- npm downloads sources along with artifacts > (e.g. if the package is written in coffee-script, it will contain both > the coffee-script sources and the compiled js). And, we plan to use npm > to also build the minified code (e.g. "npm run build"). > > What I propose to do is: > > 1. On release, run "npm install" to bring in all dependencies > 2. Create a tarball of node_modules > 3. Run "npm pack" to create a release package To be clear, this should be the tarball released by the TripleO project. RDO packages upstream sources, and here you're creating new source artifacts, which should also come from upstream. I think it's possibly acceptable as a first step, but don't be surprised if and when people declare this the ugliest thing they've ever seen :) Where would 'npm install' be run? In upstream infra CI or a developer's laptop? > 4. The tripleo-ui RPM spec will receive the package from 3. as Source0 You would also need to verify that you can add Patch/%patch statements easily to patch any of the code included. If, in order to fix a bug, you need to ask upstream in 18 months to generate a new tarball with whatever 'npm install' happens to find on the internet at that time, you no longer have the ability to do an isolated bugfix. Thanks, Mark. > 5. The RPM build system has all of the application and build > dependencies in the node_modules.tar.gz file; it can build minified > dist files (release, production) without internet access > > Once we have this system in place and we can actually ship our code, we > can start working on unbundling those dependencies (i.e removing them > from the node_modules tarball, and publishing them as rpms that the > tripleo-ui.spec can request). > > How does this sound? Do I understand this correctly? > > Honza Pokorny > > On 2016-07-19 17:34, Ha?kel wrote: >> 2016-07-19 16:53 GMT+02:00 Honza Pokorny : >> > On 2016-07-19 16:29, Ha?kel wrote: >> >> 2016-07-19 16:08 GMT+02:00 Florian Fuchs : >> >> > >> >> > >> >> > So a couple of questions, assuming/suggesting the following workflow: >> >> > >> >> > >> >> > 1. In a first step, we make sure the build tools and dependencies exist as >> >> > node modules on the build system, so it can compile the target JS files from >> >> > it. We make sure all dependencies have compatible licenses. >> >> > >> >> > 2. On each new tripleo-ui release, the build system compiles new target JS >> >> > files using the dependencies from step 1. >> >> > >> >> > 3. The build system adds the compiled files to the new package (which is >> >> > otherwise based on the tripleo-ui distgit repo). >> >> > >> >> > >> >> > Questions: >> >> > >> >> > - Is this workflow plausible/acceptable/feasible? >> >> > >> >> >> >> Yes, though I'm not sure what you understand as build system. >> >> Build system has no internet access, and except baseOS, only things >> >> available are provided sources + dependencies declared as >> >> BuildRequires (must be packaged) >> > >> > I guess this is the biggest problem: our build system is responsible for >> > both fetching any dependencies and for actually building the project. >> > Preferably, we'd like to run "npm install" from the RPM spec. This step >> > requires internet access, and therefore violates one of the rules. Since >> > our dependencies are fixed/pinned, there is a fair degree of certainty >> > that the dependencies will be the same each time the build is run[1]. >> > Npm install brings in sources, not artifacts. >> > >> >> There's an ongoing work to integrate language "native" packages with >> RPM ecosystem (so-called modularity workgroup in Fedora) >> In the future, build system will have access to an internal npm >> registry mirror (and pypi for python, etc.), but that's still an >> ongoing work and there are many issues to solve (notably >> reproducibility). >> >> For now, we either have to package dependencies or bundle them. Our >> build and delivery infrastructure is provided by CentOS, these are not >> constraints that we can bypass, nor we can maintain on our own. >> >> The landscape of software engineering was very different when >> GNU/Linux packaging and distributions were created, and it'll take >> time to adapt to modern software engineering (for the better or the >> worst) >> >> > What would be your preferred solution? Should we try and use xstatic? >> > We could also bundle our dependencies along with the source tarball --- >> > would that ease your mind? >> > >> >> xstatic would be nice but I'd prefer that you check with our horizon >> developers, first. They have more experience on that topic, especially >> Mattias who also maintained horizon packaging. >> Yes, direct dependencies can be bundled, we can tolerate minification >> toolchain (provided it complies with our licensing terms) bundling but >> that'd be temporary exception. >> >> > [1]: Yes, I know about the leftpad fiasco :) >> > >> >> >> >> > - If it is, would that flow be good acceptable for now only, or even >> >> > permanently, given that all sources are free software and the build is >> >> > transparent and reproducible? >> >> > >> >> >> >> That's the stable state we want to reach. >> >> Depending the amount of work needed, we may tolerate temporary >> >> exceptions, but they have to be approved by RDO maintainers in our >> >> weekly meeting. >> >> >> >> > - Would version changes for dependencies have to be reviewed separately or >> >> > could they be updated with each new build based on the version information >> >> > in the upstream repo's package.json file? >> >> > >> >> >> >> Process is: >> >> * initial review when you introduce new package (except if it's >> >> packaged in Fedora as they have exemption from legal team) >> >> * update bumps are done directly without peer reviewing (well release >> >> wranglers and CI are checking sanity) >> >> >> >> > - Could steps 1. and 2. be combined, so tools and dependencies are updated >> >> > and installed on each new release? (Assuming dependency changes are >> >> > reviewed beforehand.) >> >> > >> >> > >> >> > Thanks for clarifying! >> >> > Florian >> >> > >> >> >> >> Up to a certain extent, while we tolerate bundling web assets, I >> >> prefer that we don't bundle the toolchain and try to keep it stable. >> >> Not that we'd enforce strict constraints on that, but remember that we >> >> have limited ressources to maintain the whole distribution. >> >> >> >> Regards, >> >> H. >> >> >> >> _______________________________________________ >> >> rdo-list mailing list >> >> rdo-list at redhat.com >> >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From mrunge at redhat.com Fri Jul 22 06:35:52 2016 From: mrunge at redhat.com (Matthias Runge) Date: Fri, 22 Jul 2016 08:35:52 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> Message-ID: <78d175e6-defd-8920-34a2-bcd81aba11cd@redhat.com> On 21/07/16 16:23, Honza Pokorny wrote: > There still seems to be some confusion about what we're saying, so let > me attempt to summarize: > > 1. bundling of npm dependencies (sources) undesirable but temporarily tolerated Taking the conversation from IRC here: I don't think we got an answer on this yet. If you're pulling all dependencies in, and compile a package then, you're basically creating something comparable to statically linked binaries: If a library has a security issue, you're going to rebuild the whole thing. You mentioned somewhere else, dependencies are pinned: is that true for dependencies of dependencies as well? Or would I get a different tarball, when collecting all dependencies (and deps of deps) in a few weeks? > node_modules/ directory --- npm downloads sources along with artifacts > (e.g. if the package is written in coffee-script, it will contain both > the coffee-script sources and the compiled js). And, we plan to use npm > to also build the minified code (e.g. "npm run build"). -- Matthias Runge Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From markmc at redhat.com Fri Jul 22 08:13:18 2016 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 22 Jul 2016 10:13:18 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <78d175e6-defd-8920-34a2-bcd81aba11cd@redhat.com> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <78d175e6-defd-8920-34a2-bcd81aba11cd@redhat.com> Message-ID: On Fri, Jul 22, 2016 at 8:35 AM, Matthias Runge wrote: > On 21/07/16 16:23, Honza Pokorny wrote: >> There still seems to be some confusion about what we're saying, so let >> me attempt to summarize: >> >> 1. bundling of npm dependencies (sources) undesirable but temporarily tolerated > > Taking the conversation from IRC here: > > I don't think we got an answer on this yet. > > If you're pulling all dependencies in, and compile a package then, > you're basically creating something comparable to statically linked > binaries: If a library has a security issue, you're going to rebuild the > whole thing. Let's challenge ourselves to justify the constraints we're placing on ourselves using first principles :) What's wrong with rebuilding the whole thing? e.g. is it - the user will have a big download/update, for a fix that could have been self-contained - the build will take a lot longer than if it was self-contained - or ...? The most compelling reason usually is so that, in a case like this, you don't have to rebuild many packages that statically link to the library when you have a security issue. Assuming we only have one app using this library (is that a valid assumption?) then we don't have that issue here. > You mentioned somewhere else, dependencies are pinned: is that true for > dependencies of dependencies as well? Or would I get a different > tarball, when collecting all dependencies (and deps of deps) in a few weeks? Right, and the issue there would be that if you have to re-run this (and as a result get a new set of dependencies) just to fix a bug, then that's not acceptable. Hence my question about whether we would have a workable method of patching the bundled sources in order to apply a fix. Thanks, Mark. > > >> node_modules/ directory --- npm downloads sources along with artifacts >> (e.g. if the package is written in coffee-script, it will contain both >> the coffee-script sources and the compiled js). And, we plan to use npm >> to also build the minified code (e.g. "npm run build"). > > > -- > Matthias Runge > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, > Michael O'Neill, Eric Shander > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From honza at redhat.com Fri Jul 22 14:02:48 2016 From: honza at redhat.com (Honza Pokorny) Date: Fri, 22 Jul 2016 11:02:48 -0300 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> Message-ID: <20160722140248.iwcumqc74iaifvji@localhost.localdomain> Notes from our meeting today: * We have outlined three timelines for handling dependencies a) short term - bundle everything b) long term - unbundle toolchain c) very long term - use new npm registry * Currently, the build system uses nodejs 0.10.x, let's look at upgrading that * Upstream CI should run selenium tests and other smoke tests * Related patches: * openstack infra - https://review.openstack.org/#/c/343834/ * rpm spec in tripleo-ui - https://review.openstack.org/#/c/344932/ * once these are merged: * open a request for review in rdo * create a distgit repo for tripleo-ui Feel free to add to this Thanks Honza Pokorny On 2016-07-21 17:47, Ha?kel wrote: > 2016-07-21 16:23 GMT+02:00 Honza Pokorny : > > There still seems to be some confusion about what we're saying, so let > > me attempt to summarize: > > > > 1. bundling of npm dependencies (sources) undesirable but temporarily tolerated > > > > 2. bundling of build toolchain even more undesirable > > > > 3. all bundling of sources tolerated temporarily > > > > 4. start working on packaging build toolchain as soon as possible > > > > A modern javascript application (both frontend and nodejs) uses npm to > > manage its dependencies and to build production/release versions from > > sources. All of this configuration information is contained in the > > package.json file. The "dependencies" section of that file contains a > > list of direct application dependencies; the "devDependencies" section > > contains a list of build/minification dependencies. Typically, one will > > run "npm install" to fetch all dependencies: these will be placed in the > > node_modules/ directory --- npm downloads sources along with artifacts > > (e.g. if the package is written in coffee-script, it will contain both > > the coffee-script sources and the compiled js). And, we plan to use npm > > to also build the minified code (e.g. "npm run build"). > > > > What I propose to do is: > > > > 1. On release, run "npm install" to bring in all dependencies > > 2. Create a tarball of node_modules > > 3. Run "npm pack" to create a release package > > 4. The tripleo-ui RPM spec will receive the package from 3. as Source0 > > 5. The RPM build system has all of the application and build > > dependencies in the node_modules.tar.gz file; it can build minified > > dist files (release, production) without internet access > > > > Once we have this system in place and we can actually ship our code, we > > can start working on unbundling those dependencies (i.e removing them > > from the node_modules tarball, and publishing them as rpms that the > > tripleo-ui.spec can request). > > > > How does this sound? Do I understand this correctly? > > > > Honza Pokorny > > > > Looks ok as a first step. > Difficulty is that as long as we have this bundling, we won't be able > to build TripleO UI in DLRN (except by introducing a specific > workaround). > > H. > > > > On 2016-07-19 17:34, Ha?kel wrote: > >> 2016-07-19 16:53 GMT+02:00 Honza Pokorny : > >> > On 2016-07-19 16:29, Ha?kel wrote: > >> >> 2016-07-19 16:08 GMT+02:00 Florian Fuchs : > >> >> > > >> >> > > >> >> > So a couple of questions, assuming/suggesting the following workflow: > >> >> > > >> >> > > >> >> > 1. In a first step, we make sure the build tools and dependencies exist as > >> >> > node modules on the build system, so it can compile the target JS files from > >> >> > it. We make sure all dependencies have compatible licenses. > >> >> > > >> >> > 2. On each new tripleo-ui release, the build system compiles new target JS > >> >> > files using the dependencies from step 1. > >> >> > > >> >> > 3. The build system adds the compiled files to the new package (which is > >> >> > otherwise based on the tripleo-ui distgit repo). > >> >> > > >> >> > > >> >> > Questions: > >> >> > > >> >> > - Is this workflow plausible/acceptable/feasible? > >> >> > > >> >> > >> >> Yes, though I'm not sure what you understand as build system. > >> >> Build system has no internet access, and except baseOS, only things > >> >> available are provided sources + dependencies declared as > >> >> BuildRequires (must be packaged) > >> > > >> > I guess this is the biggest problem: our build system is responsible for > >> > both fetching any dependencies and for actually building the project. > >> > Preferably, we'd like to run "npm install" from the RPM spec. This step > >> > requires internet access, and therefore violates one of the rules. Since > >> > our dependencies are fixed/pinned, there is a fair degree of certainty > >> > that the dependencies will be the same each time the build is run[1]. > >> > Npm install brings in sources, not artifacts. > >> > > >> > >> There's an ongoing work to integrate language "native" packages with > >> RPM ecosystem (so-called modularity workgroup in Fedora) > >> In the future, build system will have access to an internal npm > >> registry mirror (and pypi for python, etc.), but that's still an > >> ongoing work and there are many issues to solve (notably > >> reproducibility). > >> > >> For now, we either have to package dependencies or bundle them. Our > >> build and delivery infrastructure is provided by CentOS, these are not > >> constraints that we can bypass, nor we can maintain on our own. > >> > >> The landscape of software engineering was very different when > >> GNU/Linux packaging and distributions were created, and it'll take > >> time to adapt to modern software engineering (for the better or the > >> worst) > >> > >> > What would be your preferred solution? Should we try and use xstatic? > >> > We could also bundle our dependencies along with the source tarball --- > >> > would that ease your mind? > >> > > >> > >> xstatic would be nice but I'd prefer that you check with our horizon > >> developers, first. They have more experience on that topic, especially > >> Mattias who also maintained horizon packaging. > >> Yes, direct dependencies can be bundled, we can tolerate minification > >> toolchain (provided it complies with our licensing terms) bundling but > >> that'd be temporary exception. > >> > >> > [1]: Yes, I know about the leftpad fiasco :) > >> > > >> >> > >> >> > - If it is, would that flow be good acceptable for now only, or even > >> >> > permanently, given that all sources are free software and the build is > >> >> > transparent and reproducible? > >> >> > > >> >> > >> >> That's the stable state we want to reach. > >> >> Depending the amount of work needed, we may tolerate temporary > >> >> exceptions, but they have to be approved by RDO maintainers in our > >> >> weekly meeting. > >> >> > >> >> > - Would version changes for dependencies have to be reviewed separately or > >> >> > could they be updated with each new build based on the version information > >> >> > in the upstream repo's package.json file? > >> >> > > >> >> > >> >> Process is: > >> >> * initial review when you introduce new package (except if it's > >> >> packaged in Fedora as they have exemption from legal team) > >> >> * update bumps are done directly without peer reviewing (well release > >> >> wranglers and CI are checking sanity) > >> >> > >> >> > - Could steps 1. and 2. be combined, so tools and dependencies are updated > >> >> > and installed on each new release? (Assuming dependency changes are > >> >> > reviewed beforehand.) > >> >> > > >> >> > > >> >> > Thanks for clarifying! > >> >> > Florian > >> >> > > >> >> > >> >> Up to a certain extent, while we tolerate bundling web assets, I > >> >> prefer that we don't bundle the toolchain and try to keep it stable. > >> >> Not that we'd enforce strict constraints on that, but remember that we > >> >> have limited ressources to maintain the whole distribution. > >> >> > >> >> Regards, > >> >> H. > >> >> > >> >> _______________________________________________ > >> >> rdo-list mailing list > >> >> rdo-list at redhat.com > >> >> https://www.redhat.com/mailman/listinfo/rdo-list > >> >> > >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From rbowen at redhat.com Fri Jul 22 15:23:53 2016 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 22 Jul 2016 11:23:53 -0400 Subject: [rdo-list] Reschedule test day? Message-ID: <5c30c081-6177-f662-a11e-a0a93abfaa24@redhat.com> As many of you know, this week's test day was a bust, due to the inability to get a promotion of Newton 2. Question: Do we want to reschedule a test day for next week, or just wait until N3? -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From hguemar at fedoraproject.org Fri Jul 22 18:16:58 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Fri, 22 Jul 2016 20:16:58 +0200 Subject: [rdo-list] Reschedule test day? In-Reply-To: <5c30c081-6177-f662-a11e-a0a93abfaa24@redhat.com> References: <5c30c081-6177-f662-a11e-a0a93abfaa24@redhat.com> Message-ID: 2016-07-22 17:23 GMT+02:00 Rich Bowen : > As many of you know, this week's test day was a bust, due to the > inability to get a promotion of Newton 2. > > Question: Do we want to reschedule a test day for next week, or just > wait until N3? > > -- > Rich Bowen - rbowen at redhat.com > RDO Community Liaison > http://rdoproject.org > @RDOCommunity > Wait until next promotion and schedule a test day the next week. M3 is too far away and we have little visibility for now to set a date in stone. Regards, H. From slinaber at redhat.com Fri Jul 22 18:26:26 2016 From: slinaber at redhat.com (Steven Linabery) Date: Fri, 22 Jul 2016 13:26:26 -0500 Subject: [rdo-list] Reschedule test day? In-Reply-To: References: <5c30c081-6177-f662-a11e-a0a93abfaa24@redhat.com> Message-ID: +1 On Fri, Jul 22, 2016 at 1:16 PM, Ha?kel wrote: > 2016-07-22 17:23 GMT+02:00 Rich Bowen : >> As many of you know, this week's test day was a bust, due to the >> inability to get a promotion of Newton 2. >> >> Question: Do we want to reschedule a test day for next week, or just >> wait until N3? >> >> -- >> Rich Bowen - rbowen at redhat.com >> RDO Community Liaison >> http://rdoproject.org >> @RDOCommunity >> > > Wait until next promotion and schedule a test day the next week. > M3 is too far away and we have little visibility for now to set a date in stone. > > Regards, > H. > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From whayutin at redhat.com Fri Jul 22 21:26:20 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Fri, 22 Jul 2016 17:26:20 -0400 Subject: [rdo-list] package list for rdo oooq builds Message-ID: FYI.. We've known for quite some time that maintaining a list of packages for image builds [2] is not ideal. We need to push this review along [1]. This relies on DIB for the package list vs.. us specifying the list in the variables. We're going to make this a priority now. Please review [1] Thanks! [1] https://review.gerrithub.io/#/c/280666 [2] https://github.com/redhat-openstack/ansible-role-tripleo-image-build/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrist at redhat.com Fri Jul 22 22:10:38 2016 From: jrist at redhat.com (Jason Rist) Date: Fri, 22 Jul 2016 16:10:38 -0600 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160722140248.iwcumqc74iaifvji@localhost.localdomain> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> Message-ID: <88759090-5422-cfab-7626-166adf959b4a@redhat.com> On 07/22/2016 08:02 AM, Honza Pokorny wrote: > Notes from our meeting today: > > * We have outlined three timelines for handling dependencies > > a) short term - bundle everything > b) long term - unbundle toolchain > c) very long term - use new npm registry > > * Currently, the build system uses nodejs 0.10.x, let's look at > upgrading that > What is the purpose of this? I saw today Fedora 25 is using 6.x but RHEL/CentOS is still Version : 0.10.42 Release : 4.el7 We should probably make sure this is highly reproducible with RHEL and CentOS specifically, right? > * Upstream CI should run selenium tests and other smoke tests :thumbsup: > > * Related patches: > > * openstack infra - https://review.openstack.org/#/c/343834/ Has a +2, needs a +1 workflow > * rpm spec in tripleo-ui - https://review.openstack.org/#/c/344932/ Needs eyes > * once these are merged: > * open a request for review in rdo > * create a distgit repo for tripleo-ui > Since the two patches are up, we just need eyes. I'm guessing as long as we get a +1 on workflow next week we can have both merged. I think we can have the beginning of something in next week. Honza, Haikel - does that sound reasonable? After that, we'll probably have to refine what's in to work correctly with the undercloud install, which would probably take another week, give or take a few days for reviews. -Jason > Feel free to add to this > > Thanks > > Honza Pokorny > -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen From apevec at redhat.com Fri Jul 22 22:18:43 2016 From: apevec at redhat.com (Alan Pevec) Date: Sat, 23 Jul 2016 00:18:43 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <88759090-5422-cfab-7626-166adf959b4a@redhat.com> References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> Message-ID: >> * Currently, the build system uses nodejs 0.10.x, let's look at >> upgrading that > > What is the purpose of this? I saw today Fedora 25 is using 6.x but > RHEL/CentOS is still That's EPEL7, nodejs is not in base EL7., > Version : 0.10.42 > Release : 4.el7 0.10 goes EOL soon https://github.com/nodejs/LTS#lts-schedule so better to upgrade now while preparing the tool chain. Alan From jrist at redhat.com Fri Jul 22 22:38:36 2016 From: jrist at redhat.com (Jason Rist) Date: Fri, 22 Jul 2016 16:38:36 -0600 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> Message-ID: On 07/22/2016 04:18 PM, Alan Pevec wrote: > >> * Currently, the build system uses nodejs 0.10.x, let's look at > >> upgrading that > > > > What is the purpose of this? I saw today Fedora 25 is using 6.x but > > RHEL/CentOS is still > > That's EPEL7, nodejs is not in base EL7., > > > Version : 0.10.42 > > Release : 4.el7 > > 0.10 goes EOL soon https://github.com/nodejs/LTS#lts-schedule so > better to upgrade now while preparing the tool chain. > > Alan > Makes perfect sense. Thanks. -J -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen From hguemar at fedoraproject.org Sat Jul 23 02:26:40 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Sat, 23 Jul 2016 04:26:40 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160719140828.GA11108@linux.fritz.box> <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> Message-ID: @Jason: As I said during the mentioned call, we have nodejs 0.10.36 build in CBS -I'm actually the one who built it- and there's no problem in importing a LTS release (4.x or 6.x) Mattias is of the opinion we should stick to 4.x which is the current LTS. http://cbs.centos.org/koji/buildinfo?buildID=8185 I'm taking the action of importing a newer nodejs build in our repository. Jakub and I will be providing support in packaging/reviewing tripleo-ui. Considering we'll be having many missing people due to summer vacations, I associated Jakub to avoid being the SPOF in that process. As we want to have this sorted out before M3, I'd like to have status during our weekly RDO meetings to follow up progress and solve impediments. Regards, H. From honza at redhat.com Mon Jul 25 14:17:15 2016 From: honza at redhat.com (Honza Pokorny) Date: Mon, 25 Jul 2016 11:17:15 -0300 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> Message-ID: <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> On 2016-07-23 04:26, Ha?kel wrote: > @Jason: As I said during the mentioned call, we have nodejs 0.10.36 > build in CBS -I'm actually the one who built it- and there's no > problem in importing a LTS release (4.x or 6.x) > Mattias is of the opinion we should stick to 4.x which is the current LTS. > http://cbs.centos.org/koji/buildinfo?buildID=8185 > > I'm taking the action of importing a newer nodejs build in our > repository. Jakub and I will be providing support in > packaging/reviewing tripleo-ui. I'm confident we can make this happen early this week, thanks to Haikel and Jakup. As Jason said, if we can get some eyes on the infra patch and the packaging patch that would certainly speed things up. Haikel, if you could have a quick look at the spec file for tripleo-ui, I think that would make a nice starting point. Or, would you rather I submitted a format request for review to RDO at this point? > Considering we'll be having many missing people due to summer > vacations, I associated Jakub to avoid being the SPOF in that process. > > As we want to have this sorted out before M3, I'd like to have status > during our weekly RDO meetings to follow up progress and solve > impediments. > > Regards, > H. From hguemar at fedoraproject.org Mon Jul 25 14:23:14 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 25 Jul 2016 16:23:14 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> References: <20160719145334.j3y5lnp3ytjpwp3j@localhost.localdomain> <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> Message-ID: 2016-07-25 16:17 GMT+02:00 Honza Pokorny : > On 2016-07-23 04:26, Ha?kel wrote: >> @Jason: As I said during the mentioned call, we have nodejs 0.10.36 >> build in CBS -I'm actually the one who built it- and there's no >> problem in importing a LTS release (4.x or 6.x) >> Mattias is of the opinion we should stick to 4.x which is the current LTS. >> http://cbs.centos.org/koji/buildinfo?buildID=8185 >> >> I'm taking the action of importing a newer nodejs build in our >> repository. Jakub and I will be providing support in >> packaging/reviewing tripleo-ui. > > I'm confident we can make this happen early this week, thanks to Haikel > and Jakup. As Jason said, if we can get some eyes on the infra patch > and the packaging patch that would certainly speed things up. > > Haikel, if you could have a quick look at the spec file for tripleo-ui, > I think that would make a nice starting point. Or, would you rather I > submitted a format request for review to RDO at this point? > Both works for me. >> Considering we'll be having many missing people due to summer >> vacations, I associated Jakub to avoid being the SPOF in that process. >> >> As we want to have this sorted out before M3, I'd like to have status >> during our weekly RDO meetings to follow up progress and solve >> impediments. >> >> Regards, >> H. From hguemar at fedoraproject.org Mon Jul 25 15:00:03 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 25 Jul 2016 15:00:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20160725150003.2C90B60A4009@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-07-27 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From rbowen at redhat.com Mon Jul 25 15:45:36 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 25 Jul 2016 11:45:36 -0400 Subject: [rdo-list] This week's blogs Message-ID: <7a117765-f0bc-ceb4-c805-9373788ced46@redhat.com> Here's what RDO enthusiasts have been writing about over the past week: TripleO deep dive session #3 (Overcloud deployment debugging) by Carlos Camacho This is the third video from a series of ?Deep Dive? sessions related to TripleO deployments. ? read (and watch) more at http://tm3.org/81 How connection tracking in Open vSwitch helps OpenStack performance by Jiri Benc By introducing a connection tracking feature in Open vSwitch, thanks to the latest Linux kernel, we greatly simplified the maze of virtual network interfaces on OpenStack compute nodes and improved its networking performance. This feature will appear soon in Red Hat OpenStack Platform. ? read more at http://tm3.org/82 Introduction to Red Hat OpenStack Platform Director by Marcos Garcia Those familiar with OpenStack already know that deployment has historically been a bit challenging. That?s mainly because deployment includes a lot more than just getting the software installed ? it?s about architecting your platform to use existing infrastructure as well as planning for future scalability and flexibility. OpenStack is designed to be a massively scalable platform, with distributed components on a shared message bus and database backend. For most deployments, this distributed architecture consists of Controller nodes for cluster management, resource orchestration, and networking services, Compute nodes where the virtual machines (the workloads) are executed, and Storage nodes where persistent storage is managed. ? read more at http://tm3.org/83 Cinder Active-Active HA ? Newton mid-cycle by Gorka Eguileor Last week took place the OpenStack Cinder mid-cycle sprint in Fort Collins, and on the first day we discussed the Active-Active HA effort that?s been going on for a while now and the plans for the future. This is a summary of that session. ? read more at http://tm3.org/84 -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Mon Jul 25 17:57:38 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 25 Jul 2016 13:57:38 -0400 Subject: [rdo-list] Ask.openstack.org unanswered RDO questions Message-ID: <5b384915-7dba-b6fa-7579-502f621b490b@redhat.com> 39 unanswered questions: Adding a compute node with RDO - Puppet/Hiera error? https://ask.openstack.org/en/question/94951/adding-a-compute-node-with-rdo-puppethiera-error/ Tags: adding, compute-node, rdo Failed to set RDO repo on host-packstact-centOS-7 https://ask.openstack.org/en/question/94828/failed-to-set-rdo-repo-on-host-packstact-centos-7/ Tags: openstack-packstack, centos7, rdo how to deploy haskell-distributed in RDO? https://ask.openstack.org/en/question/94785/how-to-deploy-haskell-distributed-in-rdo/ Tags: rdo How to set quota for domain and have it shared with all the projects/tenants in domain https://ask.openstack.org/en/question/94105/how-to-set-quota-for-domain-and-have-it-shared-with-all-the-projectstenants-in-domain/ Tags: domainquotadriver rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Are following links considered by RH as official guide lines in meantime for TripleO instack-virt-setup RDO Liberty Stable? https://ask.openstack.org/en/question/93751/are-following-links-considered-by-rh-as-official-guide-lines-in-meantime-for-tripleo-instack-virt-setup-rdo-liberty-stable/ Tags: rdo, tripleo, instack Add new compute node for TripleO deployment in virtual environment https://ask.openstack.org/en/question/93703/add-new-compute-node-for-tripleo-deployment-in-virtual-environment/ Tags: compute, tripleo, liberty, virtual, baremetal Unable to start Ceilometer services https://ask.openstack.org/en/question/93600/unable-to-start-ceilometer-services/ Tags: ceilometer, ceilometer-api Adding hard drive space to RDO installation https://ask.openstack.org/en/question/93412/adding-hard-drive-space-to-rdo-installation/ Tags: cinder, openstack, space, add AWS Ec2 inst Eth port loses IP when attached to linux bridge in Openstack https://ask.openstack.org/en/question/92271/aws-ec2-inst-eth-port-loses-ip-when-attached-to-linux-bridge-in-openstack/ Tags: openstack, networking, aws ceilometer: I've installed openstack mitaka. but swift stops working when i configured the pipeline and ceilometer filter https://ask.openstack.org/en/question/92035/ceilometer-ive-installed-openstack-mitaka-but-swift-stops-working-when-i-configured-the-pipeline-and-ceilometer-filter/ Tags: ceilometer, openstack-swift, mitaka Fail on installing the controller on Cent OS 7 https://ask.openstack.org/en/question/92025/fail-on-installing-the-controller-on-cent-os-7/ Tags: installation, centos7, controller the error of service entity and API endpoints https://ask.openstack.org/en/question/91702/the-error-of-service-entity-and-api-endpoints/ Tags: service, entity, and, api, endpoints Running delorean fails: Git won't fetch sources https://ask.openstack.org/en/question/91600/running-delorean-fails-git-wont-fetch-sources/ Tags: delorean, rdo Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: stack, resource, topology, dashboard Build of instance aborted: Block Device Mapping is Invalid. https://ask.openstack.org/en/question/91205/build-of-instance-aborted-block-device-mapping-is-invalid/ Tags: cinder, lvm, centos7 No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack how to use chef auto manage openstack in RDO? https://ask.openstack.org/en/question/90992/how-to-use-chef-auto-manage-openstack-in-rdo/ Tags: chef, rdo Separate Cinder storage traffic from management https://ask.openstack.org/en/question/90405/separate-cinder-storage-traffic-from-management/ Tags: cinder, separate, nic, iscsi Openstack installation fails using packstack, failure is in installation of openstack-nova-compute. Error: Dependency Package[nova-compute] has failures https://ask.openstack.org/en/question/88993/openstack-installation-fails-using-packstack-failure-is-in-installation-of-openstack-nova-compute-error-dependency-packagenova-compute-has-failures/ Tags: novacompute, rdo, packstack, dependency, failure CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Sahara SSHException: Error reading SSH protocol banner https://ask.openstack.org/en/question/84710/sahara-sshexception-error-reading-ssh-protocol-banner/ Tags: sahara, icehouse, ssh, vanila Error Sahara create cluster: 'Error attach volume to instance https://ask.openstack.org/en/question/84651/error-sahara-create-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, vanila, icehouse Creating Sahara cluster: Error attach volume to instance https://ask.openstack.org/en/question/84650/creating-sahara-cluster-error-attach-volume-to-instance/ Tags: sahara, attach-volume, hadoop, icehouse, vanilla Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Mon Jul 25 18:45:53 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 25 Jul 2016 14:45:53 -0400 Subject: [rdo-list] OpenStack meetups happening this week (Lots of 6th Birthday events!) Message-ID: <8c98d7f4-6a3a-1c7b-158b-cc2c1eb73a36@redhat.com> This month, the OpenStack Foundation offered money to meetup groups to do OpenStack 6th Birthday events. Now that it's the last week of the month, a lot of groups are getting in on that at the last minute, so you've got pretty good chances of finding a 6th Birthday event near you. I'll be speaking on Thursday at the Lexington, Kentucky event! If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Monday July 25 in Saint Paul, MN, US: OpenStack 6th Birthday Celebration! - http://www.meetup.com/Minnesota-OpenStack-Meetup/events/232535058/ * Monday July 25 in Istanbul, TR: SUSE way of OpenStack - http://www.meetup.com/Turkey-OpenStack-Meetup/events/232638843/ * Wednesday July 27 in Islamabad, PK: Celebrating OpenStack 6th Birthday - http://www.meetup.com/Openstack-Pakistan/events/232075494/ * Wednesday July 27 in Berlin, DE: 9th OpenStack User Group Berlin - http://www.meetup.com/OpenStack-User-Group-Berlin/events/232387643/ * Wednesday July 27 in Manchester, 18, GB: OpenStack's 6th Birthday - 6 years and SDN - http://www.meetup.com/Manchester-OpenStack-Meetup/events/232048418/ * Thursday July 28 in Lexington, KY, US: OpenStack Birthday Event - http://www.meetup.com/OpenStack-Kentucky/events/232204499/ * Thursday July 28 in Moscow, RU: ???? ???????? OpenStack - http://www.meetup.com/OpenStack-Russia/events/232540797/ * Thursday July 28 in Buenos Aires, AR: OpenStack 6th Birthday - http://www.meetup.com/openstack-argentina/events/232420473/ * Thursday July 28 in Philadelphia, PA, US: OpenStack 6th Anniversary/ Using OpenStack Cinder to manage Docker storage - http://www.meetup.com/Philly-OpenStack-Meetup-Group/events/231931036/ * Thursday July 28 in Reston, VA, US: OpenStack's 6th Birthday Celebration - http://www.meetup.com/OpenStack-Nova/events/231886422/ * Thursday July 28 in Durham, NC, US: Triangle Kubernetes meetup session #4 - http://www.meetup.com/Triangle-Kubernetes-Meetup/events/231104568/ * Thursday July 28 in Fort Collins, CO, US: OpenStack 6th Birthday and ... - http://www.meetup.com/OpenStack-Colorado/events/231949941/ * Thursday July 28 in Pasadena, CA, US: Datera/OpenStack 6th Birthday Gala. The July 2016 OpenStack L.A. Meetup - http://www.meetup.com/OpenStack-LA/events/231967524/ * Thursday July 28 in Herriman, UT, US: OpenStack at Overstock - http://www.meetup.com/openstack-utah/events/232270938/ * Saturday July 30 in Ha Noi, VN: OpenStack 6th Birthday Meetup #11 - http://www.meetup.com/VietOpenStack/events/231902183/ -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From honza at redhat.com Mon Jul 25 23:04:40 2016 From: honza at redhat.com (Honza Pokorny) Date: Mon, 25 Jul 2016 20:04:40 -0300 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> Message-ID: <20160725230440.wxizfp5bjscklmyd@localhost.localdomain> On 2016-07-25 16:23, Ha?kel wrote: > 2016-07-25 16:17 GMT+02:00 Honza Pokorny : > > On 2016-07-23 04:26, Ha?kel wrote: > >> @Jason: As I said during the mentioned call, we have nodejs 0.10.36 > >> build in CBS -I'm actually the one who built it- and there's no > >> problem in importing a LTS release (4.x or 6.x) > >> Mattias is of the opinion we should stick to 4.x which is the current LTS. > >> http://cbs.centos.org/koji/buildinfo?buildID=8185 > >> > >> I'm taking the action of importing a newer nodejs build in our > >> repository. Jakub and I will be providing support in > >> packaging/reviewing tripleo-ui. > > > > I'm confident we can make this happen early this week, thanks to Haikel > > and Jakup. As Jason said, if we can get some eyes on the infra patch > > and the packaging patch that would certainly speed things up. > > > > Haikel, if you could have a quick look at the spec file for tripleo-ui, > > I think that would make a nice starting point. Or, would you rather I > > submitted a format request for review to RDO at this point? > > > > Both works for me. RDO review request: https://bugzilla.redhat.com/show_bug.cgi?id=1359950 Gerrit patch: https://review.openstack.org/#/c/344932/ > > >> Considering we'll be having many missing people due to summer > >> vacations, I associated Jakub to avoid being the SPOF in that process. > >> > >> As we want to have this sorted out before M3, I'd like to have status > >> during our weekly RDO meetings to follow up progress and solve > >> impediments. > >> > >> Regards, > >> H. From tsarah8139 at gmail.com Tue Jul 26 09:09:39 2016 From: tsarah8139 at gmail.com (Takeshi Kuramochi) Date: Tue, 26 Jul 2016 18:09:39 +0900 Subject: [rdo-list] Error Packstack (Error: Could not prefetch keystone_role provider) on Mitaka Message-ID: When I run packstack below, I saw "Error: Could not prefetch keystone_role provider". # packstack --answer-file=./packstack_answer2.txt : : : Applying 192.168.175.244_keystone.pp Applying 192.168.175.244_glance.pp Applying 192.168.175.244_cinder.pp 192.168.175.244_keystone.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 192.168.175.244_keystone.pp Error: Could not prefetch keystone_role provider 'openstack': Execution of '/usr/bin/openstack role list --quiet --format csv' returned 1: Service Unavailable (HTTP 503) You will find full trace in log /var/tmp/packstack/20160726-172409-w2NyIb/manifests/192.168.175.244_keystone.pp.log Please check log file /var/tmp/packstack/20160726-172409-w2NyIb/openstack-setup.log for more information Additional information: * Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components. * File /root/keystonerc_admin has been created on OpenStack client host 192.168.175.244. To use the command line tools you need to source the file. * To access the OpenStack Dashboard browse to http://192.168.175.244/dashboard . Please, find your login credentials stored in the keystonerc_admin in your home directory. Has anyone had this problem? Best Regards Takeshi.K, < /var/tmp/packstack/latest/openstack-setup.log > tar --dereference -cpzf - aodh apache ceilometer certmonger cinder concat firewall glance gnocchi heat horizon inifile ironic keystone manila memcached mongodb mysql neutron nova nssdb openstack openstacklib packstack rabbitmq redis remote rsync sahara ssh stdlib swift sysctl tempest trove vcsrepo vlan vswitch xinetd | ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root at 192.168.175.244 tar -C /var/tmp/packstack/b7ad7e358e984de9ac2e00 a911deee4d/modules -xpzf - 2016-07-26 17:31:43::ERROR::run_setup::1018::root:: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", line 1013, in main _main(options, confFile, logFile) File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", line 660, in _main runSequences() File "/usr/lib/python2.7/site-packages/packstack/installer/run_setup.py", line 627, in runSequences controller.runAllSequences() File "/usr/lib/python2.7/site-packages/packstack/installer/setup_controller.py", line 81, in runAllSequences sequence.run(config=self.CONF, messages=self.MESSAGES) File "/usr/lib/python2.7/site-packages/packstack/installer/core/sequences.py", line 109, in run step.run(config=config, messages=messages) File "/usr/lib/python2.7/site-packages/packstack/installer/core/sequences.py", line 50, in run self.function(config, messages) File "/usr/lib/python2.7/site-packages/packstack/plugins/puppet_950.py", line 209, in apply_puppet_manifest wait_for_puppet(currently_running, messages) File "/usr/lib/python2.7/site-packages/packstack/plugins/puppet_950.py", line 123, in wait_for_puppet validate_logfile(log) File "/usr/lib/python2.7/site-packages/packstack/modules/puppet.py", line 107, in validate_logfile raise PuppetError(message) PuppetError: Error appeared during Puppet run: 192.168.175.244_keystone.pp Error: Could not prefetch keystone_role provider 'openstack': Execution of '/usr/bin/openstack role list --quiet --format csv' returned 1: Service Unavailable (HTTP 503) You will find full trace in log /var/tmp/packstack/20160726-172409-w2NyIb/manifests/192.168.175.244_keystone.pp.log 2016-07-26 17:31:43::INFO::shell::94::root:: [192.168.175.244] Executing script: rm -rf /var/tmp/packstack/b7ad7e358e984de9ac2e00a911deee4d # rpm -aq|grep openstack openstack-packstack-puppet-8.0.0-1.el7.noarch openstack-selinux-0.7.2-1.el7.noarch centos-release-openstack-mitaka-1-3.el7.noarch python2-openstacksdk-0.8.3-1.el7.noarch python-openstackclient-2.2.0-1.el7.noarch openstack-cinder-8.0.0-1.el7.noarch openstack-packstack-8.0.0-1.el7.noarch openstack-puppet-modules-8.0.4-1.el7.noarch openstack-keystone-9.0.2-1.el7.noarch openstack-utils-2015.2-1.el7.noarch I attached an answer-file. -------------- next part -------------- A non-text attachment was scrubbed... Name: packstack_answer2.txt.gz Type: application/x-gzip Size: 13915 bytes Desc: not available URL: From markmc at redhat.com Tue Jul 26 10:33:47 2016 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 26 Jul 2016 12:33:47 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: <20160725230440.wxizfp5bjscklmyd@localhost.localdomain> References: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> <20160725230440.wxizfp5bjscklmyd@localhost.localdomain> Message-ID: On Tue, Jul 26, 2016 at 1:04 AM, Honza Pokorny wrote: > On 2016-07-25 16:23, Ha?kel wrote: >> 2016-07-25 16:17 GMT+02:00 Honza Pokorny : >> > On 2016-07-23 04:26, Ha?kel wrote: >> >> @Jason: As I said during the mentioned call, we have nodejs 0.10.36 >> >> build in CBS -I'm actually the one who built it- and there's no >> >> problem in importing a LTS release (4.x or 6.x) >> >> Mattias is of the opinion we should stick to 4.x which is the current LTS. >> >> http://cbs.centos.org/koji/buildinfo?buildID=8185 >> >> >> >> I'm taking the action of importing a newer nodejs build in our >> >> repository. Jakub and I will be providing support in >> >> packaging/reviewing tripleo-ui. >> > >> > I'm confident we can make this happen early this week, thanks to Haikel >> > and Jakup. As Jason said, if we can get some eyes on the infra patch >> > and the packaging patch that would certainly speed things up. >> > >> > Haikel, if you could have a quick look at the spec file for tripleo-ui, >> > I think that would make a nice starting point. Or, would you rather I >> > submitted a format request for review to RDO at this point? >> > >> >> Both works for me. > > RDO review request: https://bugzilla.redhat.com/show_bug.cgi?id=1359950 > > Gerrit patch: https://review.openstack.org/#/c/344932/ Thanks, Honza. Just looking through the node_modules tarball very briefly, I think it's going to take quite a bit of review to satisfy ourselves that everything is really built from source in the build system, and that we will actually be able to %patch the source for anything shipped in the final RPM or anything used to build an artifact in the final RPM. For a start, I suggest deleting phantomjs-prebuilt and see what happens. It contains an ELF executable. Another minor observation - the tarball published by upstream should have a tripleo-ui-$version base directory. Mark. >> >> Considering we'll be having many missing people due to summer >> >> vacations, I associated Jakub to avoid being the SPOF in that process. >> >> >> >> As we want to have this sorted out before M3, I'd like to have status >> >> during our weekly RDO meetings to follow up progress and solve >> >> impediments. >> >> >> >> Regards, >> >> H. > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Tue Jul 26 12:52:47 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 26 Jul 2016 14:52:47 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> <20160725230440.wxizfp5bjscklmyd@localhost.localdomain> Message-ID: 2016-07-26 12:33 GMT+02:00 Mark McLoughlin : > On Tue, Jul 26, 2016 at 1:04 AM, Honza Pokorny wrote: >> On 2016-07-25 16:23, Ha?kel wrote: >>> 2016-07-25 16:17 GMT+02:00 Honza Pokorny : >>> > On 2016-07-23 04:26, Ha?kel wrote: >>> >> @Jason: As I said during the mentioned call, we have nodejs 0.10.36 >>> >> build in CBS -I'm actually the one who built it- and there's no >>> >> problem in importing a LTS release (4.x or 6.x) >>> >> Mattias is of the opinion we should stick to 4.x which is the current LTS. >>> >> http://cbs.centos.org/koji/buildinfo?buildID=8185 >>> >> >>> >> I'm taking the action of importing a newer nodejs build in our >>> >> repository. Jakub and I will be providing support in >>> >> packaging/reviewing tripleo-ui. >>> > >>> > I'm confident we can make this happen early this week, thanks to Haikel >>> > and Jakup. As Jason said, if we can get some eyes on the infra patch >>> > and the packaging patch that would certainly speed things up. >>> > >>> > Haikel, if you could have a quick look at the spec file for tripleo-ui, >>> > I think that would make a nice starting point. Or, would you rather I >>> > submitted a format request for review to RDO at this point? >>> > >>> >>> Both works for me. >> >> RDO review request: https://bugzilla.redhat.com/show_bug.cgi?id=1359950 >> >> Gerrit patch: https://review.openstack.org/#/c/344932/ > > Thanks, Honza. > > Just looking through the node_modules tarball very briefly, I think > it's going to take quite a bit of review to satisfy ourselves that > everything is really built from source in the build system, and that > we will actually be able to %patch the source for anything shipped in > the final RPM or anything used to build an artifact in the final RPM. > > For a start, I suggest deleting phantomjs-prebuilt and see what > happens. It contains an ELF executable. > This is the only ELF binary, and it's only required for running tests, so we can drop it. Another good reason is that rebuilding recent webkit on EL7 would take some time. node_modules.tar.gz should be in a separate tarballs, in order for us to include tripleo-ui in DLRN. Many libs are generated from coffeescript (800 exactly), some libs are duplicated (e.g lodash, source-map, express, base64 etc.) but fighting duplication will be a never-ending task with node apps. First licensing checks: * React.js: should be ok but patents grant is still debated among legal * known licenses: MIT, BSD 2 and 3 clauses, ISC, WTFPL 2.0, ASL 2.0, MPL 2.0 (w/ BSD 3 clauses which saves the hassle to figure out compatibility w/ GPL) * unknown licenses: mostly generated files from coffeescript. Regards, H. > Another minor observation - the tarball published by upstream should > have a tripleo-ui-$version base directory. > > Mark. > > > > >>> >> Considering we'll be having many missing people due to summer >>> >> vacations, I associated Jakub to avoid being the SPOF in that process. >>> >> >>> >> As we want to have this sorted out before M3, I'd like to have status >>> >> during our weekly RDO meetings to follow up progress and solve >>> >> impediments. >>> >> >>> >> Regards, >>> >> H. >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From dms at redhat.com Tue Jul 26 12:57:05 2016 From: dms at redhat.com (David Moreau Simard) Date: Tue, 26 Jul 2016 08:57:05 -0400 Subject: [rdo-list] Overlap between dashboards/monitoring and future status aggregation tool Message-ID: Hello, We've discussed several times that we need a public place to centralize relevant status information for the community in an user-friendly way. The status information we have right now are available either from the dashboard [1] or the monitoring [2]. Ultimately, the dashboard is monitoring things that is either already monitored by our Sensu instance or could be. I'm working on status.rdoproject.org [3] right now (not yet fed with live data). The software for it, Cachet [4], is an open source version of statuspage.io. It's meant to be driven automatically through it's API but there is also an administrative interface to manually create/edit/resolve events if need be. So, for example, if Sensu detects a problem, it coud create an event on status.rdoproject -- and resolve it when it's resolved. The existing scripts for dashboards could be adapted to work with status.rdoproject. We could even have jenkins jobs post updates on status.rdoproject if we wanted. It also supports displaying basic metrics, like shown in the demo [5]. There will clearly be an overlap between status.rdo and dashboards.rdo. Are we okay with this ? I'm not looking to create yet another standard to rule them all (cue XKCD) but to use the right tool for the right job. Thoughts ? [1]: https://dashboards.rdoproject.org/rdo-dev [2]: http://uchiwa.monitoring.rdoproject.org/ (creds: rdo/rdo) [3]: http://status.rdoproject.org/ [4]: https://cachethq.io/ [5]: https://demo.cachethq.io/ David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] From dms at redhat.com Tue Jul 26 13:06:36 2016 From: dms at redhat.com (David Moreau Simard) Date: Tue, 26 Jul 2016 09:06:36 -0400 Subject: [rdo-list] Overlap between dashboards/monitoring and future status aggregation tool In-Reply-To: References: Message-ID: Worth mentioning that both uchiwa.monitoring.rdoproject.org and status.rdoproject.org are not HTTPS (yet). Because of this, if you've ever visited https://trunk.rdoproject.org, trunk.rdoproject.org provides a HSTS [1] configuration (persistent SSL configuration for the rdoproject.org domain), your browser will redirect status.rdo and uchiwa.monitoring.rdo to https and this will not work. You can either clear your HSTS configuration for rdoproject.org in your browser or use another browser to look at the interfaces for the time being. I've opened an issue to make the trunk.rdoproject.org HSTS config scoped correctly [2]. [1]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [2]: https://github.com/rdo-infra/puppet-dlrn/issues/40 David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Tue, Jul 26, 2016 at 8:57 AM, David Moreau Simard wrote: > Hello, > > We've discussed several times that we need a public place to > centralize relevant status information for the community in an > user-friendly way. > > The status information we have right now are available either from the > dashboard [1] or the monitoring [2]. > Ultimately, the dashboard is monitoring things that is either already > monitored by our Sensu instance or could be. > > I'm working on status.rdoproject.org [3] right now (not yet fed with live data). > The software for it, Cachet [4], is an open source version of statuspage.io. > It's meant to be driven automatically through it's API but there is > also an administrative interface to manually create/edit/resolve > events if need be. > > So, for example, if Sensu detects a problem, it coud create an event > on status.rdoproject -- and resolve it when it's resolved. > The existing scripts for dashboards could be adapted to work with > status.rdoproject. > We could even have jenkins jobs post updates on status.rdoproject if we wanted. > It also supports displaying basic metrics, like shown in the demo [5]. > > There will clearly be an overlap between status.rdo and > dashboards.rdo. Are we okay with this ? > I'm not looking to create yet another standard to rule them all (cue > XKCD) but to use the right tool for the right job. > > Thoughts ? > > [1]: https://dashboards.rdoproject.org/rdo-dev > [2]: http://uchiwa.monitoring.rdoproject.org/ (creds: rdo/rdo) > [3]: http://status.rdoproject.org/ > [4]: https://cachethq.io/ > [5]: https://demo.cachethq.io/ > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] From hbrock at redhat.com Tue Jul 26 13:09:10 2016 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 26 Jul 2016 15:09:10 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> <20160725230440.wxizfp5bjscklmyd@localhost.localdomain> Message-ID: On Tue, Jul 26, 2016 at 2:52 PM, Ha?kel wrote: > 2016-07-26 12:33 GMT+02:00 Mark McLoughlin : >> On Tue, Jul 26, 2016 at 1:04 AM, Honza Pokorny wrote: >>> On 2016-07-25 16:23, Ha?kel wrote: >>>> 2016-07-25 16:17 GMT+02:00 Honza Pokorny : >>>> > On 2016-07-23 04:26, Ha?kel wrote: >>>> >> @Jason: As I said during the mentioned call, we have nodejs 0.10.36 >>>> >> build in CBS -I'm actually the one who built it- and there's no >>>> >> problem in importing a LTS release (4.x or 6.x) >>>> >> Mattias is of the opinion we should stick to 4.x which is the current LTS. >>>> >> http://cbs.centos.org/koji/buildinfo?buildID=8185 >>>> >> >>>> >> I'm taking the action of importing a newer nodejs build in our >>>> >> repository. Jakub and I will be providing support in >>>> >> packaging/reviewing tripleo-ui. >>>> > >>>> > I'm confident we can make this happen early this week, thanks to Haikel >>>> > and Jakup. As Jason said, if we can get some eyes on the infra patch >>>> > and the packaging patch that would certainly speed things up. >>>> > >>>> > Haikel, if you could have a quick look at the spec file for tripleo-ui, >>>> > I think that would make a nice starting point. Or, would you rather I >>>> > submitted a format request for review to RDO at this point? >>>> > >>>> >>>> Both works for me. >>> >>> RDO review request: https://bugzilla.redhat.com/show_bug.cgi?id=1359950 >>> >>> Gerrit patch: https://review.openstack.org/#/c/344932/ >> >> Thanks, Honza. >> >> Just looking through the node_modules tarball very briefly, I think >> it's going to take quite a bit of review to satisfy ourselves that >> everything is really built from source in the build system, and that >> we will actually be able to %patch the source for anything shipped in >> the final RPM or anything used to build an artifact in the final RPM. >> >> For a start, I suggest deleting phantomjs-prebuilt and see what >> happens. It contains an ELF executable. >> Thanks for your help on this, Haikel. > This is the only ELF binary, and it's only required for running tests, > so we can drop it. > Another good reason is that rebuilding recent webkit on EL7 would take > some time. Very good. > node_modules.tar.gz should be in a separate tarballs, in order for us > to include tripleo-ui in DLRN. > > > Many libs are generated from coffeescript (800 exactly), some libs are > duplicated (e.g lodash, source-map, express, base64 etc.) but fighting > duplication will be a never-ending task with node apps. Yay... > First licensing checks: > * React.js: should be ok but patents grant is still debated among legal How big a problem is this? Do I need to panic and call rfontana? > * known licenses: MIT, BSD 2 and 3 clauses, ISC, WTFPL 2.0, ASL 2.0, > MPL 2.0 (w/ BSD 3 clauses which saves the hassle to figure out > compatibility w/ GPL) Good, I think... > * unknown licenses: mostly generated files from coffeescript. Is this safe, then? Thanks, --H > > Regards, > H. > >> Another minor observation - the tarball published by upstream should >> have a tripleo-ui-$version base directory. >> >> Mark. >> >> >> >> >>>> >> Considering we'll be having many missing people due to summer >>>> >> vacations, I associated Jakub to avoid being the SPOF in that process. >>>> >> >>>> >> As we want to have this sorted out before M3, I'd like to have status >>>> >> during our weekly RDO meetings to follow up progress and solve >>>> >> impediments. >>>> >> >>>> >> Regards, >>>> >> H. >>> >>> _______________________________________________ >>> rdo-list mailing list >>> rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -- , , | Hugh Brock, hbrock at redhat.com )-_"""_-( | Director of Engineering, OpenStack Management ./ o\ /o \. | TripleO: Install, configure, and scale OpenStack. . \__/ \__/ . | http://rdoproject.org, http://tripleo.org ... V ... | ... - - - ... | "I know that you believe you understand what you . - - . | think I said, but I'm not sure you realize that what `-.....-? | you heard is not what I meant." --Robert McCloskey "TripleOwl" From hguemar at fedoraproject.org Tue Jul 26 14:15:58 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 26 Jul 2016 16:15:58 +0200 Subject: [rdo-list] TripleO UI Packaging Strategy In-Reply-To: References: <20160721142329.7hhu3hhcynxryw5k@localhost.localdomain> <20160722140248.iwcumqc74iaifvji@localhost.localdomain> <88759090-5422-cfab-7626-166adf959b4a@redhat.com> <20160725141715.vp3j6mo7ker57mln@localhost.localdomain> <20160725230440.wxizfp5bjscklmyd@localhost.localdomain> Message-ID: 2016-07-26 15:09 GMT+02:00 Hugh Brock : > On Tue, Jul 26, 2016 at 2:52 PM, Ha?kel wrote: >> 2016-07-26 12:33 GMT+02:00 Mark McLoughlin : >>> On Tue, Jul 26, 2016 at 1:04 AM, Honza Pokorny wrote: >>>> On 2016-07-25 16:23, Ha?kel wrote: >>>>> 2016-07-25 16:17 GMT+02:00 Honza Pokorny : >>>>> > On 2016-07-23 04:26, Ha?kel wrote: >>>>> >> @Jason: As I said during the mentioned call, we have nodejs 0.10.36 >>>>> >> build in CBS -I'm actually the one who built it- and there's no >>>>> >> problem in importing a LTS release (4.x or 6.x) >>>>> >> Mattias is of the opinion we should stick to 4.x which is the current LTS. >>>>> >> http://cbs.centos.org/koji/buildinfo?buildID=8185 >>>>> >> >>>>> >> I'm taking the action of importing a newer nodejs build in our >>>>> >> repository. Jakub and I will be providing support in >>>>> >> packaging/reviewing tripleo-ui. >>>>> > >>>>> > I'm confident we can make this happen early this week, thanks to Haikel >>>>> > and Jakup. As Jason said, if we can get some eyes on the infra patch >>>>> > and the packaging patch that would certainly speed things up. >>>>> > >>>>> > Haikel, if you could have a quick look at the spec file for tripleo-ui, >>>>> > I think that would make a nice starting point. Or, would you rather I >>>>> > submitted a format request for review to RDO at this point? >>>>> > >>>>> >>>>> Both works for me. >>>> >>>> RDO review request: https://bugzilla.redhat.com/show_bug.cgi?id=1359950 >>>> >>>> Gerrit patch: https://review.openstack.org/#/c/344932/ >>> >>> Thanks, Honza. >>> >>> Just looking through the node_modules tarball very briefly, I think >>> it's going to take quite a bit of review to satisfy ourselves that >>> everything is really built from source in the build system, and that >>> we will actually be able to %patch the source for anything shipped in >>> the final RPM or anything used to build an artifact in the final RPM. >>> >>> For a start, I suggest deleting phantomjs-prebuilt and see what >>> happens. It contains an ELF executable. >>> > > Thanks for your help on this, Haikel. > >> This is the only ELF binary, and it's only required for running tests, >> so we can drop it. >> Another good reason is that rebuilding recent webkit on EL7 would take >> some time. > > Very good. > >> node_modules.tar.gz should be in a separate tarballs, in order for us >> to include tripleo-ui in DLRN. >> >> >> Many libs are generated from coffeescript (800 exactly), some libs are >> duplicated (e.g lodash, source-map, express, base64 etc.) but fighting >> duplication will be a never-ending task with node apps. > > Yay... > >> First licensing checks: >> * React.js: should be ok but patents grant is still debated among legal > > How big a problem is this? Do I need to panic and call rfontana? > Well, according to him safe to ship, I already followed up to dbecker and the other folks. It boils down to some techn >> * known licenses: MIT, BSD 2 and 3 clauses, ISC, WTFPL 2.0, ASL 2.0, >> MPL 2.0 (w/ BSD 3 clauses which saves the hassle to figure out >> compatibility w/ GPL) > > Good, I think... > >> * unknown licenses: mostly generated files from coffeescript. > > Is this safe, then? > I think so, but looking at these more carefully, I need to check both toolchain and original sources. H. > Thanks, > --H > >> >> Regards, >> H. >> >>> Another minor observation - the tarball published by upstream should >>> have a tripleo-ui-$version base directory. >>> >>> Mark. >>> >>> >>> >>> >>>>> >> Considering we'll be having many missing people due to summer >>>>> >> vacations, I associated Jakub to avoid being the SPOF in that process. >>>>> >> >>>>> >> As we want to have this sorted out before M3, I'd like to have status >>>>> >> during our weekly RDO meetings to follow up progress and solve >>>>> >> impediments. >>>>> >> >>>>> >> Regards, >>>>> >> H. >>>> >>>> _______________________________________________ >>>> rdo-list mailing list >>>> rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> _______________________________________________ >> rdo-list mailing list >> rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > -- > , , | Hugh Brock, hbrock at redhat.com > )-_"""_-( | Director of Engineering, OpenStack Management > ./ o\ /o \. | TripleO: Install, configure, and scale OpenStack. > . \__/ \__/ . | http://rdoproject.org, http://tripleo.org > ... V ... | > ... - - - ... | "I know that you believe you understand what you > . - - . | think I said, but I'm not sure you realize that what > `-.....-? | you heard is not what I meant." --Robert McCloskey > "TripleOwl" From whayutin at redhat.com Tue Jul 26 16:52:30 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 26 Jul 2016 12:52:30 -0400 Subject: [rdo-list] rdo infra team meeting Message-ID: FYI.. https://bluejeans.com/s/a2_o/ https://review.rdoproject.org/etherpad/p/rdo-infra-scrum Please add items to the agenda for next week if there is anything you would like to cover. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at redhat.com Wed Jul 27 08:32:34 2016 From: apevec at redhat.com (Alan Pevec) Date: Wed, 27 Jul 2016 10:32:34 +0200 Subject: [rdo-list] Error Packstack (Error: Could not prefetch keystone_role provider) on Mitaka In-Reply-To: References: Message-ID: Hi, > PuppetError: Error appeared during Puppet run: 192.168.175.244_keystone.pp > Error: Could not prefetch keystone_role provider 'openstack': > Execution of '/usr/bin/openstack role list --quiet --format csv' > returned 1: Service Unavailable (HTTP 503) > You will find full trace in log > /var/tmp/packstack/20160726-172409-w2NyIb/manifests/192.168.175.244_keystone.pp.log are there any more clues in this log ^ also in httpd/keystone logs? Cheers, Alan From whayutin at redhat.com Wed Jul 27 12:51:22 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Wed, 27 Jul 2016 08:51:22 -0400 Subject: [rdo-list] Using tripleo-quickstart to debug failures in a deployment Message-ID: Greetings, I thought it might be worth starting a discussion regarding including debug steps as part of oooq. To define what I mean by a debug step I'm referring to steps like [1], when something fails present more information about the failure in the logs or console. There are three primary use cases for oooq atm. Use Cases: 1. new user deploying TripleO 2. CI 3. Developer debug/test For use cases 2,3 extra debug information is very handy. My own experience with debugging 10-30 jobs a day extra debug information in the logs can save a lot of time and prevent a misdiagnosis of a failed deployment. For use case #1, I think we want to be careful and protect the simplicity of the jinja templated bash scripts. Basically presenting the user with a clean and simple workflow. I do think if a new user does unfortunately hit an error, they might be completely unaware of how to debug the issue. The implementation here is up to the technical guys of course, but my thought was to only run debugging tasks on failed tasks. So I would classify additional debug steps as *critical* for #2, and a really nice to have for #1, and #3. I hoping that the group finds debugging steps as useful as I do. I am also hoping that we can review, add the following reviews [2-3]. I hope that other people have additional debug steps to add, and we can start moving debug tribal knowledge into the steps in tripleo-quickstart. Thanks! [1] https://github.com/openstack/tripleo-quickstart/blob/master/roles/tripleo/overcloud/templates/overcloud-deploy.sh.j2#L56 [2] https://review.openstack.org/#/c/345559/ [3] https://review.openstack.org/#/c/346889/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goneri at redhat.com Wed Jul 27 13:25:01 2016 From: goneri at redhat.com (=?utf-8?Q?Gon=C3=A9ri?= Le Bouder) Date: Wed, 27 Jul 2016 15:25:01 +0200 Subject: [rdo-list] Using tripleo-quickstart to debug failures in a deployment In-Reply-To: References: Message-ID: <8737mvtdqq.fsf@redhat.com> Hi Wes and all, We face the same problem with Distributed CI[1]. The heat logs are not enough more of the time. So far we run a little script to show up the last os-collect-config error. I would love to see a shared repository with this kind of scripts. Such effort could also be interesting for the ops/consulting teams. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/100087.html [2] https://github.com/goneri/tripleo-stack-dump/blob/master/list_nodes_status Regards, -- Gon?ri Le Bouder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From rbowen at redhat.com Wed Jul 27 15:15:53 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 27 Jul 2016 11:15:53 -0400 Subject: [rdo-list] Newton 2 test day re-run, July 28, 29th Message-ID: <596fbaf0-2dca-fd50-c751-1b7e6ff82bfb@redhat.com> Due to the lack of Newton 2 packages for last week's test day, we'll be re-running the Newton 2 test day this Thursday and Friday, July 28th and 29th. Details are here: https://www.rdoproject.org/testday/newton/milestone2/ (I'll be fixing the dates on that as soon as I get this sent.) We'll be testing the Newton 2 packages that have passed CI. Please consider taking a few hours to join us in testing, to help make Newton the best release of RDO yet. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From chkumar246 at gmail.com Wed Jul 27 16:06:49 2016 From: chkumar246 at gmail.com (Chandan kumar) Date: Wed, 27 Jul 2016 21:36:49 +0530 Subject: [rdo-list] [Minute] RDO meeting (2016-07-27) Minutes Message-ID: ============================== #rdo: RDO meeting - 2016-07-27 ============================== Meeting started by chandankumar at 15:01:06 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-07-27/rdo_meeting_-_2016-07-27.2016-07-27-15.01.log.html . Meeting summary --------------- * Roll Call (chandankumar, 15:01:18) * Newton2 testday re-run on July 28-29 ? (chandankumar, 15:03:01) * AGREED: test days will occur this week July 28th and 29th (dmsimard, 15:11:31) * ACTION: rbowen to getting word out for Newton2 testday re-run on 28-29 July (chandankumar, 15:12:27) * Package Review Status (chandankumar, 15:12:55) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1329341 (chandankumar, 15:13:13) * tripleo-ui is moving forward (number80, 15:13:33) * ACTION: apevec to approve python-horizon-tests-tempest package (chandankumar, 15:28:10) * ACTION: apevec to followup on tripleo-ui packaging thread on rdo-list (apevec, 15:28:38) * ACTION: apevec to revisit giving exception for JARs in sahara-tests (apevec, 15:30:54) * pin some versions according to upper-constraints.txt (chandankumar, 15:32:32) * LINK: https://trello.com/c/guK9Ag12/157-dlrn-builds-must-reflect-what-is-tested-upstream (chandankumar, 15:32:47) * LINK: https://ci.centos.org/view/rdo/view/tripleo-periodic/job/tripleo-quickstart-upgrade-minor-mitaka-to-mitaka/ (trown, 15:40:32) * LINK: https://ci.centos.org/view/rdo/view/tripleo-periodic/job/tripleo-quickstart-upgrade-minor-master-to-master/ (trown, 15:40:54) * Status of Automate stable packages releases (chandankumar, 15:45:33) * LINK: https://www.redhat.com/archives/rdo-list/2016-July/msg00140.html (chandankumar, 15:46:54) * LINK: https://review.rdoproject.org/r/#/c/1727/ (number80, 15:46:55) * LINK: https://review.rdoproject.org/r/#/c/1732/ (fbo, 15:47:19) * LINK: https://trello.com/c/URAtrhLU/86-automate-stable-packages-releases (flepied, 15:47:51) * overlap between dashboards.rdo and future status.rdo (chandankumar, 15:50:22) * LINK: https://www.redhat.com/archives/rdo-list/2016-July/msg00140.html (chandankumar, 15:51:28) * RFE provide stable DLRN interface for TripleO CI (chandankumar, 15:54:44) * chair for next meeting (chandankumar, 16:00:28) * ACTION: jruzicka to chair for next meeting (chandankumar, 16:00:50) Meeting ended at 16:01:18 UTC. Action Items ------------ * rbowen to getting word out for Newton2 testday re-run on 28-29 July * apevec to approve python-horizon-tests-tempest package * apevec to followup on tripleo-ui packaging thread on rdo-list * apevec to revisit giving exception for JARs in sahara-tests * jruzicka to chair for next meeting Action Items, by person ----------------------- * apevec * apevec to approve python-horizon-tests-tempest package * apevec to followup on tripleo-ui packaging thread on rdo-list * apevec to revisit giving exception for JARs in sahara-tests * * rbowen to getting word out for Newton2 testday re-run on 28-29 July * apevec to revisit giving exception for JARs in sahara-tests * jruzicka to chair for next meeting * jruzicka * jruzicka to chair for next meeting * meeting * jruzicka to chair for next meeting * next * jruzicka to chair for next meeting * rbowen * rbowen to getting word out for Newton2 testday re-run on 28-29 July * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * apevec (98) * chandankumar (56) * dmsimard (55) * number80 (54) * trown (22) * rbowen (15) * flepied (13) * zodbot (12) * adarazs (10) * weshay (9) * jruzicka (8) * openstack (3) * jschlueter (3) * Duck (3) * social (3) * fbo (2) * coolsvap (2) * jjoyce (1) * mengxd (1) * imcsk8 (1) * pradk (1) * richm (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot Thanks, Chandan Kumar From bderzhavets at hotmail.com Wed Jul 27 21:19:25 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Wed, 27 Jul 2016 21:19:25 +0000 Subject: [rdo-list] TripleO QuickStart vs official Mitaka TripleO HA install via instack-virt-setup Message-ID: If question posted by you on rdo mailing list in march 2016 still makes sense for you, see https://www.redhat.com/archives/rdo-list/2016-March/msg00171.html On 03/28/2016 Arash Kaffamanesh wrote: By the way, I'd love to see and help to have an complete installation guide for TripleO powered by RDO on the RDO site (the instack virt setup without quickstart on http://docs.openstack.org/ doesn't work and this might be changed through the RDO community power :-)). You may take a look at http://dbaxps.blogspot.ru/2016/07/tripleo-quickstart-vs-official-mitaka.html Issues are fixed and explained in details . RDO Mitaka Stable deployed to overcloud along with "Network Isolation" . In case "Network Isolation" is not required then official instruction http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html#get-image should work as is. Significant input for Mitaka overcloud deployment has been done here :- https://review.openstack.org/#/c/329438/ Thank you. Boris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhvanan at gmail.com Thu Jul 28 10:58:04 2016 From: dhvanan at gmail.com (Dhvanan Shah) Date: Thu, 28 Jul 2016 16:28:04 +0530 Subject: [rdo-list] Fwd: Installation Error : keystone_role provider 'openstack': Could not authenticate In-Reply-To: References: Message-ID: Hi, I'm installing OpenStack using packstack, and during the installation I'm facing an issue, keystone is not installing to completion. It gives the following error: ERROR : Error appeared during Puppet run: 10.16.6.33_keystone.pp > Error: Could not prefetch keystone_role provider 'openstack': Could not > authenticate It also says that the file /root/keystonerc_admin has been created, but there is no such file present in that location. Could someone guide me on this, as I did not find this issue discussed on any forum. Thanks, Dhvanan Shah -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Thu Jul 28 14:59:05 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 28 Jul 2016 10:59:05 -0400 Subject: [rdo-list] Using tripleo-quickstart to debug failures in a deployment In-Reply-To: <8737mvtdqq.fsf@redhat.com> References: <8737mvtdqq.fsf@redhat.com> Message-ID: On Wed, Jul 27, 2016 at 9:25 AM, Gon?ri Le Bouder wrote: > Hi Wes and all, > > We face the same problem with Distributed CI[1]. The heat logs are not > enough more of the time. So far we run a little script to show up the > last os-collect-config error. > > I would love to see a shared repository with this kind of scripts. Such > effort could also be interesting for the ops/consulting teams. > Agree.. I'll post something shortly > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-July/100087.html > [2] > https://github.com/goneri/tripleo-stack-dump/blob/master/list_nodes_status > > Regards, > -- > Gon?ri Le Bouder > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbrlperal at gmail.com Sun Jul 31 09:10:25 2016 From: gbrlperal at gmail.com (Gabriel Peral) Date: Sun, 31 Jul 2016 11:10:25 +0200 Subject: [rdo-list] Overcloud Deployment failsm not br-int Message-ID: Hi everyone! I've been trying to deploy OpenStack using TripleO for 2 weeks and I am get stucked in the same step. But let's see first my environment, 3 baremetal nodes, one will be a compute node, the other two will be compute nodes. In each pyhiscal node I have two pyhiscal NICs, one for the PXE+DHCP provisioning, and the other pyhsical NIC connected to a pyhiscal switch which has the rest of the vlans for the deployment (api, storage, tenant, exeternal, etc). I am deploying OpeStack Kilo version. The first step of the installation was good, the undercloud and the introspection was done in the right way, but the problem cames when I try to deploy the overcloud, I set up the network-environment.yaml template in order to set the vlans to the networks, and the compute.yaml and controller.yaml templates to set the right NICs to the right networks. And then I launch the deploy command like this (vlan mode) : $ openstack overcloud deploy --templates ~/templates/my-overcloud/ -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml -e ~/templates/my-overcloud/environments/network-isolation.yaml --control-scale 1 --compute-scale 2 --control-flavor control --compute-flavor compute --ntp-server 10.20.10.3 --neutron-network-type vlan --neutron-disable-tunneling --neutron-bridge-mappings datacentre:br-ex --neutron-network-vlan-ranges datacentre:30:100 --timeout 60 --verbose --log-file overcloud_vlan.log And all seems go well untill it fails due to timeout, the heat resource-list --nested-depth 5 overcloud | grep FAILED Show that something is wrong in the NetworkDeploy, and when I log into the controller node, if I type sudo ovs-vsctl list-br it only shows me the br-ex bridge, so it wasn't able to create the br-int, and I think that's the reason because the deployment has been failed, when I've tryied to deploy more i log into the controller node, and check the sudo tail -f /var/log/messages and this is the only message that appears: Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.337 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.624 4606 WARNING os-collect-config [-] Source [request] Unavailable. Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.625 4606 WARNING os_collect_config.local [-] /var/lib/os-collect-config/local-data not found. Skipping Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.625 4606 WARNING os_collect_config.local [-] No local metadata found (['/var/lib/os-collect-config/local-data']) Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.615 4606 WARNING os_collect_config.ec2 [-] ('Connection aborted.', error(113, 'No route to host')) Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.615 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.833 4606 WARNING os-collect-config [-] Source [request] Unavailable. Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.833 4606 WARNING os_collect_config.local [-] /var/lib/os-collect-config/local-data not found. Skipping Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.834 4606 WARNING os_collect_config.local [-] No local metadata found (['/var/lib/os-collect-config/local-data']) So something is wrong with the network, but I don't know what because I can ping the external network and gateway from the controller node. If someone knows what could be I would be so glad, because I've been trying to deploy and all the times it fails Kind regards, Gabriel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrown2 at ocf.co.uk Sun Jul 31 12:49:18 2016 From: cbrown2 at ocf.co.uk (Christopher Brown) Date: Sun, 31 Jul 2016 13:49:18 +0100 Subject: [rdo-list] Overcloud Deployment failsm not br-int Message-ID: Hi Gabriel, Any reason you are trying to install such an old version? Kilo is no longer supported and the repository has been archived. I'd recommend trying again with Liberty or perhaps Mitaka first. Regards, Christopher Brown OpenStack Engineer OCF plc Tel: +44 (0)114 257 2200 Web: www.ocf.co.uk Blog: blog.ocf.co.uk Twitter: @ocfplc OCF plc is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. -------- Original message -------- From: Gabriel Peral Date: 31/07/2016 10:16 a.m. (GMT+00:00) To: rdo-list at redhat.com Subject: [rdo-list] Overcloud Deployment failsm not br-int Hi everyone! I've been trying to deploy OpenStack using TripleO for 2 weeks and I am get stucked in the same step. But let's see first my environment, 3 baremetal nodes, one will be a compute node, the other two will be compute nodes. In each pyhiscal node I have two pyhiscal NICs, one for the PXE+DHCP provisioning, and the other pyhsical NIC connected to a pyhiscal switch which has the rest of the vlans for the deployment (api, storage, tenant, exeternal, etc). I am deploying OpeStack Kilo version. The first step of the installation was good, the undercloud and the introspection was done in the right way, but the problem cames when I try to deploy the overcloud, I set up the network-environment.yaml template in order to set the vlans to the networks, and the compute.yaml and controller.yaml templates to set the right NICs to the right networks. And then I launch the deploy command like this (vlan mode) : $ openstack overcloud deploy --templates ~/templates/my-overcloud/ -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml -e ~/templates/my-overcloud/environments/network-isolation.yaml --control-scale 1 --compute-scale 2 --control-flavor control --compute-flavor compute --ntp-server 10.20.10.3 --neutron-network-type vlan --neutron-disable-tunneling --neutron-bridge-mappings datacentre:br-ex --neutron-network-vlan-ranges datacentre:30:100 --timeout 60 --verbose --log-file overcloud_vlan.log And all seems go well untill it fails due to timeout, the heat resource-list --nested-depth 5 overcloud | grep FAILED Show that something is wrong in the NetworkDeploy, and when I log into the controller node, if I type sudo ovs-vsctl list-br it only shows me the br-ex bridge, so it wasn't able to create the br-int, and I think that's the reason because the deployment has been failed, when I've tryied to deploy more i log into the controller node, and check the sudo tail -f /var/log/messages and this is the only message that appears: Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.337 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.624 4606 WARNING os-collect-config [-] Source [request] Unavailable. Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.625 4606 WARNING os_collect_config.local [-] /var/lib/os-collect-config/local-data not found. Skipping Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 04:59:53.625 4606 WARNING os_collect_config.local [-] No local metadata found (['/var/lib/os-collect-config/local-data']) Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.615 4606 WARNING os_collect_config.ec2 [-] ('Connection aborted.', error(113, 'No route to host')) Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.615 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.833 4606 WARNING os-collect-config [-] Source [request] Unavailable. Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.833 4606 WARNING os_collect_config.local [-] /var/lib/os-collect-config/local-data not found. Skipping Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 05:00:26.834 4606 WARNING os_collect_config.local [-] No local metadata found (['/var/lib/os-collect-config/local-data']) So something is wrong with the network, but I don't know what because I can ping the external network and gateway from the controller node. If someone knows what could be I would be so glad, because I've been trying to deploy and all the times it fails Kind regards, Gabriel -------------- next part -------------- An HTML attachment was scrubbed... URL: From marius at remote-lab.net Sun Jul 31 13:49:30 2016 From: marius at remote-lab.net (Marius Cornea) Date: Sun, 31 Jul 2016 15:49:30 +0200 Subject: [rdo-list] Overcloud Deployment failsm not br-int In-Reply-To: References: Message-ID: On Sun, Jul 31, 2016 at 11:10 AM, Gabriel Peral wrote: > Hi everyone! > > I've been trying to deploy OpenStack using TripleO for 2 weeks and I am get > stucked in the same step. > > But let's see first my environment, 3 baremetal nodes, one will be a compute > node, the other two will be compute nodes. In each pyhiscal node I have two > pyhiscal NICs, one for the PXE+DHCP provisioning, and the other pyhsical NIC > connected to a pyhiscal switch which has the rest of the vlans for the > deployment (api, storage, tenant, exeternal, etc). I am deploying OpeStack > Kilo version. > The first step of the installation was good, the undercloud and the > introspection was done in the right way, but the problem cames when I try to > deploy the overcloud, I set up the network-environment.yaml template in > order to set the vlans to the networks, and the compute.yaml and > controller.yaml templates to set the right NICs to the right networks. And > then I launch the deploy command like this (vlan mode) : > > $ openstack overcloud deploy --templates ~/templates/my-overcloud/ -e > ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml > -e ~/templates/my-overcloud/environments/network-isolation.yaml > --control-scale 1 --compute-scale 2 --control-flavor control > --compute-flavor compute --ntp-server 10.20.10.3 --neutron-network-type vlan > --neutron-disable-tunneling --neutron-bridge-mappings datacentre:br-ex > --neutron-network-vlan-ranges datacentre:30:100 --timeout 60 --verbose > --log-file overcloud_vlan.log > > And all seems go well untill it fails due to timeout, the > > heat resource-list --nested-depth 5 overcloud | grep FAILED > > Show that something is wrong in the NetworkDeploy, and when I log into the > controller node, if I type sudo ovs-vsctl list-br it only shows me the br-ex > bridge, so it wasn't able to create the br-int, and I think that's the > reason because the deployment has been failed, when I've tryied to deploy > more i log into the controller node, and check the sudo tail -f > /var/log/messages and this is the only message that appears: > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.337 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.624 4606 WARNING os-collect-config [-] Source [request] > Unavailable. > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.625 4606 WARNING os_collect_config.local [-] > /var/lib/os-collect-config/local-data not found. Skipping > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.625 4606 WARNING os_collect_config.local [-] No local metadata > found (['/var/lib/os-collect-config/local-data']) > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.615 4606 WARNING os_collect_config.ec2 [-] ('Connection aborted.', > error(113, 'No route to host')) This generally indicates that it couldn't reach the metadata server ( route to 169.254.169.254). This gets set in the nic templates that you've used. Next debugging steps would be to run ip r get 169.254.169.254, see what's the next hop for it - it should be the ctlplane address of the undercloud. Then do some connectivity checks for it such as ping or curl http://169.254.169.254 > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.615 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.833 4606 WARNING os-collect-config [-] Source [request] > Unavailable. > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.833 4606 WARNING os_collect_config.local [-] > /var/lib/os-collect-config/local-data not found. Skipping > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.834 4606 WARNING os_collect_config.local [-] No local metadata > found (['/var/lib/os-collect-config/local-data']) > > So something is wrong with the network, but I don't know what because I can > ping the external network and gateway from the controller node. > > If someone knows what could be I would be so glad, because I've been trying > to deploy and all the times it fails > > Kind regards, > > Gabriel > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From bfournie at redhat.com Sun Jul 31 15:26:20 2016 From: bfournie at redhat.com (Bob Fournier) Date: Sun, 31 Jul 2016 11:26:20 -0400 (EDT) Subject: [rdo-list] Overcloud Deployment failsm not br-int In-Reply-To: References: Message-ID: <241172949.48632896.1469978780135.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Christopher Brown" > To: "Gabriel Peral" , rdo-list at redhat.com > Sent: Sunday, July 31, 2016 8:49:18 AM > Subject: Re: [rdo-list] Overcloud Deployment failsm not br-int > > Hi Gabriel, > > Any reason you are trying to install such an old version? Kilo is no longer > supported and the repository has been archived. > > I'd recommend trying again with Liberty or perhaps Mitaka first. > > Regards, > > Christopher Brown > OpenStack Engineer > OCF plc > > Tel: +44 (0)114 257 2200 > Web: www.ocf.co.uk > Blog: blog.ocf.co.uk > Twitter: @ocfplc > > OCF plc is a company registered in England and Wales. Registered number > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 > Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG. > > This message is private and confidential. If you have received this message > in error, please notify us and remove it from your system. > > Gabriel, After trying again with a newer version, if you are still having problems it would be useful if you included the network-environment.yaml and network-isolation.yaml files in the email. Also, as your deployment doesn't include storage, it shouldn't be necessary to include storage-environment.yaml in your deployment command, i.e. "-e ~/templates/storage-environment.yaml" isn't needed. Regards, Bob Fournier > -------- Original message -------- > From: Gabriel Peral > Date: 31/07/2016 10:16 a.m. (GMT+00:00) > To: rdo-list at redhat.com > Subject: [rdo-list] Overcloud Deployment failsm not br-int > > Hi everyone! > > I've been trying to deploy OpenStack using TripleO for 2 weeks and I am get > stucked in the same step. > > But let's see first my environment, 3 baremetal nodes, one will be a compute > node, the other two will be compute nodes. In each pyhiscal node I have two > pyhiscal NICs, one for the PXE+DHCP provisioning, and the other pyhsical NIC > connected to a pyhiscal switch which has the rest of the vlans for the > deployment (api, storage, tenant, exeternal, etc). I am deploying OpeStack > Kilo version. > The first step of the installation was good, the undercloud and the > introspection was done in the right way, but the problem cames when I try to > deploy the overcloud, I set up the network-environment.yaml template in > order to set the vlans to the networks, and the compute.yaml and > controller.yaml templates to set the right NICs to the right networks. And > then I launch the deploy command like this (vlan mode) : > > $ openstack overcloud deploy --templates ~/templates/my-overcloud/ -e > ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml > -e ~/templates/my-overcloud/environments/network-isolation.yaml > --control-scale 1 --compute-scale 2 --control-flavor control > --compute-flavor compute --ntp-server 10.20.10.3 --neutron-network-type vlan > --neutron-disable-tunneling --neutron-bridge-mappings datacentre:br-ex > --neutron-network-vlan-ranges datacentre:30:100 --timeout 60 --verbose > --log-file overcloud_vlan.log > > And all seems go well untill it fails due to timeout, the > > heat resource-list --nested-depth 5 overcloud | grep FAILED > > Show that something is wrong in the NetworkDeploy, and when I log into the > controller node, if I type sudo ovs-vsctl list-br it only shows me the br-ex > bridge, so it wasn't able to create the br-int, and I think that's the > reason because the deployment has been failed, when I've tryied to deploy > more i log into the controller node, and check the sudo tail -f > /var/log/messages and this is the only message that appears: > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.337 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.624 4606 WARNING os-collect-config [-] Source [request] > Unavailable. > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.625 4606 WARNING os_collect_config.local [-] > /var/lib/os-collect-config/local-data not found. Skipping > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > 04:59:53.625 4606 WARNING os_collect_config.local [-] No local metadata > found (['/var/lib/os-collect-config/local-data']) > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.615 4606 WARNING os_collect_config.ec2 [-] ('Connection aborted.', > error(113, 'No route to host')) > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.615 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.833 4606 WARNING os-collect-config [-] Source [request] > Unavailable. > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.833 4606 WARNING os_collect_config.local [-] > /var/lib/os-collect-config/local-data not found. Skipping > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > 05:00:26.834 4606 WARNING os_collect_config.local [-] No local metadata > found (['/var/lib/os-collect-config/local-data' ]) > > So something is wrong with the network, but I don't know what because I can > ping the external network and gateway from the controller node. > > If someone knows what could be I would be so glad, because I've been trying > to deploy and all the times it fails > > Kind regards, > > Gabriel > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From bfournie at redhat.com Sun Jul 31 16:24:30 2016 From: bfournie at redhat.com (Bob Fournier) Date: Sun, 31 Jul 2016 12:24:30 -0400 (EDT) Subject: [rdo-list] Overcloud Deployment failsm not br-int In-Reply-To: <241172949.48632896.1469978780135.JavaMail.zimbra@redhat.com> References: <241172949.48632896.1469978780135.JavaMail.zimbra@redhat.com> Message-ID: <1953265577.48640319.1469982270640.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bob Fournier" > To: "Christopher Brown" > Cc: rdo-list at redhat.com > Sent: Sunday, July 31, 2016 11:26:20 AM > Subject: Re: [rdo-list] Overcloud Deployment failsm not br-int > > > ----- Original Message ----- > > From: "Christopher Brown" > > To: "Gabriel Peral" , rdo-list at redhat.com > > Sent: Sunday, July 31, 2016 8:49:18 AM > > Subject: Re: [rdo-list] Overcloud Deployment failsm not br-int > > > > Hi Gabriel, > > > > Any reason you are trying to install such an old version? Kilo is no longer > > supported and the repository has been archived. > > > > I'd recommend trying again with Liberty or perhaps Mitaka first. > > > > Regards, > > > > Christopher Brown > > OpenStack Engineer > > OCF plc > > > > Tel: +44 (0)114 257 2200 > > Web: www.ocf.co.uk > > Blog: blog.ocf.co.uk > > Twitter: @ocfplc > > > > OCF plc is a company registered in England and Wales. Registered number > > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 > > Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG. > > > > This message is private and confidential. If you have received this message > > in error, please notify us and remove it from your system. > > > > > > Gabriel, > > After trying again with a newer version, if you are still having problems > it would be useful if you included the network-environment.yaml > and network-isolation.yaml files in the email. Also, as your > deployment doesn't include storage, it shouldn't be necessary to > include storage-environment.yaml in your deployment command, > i.e. "-e ~/templates/storage-environment.yaml" isn't needed. > > Regards, > Bob Fournier Gabriel, Also, I recently did a baremetal deployment very similar to what you are trying to set up (2 NICs - one NIC for provisioning and one with VLANs for external, api, tenant, and storage networks). I have attached the relevant yaml files that you should be able to use as a reference. Regards, Bob Fournier > > > -------- Original message -------- > > From: Gabriel Peral > > Date: 31/07/2016 10:16 a.m. (GMT+00:00) > > To: rdo-list at redhat.com > > Subject: [rdo-list] Overcloud Deployment failsm not br-int > > > > Hi everyone! > > > > I've been trying to deploy OpenStack using TripleO for 2 weeks and I am get > > stucked in the same step. > > > > But let's see first my environment, 3 baremetal nodes, one will be a > > compute > > node, the other two will be compute nodes. In each pyhiscal node I have two > > pyhiscal NICs, one for the PXE+DHCP provisioning, and the other pyhsical > > NIC > > connected to a pyhiscal switch which has the rest of the vlans for the > > deployment (api, storage, tenant, exeternal, etc). I am deploying OpeStack > > Kilo version. > > The first step of the installation was good, the undercloud and the > > introspection was done in the right way, but the problem cames when I try > > to > > deploy the overcloud, I set up the network-environment.yaml template in > > order to set the vlans to the networks, and the compute.yaml and > > controller.yaml templates to set the right NICs to the right networks. And > > then I launch the deploy command like this (vlan mode) : > > > > $ openstack overcloud deploy --templates ~/templates/my-overcloud/ -e > > ~/templates/network-environment.yaml -e > > ~/templates/storage-environment.yaml > > -e ~/templates/my-overcloud/environments/network-isolation.yaml > > --control-scale 1 --compute-scale 2 --control-flavor control > > --compute-flavor compute --ntp-server 10.20.10.3 --neutron-network-type > > vlan > > --neutron-disable-tunneling --neutron-bridge-mappings datacentre:br-ex > > --neutron-network-vlan-ranges datacentre:30:100 --timeout 60 --verbose > > --log-file overcloud_vlan.log > > > > And all seems go well untill it fails due to timeout, the > > > > heat resource-list --nested-depth 5 overcloud | grep FAILED > > > > Show that something is wrong in the NetworkDeploy, and when I log into the > > controller node, if I type sudo ovs-vsctl list-br it only shows me the > > br-ex > > bridge, so it wasn't able to create the br-int, and I think that's the > > reason because the deployment has been failed, when I've tryied to deploy > > more i log into the controller node, and check the sudo tail -f > > /var/log/messages and this is the only message that appears: > > > > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > 04:59:53.337 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > 04:59:53.624 4606 WARNING os-collect-config [-] Source [request] > > Unavailable. > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > 04:59:53.625 4606 WARNING os_collect_config.local [-] > > /var/lib/os-collect-config/local-data not found. Skipping > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > 04:59:53.625 4606 WARNING os_collect_config.local [-] No local metadata > > found (['/var/lib/os-collect-config/local-data']) > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > 05:00:26.615 4606 WARNING os_collect_config.ec2 [-] ('Connection aborted.', > > error(113, 'No route to host')) > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > 05:00:26.615 4606 WARNING os-collect-config [-] Source [ec2] Unavailable. > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > 05:00:26.833 4606 WARNING os-collect-config [-] Source [request] > > Unavailable. > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > 05:00:26.833 4606 WARNING os_collect_config.local [-] > > /var/lib/os-collect-config/local-data not found. Skipping > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > 05:00:26.834 4606 WARNING os_collect_config.local [-] No local metadata > > found (['/var/lib/os-collect-config/local-data' ]) > > > > So something is wrong with the network, but I don't know what because I can > > ping the external network and gateway from the controller node. > > > > If someone knows what could be I would be so glad, because I've been trying > > to deploy and all the times it fails > > > > Kind regards, > > > > Gabriel > > > > _______________________________________________ > > rdo-list mailing list > > rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: compute.yaml Type: application/octet-stream Size: 4431 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: controller.yaml Type: application/octet-stream Size: 4974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: deploy.sh Type: application/x-shellscript Size: 366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: network-environment.yaml Type: application/octet-stream Size: 3348 bytes Desc: not available URL: From bfournie at redhat.com Sun Jul 31 18:17:50 2016 From: bfournie at redhat.com (Bob Fournier) Date: Sun, 31 Jul 2016 14:17:50 -0400 (EDT) Subject: [rdo-list] Overcloud Deployment failsm not br-int In-Reply-To: References: <241172949.48632896.1469978780135.JavaMail.zimbra@redhat.com> <1953265577.48640319.1469982270640.JavaMail.zimbra@redhat.com> Message-ID: <784002863.48650681.1469989070484.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Gabriel Peral" > To: "Bob Fournier" > Sent: Sunday, July 31, 2016 1:39:05 PM > Subject: Re: [rdo-list] Overcloud Deployment failsm not br-int > > Hi everyone, > > All seems to be okay, > *@Marius Cornea -->* Iptables are not blocking any access but still cannot > curl the http://169.254.169.254 > *@Bob Fournier --> *my templates are almost like yours, I will attach them > and so you can take a look, maybe I am missing something > > Is very weird cause all the vlans are defined in a pyhiscal switch, and the > PXE+DHCP vlan is the only one which is native, the others are in trunk mode > (include the External) > > Thank you all for the help!! > > Regards, > > Gabriel Thanks Gabriel. Is the deployment working OK now? If your still having problems there were a couple things I noticed in the yaml files that you sent. (Note, your last response seems like it was intended for the list but not sure if list was included). Can you try using dhcp for the vlan networks, so removing this line in your controller and compute yams? type: ovs_bridge name: {get_input: bridge_name} use_dhcp: false <==== remove You have 2 extra interfaces in your controller and compute yaml files. Not sure what these are used for but they should be removed. type: interface name: enp9s0 use_dhcp: false defroute: false - type: interface name: enp10s0 use_dhcp: false defroute: false Can you make sure that your custom controller and compute yaml files are located at these locations? (I'm not saying they aren't, but its a common problem I have made :-) ) OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/my-overcloud/network/config/single-nic\ -vlans/compute.yaml OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/my-overcloud/network/config/single-\ nic-vlans/controller.yaml It would also be useful to send the deploy command you are using if you are still having problems. Thanks, Bob > > 2016-07-31 18:24 GMT+02:00 Bob Fournier : > > > > > ----- Original Message ----- > > > From: "Bob Fournier" > > > To: "Christopher Brown" > > > Cc: rdo-list at redhat.com > > > Sent: Sunday, July 31, 2016 11:26:20 AM > > > Subject: Re: [rdo-list] Overcloud Deployment failsm not br-int > > > > > > > > > ----- Original Message ----- > > > > From: "Christopher Brown" > > > > To: "Gabriel Peral" , rdo-list at redhat.com > > > > Sent: Sunday, July 31, 2016 8:49:18 AM > > > > Subject: Re: [rdo-list] Overcloud Deployment failsm not br-int > > > > > > > > Hi Gabriel, > > > > > > > > Any reason you are trying to install such an old version? Kilo is no > > longer > > > > supported and the repository has been archived. > > > > > > > > I'd recommend trying again with Liberty or perhaps Mitaka first. > > > > > > > > Regards, > > > > > > > > Christopher Brown > > > > OpenStack Engineer > > > > OCF plc > > > > > > > > Tel: +44 (0)114 257 2200 > > > > Web: www.ocf.co.uk > > > > Blog: blog.ocf.co.uk > > > > Twitter: @ocfplc > > > > > > > > OCF plc is a company registered in England and Wales. Registered number > > > > 4132533, VAT number GB 780 6803 14. Registered office address: OCF > > plc, 5 > > > > Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 > > 2PG. > > > > > > > > This message is private and confidential. If you have received this > > message > > > > in error, please notify us and remove it from your system. > > > > > > > > > > > > > > Gabriel, > > > > > > After trying again with a newer version, if you are still having problems > > > it would be useful if you included the network-environment.yaml > > > and network-isolation.yaml files in the email. Also, as your > > > deployment doesn't include storage, it shouldn't be necessary to > > > include storage-environment.yaml in your deployment command, > > > i.e. "-e ~/templates/storage-environment.yaml" isn't needed. > > > > > > Regards, > > > Bob Fournier > > > > Gabriel, > > > > Also, I recently did a baremetal deployment very similar to > > what you are trying to set up (2 NICs - one NIC for provisioning and one > > with VLANs for external, api, tenant, and storage networks). I have > > attached the relevant yaml files that you should be able to use as > > a reference. > > > > Regards, > > Bob Fournier > > > > > > > > > > > -------- Original message -------- > > > > From: Gabriel Peral > > > > Date: 31/07/2016 10:16 a.m. (GMT+00:00) > > > > To: rdo-list at redhat.com > > > > Subject: [rdo-list] Overcloud Deployment failsm not br-int > > > > > > > > Hi everyone! > > > > > > > > I've been trying to deploy OpenStack using TripleO for 2 weeks and I > > am get > > > > stucked in the same step. > > > > > > > > But let's see first my environment, 3 baremetal nodes, one will be a > > > > compute > > > > node, the other two will be compute nodes. In each pyhiscal node I > > have two > > > > pyhiscal NICs, one for the PXE+DHCP provisioning, and the other > > pyhsical > > > > NIC > > > > connected to a pyhiscal switch which has the rest of the vlans for the > > > > deployment (api, storage, tenant, exeternal, etc). I am deploying > > OpeStack > > > > Kilo version. > > > > The first step of the installation was good, the undercloud and the > > > > introspection was done in the right way, but the problem cames when I > > try > > > > to > > > > deploy the overcloud, I set up the network-environment.yaml template in > > > > order to set the vlans to the networks, and the compute.yaml and > > > > controller.yaml templates to set the right NICs to the right networks. > > And > > > > then I launch the deploy command like this (vlan mode) : > > > > > > > > $ openstack overcloud deploy --templates ~/templates/my-overcloud/ -e > > > > ~/templates/network-environment.yaml -e > > > > ~/templates/storage-environment.yaml > > > > -e ~/templates/my-overcloud/environments/network-isolation.yaml > > > > --control-scale 1 --compute-scale 2 --control-flavor control > > > > --compute-flavor compute --ntp-server 10.20.10.3 --neutron-network-type > > > > vlan > > > > --neutron-disable-tunneling --neutron-bridge-mappings datacentre:br-ex > > > > --neutron-network-vlan-ranges datacentre:30:100 --timeout 60 --verbose > > > > --log-file overcloud_vlan.log > > > > > > > > And all seems go well untill it fails due to timeout, the > > > > > > > > heat resource-list --nested-depth 5 overcloud | grep FAILED > > > > > > > > Show that something is wrong in the NetworkDeploy, and when I log into > > the > > > > controller node, if I type sudo ovs-vsctl list-br it only shows me the > > > > br-ex > > > > bridge, so it wasn't able to create the br-int, and I think that's the > > > > reason because the deployment has been failed, when I've tryied to > > deploy > > > > more i log into the controller node, and check the sudo tail -f > > > > /var/log/messages and this is the only message that appears: > > > > > > > > > > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 04:59:53.337 4606 WARNING os-collect-config [-] Source [ec2] > > Unavailable. > > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 04:59:53.624 4606 WARNING os-collect-config [-] Source [request] > > > > Unavailable. > > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 04:59:53.625 4606 WARNING os_collect_config.local [-] > > > > /var/lib/os-collect-config/local-data not found. Skipping > > > > Jul 31 04:59:53 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 04:59:53.625 4606 WARNING os_collect_config.local [-] No local metadata > > > > found (['/var/lib/os-collect-config/local-data']) > > > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 05:00:26.615 4606 WARNING os_collect_config.ec2 [-] ('Connection > > aborted.', > > > > error(113, 'No route to host')) > > > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 05:00:26.615 4606 WARNING os-collect-config [-] Source [ec2] > > Unavailable. > > > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 05:00:26.833 4606 WARNING os-collect-config [-] Source [request] > > > > Unavailable. > > > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 05:00:26.833 4606 WARNING os_collect_config.local [-] > > > > /var/lib/os-collect-config/local-data not found. Skipping > > > > Jul 31 05:00:26 overcloud-controller-0 os-collect-config: 2016-07-31 > > > > 05:00:26.834 4606 WARNING os_collect_config.local [-] No local metadata > > > > found (['/var/lib/os-collect-config/local-data' ]) > > > > > > > > So something is wrong with the network, but I don't know what because > > I can > > > > ping the external network and gateway from the controller node. > > > > > > > > If someone knows what could be I would be so glad, because I've been > > trying > > > > to deploy and all the times it fails > > > > > > > > Kind regards, > > > > > > > > Gabriel > > > > > > > > _______________________________________________ > > > > rdo-list mailing list > > > > rdo-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > > > _______________________________________________ > > > rdo-list mailing list > > > rdo-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > > >