Containers sometimes stuck in Networking state when scaling up

I was having an issue with the same symptoms as #2571. But it appears to be a different issue (my networks don't appear to overlap, local is <IP_ADDRESS>/16). Containers that get scheduled on a certain host don't startup and are stuck in "Networking" state in UI.
Logs from the rancher-agent container (removing the nsenter lines since there are tons of them):
time="2015-11-16T23:51:23Z" level="error" msg="Couldn't find container for id." error="No such container: 43887083-5910-4cb4-bc6b-9a8e8c512b44" id="43887083-5910-4cb4-bc6b-9a8e8c512b44"
time="2015-11-16T23:51:23Z" level="error" msg="Error getting machine info." error="unable to get \"machine info\" from \"http://<IP_ADDRESS>:9344/api/v1.3/machine\": Get http://<IP_ADDRESS>:9344/api/v1.3/machine: dial tcp <IP_ADDRESS>:9344: connection refused"
time="2015-11-16T23:51:31Z" level="info" msg="Processing event: &docker.APIEvents{Status:\"start\", ID:\"16d2e56df5ab92b73d0f625551c87e0c418e182f55b47cc31d8f92ba30b6c495\", From:\"docker-reg-stg:8443/lims-taskscheduler:2.24.173\", Time:1447717891}"
time="2015-11-16T23:51:31Z" level="info" msg="Assigning IP [<IP_ADDRESS>/16], ContainerId [16d2e56df5ab92b73d0f625551c87e0c418e182f55b47cc31d8f92ba30b6c495], Pid [21450]"
time="2015-11-16T23:51:31Z" level="info" msg="Processing event: &docker.APIEvents{Status:\"start\", ID:\"16d2e56df5ab92b73d0f625551c87e0c418e182f55b47cc31d8f92ba30b6c495\", From:\"-simulated-\", Time:0}"
time="2015-11-16T23:51:31Z" level="info" msg="Container locked. Can't run StartHandler. ID: [16d2e56df5ab92b73d0f625551c87e0c418e182f55b47cc31d8f92ba30b6c495]"
time="2015-11-16T23:51:42Z" level="error" msg="Couldn't find container for id." error="No such container: 43887083-5910-4cb4-bc6b-9a8e8c512b44" id="43887083-5910-4cb4-bc6b-9a8e8c512b44"
time="2015-11-16T23:51:42Z" level="error" msg="Error getting machine info." error="unable to get \"machine info\" from \"http://<IP_ADDRESS>:9344/api/v1.3/machine\": Get http://<IP_ADDRESS>:9344/api/v1.3/machine: dial tcp <IP_ADDRESS>:9344: connection refused"

Lines from the networking container (agent-instance image):
INFO: ROOT -> ./etc/
INFO: ROOT -> ./etc/monit/
INFO: ROOT -> ./etc/monit/conf.d/
INFO: ROOT -> ./etc/monit/conf.d/rancher-dns
INFO: ROOT -> ./etc/init.d/
INFO: ROOT -> ./etc/init.d/rancher-dns
 * rancher-dns is running
 * Stopping rancher-dns configuration rancher-dns
   ...done.
 * Starting rancher-dns configuration rancher-dns
   ...done.
INFO: Sending rancher-dns applied 1-f7a323a556662cba4edbce4b10c3e41fa93247776a7e1f7f963805cf33ce85a4
INFO: Getting host-api
INFO: Updating host-api
INFO: Downloading https://rancher.natera.com/v1//configcontent//host-api current=
INFO: Running /var/lib/cattle/download/host-api/1-cbed785205aa661fd5fff3598faf04649a9a4743bae83643aacdc9e7b3d5289c/apply.sh
INFO: Sending host-api applied 1-cbed785205aa661fd5fff3598faf04649a9a4743bae83643aacdc9e7b3d5289c
INFO: HOME -> ./
INFO: HOME -> ./etc/
INFO: HOME -> ./etc/cattle/
INFO: HOME -> ./etc/cattle/startup-env
INFO: ROOT -> ./
INFO: ROOT -> ./etc/
INFO: ROOT -> ./etc/init.d/
INFO: ROOT -> ./etc/init.d/agent-instance-startup
INFO: Sending agent-instance-startup applied 4-2a88131eee029195e9789b6fe511e1fc9e5c5a540bffa62624a64eba08697665
Starting monit daemon with http interface at [localhost:2812]

