stork issueshttps://gitlab.isc.org/isc-projects/stork/-/issues2020-03-06T07:45:50Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/189Fix docker traffic-dhcp build2020-03-06T07:45:50ZMatthijs Mekkingmatthijs@isc.orgFix docker traffic-dhcp build0.5Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/180shared networks in db should be distinghuished by inet family2020-03-05T17:00:06ZMichal Nowikowskishared networks in db should be distinghuished by inet familyWhen there are 2 networks defined, one in dhcp4 and one in dhcp6 and they have the same name then creating LocalSubnets go wrong.When there are 2 networks defined, one in dhcp4 and one in dhcp6 and they have the same name then creating LocalSubnets go wrong.0.5https://gitlab.isc.org/isc-projects/stork/-/issues/179Parsing prefix delegation pool from Kea expects invalid format of the pool2020-03-04T18:36:34ZMarcin SiodelskiParsing prefix delegation pool from Kea expects invalid format of the poolThe current code assumes that the prefix delegation pool is specified like this:
```
"pd-pools": [
{
"prefix": 2001:db8:8::/56",
"delegated-len": 96
}
]
```
whereas the actual format is:
```
"pd-pools": [
{
...The current code assumes that the prefix delegation pool is specified like this:
```
"pd-pools": [
{
"prefix": 2001:db8:8::/56",
"delegated-len": 96
}
]
```
whereas the actual format is:
```
"pd-pools": [
{
"prefix": 2001:db8:8::",
"prefix-len": 56,
"delegated-len": 96
}
]
```
This parsing must be corrected.0.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/159when machine is deleted its app with configuration is not deleted2020-03-05T13:18:00ZMichal Nowikowskiwhen machine is deleted its app with configuration is not deletedThis is connected with @marcin redesign where deleted field will be removed. So them it should start just work.This is connected with @marcin redesign where deleted field will be removed. So them it should start just work.0.5https://gitlab.isc.org/isc-projects/stork/-/issues/148Adding the same machine after removing it causes db constraints errors2020-03-05T13:17:52ZMarcin SiodelskiAdding the same machine after removing it causes db constraints errorsWhile I was reviewing !63, I did the following test:
- I've added a machine with one Kea server having a subnet within the shared network. It did it fine, although didn't show the subnet because the logic there does not support subnets w...While I was reviewing !63, I did the following test:
- I've added a machine with one Kea server having a subnet within the shared network. It did it fine, although didn't show the subnet because the logic there does not support subnets within a shared network
- I removed the machine via the UI. The machine got marked as deleted in the db.
- I changed the configuration of the Kea server by making the subnet global rather than belong to a shared network.
- I used UI to add the machine. The machine was added again but an error was reported while adding the app because of the constraint violation:
```
RRO[2020-02-03 13:46:43] restimpl.go:150 problem with inserting app &{0 0001-01-01 00:00:00 +0000 UTC 0001-01-01 00:00:00 +0000 UTC 1 0xc0004ba900 kea 192.168.56.33 8000 false {1.7.3-git} { [0xc000194460 0xc0001b36c0 0xc0001b3730]}}: ERROR #23505 duplicate key value violates unique constraint "app_machine_id_ctrl_port_key
```
The machine was undeleted it seems but the app configuration remains old.0.5https://gitlab.isc.org/isc-projects/stork/-/issues/138Display of Kea hooks installed in Stork2020-03-03T16:20:51ZVicky Riskvicky@isc.orgDisplay of Kea hooks installed in Stork
**Describe the bug**
Looking at the stork demo running at http://stork.lab.isc.org:8080/machines/all
I can see that for the same application, if you look at it by first navigating to the machine and clicking on the application, you ca...
**Describe the bug**
Looking at the stork demo running at http://stork.lab.isc.org:8080/machines/all
I can see that for the same application, if you look at it by first navigating to the machine and clicking on the application, you can see the Kea hooks installed.
If you instead navigate directly to applications/Kea it says there are no hooks installed (for each of the 3 demo Kea servers that are set up). It even shows no hooks installed for the HA servers for which there is HA status shown, and I KNOW those must be running the HA hook.
**To Reproduce**
Steps to reproduce the behavior:
1. Navigate to the demo stork app
3. Select the pull down for Services and Select Kea
4. In the resulting table, click on the Kea version to bring up the detail display
5. Note there are no hooks listed
1. Now select the pull down for services and select Machines
1. Click on the word Kea under the Apps column to bring up the detail display
1. Note that there are now hooks listed.
Ponder the difference.
**Expected behavior**
I would expect since each of these screens is reporting the information about the Kea version and modules installed, that they would both show the same hooks installed.
**Environment:**
This is the version up on storklab as of 1/17/2020. I don't see a Stork version listed anywhere in the UI, but I believe it is 0.3.
If it matters, I was using the Brave browser, Version 1.1.23 Chromium: 79.0.3945.88 (Official Build) (64-bit)
**Additional Information**
![Screen_Shot_2020-01-17_at_2.38.46_PM](/uploads/bf9fb76e558e058168e598dfbaf2bade/Screen_Shot_2020-01-17_at_2.38.46_PM.png)![Screen_Shot_2020-01-17_at_2.41.53_PM](/uploads/2a65f8f3bbc8e03341b1527122c1b60c/Screen_Shot_2020-01-17_at_2.41.53_PM.png)0.5Vicky Riskvicky@isc.orgVicky Riskvicky@isc.org