Perl 6 - the future is here, just unevenly distributed

IRC log for #fuel, 2014-12-08

| Channels | #fuel index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:08 e0ne joined #fuel
00:09 Longgeek joined #fuel
00:14 e0ne joined #fuel
00:23 e0ne joined #fuel
00:30 e0ne joined #fuel
00:50 emagana joined #fuel
00:53 e0ne joined #fuel
01:09 e0ne joined #fuel
01:38 emagana joined #fuel
01:58 Longgeek joined #fuel
02:15 rongze joined #fuel
02:28 emagana joined #fuel
03:19 monester_laptop joined #fuel
03:23 fandi joined #fuel
03:23 emagana joined #fuel
04:31 emagana joined #fuel
04:47 Longgeek joined #fuel
05:18 emagana joined #fuel
05:29 emagana joined #fuel
05:33 emagana_ joined #fuel
06:14 coryc1 joined #fuel
06:25 emagana joined #fuel
06:36 Longgeek joined #fuel
06:44 taj joined #fuel
06:59 emagana joined #fuel
07:11 ddmitriev joined #fuel
07:14 baboune joined #fuel
07:14 baboune evg;  "[root@node-68 ~]# ip neigh list dev eth1" returns nothing
07:15 baboune evg: [root@node-68 ~]# dhcpcd eth1 -bash: dhcpcd: command not found
07:16 baboune kaliya: "regarding https://answers.launchpad.net/fuel/+question/258562 what's your network topology?" Neutron vlan, eth0 is public/mgt/storage, eth1 is Private, eth2 is Admin (PXE)
07:37 Longgeek joined #fuel
07:37 Longgeek joined #fuel
07:38 baboune is 5.1.1 available now?
07:38 monester_laptop joined #fuel
07:40 subscope joined #fuel
07:52 adanin joined #fuel
07:53 emagana joined #fuel
08:09 dilyin joined #fuel
08:09 kaliya joined #fuel
08:09 taj joined #fuel
08:10 meow-nofer_ joined #fuel
08:10 arogusskiy joined #fuel
08:11 HeOS_ joined #fuel
08:12 asilenkov joined #fuel
08:12 akurenyshev joined #fuel
08:32 monester_laptop joined #fuel
08:34 emagana joined #fuel
08:38 stamak joined #fuel
08:40 Longgeek joined #fuel
08:49 kaliya baboune: 5.1.1 is in code freeze, going to be released soon
08:51 baboune kaliya: if I set up a new fuel using the community iso, will I be able to upgrade it afterwards?
08:52 kaliya baboune: this is not supported officially, the build might include errors that could block the package upgrade
08:55 baboune so wiping out everything and using 5.1.1 will not solve my problems immediately.  Any ides on moving my env from "deploying" to operational?
08:55 kaliya baboune: do you have other running envs there?
08:55 baboune kaliya: I just wiped it out..
08:56 kaliya so you did delete the deployment tasks, but the env won't end being stuck
08:56 baboune kaliya: and I am thinking of resetting everything from scratch once more
08:56 baboune yes
08:56 kaliya have you redeployed after wiping out?
08:57 saibarspeis joined #fuel
08:57 baboune no I have not.  At the moment I have only the "deploying" stuck env remaining.  And 8 nodes unassigned.
08:58 kaliya what's your network setup? I mean how did you assign interfaces on nodes?
08:58 teran joined #fuel
08:58 baboune The "verify networks" fails with an error. and leaves two tasks behind.
08:58 Longgeek joined #fuel
08:59 baboune Neutron vlan, eth0 is public/mgt/storage, eth1 is Private, eth2 is Admin (PXE)
08:59 kaliya I've experienced some other 100% stuck, was due wrong network conf
08:59 kaliya what's the verify networks error?
08:59 baboune it got stuck initially due to a Net timeout exception
08:59 kaliya duplicate MAC?
08:59 baboune Node Untitled (31:8c) discovered DHCP server via eth1 with following parameters: IP: 21.21.21.3, MAC: fa:16:3e:ad:a1:45. This server will conflict with the installation.
09:00 baboune Node Untitled (2c:e8) discovered DHCP server via eth1 with following parameters: IP: 20.20.20.3, MAC: fa:16:3e:7c:6b:44. This server will conflict with the installation.
09:00 baboune etc
09:00 baboune this message is often misleading as it generally points to a problem in the NW configuration
09:00 baboune ip neigh list dev eth1" returns nothing
09:01 baboune on any of the nodes with this pb
09:01 baboune 20.20.20.3 or 21.21.21.3 are not real addresses
09:02 baboune they exist within OpenStack as subnets, and the port connections to the net4 router
09:02 baboune so unless hosts can resolve towards internal virtual OpenStack router I dont see how this is possible
09:03 bazilza joined #fuel
09:04 baboune if I press "Deploy changes" in the UI, I get: 7faa720e4740] (logger) Traceback (most recent call last):   File "/usr/lib/python2.6/site-packages/web/application.py", line 239, in process     return self.handle()   File "/usr/lib/python2.6/site-packages/web/application.py", line 230, in handle     return self._delegate(fn, self.fvars, args)   File "/usr/lib/python2.6/site-packages/web/application.py", line 420, in _delegate     return h
09:04 baboune File "/usr/lib/python2.6/site-packages/nailgun/task/manager.py", line 104, in _remove_obsolete_tasks     raise errors.DeploymentAlreadyStarted() DeploymentAlreadyStarted: Deployment already started
09:05 kaliya This is just after installing the 5.1? You add the nodes, run Verify Network, and get this error?
09:06 kaliya We had https://bugs.launchpad.net/fuel/+bug/1360127 which our devs said is due wrong network configuration
09:06 evg baboune: according to the MACs these dhcp servers are somethere in your env. Please try to findn them on your nodes.
09:06 fandi joined #fuel
09:07 evg baboune: i mean they are not real HW but virtual.
09:08 baboune story is: I have one environment up and running on 5.1 for 3 months.  We get told to change ip range. I created a second env. Both coexisted for a week.  Then I removed 3 nodes from old, and added to new.  And it got stuck
09:09 baboune evg: how can I find those?  They exist as ports on the net4 virtual router within openstack.
09:10 baboune both environments worked. both had green status in "Verify networks".
09:10 baboune it is there: https://answers.launchpad.net/fuel/+question/258562
09:12 baboune In neutron: 20.20.20.3 network:dhcpACTIVEUP
09:12 baboune 91a4bda5-a5d5-427c-a93e-9b708bfe51a5
09:12 baboune that is what the verify networks is pointing to
09:12 baboune how is that possible?
09:13 baboune the physical hosts finds a virtual DHCP server within Neutron over vlans?
09:13 emagana joined #fuel
09:14 baboune 20.20.20.0/24 is defined as "0e3b927f-dc2a-4d21-9b4d-de383f8e62f2 Network Type: vlan Physical Network: physnet2 Segmentation ID: 1211"
09:16 baboune this network is connected to the "router04" which connects to "net04_ext" which is then connecting to our floating + public ip range. so it is technically possible to route packets there.  I would not expect that "Verify networks" can resolve into a virtual DHCP ip address though
09:18 baboune eth1 is assigned to "private" so it is consistent with finding this virtual DHCP address but still
09:20 corepb joined #fuel
09:29 baboune apparently, dhcp_discover does atttempt to find DHCP server on VLAN ports that are reserved for virtual lans: 10:29:04.079319 fa:16:3e:7c:6b:44 > fa:16:3e:16:61:47, ethertype 802.1Q (0x8100), length 372: vlan 1211, p 0, ethertype IPv4, (tos 0xc0, ttl 64, id 18457, offset 0, flags [none], proto UDP (17), length 354)     20.20.20.3.bootps > 20.20.20.19.bootpc: BOOTP/DHCP, Reply, length 326, xid 0xae4a1423, Flags [none]   Client-IP 20.20
09:30 baboune This I get from: tcpdump -i eth1 -nev udp port 68
09:30 baboune Shoudl that be the case?  this is a VLAN id assigned to a virtual network in neutron
09:32 baboune but my first problem is: why is my env stuck in deploying state?
09:33 baboune and that was initially this: " fuel task list id | status | name | cluster | progress | uuid ----|---------|------------|---------|----------|------------------------------------- 166 | error | dump | None | 100 | 6f5383ae-78b7-4e9a-bbf4-1790617966d4 178 | ready | provision | 9 | 100 | 22a56349-0fb6-4df8-84e2-ac6e55b396fe 179 | running | deployment | 9 | 100 | 32c12350-7336-4a67-b526-7ec2cfe92b21 175 | running | deploy | 9 | 100 | e6c5
09:33 baboune which got stuck
09:42 evg baboune: ok. so let's suppose it's not a network problem as int's not the admin network.
09:43 evg baboune:  your deployment stack in 100% like here https://bugs.launchpad.net/fuel/+bug/1255426
09:43 evg baboune: am I right?
09:44 dklepikov joined #fuel
09:44 baboune It is stuck at 100% yes.  But I do not think it has anything to do with uploading an image.  All openstack nodes are fully operational
09:46 baboune evg: out of the 4 tasks at 100% that were stuck which one is according to you the astute upload?
09:47 baboune evg: see https://answers.launchpad.net/fuel/+question/258562 #3
09:47 baboune I dont think it is the same bug
09:47 baboune It was stuck for 5 days before I decided to raise it an issue and ask here
09:48 e0ne joined #fuel
09:48 evg baboune: it's not obligatory about image uploading. Can you find something suspicious in astute logs?
09:48 baboune no I could not
09:48 evg baboune: more nearer to the end
09:48 baboune it looked fine
09:49 evg baboune: do yu think the deployment is ok?
09:49 baboune evg: yes
09:50 evg baboune: tried deleting the task?
09:50 baboune evg: did u read anything about the link?
09:50 baboune evg: https://answers.launchpad.net/fuel/+question/258562
09:51 baboune evg: yes
09:51 evg baboune: reading...
09:54 artem_panchenko left #fuel
09:54 artem_panchenko joined #fuel
09:56 evg baboune: there are a lot of issues there...
09:57 baboune evg: yes
09:59 evg baboune: and now you've redeployed on ef your env and got it stuck in 100% too?
10:00 baboune evg: no I have not. I do not dare to.
10:00 baboune evg: the stuck environment is the one I need
10:00 evg baboune: ah, yes. the network test have stuck?
10:06 e0ne joined #fuel
10:07 emagana joined #fuel
10:08 baboune evg: yes
10:09 fandi joined #fuel
10:14 evg baboune: still I think the issue is in network configuration. Let's delete the task, run it and see the last messages from astute. May be it'll hint.
10:19 baboune last astute log from UI: http://pastebin.com/5a268mcj
10:19 omolchanov joined #fuel
10:20 baboune from log file: 014-12-05 09:34:52,076 DEBG 'astute' stdout output: [amqp] Detected TCP connection failure  2014-12-05 09:34:52,347 DEBG 'astute' stdout output: [amqp] Detected TCP connection failure  2014-12-05 09:34:52,575 DEBG 'astute' stdout output: [amqp] Detected TCP connection failure  2014-12-05 09:34:54,585 INFO success: astute entered RUNNING state, process has stayed up for > than 10 seconds (startsecs)
10:28 adanin joined #fuel
10:29 evg baboune: 09:34:52 is two hours before. And now you've reran the tests - no errors. And what's about the tasks status? Have thay stuck again?
10:32 baboune [root@kds-cmc-fuel-02 log]# fuel task list id  | status | name            | cluster | progress | uuid                                 ----|--------|-----------------|---------|----------|------------------------------------- 202 | error  | check_dhcp      | 9       | 100      | 8ca7ed8c-2712-4bce-9f60-d1c4f0fd5635 201 | error  | verify_networks | 9       | 100      | a0f1b6be-ae75-42f9-a2c0-ab7998c034c1
10:32 baboune same errors Node Untitled (39:38) discovered DHCP server via eth1 with following parameters: IP: 20.20.20.3, MAC: fa:16:3e:7c:6b:44. This server will conflict with the installation. Node Untitled (31:8c) discovered DHCP server via eth1 with following parameters: IP: 21.21.21.3, MAC: fa:16:3e:ad:a1:45. This server will conflict with the installation. Node Untitled (2c:e8) discovered DHCP server via eth1 with following parameters: IP: 20
10:33 baboune etc
10:33 baboune same exact result
10:56 evg baboune: are vlan ranges the same in both env?
11:00 miroslav_ joined #fuel
11:01 emagana joined #fuel
11:15 baboune evg: no. we used different vlands for both env.  In any case I deleted the "operational" env this morning.
11:16 baboune evg: sry meant "we used different vlans for both envs with no overlap"
11:25 evg baboune: deleted? pity. It's may be a bug in dhcp testing when two env are deployed (if your network conf was correct). I think I should check it asap.
11:30 HeOS joined #fuel
11:56 emagana joined #fuel
12:08 evgeniyl__ joined #fuel
12:30 saibarspeis joined #fuel
12:37 aliemieshko_ joined #fuel
12:50 emagana joined #fuel
12:59 HeOS joined #fuel
13:08 aarefiev joined #fuel
13:09 aarefiev joined #fuel
13:26 warpc__ joined #fuel
13:44 emagana joined #fuel
13:53 rongze joined #fuel
14:27 taj joined #fuel
14:27 vtzan joined #fuel
14:38 emagana joined #fuel
14:40 jaypipes joined #fuel
14:50 sanek joined #fuel
14:55 sanek joined #fuel
15:02 coryc joined #fuel
15:04 mpetason joined #fuel
15:12 mattgriffin joined #fuel
15:32 emagana joined #fuel
15:33 teran joined #fuel
15:39 e0ne joined #fuel
15:40 jobewan joined #fuel
15:53 angdraug joined #fuel
15:57 blahRus joined #fuel
16:25 jaypipes joined #fuel
16:26 emagana joined #fuel
16:33 Rajbir joined #fuel
17:19 rmoe joined #fuel
17:25 kupo24z joined #fuel
17:34 Rajbir left #fuel
18:11 swordzz joined #fuel
18:13 emagana joined #fuel
18:15 swordzz Hi. I have an Openstack Juno install, using the Fuel 6.0 Tech Preview. I'm wanting to try out SR-IOV support in Juno, and am not having a lot of success.
18:15 swordzz Currently wondering if I should update my Ubuntu servers to the latest packages, and this seems to be done through Fuel.
18:16 swordzz How do I/Can I update my servers? I suspect there must be a way, if only to take security fixes.
18:16 swordzz Or if I want to do this should I point my server sources to the live Ubunutu repos? But if I do this what am I going to break?
18:17 swordzz Also, my nodes are aware that 14.04.1 exists. What will happen if I run do-release-upgrade as they suggest?
18:17 kupo24z swordzz: Most of the packages provided are picked for a specific reason and shouldnt be upgraded from the live repository unless you know exactly what will change
18:18 kupo24z Make a bug report on launchpad if you believe a feature isnt working as it should
18:19 kupo24z upgrading to LTS 14 will most likely break it, I would avoid it
18:19 swordzz So it is the intention that the full Openstack feature set should work on systems installed using Fuel?
18:19 swordzz Possibly with additional (manual) configuration.
18:20 kupo24z Yes, unless the feature you require needs additional agents (lbaas)
18:20 kupo24z if so you would need to install them from the mirantis repository, and if it isnt there will need to be compiled and uploaded
18:21 swordzz Is lbaas the only example of that or could there be more?
18:21 kupo24z there are more
18:21 swordzz I know the instructions I'm following do mention an SR-IOV agent...
18:22 kupo24z Check with mirantis to see if it is a supported feature, check 6.x blueprints
18:22 kupo24z If so you will need to check the 6.0 repositories and see if its there
18:22 kupo24z http://fuel-repository.mirantis.com/fwm/
18:23 e0ne joined #fuel
18:23 kupo24z looks like what you're looking for is neutron-plugin-sriov-agent
18:25 kupo24z Dont see it on the repositories, check with one of the devs to see if they have plans to support it
18:25 kkk joined #fuel
18:26 kupo24z basically they would need to compile it up and package it for you as its normally a LTS 14 package
18:37 aleksandr_null joined #fuel
18:49 e0ne joined #fuel
19:00 emagana joined #fuel
19:03 emagana_ joined #fuel
19:11 xarses joined #fuel
19:34 fandi joined #fuel
19:46 emagana joined #fuel
19:49 bazilza joined #fuel
19:58 taj joined #fuel
20:05 emagana joined #fuel
20:21 geekinutah joined #fuel
20:35 xarses joined #fuel
20:55 bazilza joined #fuel
20:59 e0ne joined #fuel
21:06 e0ne joined #fuel
21:34 e0ne joined #fuel
21:50 teran joined #fuel
22:03 teran_ joined #fuel
22:13 teran joined #fuel
22:44 teran_ joined #fuel
23:13 Longgeek joined #fuel
23:15 teran joined #fuel
23:22 rongze joined #fuel
23:44 xarses joined #fuel

| Channels | #fuel index | Today | | Search | Google Search | Plain-Text | summary