Logs from rancher-server container (with nsenter stuff filtered out):
2015-11-16 23:50:29,973 ERROR [:] [] [] [] [ecutorService-6] [i.c.p.a.s.ping.impl.PingMonitorImpl ] Failed to get ping from agent [1] count [1]
2015-11-16 23:50:32,839 ERROR [:] [] [] [] [ecutorService-1] [.p.c.v.i.ConfigItemStatusManagerImpl] Error updating item(s) [ipsec-hosts, hosts, iptables, healthcheck] on [agent:3] io.cattle.platform.eventing.exception.EventExecutionException: d22b566f-25b9-480d-be90-e22b8aa6cdf7 : ('Connection aborted.', error(111, 'ECONNREFUSED'))
	at io.cattle.platform.eventing.exception.EventExecutionException.fromEvent(EventExecutionException.java:53) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.FutureEventListener.onEvent(FutureEventListener.java:47) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.AbstractThreadPoolingEventService$2.doRun(AbstractThreadPoolingEventService.java:135) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.NoExceptionRunnable.runInContext(NoExceptionRunnable.java:13) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:108) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_85]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_85]
	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_85]

2015-11-16 23:50:32,840 ERROR [:] [] [] [] [ecutorService-1] [.p.c.v.i.ConfigItemStatusManagerImpl] Error updating item(s) [ipsec-hosts, hosts, iptables, healthcheck] on [agent:3] io.cattle.platform.eventing.exception.EventExecutionException: d22b566f-25b9-480d-be90-e22b8aa6cdf7 : ('Connection aborted.', error(111, 'ECONNREFUSED'))
	at io.cattle.platform.eventing.exception.EventExecutionException.fromEvent(EventExecutionException.java:53) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.FutureEventListener.onEvent(FutureEventListener.java:47) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.AbstractThreadPoolingEventService$2.doRun(AbstractThreadPoolingEventService.java:135) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.NoExceptionRunnable.runInContext(NoExceptionRunnable.java:13) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:108) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_85]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_85]
	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_85]

2015-11-16 23:50:32,841 ERROR [:] [] [] [] [ecutorService-1] [.p.c.v.i.ConfigItemStatusManagerImpl] Error updating item(s) [ipsec-hosts, hosts, iptables, healthcheck] on [agent:3] io.cattle.platform.eventing.exception.EventExecutionException: d22b566f-25b9-480d-be90-e22b8aa6cdf7 : ('Connection aborted.', error(111, 'ECONNREFUSED'))
	at io.cattle.platform.eventing.exception.EventExecutionException.fromEvent(EventExecutionException.java:53) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.FutureEventListener.onEvent(FutureEventListener.java:47) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.AbstractThreadPoolingEventService$2.doRun(AbstractThreadPoolingEventService.java:135) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.NoExceptionRunnable.runInContext(NoExceptionRunnable.java:13) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:108) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_85]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_85]
	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_85]

2015-11-16 23:50:32,841 ERROR [f81364bc-1128-48e8-9b3b-1dae91bfceed:166] [instance:14->nic:14] [instance.start->(InstanceStart)->nic.activate] [] [ecutorService-9] [c.p.e.p.i.DefaultProcessInstanceImpl] Unknown exception io.cattle.platform.eventing.exception.EventExecutionException: d22b566f-25b9-480d-be90-e22b8aa6cdf7 : ('Connection aborted.', error(111, 'ECONNREFUSED'))
	at io.cattle.platform.eventing.exception.EventExecutionException.fromEvent(EventExecutionException.java:53) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.FutureEventListener.onEvent(FutureEventListener.java:47) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at io.cattle.platform.eventing.impl.AbstractThreadPoolingEventService$2.doRun(AbstractThreadPoolingEventService.java:135) ~[cattle-framework-eventing-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.NoExceptionRunnable.runInContext(NoExceptionRunnable.java:13) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) ~[cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55) [cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:108) [cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52) [cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) [cattle-framework-managed-context-0.5.0-SNAPSHOT.jar:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_85]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_85]
	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_85]

