Friday, 2019-04-19

*** samueldmq has quit IRC00:08
*** gyee has quit IRC00:31
*** zhangfei has joined #openstack-ironic01:17
*** zhangfei has quit IRC01:23
*** zhangfei has joined #openstack-ironic01:25
*** hwoarang has quit IRC01:46
*** hwoarang has joined #openstack-ironic01:48
*** dsneddon has quit IRC02:50
*** dsneddon has joined #openstack-ironic02:50
*** dsneddon has quit IRC02:57
*** irclogbot_1 has quit IRC03:05
*** irclogbot_3 has joined #openstack-ironic03:08
*** edleafe has quit IRC03:10
*** dsneddon has joined #openstack-ironic03:15
*** dsneddon has quit IRC03:19
*** dsneddon has joined #openstack-ironic03:32
*** dsneddon has quit IRC03:39
*** w14161_1 has quit IRC03:47
*** w14161_1 has joined #openstack-ironic03:48
*** dsneddon has joined #openstack-ironic05:20
*** dsneddon has quit IRC05:24
*** whoami-rajat has joined #openstack-ironic06:15
*** dsneddon has joined #openstack-ironic06:20
*** dsneddon has quit IRC06:25
*** e0ne has joined #openstack-ironic06:26
*** e0ne has quit IRC06:28
*** e0ne has joined #openstack-ironic06:36
*** e0ne has quit IRC06:38
*** e0ne has joined #openstack-ironic06:38
*** rpittau|afk is now known as rpittau06:52
rpittaugood morning ironic! o/06:52
*** pcaruana has joined #openstack-ironic07:12
*** yolanda_ has joined #openstack-ironic07:24
*** e0ne has quit IRC07:37
*** e0ne has joined #openstack-ironic07:43
*** e0ne has quit IRC07:55
*** mbeierl has quit IRC08:03
*** e0ne has joined #openstack-ironic08:04
*** e0ne has quit IRC08:07
*** gkadam has joined #openstack-ironic08:07
*** e0ne has joined #openstack-ironic08:15
*** dsneddon has joined #openstack-ironic08:21
openstackgerritraphael.glon proposed openstack/ironic master: Truncate node text fields when too long  https://review.openstack.org/65030708:23
*** whoami-rajat has quit IRC08:24
*** dsneddon has quit IRC08:26
openstackgerritraphael.glon proposed openstack/ironic master: Truncate node text fields when too long  https://review.openstack.org/65030708:27
*** dsneddon has joined #openstack-ironic08:28
*** dsneddon has quit IRC08:33
*** e0ne has quit IRC08:35
*** dsneddon has joined #openstack-ironic08:37
openstackgerritDigambar proposed openstack/ironic master: Modify the iDRAC driver to use realtime RAID creation  https://review.openstack.org/63490308:41
*** e0ne has joined #openstack-ironic08:41
*** dsneddon has quit IRC08:42
*** e0ne has quit IRC08:43
*** whoami-rajat has joined #openstack-ironic08:55
*** andrein has joined #openstack-ironic08:55
*** andrein has quit IRC08:56
*** diga has joined #openstack-ironic08:59
*** dsneddon has joined #openstack-ironic09:22
*** dsneddon has quit IRC09:27
openstackgerritVarsha Verma proposed openstack/ironic master: Removes `hash_distribution_replicas` configuration option  https://review.openstack.org/65091209:41
*** andrein has joined #openstack-ironic09:54
*** pcaruana has quit IRC10:17
*** e0ne has joined #openstack-ironic10:18
*** andrein has quit IRC10:23
*** dsneddon has joined #openstack-ironic11:03
*** e0ne has quit IRC11:04
*** dsneddon has quit IRC11:07
*** andrein has joined #openstack-ironic11:40
*** Lucas_Gray has joined #openstack-ironic11:42
*** dsneddon has joined #openstack-ironic12:02
*** whoami-rajat has quit IRC12:05
*** dsneddon has quit IRC12:06
*** Lucas_Gray has quit IRC12:08
*** e0ne has joined #openstack-ironic12:08
*** Lucas_Gray has joined #openstack-ironic12:10
openstackgerritDigambar proposed openstack/ironic master: Modify the iDRAC driver to use realtime RAID creation  https://review.openstack.org/63490312:29
*** e0ne has quit IRC12:41
*** e0ne has joined #openstack-ironic12:42
*** dsneddon has joined #openstack-ironic13:03
*** Lucas_Gray has quit IRC13:07
*** dsneddon has quit IRC13:08
*** mjturek has joined #openstack-ironic13:11
*** dims has quit IRC13:21
*** e0ne has quit IRC13:23
*** edleafe has joined #openstack-ironic13:29
*** whoami-rajat has joined #openstack-ironic13:31
*** e0ne has joined #openstack-ironic13:36
*** dims has joined #openstack-ironic13:48
*** dsneddon has joined #openstack-ironic13:52
*** baha has joined #openstack-ironic13:53
*** dsneddon has quit IRC13:57
*** diga has quit IRC14:04
*** hjensas has joined #openstack-ironic14:19
*** dims has quit IRC14:20
*** e0ne has quit IRC14:21
*** e0ne has joined #openstack-ironic14:26
*** Lucas_Gray has joined #openstack-ironic14:27
*** dsneddon has joined #openstack-ironic14:32
*** dims has joined #openstack-ironic14:35
*** dsneddon has quit IRC14:37
NobodyCamGood Morning Ironic'ers14:40
NobodyCamand ofc14:40
rpittauhey NobodyCam :)14:40
NobodyCamTGIF!14:40
NobodyCamhey hey rpittau :) happy Friday14:40
rpittau:)14:40
*** e0ne has quit IRC14:43
*** e0ne has joined #openstack-ironic14:52
*** dims has quit IRC14:53
*** e0ne has quit IRC14:53
*** dims has joined #openstack-ironic14:56
*** dims has quit IRC15:01
*** Goneri has joined #openstack-ironic15:01
*** e0ne has joined #openstack-ironic15:03
-openstackstatus- NOTICE: Gerrit is offline for several hours starting at 15:00 UTC to perform the opendev migration; see http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005011.html15:03
*** ChanServ changes topic to "Gerrit is offline for several hours starting at 15:00 UTC to perform the opendev migration; see http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005011.html"15:03
*** gyee has joined #openstack-ironic15:06
*** dims has joined #openstack-ironic15:07
*** dsneddon has joined #openstack-ironic15:31
*** dims has quit IRC15:35
*** dsneddon has quit IRC15:36
*** zhangfei has quit IRC15:41
*** dims has joined #openstack-ironic15:44
*** Lucas_Gray has quit IRC15:44
*** dsneddon has joined #openstack-ironic15:49
*** dsneddon has quit IRC15:54
*** e0ne has quit IRC15:57
*** e0ne has joined #openstack-ironic16:09
*** mgoddard has quit IRC16:34
*** mgoddard has joined #openstack-ironic16:35
*** e0ne has quit IRC16:36
rpittaubye all! have a great long weekend! o/16:42
*** rpittau is now known as rpittau|afk16:42
*** mgoddard has quit IRC16:44
*** mgoddard has joined #openstack-ironic16:45
*** gyee has quit IRC16:48
*** andrein has quit IRC16:48
*** gyee has joined #openstack-ironic16:49
*** gkadam has quit IRC16:58
TheJulia\o/ friday17:25
eanderssono/18:03
eanderssonWe are finally able to use port groups18:03
eanderssonbut we are seeing one issue during pxe18:03
eanderssonironic only configures one port during pxe. Which makes sense because only one port has pxe enabled.18:03
eanderssonThe problem is that both switches needs to be configured for lacp to not freak out18:04
*** e0ne has joined #openstack-ironic18:19
*** dims has quit IRC18:26
*** jaypipes_ has joined #openstack-ironic18:28
*** dims has joined #openstack-ironic18:29
*** jaypipes has quit IRC18:30
*** e0ne has quit IRC18:46
*** dims has quit IRC18:48
*** dims has joined #openstack-ironic18:51
*** baha has quit IRC18:56
*** Goneri has quit IRC18:57
*** ijw has joined #openstack-ironic19:17
TheJuliaeandersson: static switch side?19:18
*** hjensas has quit IRC19:19
TheJuliaeandersson: the issue if the other Port is online is the switch tries to send the packets down the second link and you then have magical packet loss :/19:20
*** jaypipes_ is now known as jaypipes19:26
*** hjensas has joined #openstack-ironic19:32
TheJuliaeandersson: I know some switches have defaults that can be set for lacp behavior, but it has been ages since I've done anything like that with fully featured switches.19:40
*** whoami-rajat has quit IRC19:40
*** andrein has joined #openstack-ironic19:52
*** jcoufal has joined #openstack-ironic20:10
ccstoneeandersson has summoned me because I forgot that I'm on IRC! I work with him and have been working on PXE boot also. What I ended up doing was configuring port groups for all nodes, setting the first port PXE-enabled and the second PXE-disabled, but I had to go onto the switch and set 'switchport trunk allowed vlan <provisioning_net_vlan>'20:32
ccstone... on the second switch, so it would pass through that VLAN ID on both ports in the channel (sorry, early-ENTER)20:32
ccstoneOne fix may be to have the IPA image only bring up eth0 and never eth1 - but from looking at docs, it looks like that element also pulls in an element that configures DHCP on all available interfaces.20:35
*** hjensas has quit IRC20:41
*** andrein has quit IRC20:49
TheJuliaWill be in front of a computer in 1520:50
*** macintoshme has joined #openstack-ironic20:50
*** jcoufal has quit IRC20:50
*** andrein has joined #openstack-ironic20:56
TheJuliaccstone: But is that not the best way to be summoned to irc? :)21:01
TheJuliaccstone: so... I guess there are two ways people have done it that I'm aware of. The first being static portgroup configurations with LACP configured such that once the OS begins to announce LACP, the LAG is established, but it also sounds like your portgrouping across switches...21:04
*** Emine has quit IRC21:04
TheJuliaccstone: The other way that I know peopel have do it, and I know cisco had been pushing was with the ML2 drivers to pass the portgroup configuration so the port group is dynamically configured.21:05
*** mjturek has quit IRC21:05
TheJuliaI feel like a better descriptive phrase for what seems to be your configuration is cross switch bonding/balancing21:06
ccstoneYeah, all of our port groups are across multiple switches. In this case there should be no case where the port channel differs between the two switches (it either doesn't work, or intermittently works in this case), but if we only set one of the two ports to pxe_enabled, it never configures the port channel on the partner switch21:10
ccstoneA workaround was to set that VLAN ID on the second switch. It allows provisioning, and networking-cisco later configures both ports correctly. We're then left in a case where SW1 PO has only one vlan (the desired vlan) and SW2 PO has both the desired vlan and the provisioning vlan (since networking-cisco doesn't remove existing config). And then a manual step to remove that provisioning vlan from the second switch.21:12
ccstoneBut for security, that provisioning vlan must be removed from the second switch, or there's a risk of the provisioned node being able to access resources on the provisioning VLAN21:13
*** dsneddon has joined #openstack-ironic21:15
TheJuliaccstone: Is that logic burried in networking-cisco?21:23
TheJuliaspecifically the refusal to configure the second switch based upon pxe_enabled?21:23
* TheJulia wonders if networking-ansible could one day be useful21:24
ccstoneYeah - it seems that the switch only gets configured during the provisioning phase if pxe_enabled on the port is true - so it sort of feels like it's treated as if there's no port group at all during the provisioning phase, these were the same issues we were having before we could use port groups (nova-mitaka). (After provisioning it works exactly as expected)21:29
*** Lucas_Gray has joined #openstack-ironic21:31
TheJuliaOkay, that is partial logic that is likely causing that in ironic which we could likely patch or make changable21:31
TheJuliaccstone: neutron network interface  right? :)21:32
TheJuliainteresting...21:34
*** ijw has quit IRC21:34
ccstoneTheJulia: Yep :D Ideally we would have a port group with two ports, both with switch+portchannel config, one pxe_enabled, one pxe_disabled. It should configure both port channels (because those should always be the same) but since IPA treats them as separate interfaces, we need to only give DHCP to one of them. Otherwise we have 2x nics with different IPs behind the same port channel.21:36
TheJuliaWell, it is interesting because when we sort portgroup data, pxe_enabled should be set21:36
*** ijw has joined #openstack-ironic21:36
TheJuliabut I'm only looking at part of the path21:36
* TheJulia is still looking21:36
ccstoneso neutron should only create a DHCP lease for either the pxe_enabled port, or (ideally) the port address on the port group21:36
*** ianw_pto is now known as ianw21:37
ccstoneOr at least this is how it seems from my tinkering last night and how we were able to get around it :D21:38
TheJuliarocky right?21:38
eanderssonYep21:39
TheJuliaso I guess, we basically still need to plug the port, but not do PXE config.... is that correct?21:40
*** ijw has quit IRC21:41
TheJuliawhat if both ports are labeled with pxe_enabled?21:41
eanderssonThat almost works21:41
TheJuliahowso?21:42
TheJuliaand how not, trying to compare/contrast with the code on my other monitor :)21:42
TheJuliaeandersson: ccstone: I guess my impression is the attempt is to throw all provisioning traffic to one side of the switching fabric?21:55
ccstoneYeah - first attempt was with pxe_enabled on both, which does configure the switch exactly the way we want. At that point the problem is IPA and Neutron - Neutron supplies DHCP info for each port MAC address individually, so we have two independent configs on the same port channel. So one fix would be for neutron to still only provide one DHCP interface, or for IPA to never bring up eth121:57
ccstoneYeah, since it's very unlikely we can do LACP within the IPA image, we need to make sure eth1 doesn't interfere with anything (don't come up, absolutely don't ask for a DHCP address, etc)21:58
ccstoneA hacky fix that I was thinking of was just putting a dummy MAC on the 2nd NIC of the port group. There are no cases where we want neutron to give a unique IP to that second NIC. We either want it to not work, or to be configured in a port group post-provision.21:59
ccstoneAnd the port group will ignore the dummy MAC we gave it21:59
ccstoneSo neutron will think it configured it, but the DHCP address is for the wrong MAC and it never comes up22:00
TheJuliaIts not a bad idea, except there is a bunch of predication on keeping that up to date22:03
* TheJulia ponders22:03
TheJuliaccstone: what if an IP is assigned but DHCP is not offered?22:05
ccstoneTheJulia: in our case that would work (both are pxe_enabled, both DHCP only offered to one MAC?) That would configure both sides of the port channel correctly. eth1 would attempt to come up but fail. Since we have 'no lacp suspend-individual' set on ports (which allows them to be standalone), as long as eth1 fails to become active then we're good.22:07
TheJuliaoh22:08
TheJuliashoot22:08
ccstoneWe run into an issue only when a: the port channel config on both switches differs, or b: both interfaces on the host come up independently because neutron gave them different DHCP IPs, but are supposed to be part of a single port channel22:08
TheJuliaso dhcp at all is going to bring up link carrier on eth122:08
ccstoneYeah.. Honestly feels like something we could fix in IPA if we just never brought eth1 up. That's how PXE works IIRC, it never tries eth122:09
TheJuliathen again, well behaved dhcp clients also down the port after failing....22:09
TheJuliaThat is correct22:09
ccstoneYeah, an active port with no IP will not interfere with us from what I've been noticing.22:09
ccstoneSo as long as eth1 never gets an IP from DHCP, it's still OK that it's link up22:10
*** ijw has joined #openstack-ironic22:10
ccstone(again, this is just our cisco hardware, this could be different elsewhere)22:10
TheJuliaccstone: interesting, I wonder if that is a safety measure in the switch...22:10
*** ijw has quit IRC22:13
TheJuliaccstone: what if we admin state down'ed it?22:14
*** ijw has joined #openstack-ironic22:14
TheJuliathe second port that is?22:14
*** rpioso is now known as rpioso|afk22:14
ijwI sense networking22:14
TheJuliaijw: indeed22:15
ijwAh, the old PXE/bond problem?22:15
*** rh-jelabarre has quit IRC22:15
TheJuliaijw: indeed!22:15
TheJuliacross-switch as well!22:15
ijwYup22:15
TheJuliaI don't think we can tell neutron not to actually do a dhcp entry for an individual port :\22:16
ijwBreak the port group (and you can leave both ports up if you like), and things work, which it seems you have...22:16
ijwNo, I think you can only disable DHCP for the whole network22:16
* TheJulia wonders what exactly admin state down does22:16
ijwIf only there were some sort of gathering of teams where you could ask people for that sort of thing22:16
TheJuliaheh22:17
ijwIt is literally port-down no-link, I think, and as such you don't have to remove the DHCP entry22:17
TheJuliaOnly if there is beer or whisky22:17
ijwIn Denver there is much beer22:17
TheJulia++22:17
TheJuliaGuess it depends on the ml2 driver if it would honor the port admin state down bit22:18
ijwSorry, the 'cisco' bit pinged me or I would have never spotted this, but seems to me that you really want both interfaces to have DHCP entries in the right circumstances, and for the same address22:18
ijw(spitballing a bit)22:18
TheJuliaOh wow, there IS a "don't allocate an ip" flag22:18
ijwPerhaps one option would be not to use Neutron's DHCP for the provisioning network since it doesn't do what you want.  You could run your own22:19
ijwThat does work - ports don't have to have IPs at all (and the only reason the flag is there is because it was so easy to do it by accident)22:19
TheJuliaijw: ccstone's issue is a little different than that because they are doing cross-chassis lacp and if only one side gets configured bad things happen22:20
ijwYeah, that would probably end badly22:20
ijwBut bonding is bad, you want ECMP :)22:21
TheJuliaEh, I'm an OSPF (with ECMP...) girl.22:21
*** sleterrier has joined #openstack-ironic22:25
sleterrierHey there. I am not sure if this is the best place to ask but I figured there must be a good pool of cloud-init experts around here.22:28
sleterrierI am trying to overwrite the config of growpart cloud-init, but without having to pass any user_data22:28
TheJuliasleterrier: One warning, most people are off/away today, but we do have some folks here22:28
ijwAlso #cloud-init is full of friendly folks22:29
TheJuliasleterrier: if memory serves, it is static in the code path only controlled by user-data :\22:29
TheJuliasleterrier: but yeah, #cloud-init is likely your best bet for ideas.22:29
sleterrierCould I drop a file somewhere in /var/lib/cloud/ instead of passing the following user_data:22:30
TheJuliasleterrier: The other option may be to actually bake the config in the images.... the default config includes the flag to growpart if memory serves22:30
TheJuliasleterrier: That would totally be a #cloud-init question :\22:30
TheJuliabut if you can influence the config by dropping a file, you can inject files22:30
TheJuliaI'm 95% sure it unpacks files first22:30
sleterrierhttp://paste.openstack.org/show/749557/22:31
sleterrierOk thanks TheJulia !22:31
*** Goneri has joined #openstack-ironic22:42
TheJuliaccstone: ijw might be able to provide something of a quick sanity check, but I suspect something like https://gist.github.com/juliakreger/4b56b0c67c2776b54815dfcc02847c04 might work... (missing a config entry that would need to be created.)22:44
ijwSo if you're looking for Neutron DHCP to leave those ports alone - which is what I imagine you're after - then that looks right to me22:48
ccstoneThat looks like it'd be good to me too. I've still got a couple of nodes to try deploying to shortly and can try patching that and see how it works.22:55
TheJuliaccstone: adding config option to the gist22:58
TheJuliaccstone: done, running unit tests locally22:58
TheJuliacurrent gist revision passes unit tests, so if your conductor setting is flipped.... it _should_ work for creating ports. Digging through the other paths now23:00
TheJuliaremove_ports_from_network needs logic too23:01
TheJuliaupdated again, unit tests running. I'll need to write tests and upload this into review once it is back up23:05
TheJuliapython3 unit tests pass, pep8 passes, so... should be mostly harmless in the default state, true will change things of course23:09

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!