16:01:35 #startmeeting Fuel 16:01:36 Meeting started Thu Mar 27 16:01:35 2014 UTC and is due to finish in 60 minutes. The chair is vkozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:39 The meeting name has been set to 'fuel' 16:02:36 #chair vkozhukalov 16:02:37 Current chairs: vkozhukalov 16:02:54 agenda https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda 16:03:17 #topic Greeting, announcements 16:04:10 who is here, guys? 16:04:26 i am 16:04:28 Hi, I'm here. 16:04:28 i am 16:04:29 i 16:04:32 o/ 16:04:40 I'm 16:04:49 Am I late for roll call? 16:04:50 Hi. We have moved from centos 6.4 to 6.5. And we’ve moved to 3.10 kernel on our bootstrap nodes 16:05:04 me 16:05:07 ok, looks like 16:00 UTC is much more appropriate time 16:05:25 hi! 16:05:29 We have negative feedback about 3.10 kernel, it needs to be investigated 16:05:30 me, too 16:05:46 dpyzhov: what is wrong? 16:06:06 dpyzhov: i mean with 3.10 16:06:10 Looks like there is no bug report 16:06:32 So I’ll communicate with reporter 16:06:35 there was some missing firmware 16:06:41 from one of the irc users 16:06:51 couldn't use 3.10 on Cent 16:07:10 Is it fixable? 16:07:20 xarses: ? 16:07:43 let's create a bug and assign it on someone 16:07:55 dpyzhov: will you create? 16:07:57 I didn't look very far into it, he'd rather have ubuntu working so i helped with that 16:08:26 vkozhukalov: sure 16:08:43 if there is no any other announcements, let's move on then 16:09:12 #topic Blueprints 16:09:26 https://blueprints.launchpad.net/fuel/+spec/nailgun-bootable-checkbox-for-disks this bp assigned to 5.1 milestione but linked bug assigned to 5.0 milestione, should we move it to 5.0? 16:09:35 #link https://blueprints.launchpad.net/fuel/+spec/fuel-upgrade 16:10:33 this bp assigned to 5.1 milestione but linked bug assigned to 5.0 milestione, should we move it to 5.0? 16:11:06 I think we should move the linked bug to 5.1 instead 16:11:20 evgeniyl`: we are discussing fuel master node upgrades 16:11:32 For fuel-upgrades we've merged patches with initial implementation of upgrade system. 16:11:38 https://blueprints.launchpad.net/fuel/+spec/linux-bonding 16:11:38 It's in our 5.0 release discussion doc but no BP was created until today. Who is aware of this stuff? I moved it to 5.1 as it seems that nobody was dealing with it. 16:12:52 akasatkin: Vasilenko is working on it 16:13:07 Ok 16:13:20 #link https://blueprints.launchpad.net/fuel/+spec/nailgun-bootable-checkbox-for-disks 16:13:22 I finally uploaded working version for Node object in Nailgun, but some tests still failed. After I fix it it will be much easier to implement other blueprints regarding API stabilizing before upgrades 16:13:45 akasatkin: assign him and move to 5.0 16:13:48 please 16:13:54 yep 16:14:47 what about nailgun-bootable-checkbox-for-disks bp? Do we want to implement it in 5.0 release? 16:15:20 evgeniyl`: moving to 5.1 16:15:30 #link https://blueprints.launchpad.net/fuel/+spec/fuel-stop-provision 16:15:41 What is the status of stop provisioning bp? I see several patches, are they ready to merge? Or do we wait result of testing from QA? 16:15:45 my PR on stopping provisioning is on review 16:15:51 and have 5 plus ones 16:15:58 dpyzhov: please set priority on linux-bonding. 16:16:36 as far as I know it’s working, let’s ask Vova Sharshov 16:16:57 It looks like he is not here. 16:17:36 Ok, lets ask him directly about status of this bp. 16:17:48 #link https://blueprints.launchpad.net/fuel/+spec/move-naily-to-astute-repo 16:18:00 Vladimir Sharshov moved naily to astute! 16:18:01 yay! 16:18:42 evgeniyl`: great 16:19:10 #link https://blueprints.launchpad.net/fuel/+spec/provision-ironic 16:19:22 about Ironic integration. 16:20:05 Last week we agreed with other guys from Ironic about main point of ironic-python-architecture 16:20:20 agordeev sent pull request 16:20:41 vkozhukalov: I see 'how to' link in the bp and I can't open it. 16:20:44 #link https://review.openstack.org/83087 16:22:41 evgeniyl`: it is not actual any more, will remote it 16:23:43 im working on reimplementing comprehensive partitioning stuff in terms of ironic-python-agent 16:24:10 #link https://review.openstack.org/#/c/72950/7 16:24:27 this pull request is about adding uuid into node model 16:24:48 it has 2 pluses, so let's merge it 16:25:21 vkozhukalov: ok, I'll do it. 16:25:31 why do we keep updating current migrations? 16:26:16 xarses: why not? i just didn't understand the point 16:26:16 i thought the point of alembic was so that we could make incremental changes? 16:26:33 well fist off, no one cut 4.1 16:26:43 xarses: yes, you are right 16:26:46 so thats bad 16:27:38 evgeniyl`: do you have some comments about alembic and incremental updates? 16:28:14 i think we need to talk about alembic strategy 16:28:16 xarses, vkozhukalov we need to have single migraion file for single release. 16:28:39 evgeniyl`: why? 16:28:57 evgeniyl`: is it about kinda stability? 16:29:06 xarses, vkozhukalov and we thought we don't have to make upgrades from 4.1 to 5.0 , but maybe we will have to do it. 16:29:27 actually, I see no problems in keeping many files in repo and just merging them into one before release 16:29:29 evgeniyl`: we at least need to cut 4.1 for release 16:29:37 from current 16:29:47 yeah, we need to make one for 4.1 16:29:53 not current 16:29:55 4.0 16:30:10 ok, can we discuss it in details later in mailing list? 16:30:15 they are applied one by one from the first one, which is 4.0 16:30:45 meow-nofer_: I see problems, 1. it will require a lot of time to run a lot of migration file, 2. it's messy and difficult to support 16:30:45 meow-nofer_: could you please send a letter about this topic in fuel-dev mailing 16:30:49 ? 16:30:56 correct, and we released 4.1, so it should have been cut out of current. Anyway, we need to start mail list about this 16:31:10 evgeniyl`, 1) no 2) no 16:31:20 but okay 16:31:30 I’ll send a letter 16:31:39 meow-nofer_: great 16:31:44 let's move on 16:32:02 #link https://blueprints.launchpad.net/fuel/+spec/fuel-containerization-of-services 16:32:29 this the essential part of fuel-upgrade feature 16:32:51 aglarendil: status? 16:33:22 vkozhukalov, still working on separation of services from core nailgun puppet module 16:33:41 @mattymo is leading this feature and current status is that we have several services not contained and puppetized 16:33:54 but the main gist is we will have every daemonized service in its own docker container (except cobbler + apache which cannot be split) 16:34:55 mattymo: aglarendil: ok, good progress 16:34:59 I have a handful of reviews to look at 16:35:14 https://review.openstack.org/#/c/82497/ https://review.openstack.org/#/c/82506/ https://review.openstack.org/#/c/82542/ https://review.openstack.org/#/c/83061/ 16:36:05 I still need to work on separating rabbitmq, mcollective, and rsyslog 16:36:08 but we are rather optimistic on this feature implementation in the upcoming month 16:36:23 aglarendil: ++ 16:36:48 ok, what about 16:36:53 #link https://blueprints.launchpad.net/fuel/+spec/patch-openstack 16:37:23 this feature is intersecting with fuel upgrade 16:37:43 currently we have puppet provider implementation completed that does full installation and rollback 16:38:15 thus, the only things we need to implement is repository management and tying of all this stuff with nailgun engine 16:38:28 akasatkin: is working on implenetation of this feature in nailgun 16:38:30 thus allowing user to download the update and apply it by simple redeployment 16:38:46 yes. https://blueprints.launchpad.net/fuel/+spec/openstack-patching-nailgun-part 16:39:21 we are going to achieve this also by moving closer to upstream puppet manifests of stackforge/puppet-* 16:39:28 aglarendil: akasatkin: afaiu, it is still on designing stage 16:39:45 which part do you mean? 16:40:11 puppet part 16:40:28 or we have kinda POC? 16:41:12 there is not much to do to upgrade from POC to product version 16:41:17 vkozhukalov: I started with it yesterday (Nailgun part). AFAIC, I'll finish design tomorrow. 16:41:35 akasatkin: awsome 16:41:38 we have providers implemented, thus there is not much to implement. all the other stuff is on the puppet side 16:41:51 *nailgun side 16:41:52 sorry 16:42:10 aglarendil: great 16:42:29 #link https://blueprints.launchpad.net/fuel/+spec/puppet-3-support 16:42:44 it is already implemented 16:42:48 and merged 16:43:06 #link https://blueprints.launchpad.net/fuel/+spec/relocate-haproxy-to-its-own-network-namespace 16:43:26 this blueprint is essential for HA architecture 16:43:50 there was quite an interesting bug that after moving of virtual IP addresses from a controller to another one 16:44:11 there were some connections retained, like VIP -> VIP 16:44:28 this blueprint puts haproxy and VIPs into separate networking namespaces 16:44:43 and utilizes proxy_arp in order to implement connectivity 16:45:02 such architecture makes our HA much more robust and resilient 16:45:18 afaiu, and it looks like moving haproxy to a separate namespace can help to solve this problem, right? 16:45:26 yes 16:45:35 yep, that what I am talking about 16:46:05 angdraug: aglarendil: ok 16:46:09 yes it should help alot 16:46:22 currently this blueprint is in "Beta Available" stage and is being tested 16:46:22 #topic Bugs 16:46:56 #link https://bugs.launchpad.net/fuel/+bug/1295131 16:47:20 right now we have hard coded kernel parameters which are in pmanager.py 16:47:48 we have been asked to remove some parameters 16:48:20 so it seems to be suitable to bring them out of pmanager.py into settings.yaml 16:48:32 i'll do it 16:48:39 yes that would be great! 16:48:53 #link https://bugs.launchpad.net/fuel/+bug/1294222 16:49:26 this bug is connected with the fact that our discovery agent filters out all removable drives 16:49:50 but some drives which are not removable are marked as removable 16:50:34 right now we have a list of vendors 16:50:45 which we don't have to filter out 16:51:15 but it seems to be much more suitable to stop filtering out removable devices at all 16:51:21 i think that we should move business logic like this into nailgun so that it's easier to update 16:51:36 xarses: ++ 16:51:43 and allow user to decide whether he wants to use them or not 16:52:09 if we remove the filter, we need to make deselecting disks a priorty 16:52:39 becase often it hides random usb devices, or the 16gb compact flash card that some systems have 16:52:54 which most people dont want to use, especally in a boot raid 16:53:03 yes, i agree, this piece is also on me 16:53:26 #link https://bugs.launchpad.net/fuel/+bug/1297792 16:54:04 it turned out that in some cases creating partitions on mounted drives is not viable 16:54:31 the idea of umounting come from one of our users 16:54:49 it is implemented 16:55:05 #link https://bugs.launchpad.net/fuel/+bug/1291692 16:55:25 in 4.1 we had cciss regression 16:55:54 the one related to old HP RAID controllers 16:56:10 we tried to look for drive links by their cciss!bla-bla names 16:56:16 aglarendil: exactly 16:56:28 apparently, its used on may blade chassis, so not that old 16:56:36 it has been fixed and merged 16:56:38 s/may/many 16:56:57 can we create some data tests to stop regression? 16:57:12 this is the third time it's regressed by release 16:57:19 xarses: so it is not only for old devices 16:57:26 xarses: right? 16:57:49 correct, dhblaz's servers are about 2 years old 16:58:01 he is first indicator 16:58:03 vkozhukalov: most people with HP hardware come across this problem 16:58:24 xarses: I am thinking of that, but it looks more suitable to implement this test inside ironic-python-agent 16:59:05 ok, guys 16:59:12 we have a couple minutes 16:59:26 Im closing meeting 16:59:38 thank you all for participating 16:59:42 thanks 16:59:49 thx 17:00:01 if you have to discuss something let's move to #fuel #fuel-dev 17:00:08 ерч 17:00:11 thx 17:00:14 thanks 17:00:17 #stopmeeting Fuel 17:00:33 #closemeeting Fuel 17:01:38 #endmeeting