2015-11-16 23:50:32,842 ERROR [f81364bc-1128-48e8-9b3b-1dae91bfceed:166] [instance:14] [instance.start->(InstanceStart)] [] [ecutorService-9] [i.c.p.process.instance.InstanceStart] Failed to Networking for instance [14]
2015-11-16 23:50:34,972 ERROR [:] [] [] [] [ecutorService-3] [i.c.p.a.s.ping.impl.PingMonitorImpl ] Failed to get ping from agent [1] count [2]
time="2015-11-16T23:50:41Z" level=info msg="Registering backend for host [0a86608c-a4cd-4fca-8665-59d70447bbdd]"
2015-11-16 23:50:45,811 ERROR [:] [] [] [] [ecutorService-8] [i.c.p.a.s.ping.impl.PingMonitorImpl ] Failed to get ping from agent [1] count [1]
time="2015-11-16T23:53:08Z" level=error msg="Error parsing token." error="token is expired"
time="2015-11-16T23:54:08Z" level=error msg="Error parsing token." error="token is expired"

Any ideas what might be going on here?
Rancher 0.44.0 installed on Ubuntu 14.04. Agent on Ubuntu 12.04. both Docker 1.9.0.

I'm noticing that if I restart the Docker daemon on that agent (restarting the agent and networking agent), the the containers waiting on that host do come up (along with the others that were running). But then newly scheduled ones don't seem to work after that (by me just scaling a test stack of ubuntu containers).

Is this still the server and host setup that you had migrated over from another box? Or is this a new install?
When the containers are in "Networking" state, have you tried to SSH into the host to make sure Docker isn't hung? By doing a basic docker ps would let you know if docker is still working.
Have you tried using the network agent to ping containers on other hosts to make sure cross host communication is still in tact?

It is the same machine. But I wiped /var/lib/rancher and the MySQL database and started over. Is there anything else that was persistent?
The logs are from the agent host in question. The host isn't hung up and Docker seems to be working fine (I can manually launch containers just fine).
I just tried grabbing a shell on the network agent and host to host communication seems to work. Here are pings to a container and the network agent on another host:
$ sudo docker exec -it 005 bash
root@0056c75aa45e:/var/lib/docker/aufs/mnt/0056c75aa45e1ae8def47e81ccc33105212bcc4789e5d39f034e15d732e34c37# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_req=5 ttl=63 time=0.646 ms
64 bytes from <IP_ADDRESS>: icmp_req=6 ttl=63 time=0.438 ms
64 bytes from <IP_ADDRESS>: icmp_req=7 ttl=63 time=0.478 ms
64 bytes from <IP_ADDRESS>: icmp_req=8 ttl=63 time=0.458 ms
64 bytes from <IP_ADDRESS>: icmp_req=9 ttl=63 time=0.406 ms
64 bytes from <IP_ADDRESS>: icmp_req=10 ttl=63 time=0.439 ms
64 bytes from <IP_ADDRESS>: icmp_req=11 ttl=63 time=0.485 ms
^C
--- <IP_ADDRESS> ping statistics ---
11 packets transmitted, 7 received, 36% packet loss, time 10022ms
rtt min/avg/max/mdev = 0.406/0.478/0.646/0.076 ms
root@0056c75aa45e:/var/lib/docker/aufs/mnt/0056c75aa45e1ae8def47e81ccc33105212bcc4789e5d39f034e15d732e34c37# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_req=1 ttl=64 time=0.401 ms
64 bytes from <IP_ADDRESS>: icmp_req=2 ttl=64 time=0.391 ms
64 bytes from <IP_ADDRESS>: icmp_req=3 ttl=64 time=0.426 ms
64 bytes from <IP_ADDRESS>: icmp_req=4 ttl=64 time=0.449 ms
^C
--- <IP_ADDRESS> ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.391/0.416/0.449/0.033 ms

The first couple packets didn't get through, not sure if that means anything...

The delay before the ping is successful is a known issue. The next time you do it, it will be immediate.
I don't believe there is anything else persistent. It seems like there is some kind of networking/connection issue based on the logs.
Have you looked through the troubleshooting docs to see if anything pertains to you? Specifically, are your IP tables set up okay?
http://docs.rancher.com/rancher/faqs/troubleshooting/
I can't see anything specific that jumps out.

They look good. The IP for the pre-routing rules matches the agent-instance container. I compared the rules to another working agent and they line up exact (except for the IPs).
The only thing I notice is that this host is Ubuntu 12.04 where the other working ones are 14.04. I'll add some more 12.04 hosts and see if they exhibit the same behavior.
If it is just a one-off broken host that I can't reproduce then I'll close. But i really want to try Rancher out for some services and would hate to run into a show-stopping bug like this after setting everything up :(

I feel like it's a one-off broken host. I have a Ubuntu 12.04 host in my fresh setup and I have no issues with containers starting, so nothing to do with 12.04 hosts.
I don't know if something got corrupted when you have been migrating Rancher server and re-using hosts. It's hard for me to reproduce.

Yea, I'm starting to feel the same way. I just removed the label constraint from this host and added it to another 12.04 host and just scaled my test form 1 to 20 and back again a couple times with no issues. I'll dig some more and post if I find anything relevant. But it doesn't seem to be affecting my second test at least.

I solved this and wanted to share in case someone else runs into it. I don't know the exact cause. But this particular host was running kernel 3.2.x. I upgraded to kernel 3.13.0 (sudo apt-get install linux-image-3.13.0-68-generic) and it is working now as intended.


Tidy Json class

Simplify Json class and add tests

Is this ready to merge?

Yup :+1:
I can't think of a way to make the encode fail - since we add array as input type


Support for Alpine V3

Alpine devtools don't recognize components when using the latest version of Alpine (V3). Maybe I'm missing something.

@aguillen-js Just out of interest what browser and OS are you using? I'll see if I can declutter the auto scrollbar styles.

So I had a quick look at how we might support V3
Core functionality (current):

[x] get initial data
[x] watch for data changes
[x] edit data
[ ] catch eval errors

Future functionality:

[ ] Stores/global data support
[ ] $dispatch support

Get initial data
const xData = document.querySelector('[x-data]')._x_dataStack[0]
const dataKeys = Object.keys(xData).filter(name => !name.startsWith('$'))

Watch for data changes
const xData = document.querySelector('[x-data]')._x_dataStack[0]
const dataKeys = Object.keys(xData).filter(name => !name.startsWith('$'))

// add an x-effect that sends us back the data
// @todo: how to deal with an x-data that already has an x-effect, is it fine to `{existing};hook(aa);` it? Probably not, might be better to insert a new element and do it that way
document.querySelector('[x-data]').setAttribute('x-effect', `console.log({${dataKeys.join(',')}})`)

Edit data
const xData = document.querySelector('[x-data]')._x_dataStack[0]

xData.count = 120

Catch eval errors
Changes required to Alpine core (so that errors are emitted with the right information).
Currently alpine-next doesn't even log a warning.

@aguillen-js Just out of interest what browser and OS are you using? I'll see if I can declutter the auto scrollbar styles.

@stephenoldham Hello, I am using Windows 10. Regarding the browser, when I do web development I have Chrome, Firefox Developer Edition and Edge running, I like to check everything in the most recent version of each browser. The screenshot in question was taken from Chrome.


snpm/host.pp validate_re validate on string

I get errors when running "bundle exec rake spec SPEC_OPTS='--format documentation'". validate_re can only operate on strings.
collectd::plugin::snmp::host
default params
should contain File[snmp-host-foo.example.com.conf] with ensure => "present" and path => "/etc/collectd/conf.d/25-snmp-host-foo.example.com.conf" (FAILED - 1)
should contain File[snmp-host-foo.example.com.conf] that notifies Service[collectd] (FAILED - 2)
should contain File[snmp-host-foo.example.com.conf] with content =~ // (FAILED - 3)
should contain File[snmp-host-foo.example.com.conf] with content =~ /<Host "foo.example.com">/ (FAILED - 4)
should contain File[snmp-host-foo.example.com.conf] with content =~ /Address "foo.example.com"/ (FAILED - 5)
should contain File[snmp-host-foo.example.com.conf] with content =~ /Version 1/ (FAILED - 6)
should contain File[snmp-host-foo.example.com.conf] with content =~ /Community "public"/ (FAILED - 7)
should contain File[snmp-host-foo.example.com.conf] with content !~ /Interval \d+/ (FAILED - 8)

Thanks for the contribution


Dynamic Reload of topic policies and KMS definitions

We could implement dynamic updating of policies and KMS definitions in Kroxylicious without it being implemented upstream.
We could set up watches on the files for changes, or naively reload the configuration periodically. Then on update we load it in and swap out the old set of policies.
Upstream offers the PolicyRepository so we could build it using this and PR it back.
Maybe there's some way to establish it as a pattern that could be used with other implementations, like if the TopicPolicies are stored externally in something like vault.
We could make this in-memory reloading implementation that can ask whether/when a delegate PolicyRepository has been modified and therefore that it's cache is invalid and it should reload. Maybe it's a two way thing since a modification is more like an event that should be pushed out of the delegate and reacted to in the caching reloader.

There's a bit more to it. io.strimzi.kafka.topicenc.EncryptionModule caches a map from topic -> EncrypterDecrypter with no expiry, so it's this class that would change. Maybe this method EncrypterDecrypter getTopicEncrypter(String topicName) is the bit that should be extracted into an interface.


[WIP] Overhaul of conductor

What Changed

Extend a contract
Switch flows for contracts
Smarter search index, only rebuild when visible contracts change
Smarter template filtering
Better, less brittle tests
Pull department into its own model

Issues

Fixes #113
Fixes #121

TODO

[x] Allow switching back and forth (handle IntegretyError when trying to move back to a previous flow)
[x] Flow switching tests
[ ] Handle completed contracts (#106)

Screencaps
Update metadata, extend contracts

Switching flows

@shellicious @hamhands
Open question -- this pull request is kinda getting out of hand. Should I complete the remainder of open work on this branch, or spin out into smaller feature branches?

@bsmithgall smaller branches sounds right.

+1 to what @shellicious said

Ok, I'll do PRs directly into this (conductor-detail-view) branch. We can examine those individually and then do a conductor mega-merge. This will let us continue deploying beacon/other fixes.


Add uppercase chars, and mix in highlighting

Love the project, it's a fun one!  :-)
I made a few tweaks that made it feel more "authentic" to me.  I added capital letters to the character set, and made a mix of ascii and kana the default.  Also, taking the idea from gdamore's pull request, I set about a third of the lead characters and two thirds of the remainder bold, making them brighter.
Aside from that, I also added on-the-fly speed controls ('-' to slow down, '+' to speed up, and '=' to set it back to the original speed), replaced the inline function call in main.go with a labeled loop, and did the same with the gotos in stream.go
I hope you like the changes.  I really enjoyed playing with this. :-)

Thats awesome! I've just merged it in, thanks!


SortEngine uses too much memory on aarch64 with pagesize=64K

What did you do?

Create a changefeed and then pause it
Run 20min sysbench insert, to prepare some events
Resume the changefeed

What did you expect to see?
No response
What did you see instead?

The root block is about 12GB, but TiCDC uses about 50GB exactly. I guess GC doesn't work fine.

=======================================

The red circles indicate default TiCDC configuration;
The green circles indicate patched TiCDC configuration without pebble block-cache.

Seems disable pebble block-cache can resolve the problem, although I don't know why.
Versions of the cluster
TiCDC version (execute cdc version):
v6.5.2

/severity critical

/report customer

It is hard to validate with unit tests because there are many conditions and no clear conclusions.


Feature/prettier end of line fix

Had hundreds of Prettier errors due to Prettier endOfLine conflicting with VS Code's end of line sequence settings. Adib Khan said I could change the prettier rules to include "endOfLine":"auto" since he doesn't care which end of line sequence any of us use so I did change the rules in .eslintrc.js.
Images:
ERROR:

ALL GOOD:

Ty for the awesome documentation.


Add the ClientMock

Codecov Report

Merging #16 into master will decrease coverage by 0.64%.
The diff coverage is 96%.

@@            Coverage Diff             @@
##           master      #16      +/-   ##
==========================================
- Coverage   98.83%   98.19%   -0.65%
==========================================
  Files           2        3       +1
  Lines         171      221      +50
==========================================
+ Hits          169      217      +48
- Misses          1        2       +1
- Partials        1        2       +1

Impacted Files
Coverage Δ

client_mock.go
96% <96%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b9efe41...6fbc77c. Read the comment docs.


app install node_modules in docker image with lockfile

Right now the dependencies for the app docker image are installed without a lockfile.
This is dangerous.
We can instead generate a lockfile from the mono-repo lockfile using https://www.npmjs.com/package/generate-lockfile

@enisdenjo @n1ru4l can it be closed now, with the new pnpm setup?

We now use the deploy command to create a node_modules folder inside the dist folder containing the necessary dependencies as per the lockfile (see here).