| *** tonanhngo has joined #openstack-containers | 00:07 | |
| *** clsacramento has quit IRC | 00:12 | |
| *** Drago5 has joined #openstack-containers | 00:14 | |
| *** apuimedo has quit IRC | 00:18 | |
| *** dims_ has quit IRC | 00:20 | |
| *** vijendar_ has joined #openstack-containers | 00:25 | |
| *** vijendar has quit IRC | 00:25 | |
| *** vijendar1 has quit IRC | 00:26 | |
| *** vijendar has joined #openstack-containers | 00:30 | |
| *** dims has joined #openstack-containers | 00:31 | |
| *** srwilkers has quit IRC | 00:35 | |
| *** srwilkers has joined #openstack-containers | 00:38 | |
| *** vijendar has quit IRC | 00:41 | |
| *** vijendar_ has quit IRC | 00:41 | |
| *** vijendar has joined #openstack-containers | 00:42 | |
| *** vijendar1 has joined #openstack-containers | 00:47 | |
| openstackgerrit | feng.shengqin proposed openstack/python-magnumclient: suport insecure_registry in cluster-template https://review.openstack.org/392007 | 00:49 |
|---|---|---|
| *** Drago5 has quit IRC | 00:51 | |
| *** syed_ has quit IRC | 00:55 | |
| openstackgerrit | feng.shengqin proposed openstack/python-magnumclient: suport insecure_registry in cluster-template https://review.openstack.org/392007 | 00:58 |
| *** tonanhngo has quit IRC | 00:58 | |
| *** tushark has quit IRC | 01:01 | |
| *** dave-mccowan has joined #openstack-containers | 01:09 | |
| *** srwilkers has quit IRC | 01:09 | |
| *** vijendar1 has quit IRC | 01:15 | |
| *** vijendar has quit IRC | 01:15 | |
| *** vijendar has joined #openstack-containers | 01:16 | |
| *** Drago5 has joined #openstack-containers | 01:16 | |
| *** mtanino has quit IRC | 01:17 | |
| *** vijendar1 has joined #openstack-containers | 01:18 | |
| *** Wenzhi has joined #openstack-containers | 01:23 | |
| *** vijendar has quit IRC | 01:32 | |
| *** vijendar has joined #openstack-containers | 01:33 | |
| *** vijendar1 has quit IRC | 01:33 | |
| *** Guest56190 is now known as kevinza | 01:34 | |
| *** kevinza is now known as kevinz | 01:34 | |
| *** apuimedo has joined #openstack-containers | 01:36 | |
| *** srwilkers has joined #openstack-containers | 01:36 | |
| *** jmckind_ has quit IRC | 01:38 | |
| *** vijendar1 has joined #openstack-containers | 01:38 | |
| *** sergmelikyan has joined #openstack-containers | 01:39 | |
| *** apuimedo has quit IRC | 01:44 | |
| *** x00350071_ has quit IRC | 01:44 | |
| *** Drago5 has quit IRC | 01:50 | |
| *** mtanino has joined #openstack-containers | 02:05 | |
| *** srwilkers has quit IRC | 02:05 | |
| *** mkrai has joined #openstack-containers | 02:32 | |
| *** vijendar_ has joined #openstack-containers | 02:38 | |
| *** vijendar1 has quit IRC | 02:38 | |
| *** vijendar has quit IRC | 02:38 | |
| *** ramishra has joined #openstack-containers | 02:40 | |
| *** vijendar has joined #openstack-containers | 02:41 | |
| *** sergmelikyan has quit IRC | 02:42 | |
| *** vijendar_ has quit IRC | 02:43 | |
| *** vijendar1 has joined #openstack-containers | 02:43 | |
| *** yuanying has quit IRC | 02:47 | |
| *** yuanying has joined #openstack-containers | 02:48 | |
| *** yuanying has quit IRC | 02:52 | |
| *** dave-mccowan has quit IRC | 02:53 | |
| *** sergmelikyan has joined #openstack-containers | 03:02 | |
| *** sergmelikyan has quit IRC | 03:06 | |
| *** sergmelikyan has joined #openstack-containers | 03:08 | |
| *** tonanhngo has joined #openstack-containers | 03:10 | |
| *** tonanhngo has quit IRC | 03:15 | |
| *** dimtruck is now known as zz_dimtruck | 03:20 | |
| *** Jeffrey4l has joined #openstack-containers | 03:21 | |
| *** ramishra has quit IRC | 03:21 | |
| *** mtanino has quit IRC | 03:22 | |
| openstackgerrit | chen.xing proposed openstack/magnum: [instll] Update a more simple rabbitmq configuration https://review.openstack.org/392025 | 03:29 |
| *** sergmelikyan has quit IRC | 03:31 | |
| *** zz_dimtruck is now known as dimtruck | 03:32 | |
| openstackgerrit | chen.xing proposed openstack/magnum: [instll] Update a more simple rabbitmq configuration https://review.openstack.org/392025 | 03:33 |
| *** mkrai has quit IRC | 03:43 | |
| *** sergmelikyan has joined #openstack-containers | 03:57 | |
| *** ramishra has joined #openstack-containers | 04:06 | |
| *** mtanino has joined #openstack-containers | 04:12 | |
| *** janonymous has joined #openstack-containers | 04:12 | |
| *** Wenzhi_ has joined #openstack-containers | 04:17 | |
| *** vijendar1 has quit IRC | 04:17 | |
| *** vijendar has quit IRC | 04:17 | |
| *** Wenzhi has quit IRC | 04:20 | |
| *** duonghq_ has joined #openstack-containers | 04:25 | |
| *** sergmelikyan has quit IRC | 04:38 | |
| *** dimtruck is now known as zz_dimtruck | 04:42 | |
| *** yuanying has joined #openstack-containers | 04:42 | |
| *** takashi has joined #openstack-containers | 04:49 | |
| *** yuanying has quit IRC | 04:57 | |
| *** yuanying has joined #openstack-containers | 04:58 | |
| *** yuanying has quit IRC | 05:08 | |
| *** yuanying has joined #openstack-containers | 05:12 | |
| *** yuanying has quit IRC | 05:28 | |
| *** sheel has joined #openstack-containers | 05:28 | |
| *** askb has quit IRC | 05:29 | |
| *** yuanying has joined #openstack-containers | 05:32 | |
| *** yuanying has quit IRC | 05:36 | |
| *** yuanying has joined #openstack-containers | 05:36 | |
| *** yasemin has joined #openstack-containers | 05:37 | |
| *** yasemin has left #openstack-containers | 05:37 | |
| *** anush has joined #openstack-containers | 05:38 | |
| openstackgerrit | Merged openstack/python-magnumclient: Cluster creation command returns complete cluster uuid https://review.openstack.org/390815 | 05:42 |
| openstackgerrit | Ryosuke Mizuno proposed openstack/magnum-ui: Add javascript tests for clusterSignCertificate model and service https://review.openstack.org/392038 | 05:54 |
| *** mtanino has quit IRC | 05:56 | |
| *** ramishra_ has joined #openstack-containers | 06:00 | |
| *** ramishra has quit IRC | 06:02 | |
| *** takashi has quit IRC | 06:06 | |
| *** tonanhngo has joined #openstack-containers | 06:11 | |
| *** yuanying has quit IRC | 06:11 | |
| *** mtanino has joined #openstack-containers | 06:15 | |
| *** tonanhngo has quit IRC | 06:15 | |
| *** yuanying has joined #openstack-containers | 06:19 | |
| *** mtanino has quit IRC | 06:19 | |
| *** chetna has joined #openstack-containers | 06:19 | |
| *** chetna has quit IRC | 06:21 | |
| *** janonymous has quit IRC | 06:24 | |
| *** rcernin has joined #openstack-containers | 06:29 | |
| *** yuanying has quit IRC | 06:40 | |
| *** yuanying has joined #openstack-containers | 06:57 | |
| *** yuanying has quit IRC | 07:02 | |
| *** takashi has joined #openstack-containers | 07:19 | |
| *** AlexeyAbashkin has quit IRC | 07:20 | |
| *** chetna has joined #openstack-containers | 07:21 | |
| *** chetna has quit IRC | 07:22 | |
| *** belmoreira has joined #openstack-containers | 07:26 | |
| *** yuanying has joined #openstack-containers | 07:29 | |
| *** tonanhngo has joined #openstack-containers | 07:30 | |
| *** AlexeyAbashkin has joined #openstack-containers | 07:33 | |
| *** tonanhngo has quit IRC | 07:35 | |
| *** noama has joined #openstack-containers | 07:38 | |
| *** yuanying has quit IRC | 07:48 | |
| *** yuanying has joined #openstack-containers | 07:50 | |
| *** yuanying has quit IRC | 07:57 | |
| *** yuanying has joined #openstack-containers | 08:00 | |
| *** yuanying_ has joined #openstack-containers | 08:07 | |
| *** yuanying has quit IRC | 08:08 | |
| openstackgerrit | Michael Liu proposed openstack/magnum: magnum support cni network driver https://review.openstack.org/391718 | 08:09 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/magnum-ui: Imported Translations from Zanata https://review.openstack.org/391371 | 08:12 |
| *** Wenzhi has joined #openstack-containers | 08:20 | |
| *** Wenzhi_ has quit IRC | 08:21 | |
| *** Wenzhi has quit IRC | 08:26 | |
| *** chetna has joined #openstack-containers | 09:07 | |
| *** chetna has quit IRC | 09:08 | |
| openstackgerrit | Merged openstack/magnum-ui: Imported Translations from Zanata https://review.openstack.org/391371 | 09:35 |
| *** swatson_ has quit IRC | 09:35 | |
| *** yuanying_ has quit IRC | 09:44 | |
| *** yuanying has joined #openstack-containers | 09:44 | |
| *** duonghq_ has quit IRC | 09:45 | |
| *** dootniz is now known as kragniz | 09:59 | |
| *** tonanhngo has joined #openstack-containers | 10:22 | |
| *** tonanhngo has quit IRC | 10:27 | |
| *** chetna has joined #openstack-containers | 10:55 | |
| *** chetna has quit IRC | 10:56 | |
| *** yuanying has quit IRC | 10:56 | |
| *** chhavi has joined #openstack-containers | 11:11 | |
| openstackgerrit | Michael Liu proposed openstack/magnum: magnum support cni network driver https://review.openstack.org/391718 | 11:23 |
| openstackgerrit | Michael Liu proposed openstack/magnum: magnum support cni network driver https://review.openstack.org/391718 | 11:26 |
| *** srwilkers has joined #openstack-containers | 11:35 | |
| *** EricGonczer_ has joined #openstack-containers | 11:47 | |
| *** EricGonc_ has joined #openstack-containers | 11:51 | |
| *** EricGonczer_ has quit IRC | 11:52 | |
| *** EricGonc_ has quit IRC | 11:52 | |
| *** EricGonczer_ has joined #openstack-containers | 11:55 | |
| *** jmckind has joined #openstack-containers | 11:57 | |
| *** jmckind has quit IRC | 12:26 | |
| *** JoseMello has joined #openstack-containers | 12:30 | |
| *** jerrygb_ has quit IRC | 12:38 | |
| *** dave-mccowan has joined #openstack-containers | 12:46 | |
| *** jerrygb has joined #openstack-containers | 12:52 | |
| *** srwilkers has quit IRC | 12:52 | |
| *** ramishra_ has quit IRC | 12:53 | |
| *** chetna has joined #openstack-containers | 12:56 | |
| *** chetna has quit IRC | 12:58 | |
| *** vijendar has joined #openstack-containers | 12:58 | |
| *** vijendar1 has joined #openstack-containers | 12:59 | |
| *** ramishra has joined #openstack-containers | 13:06 | |
| openstackgerrit | Spyros Trigazis proposed openstack/magnum: Add user-domain in role creation https://review.openstack.org/391779 | 13:06 |
| *** takashi has quit IRC | 13:12 | |
| *** chetna has joined #openstack-containers | 13:12 | |
| *** chetna has quit IRC | 13:13 | |
| *** srwilkers has joined #openstack-containers | 13:19 | |
| *** EricGonczer_ has quit IRC | 13:25 | |
| *** EricGonczer_ has joined #openstack-containers | 13:26 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/magnum: Updated from global requirements https://review.openstack.org/388319 | 13:28 |
| *** EricGonczer_ has quit IRC | 13:30 | |
| *** EricGonczer_ has joined #openstack-containers | 13:31 | |
| *** fragatina has joined #openstack-containers | 13:32 | |
| *** yuanying has joined #openstack-containers | 13:32 | |
| *** fragatina has quit IRC | 13:32 | |
| *** fragatina has joined #openstack-containers | 13:33 | |
| *** kaliya has joined #openstack-containers | 13:33 | |
| *** absubram has joined #openstack-containers | 13:36 | |
| *** chetna has joined #openstack-containers | 13:43 | |
| *** chetna has quit IRC | 13:44 | |
| *** EricGonczer_ has quit IRC | 13:45 | |
| *** EricGonczer_ has joined #openstack-containers | 13:46 | |
| *** fragatina has quit IRC | 13:48 | |
| *** vijendar has quit IRC | 13:58 | |
| *** jerrygb_ has joined #openstack-containers | 14:00 | |
| *** sergmelikyan has joined #openstack-containers | 14:00 | |
| *** yuanying has quit IRC | 14:01 | |
| *** dave-mccowan has quit IRC | 14:02 | |
| *** jerrygb has quit IRC | 14:02 | |
| *** jmckind has joined #openstack-containers | 14:05 | |
| *** vijendar has joined #openstack-containers | 14:10 | |
| *** mtanino has joined #openstack-containers | 14:13 | |
| *** Drago5 has joined #openstack-containers | 14:14 | |
| *** zz_dimtruck is now known as dimtruck | 14:14 | |
| *** anushkrishnamurt has joined #openstack-containers | 14:15 | |
| *** randallburt has joined #openstack-containers | 14:16 | |
| *** Drago5 has quit IRC | 14:19 | |
| *** randallburt has quit IRC | 14:21 | |
| *** vijendar has quit IRC | 14:25 | |
| *** GB21 has joined #openstack-containers | 14:26 | |
| *** Drago5 has joined #openstack-containers | 14:28 | |
| *** randallburt has joined #openstack-containers | 14:28 | |
| *** jerrygb has joined #openstack-containers | 14:31 | |
| *** randallburt has quit IRC | 14:33 | |
| *** jerrygb_ has quit IRC | 14:33 | |
| *** sergmelikyan has quit IRC | 14:36 | |
| *** randallburt has joined #openstack-containers | 14:36 | |
| *** chris_hultin|AWA is now known as chris_hultin | 14:38 | |
| *** vijendar has joined #openstack-containers | 14:40 | |
| *** vijendar has quit IRC | 14:42 | |
| *** vijendar has joined #openstack-containers | 14:46 | |
| *** Drago5 has quit IRC | 14:48 | |
| *** dave-mccowan has joined #openstack-containers | 14:48 | |
| *** DanyC has joined #openstack-containers | 14:48 | |
| *** DanyC has left #openstack-containers | 14:54 | |
| *** vijendar has quit IRC | 14:54 | |
| *** vijendar has joined #openstack-containers | 14:59 | |
| *** chris_hultin is now known as chris_hultin|AWA | 15:00 | |
| *** dave-mccowan has quit IRC | 15:00 | |
| *** jerrygb_ has joined #openstack-containers | 15:00 | |
| *** vijendar2 has joined #openstack-containers | 15:01 | |
| *** Drago5 has joined #openstack-containers | 15:01 | |
| *** vijendar1 has quit IRC | 15:03 | |
| *** jerrygb has quit IRC | 15:03 | |
| *** chris_hultin|AWA is now known as chris_hultin | 15:03 | |
| *** chhavi has quit IRC | 15:03 | |
| *** chhavi has joined #openstack-containers | 15:05 | |
| *** EricGonc_ has joined #openstack-containers | 15:06 | |
| *** EricGonczer_ has quit IRC | 15:07 | |
| openstackgerrit | Spyros Trigazis proposed openstack/magnum: [WIP] Spec on cluster upgrades https://review.openstack.org/392193 | 15:09 |
| *** dave-mccowan has joined #openstack-containers | 15:13 | |
| *** syed_ has joined #openstack-containers | 15:14 | |
| *** dimtruck is now known as zz_dimtruck | 15:16 | |
| *** zz_dimtruck is now known as dimtruck | 15:17 | |
| *** ramishra has quit IRC | 15:17 | |
| *** ramishra has joined #openstack-containers | 15:19 | |
| *** absubram has quit IRC | 15:31 | |
| *** absubram has joined #openstack-containers | 15:36 | |
| *** sheel has quit IRC | 15:40 | |
| *** chetna has joined #openstack-containers | 15:45 | |
| *** adrian_otto has joined #openstack-containers | 15:45 | |
| *** sergmelikyan has joined #openstack-containers | 15:45 | |
| adrian_otto | Hello! Our team meeting will being in 15 minutes at 1600 UTC in #openstack-meeting-alt | 15:45 |
| adrian_otto | s/being/begin/ | 15:46 |
| *** rafael__ has joined #openstack-containers | 15:46 | |
| *** chetna has quit IRC | 15:46 | |
| openstackgerrit | Spyros Trigazis proposed openstack/magnum: [WIP] Spec on cluster upgrades https://review.openstack.org/392193 | 15:57 |
| *** DanyC has joined #openstack-containers | 15:59 | |
| *** DanyC has quit IRC | 15:59 | |
| *** Drago5 is now known as Drago | 16:01 | |
| *** JoseMello has quit IRC | 16:02 | |
| *** vijendar_ has joined #openstack-containers | 16:04 | |
| *** vijendar has quit IRC | 16:04 | |
| *** vijendar2 has quit IRC | 16:04 | |
| *** rcernin has quit IRC | 16:06 | |
| *** chetna has joined #openstack-containers | 16:07 | |
| *** chetna has quit IRC | 16:08 | |
| *** chetna has joined #openstack-containers | 16:08 | |
| *** vijendar has joined #openstack-containers | 16:09 | |
| *** vijendar1 has joined #openstack-containers | 16:13 | |
| *** vijenda__ has joined #openstack-containers | 16:13 | |
| *** vijendar has quit IRC | 16:14 | |
| *** vijendar_ has quit IRC | 16:14 | |
| *** swatson_ has joined #openstack-containers | 16:28 | |
| *** srwilkers has quit IRC | 16:34 | |
| *** kaliya has quit IRC | 16:34 | |
| *** belmoreira has quit IRC | 16:35 | |
| *** jerrygb has joined #openstack-containers | 16:41 | |
| *** jerrygb_ has quit IRC | 16:43 | |
| *** vijenda__ has quit IRC | 16:44 | |
| *** jerrygb_ has joined #openstack-containers | 16:44 | |
| *** GB21 has quit IRC | 16:44 | |
| *** JoseMello has joined #openstack-containers | 16:45 | |
| *** jerrygb has quit IRC | 16:46 | |
| *** vijendar has joined #openstack-containers | 16:51 | |
| openstackgerrit | Merged openstack/magnum: Updated from global requirements https://review.openstack.org/388319 | 16:52 |
| Drago | So strigazi and jvgrant | 17:01 |
| jvgrant | template versioning discussion? | 17:02 |
| Drago | Yes | 17:02 |
| jvgrant | Drago: i think what we discussed yesterday will cover all the needs that strigazi mentioned | 17:02 |
| strigazi | yes | 17:02 |
| Drago | jvgrant: I think so too, but I want to get something clarified | 17:02 |
| jvgrant | but it means that the current template and cluster flattening is going to need to happen first if he needs it for upgrades | 17:03 |
| *** GB21 has joined #openstack-containers | 17:03 | |
| *** DanyC has joined #openstack-containers | 17:03 | |
| Drago | 1. Create a cluster template with a specific set of attributes. Thiscluster template will have version 1. | 17:03 |
| Drago | 2. Create a cluster using the above cluster template. | 17:03 |
| Drago | 3. Modify the cluster template resulting to a new cluster template with version 2. | 17:03 |
| Drago | 4. Request a cluster to upgrade from version 1 to 2. | 17:03 |
| Drago | strigazi: You have this in your new spec for upgrades | 17:04 |
| strigazi | yes | 17:04 |
| Drago | strigazi: Step 3 makes sense as the CT and Cluster relationship is now, where they are linked | 17:04 |
| strigazi | after NGs, no CT means no upgrades | 17:05 |
| Drago | That seems like an arbitrary limitation | 17:06 |
| jvgrant | can you upgrade from no CT to a CT? | 17:06 |
| Drago | strigazi: CTs and Clusters will have the same set of attributes, so should be able to upgrade by just updating the Cluster attributes | 17:06 |
| randallburt | ^^ | 17:06 |
| jvgrant | versioning is there to orginize things but upgrade really targets current to target CT? | 17:06 |
| strigazi | jvgrant, yes | 17:07 |
| *** vijendar1 has quit IRC | 17:07 | |
| Drago | strigazi: Right, as I understand it, it's just a convenient way to do attribute updates | 17:07 |
| *** DanyC has quit IRC | 17:07 | |
| Drago | *? | 17:07 |
| strigazi | Drago we can allow non-ct upgrade too at users risk | 17:08 |
| strigazi | Drago, that is exactly what it is | 17:08 |
| Drago | strigazi: That is another thing I am confused about. How is there more risk involved when there's no CT? | 17:08 |
| jvgrant | strigazi: does it really matter how the cluster was created? The upgrade should just have a CT(or new attributes) as a target | 17:09 |
| Drago | strigazi: Do you only mean from CERN's supported vs non-supported point of view? | 17:09 |
| strigazi | yes, just to underline something | 17:10 |
| jvgrant | strigazi: by adding versioning we make it easy to just use the same CT as the target to make life easier, but really upgrade just has a target that it is changing to | 17:10 |
| strigazi | we can let any cluster to be upgraded | 17:10 |
| strigazi | what we want is versions | 17:10 |
| *** vijendar has quit IRC | 17:11 | |
| jvgrant | Drago: then i think our current plan will work fine. | 17:11 |
| Drago | Okay, I think what you're saying is clear to me. I think we can introduce what we came up with yesterday | 17:11 |
| *** harlowja has joined #openstack-containers | 17:11 | |
| Drago | jvgrant: Agreed | 17:11 |
| strigazi | I think so too | 17:11 |
| Drago | strigazi: Well, it's more concrete than the IRC conversation https://etherpad.openstack.org/p/magnum-ocata-nodegroups-fishbowl | 17:12 |
| strigazi | The work could be decoupled | 17:12 |
| Drago | Line 19 and onward | 17:12 |
| jvgrant | it does mean we need to get the current cluster template flattened into cluster ASAP if we have multiple paths needing this | 17:12 |
| Drago | jvgrant: I think we should explain it, then go over implementation order stuff | 17:13 |
| strigazi | Drago +1 | 17:13 |
| jvgrant | agreed | 17:13 |
| *** DanyC has joined #openstack-containers | 17:14 | |
| Drago | strigazi: Okay, so the idea is that CTs will be composed of three different entities. The ParentTemplate (we don't have a good name for this), ClusterTemplate, and ClusterAttributes | 17:14 |
| *** DanyC has quit IRC | 17:15 | |
| Drago | strigazi: The ParentTemplate object is the thing that links different versions of a CT together | 17:15 |
| Drago | strigazi: Quick note - CTs will be immutable | 17:15 |
| strigazi | +1 on the last one | 17:15 |
| Drago | When you create a *new* CT, it will create the 3 entities | 17:16 |
| Drago | The version, which is in the ClusterTemplate entity, will be 1 | 17:16 |
| Drago | Yes, +1 to jvgrant for that idea :) | 17:17 |
| strigazi | Why have Parent Template Object ? | 17:17 |
| Drago | When a user updates the CT, a new ClusterTemplate entity and ClusterAttributes entity will be created, and the CT entity will point to the original ParentTemplate | 17:17 |
| *** anushkrishnamurt has quit IRC | 17:18 | |
| jvgrant | the parent is what keeps the current info and past versions linked | 17:18 |
| Drago | When a cluster is created, it points to a ClusterTemplate entity, which has the version and attribute information | 17:18 |
| jvgrant | so when you display the CT it will show the latest, but have links to each previous version | 17:18 |
| Drago | jvgrant: That could all be possible without the ParentTemplate, if the relations were rearranged | 17:19 |
| strigazi | I was thinking something a bit different, let me describe | 17:19 |
| *** yatin has joined #openstack-containers | 17:19 | |
| jvgrant | agreed, it is just one implementation option | 17:19 |
| Drago | strigazi: The main reason is that you can delete the ClusterTemplate and it will set a flag on the ParentTemplate | 17:19 |
| Drago | But you will still be able to keep the version information intact | 17:19 |
| Drago | It also lets you restore the ClusterTemplate, but that's a bonus | 17:20 |
| strigazi | the CT db entry will have a uuid, a version, a parent uuid and two flags, obsolete and marked_for_Delete | 17:20 |
| Drago | We still want to be able to freely delete and modify a ClusterTemplate, even with versioning in place, and this system should enable all of that. If we did not have the ParentTemplate, it would be harder/more complicated to delete a CT | 17:21 |
| strigazi | let me finish, you can still do it very easily | 17:21 |
| strigazi | I'll write it at the end of the etherpad | 17:22 |
| Drago | Another problem with not having a ParentTemplate is that your UUID changes for each version | 17:22 |
| strigazi | that is no problem | 17:23 |
| strigazi | I thought about it | 17:23 |
| *** jerrygb has joined #openstack-containers | 17:25 | |
| *** jerrygb_ has quit IRC | 17:28 | |
| strigazi | Drago, jvgrant check the etherpad | 17:29 |
| Drago | strigazi: Looking | 17:29 |
| jvgrant | looking at it | 17:29 |
| Drago | strigazi: What do you mean by "link ti the parent cluster"? | 17:31 |
| *** yatin has quit IRC | 17:31 | |
| jvgrant | seems reasonable. So listing CTs would only list non-obsolete CTs | 17:31 |
| strigazi | yes | 17:31 |
| jvgrant | link to parent would be add UUID in a Parent_id field? | 17:31 |
| strigazi | Drago, have a field to the parent uuid | 17:31 |
| Drago | strigazi: Parent is?? | 17:32 |
| strigazi | you have verions N-1 | 17:32 |
| jvgrant | the original CT it was updated from | 17:32 |
| strigazi | parent is version N-2 | 17:32 |
| Drago | Oh so CT, not cluster? It says parent cluster and I was very confused | 17:32 |
| strigazi | line? | 17:32 |
| strigazi | oh, sorry | 17:32 |
| *** DanyC has joined #openstack-containers | 17:33 | |
| jvgrant | if it is new then it points to itself. otherwise when it is updated it would grab the UUID from the parent field it was updated from | 17:33 |
| strigazi | yes | 17:33 |
| jvgrant | cluster would just need a new field for CT UUID to know what it was created from | 17:34 |
| strigazi | yes | 17:34 |
| Drago | strigazi: So when you delete a CT, Magnum has to re-link the used CT to the CT before it that was used in order to delete the ones in the middle? | 17:34 |
| strigazi | NO deletions in the middle | 17:34 |
| strigazi | you can only see and delete the last one | 17:35 |
| Drago | "yes, also if you have 10 versions of the CT and only 1 is referenced, delete the other 9" | 17:35 |
| Drago | strigazi: ^ | 17:35 |
| jvgrant | Drago: this would allow us to just keep the one object approach we originally planned | 17:35 |
| Drago | jvgrant: I think it makes things overly difficult | 17:35 |
| strigazi | This mean that you have it for refernce, you won't be able to do any more actions with it | 17:36 |
| strigazi | not even list it | 17:36 |
| strigazi | Drago, why? | 17:37 |
| Drago | strigazi: Well, sure, the user can only delete the last one, but "delete the other 9" sounds like it is something Magnum does | 17:37 |
| jvgrant | not sure, i'm in the middle on this one. both approaches seem valid and accomplish pretty much the same thing. personally i like less db tables :) | 17:37 |
| strigazi | me too | 17:37 |
| Drago | Again, "-- this action will delete the CTs as well that are marked as deleted unless they are referenced by another cluster " | 17:37 |
| strigazi | This action is similar to the current fuctionalliyt | 17:38 |
| Drago | Magnum will have to modify the foreign keys to point to the correct CTs in order to delete them | 17:38 |
| *** srwilkers has joined #openstack-containers | 17:38 | |
| strigazi | ^^ I don't follow | 17:38 |
| Drago | strigazi: So if you have versions 1 2 3 4 5, and you delete the CT, magnum will delete the ones that aren't referenced by a cluster, right? | 17:39 |
| strigazi | yes mark_to_delete | 17:39 |
| strigazi | ih yes | 17:39 |
| strigazi | oh yes | 17:39 |
| jvgrant | so it will delete all the parents... | 17:40 |
| jvgrant | that could be a problem | 17:40 |
| strigazi | delete the ones that aren't referenced by a cluster | 17:40 |
| Drago | strigazi: Right… v2 references v1 as its parent and so on | 17:40 |
| jvgrant | i think the delete can only happen once there are not references to any versions | 17:40 |
| strigazi | let me give an example | 17:41 |
| strigazi | you have 1 2 3 4 5 | 17:41 |
| jvgrant | unless v1(which is always parent) can't be deleted while any other versions still exist | 17:41 |
| Drago | It sounds to me like step 5 will *really* delete the CTs because they're already marked to delete | 17:41 |
| strigazi | 3 and 4 have created a cluster | 17:41 |
| *** DanyC has left #openstack-containers | 17:41 | |
| strigazi | you want to delete the CT | 17:42 |
| Drago | And "the CT" is really the CT v5, right? | 17:42 |
| strigazi | 3 and 4 are marked to_delete and 1 2 and 5 are deleted | 17:42 |
| strigazi | Then | 17:42 |
| strigazi | you delete the clusters of CT 3 and you delete CT 3 too | 17:43 |
| strigazi | finally, when you delete the clusters of CT 4 you also delete the CT 4 | 17:43 |
| strigazi | "3 and 4 have created a cluster" --> "3 and 4 have created some clusters\" | 17:43 |
| jvgrant | what is parent of 3 and 4 after 1 is deleted? | 17:44 |
| strigazi | parernt of 3 is 2 and parent of 4 is 3 | 17:44 |
| jvgrant | i guess it doesn't matter as long as the UUIDs still match. as it is not a link, just a uuid | 17:44 |
| Drago | Imagine the complexity of these operations when you have 1 2 3 4 5 6 and 2, 4, and 6 have clusters | 17:44 |
| Drago | When you delete the CT, you're removing 1 3 5, but you have to update parent on 2 4 and 6 | 17:45 |
| Drago | Then when the clusters are deleted, you keep having to update parent | 17:45 |
| strigazi | NO, when you delete something | 17:45 |
| jvgrant | why? they still share the same UUID value in the parent attribute? | 17:45 |
| jvgrant | it is just something that links them, they don't need the info from v1 right? | 17:45 |
| strigazi | you don't need the parent anymore for any operation | 17:45 |
| Drago | Oh, v1 is the parent always? I was understanding it was a linked list | 17:46 |
| jvgrant | the parent uuid for all 1-6 would be the uuid for v1 right? | 17:46 |
| *** vijendar has joined #openstack-containers | 17:46 | |
| *** vijendar_ has joined #openstack-containers | 17:46 | |
| Drago | jvgrant: strigazi said above that it's a linked list | 17:47 |
| jvgrant | don't think it needs to be a linked list. they just need something that identifies they are all part of the same list? | 17:47 |
| strigazi | No, the previous one, but we need a way to delete all at once, | 17:47 |
| Drago | jvgrant: "parernt of 3 is 2 and parent of 4 is 3" | 17:47 |
| jvgrant | if it is a linked list then, deleting part of the list seems complicated | 17:47 |
| strigazi | Good point we won't traverse lists | 17:48 |
| jvgrant | could they all have the v1 value? or is there a reason they need it to be a list? | 17:48 |
| jvgrant | the version number will give you the order | 17:48 |
| Drago | This is what I was thinking before I thought of the ParentTemplate concept | 17:48 |
| strigazi | the problem is that we allow different CTs with the same name | 17:48 |
| jvgrant | to find any version i use the parent uuid and the version number | 17:49 |
| Drago | They can do the same thing, but I think it's organized better to have a ParentTemplate that links everything together | 17:49 |
| jvgrant | the latest is the parent_uuid and the highest version number | 17:49 |
| strigazi | I think what jaycen says solves it | 17:49 |
| strigazi | the parent must always be v1 | 17:49 |
| strigazi | thanks | 17:49 |
| Drago | You don't have to duplicate the marked-to-delete field and you can freely delete the CT entry when you want, without having to worry about references | 17:49 |
| jvgrant | yep | 17:50 |
| jvgrant | i think this will work | 17:50 |
| jvgrant | i like it | 17:50 |
| Drago | (when using a ParentTemplate) | 17:50 |
| strigazi | the mark field is boolean, there is no overhead in having it | 17:50 |
| jvgrant | i'm leaning for less db objects | 17:51 |
| strigazi | better a boolean than a table | 17:51 |
| jvgrant | i do see how the parenttemplate object makes for less logic though.... | 17:51 |
| strigazi | I disagree | 17:52 |
| strigazi | because | 17:52 |
| jvgrant | but is seems pretty straight forward to locate and use the versions this way as well | 17:52 |
| strigazi | When the cluster is not deleted | 17:52 |
| strigazi | the v1 cluster plays the role of the parent as it would be in the different object schema | 17:52 |
| strigazi | s/cluster/CT | 17:53 |
| strigazi | when the CT is deleted you don't have to do any more actions, you need to pay the update | 17:53 |
| strigazi | of the flag | 17:53 |
| strigazi | For a modern db that's nothing | 17:54 |
| jvgrant | i see both ways working, so when close I'm going to go for less complexity which i think keeping everything in the same db table does | 17:56 |
| Drago | I don't think the two approaches are much different performance-wise | 17:56 |
| strigazi | This way we can decouple tje work | 17:56 |
| strigazi | The nodegroups work can proceed separately | 17:56 |
| Drago | When you delete the CT, you are updating the mark_delete flag on all the versions, even though it logically applies as all-or-none | 17:56 |
| jvgrant | you could just update it on the parent | 17:57 |
| strigazi | "even though it logically applies as all-or-none" -> ? | 17:57 |
| jvgrant | and the check for delete uses that value | 17:57 |
| strigazi | jvgrant, true | 17:57 |
| strigazi | doable | 17:57 |
| Drago | strigazi: You will never have different versions having mark_delete as true AND false | 17:57 |
| jvgrant | true, so the parent is the only one that value matters on | 17:58 |
| strigazi | Drago, yeap true | 17:58 |
| strigazi | ok, so the original version v1 will stick until the end | 17:58 |
| strigazi | of all CTs | 17:58 |
| jvgrant | makes sense as it is the parent and the others have a reference to it anyway | 17:59 |
| Drago | We have also identified name as a possible field that applies to a CT in a non-version-specific way (i.e. the name doesn't belong to a specific version) | 17:59 |
| strigazi | That way you don't know when to delete v1 though | 17:59 |
| jvgrant | yeah, that now follows how names work in the rest of magnum. they don't really matter. it is the uuid that does | 17:59 |
| Drago | It feels wrong to me that we are shoehorning one entry in a table to be special | 17:59 |
| strigazi | I would prefer the name to be the same in all versions | 18:00 |
| Drago | Rather than just breaking that out into its own table | 18:00 |
| jvgrant | strigazi: the user can do that or they could modify the name if they wanted by adding _Vx if they wanted | 18:00 |
| strigazi | jvgrant, I get it, I don't have a strong objection against it | 18:01 |
| jvgrant | if we want to enforce the name i think the separate entity approach is better | 18:01 |
| Drago | jvgrant: On that note, we could add a —version flag to cluster-create that would default to latest | 18:01 |
| strigazi | Drago, in GCE you do only latest | 18:01 |
| Drago | I imagine we will find more things that will make the entry for the first version special, and at that point we will regret not making it its own table | 18:02 |
| strigazi | The user must always see only the latest | 18:02 |
| jvgrant | Drago: i think that is a risk | 18:02 |
| jvgrant | Drago: but nothing stops us from going that way in the future if we need to | 18:02 |
| strigazi | I like the non table solution to decouple the work too | 18:03 |
| strigazi | jvgrant +1 | 18:03 |
| Drago | strigazi: How does it make a difference? | 18:03 |
| jvgrant | there is a still one thing that has to be done first on both paths | 18:03 |
| jvgrant | we have to get rid of the current ClusterTemplate table | 18:04 |
| strigazi | Drago, Not a big difference | 18:04 |
| Drago | strigazi: Okay | 18:04 |
| *** anushkrishnamurt has joined #openstack-containers | 18:04 | |
| strigazi | jvgrant, Not modify? | 18:04 |
| jvgrant | all attributes needed for the cluster need to be in the same object otherwise we have to add versioning to both objects | 18:05 |
| Drago | strigazi: When we flatten the attributes, both CTs and Clusters will have the same attributes, so we don't need the ClusterTemplate table | 18:05 |
| jvgrant | it is not a hard change, just something we need to do first to make this a lot easier to support both v1 and the future changes | 18:06 |
| strigazi | wait | 18:06 |
| strigazi | so when I do ct-create it will right the cluster-table? | 18:06 |
| Drago | strigazi: Well, with the versioning we're talking about I think it would make sense to have at least a ClusterTemplate table (different than the current one) and a ClusterAttribute table, so yes | 18:07 |
| Drago | If we do not implement versioning, it would only write to the table that holds the attributes | 18:08 |
| strigazi | ok, so we can't decouple the work :) That's a big difference :) | 18:08 |
| *** Jeffrey4l has quit IRC | 18:08 | |
| Drago | I think that putting things like parent and version (for CT versioning) in the table with the attributes would not be a good choice | 18:09 |
| strigazi | We want the attribute table for the locking field? | 18:09 |
| jvgrant | the other question is will v1 api support versioning or will only the v2 api support it? | 18:10 |
| Drago | strigazi: No, for the reason I just mentioned. If we have things that are CT-only and Cluster-only all in the same table, that doesn't seem like a good DB schema to me | 18:10 |
| strigazi | Not really, no | 18:11 |
| Drago | strigazi: So break the information up into 3 tables: ClusterAttributes, ClusterTemplate, and Cluster | 18:11 |
| strigazi | Question | 18:11 |
| Drago | and in my opinion, ParentTemplate ;) | 18:11 |
| strigazi | could we have a policy for the CT and C only attrs? | 18:11 |
| strigazi | A per driver policy | 18:11 |
| Drago | strigazi: What do you mean? | 18:11 |
| Drago | strigazi: The only attributes that I have in mind are public, version, parent (all CT-only) and stack ID, stack status, etc (Cluster-only) | 18:12 |
| *** vijendar_ has quit IRC | 18:12 | |
| strigazi | each can have a policy file to dictate what is CT and C only and also dictate locking | 18:13 |
| strigazi | no | 18:13 |
| strigazi | I'm not sure about this | 18:13 |
| jvgrant | any values in CT or C should only be magnum overhead stuff not any values used by the clusters themselves. Those should all be the same between | 18:14 |
| jvgrant | that is why the original plan was the there was only 1 cluster table that had flags that indicated if it was a template or actual cluster | 18:15 |
| strigazi | Why not just copy over? | 18:15 |
| jvgrant | personally i still like that idea best. there would be only 2 tables in the end: Clusters and NodeGroups | 18:16 |
| jvgrant | templates would just use the same entries just with a flag indicating they are templates | 18:16 |
| jvgrant | since they share 95% the same values | 18:16 |
| strigazi | For versioning we definately need the CT table | 18:16 |
| jvgrant | which is why Drago suggested splitting the shared attributes out into their own table | 18:17 |
| jvgrant | so CT and Cluster just have the differences, and link to the attributes table entry | 18:18 |
| strigazi | Is this in the spec? | 18:18 |
| jvgrant | not yet | 18:18 |
| jvgrant | this is what we started yesterday after realizing we needed the versions :) | 18:18 |
| strigazi | IMO. | 18:18 |
| strigazi | CT, C, NGT and NG | 18:19 |
| strigazi | Keep in mind that the user will have the same experience as in the spec | 18:19 |
| strigazi | Yes, there is duplication | 18:19 |
| jvgrant | this is all the background implementation | 18:20 |
| strigazi | but we keep thing really clean and very safe | 18:20 |
| strigazi | yeap | 18:20 |
| *** vijendar_ has joined #openstack-containers | 18:20 | |
| Drago | Duplicating 40 fields is not clean | 18:20 |
| jvgrant | it means that any change has to be made in multiple tables | 18:21 |
| strigazi | It is, since you manage them in a very different way | 18:21 |
| Drago | Are you saying that CT and C tables should have all the attributes | 18:21 |
| jvgrant | we dont' have that right now because the templates are really separate things | 18:21 |
| strigazi | Only the common, they are 40? | 18:22 |
| *** jmckind has quit IRC | 18:22 | |
| jvgrant | there are a lot, and we keep adding more | 18:22 |
| Drago | strigazi: Yes, the idea is that the attributes are all the same between C and CT. Things like stack information doesn't count | 18:23 |
| strigazi | counting | 18:23 |
| jvgrant | i think the common attributes entry is a good idea if we want separate CT and C tables | 18:23 |
| jvgrant | it means when we add an attribute we only have to update one table and get it in both template and cluster | 18:24 |
| jvgrant | or modify/delete/rename etc... | 18:24 |
| Drago | Safety can be actually be achieved by going with ClusterAttributes that get linked to from the Cluster and ClusterTemplate tables, rather than only an is_template field | 18:25 |
| strigazi | 27 | 18:25 |
| Drago | If you're talking about things like mistakenly deleting a cluster when you meant a clustertemplate if Magnum has a logic bug | 18:25 |
| strigazi | having the attr table is a very bold move and is an optimization IMO | 18:27 |
| Drago | From a quick count, I see 42, but anyway | 18:27 |
| jvgrant | i think you 2 are talking about wanting the same thing. With the slight difference of Drago wanting the attr table for easier updates long term | 18:27 |
| jvgrant | both create separate CT and C tables. only difference is if the values are in that table or linking to a separate entry | 18:28 |
| Drago | I don't know, to me it sounds like strigazi is advocating having all the attributes in both a Cluster and ClusterTemplate table. Am I confused? | 18:28 |
| strigazi | no | 18:29 |
| strigazi | I mean that's what I'm saying | 18:29 |
| strigazi | I added the entries in the etherpad | 18:30 |
| strigazi | which ones am I missing? | 18:30 |
| strigazi | 26 actually | 18:30 |
| strigazi | cluster will have whatever it has plus these ones | 18:31 |
| strigazi | 26 are the common | 18:31 |
| Drago | Oh I see, I counted the stack output ones | 18:31 |
| Drago | :) | 18:32 |
| jvgrant | you need the cluster ones as well | 18:32 |
| Drago | jvgrant: But not all of the ones you pasted | 18:33 |
| jvgrant | ok, not all, but there are a few more, is what i am saying | 18:33 |
| jvgrant | either way the list a decent. i think it is a good optimization to have them shared | 18:34 |
| Drago | I'm just listing everything that'd be in the table. They're not all user-defined attributes | 18:34 |
| *** GB21 has quit IRC | 18:34 | |
| *** vijendar_ has quit IRC | 18:35 | |
| strigazi | A nova instance has 64 fields | 18:35 |
| *** vijendar_ has joined #openstack-containers | 18:35 | |
| strigazi | ok. we are a bit stuck now, what I propose is | 18:37 |
| strigazi | to describe both in the spec as an alternative | 18:37 |
| strigazi | we can discuss it with the team | 18:38 |
| jvgrant | agreed, i think writing it out will help and get some more feedback | 18:38 |
| jvgrant | we need to do this part soon as this will be holding up other things | 18:39 |
| Drago | strigazi, jvgrant: It might be good to talk about implementation steps for all this work now | 18:39 |
| strigazi | I can't continue for long guys, it's 19:40 here | 18:40 |
| Drago | strigazi: jvgrant and I have tenatively planned to break the NodeGroup spec into at least two specs (flattening attributes and nodegroups themselves), with a versioning spec based upon the flattening spec in between | 18:40 |
| jvgrant | yeah, thanks for staying on for this discussion | 18:40 |
| Drago | strigazi: No problem, you're awesome | 18:41 |
| Drago | strigazi: And also propose a spec for the changes to the heat templates | 18:41 |
| strigazi | :) np, we can plan this and in max two days have a plan | 18:41 |
| strigazi | So, which is the first spec? | 18:41 |
| jvgrant | flattening seems liek the one we need first | 18:42 |
| Drago | strigazi: What we'd like to do is figure out the work required to have the data model and heat template structure that will allow us to manage clusters in v2 as early as possible | 18:42 |
| jvgrant | it is partially in the nodegroup spec, but not the attr table stuff that we discussed | 18:42 |
| Drago | And then, at whatever pace, layer on the actual implementation | 18:42 |
| strigazi | To flatten thing we need to decide about the attr table? | 18:43 |
| strigazi | To flatten things we need to decide about the attr table? | 18:43 |
| Drago | strigazi: I think it would be good, but not 100% necessary | 18:44 |
| Drago | strigazi: Most of the data model changes will be reorganization of data that is already there | 18:44 |
| strigazi | Which part is it? | 18:45 |
| strigazi | Data Model Impact ? | 18:45 |
| Drago | strigazi: For example, we already have a master and minion nodegroup, we can break that out into the nodegroup table. Also, we can consider cluster templates right now to be simply CTs with a single version. | 18:45 |
| *** vijenda__ has joined #openstack-containers | 18:45 | |
| Drago | strigazi: yes | 18:45 |
| Drago | strigazi: I haven't looked deeply into it, but new data would be the nodegroup ID, for which there is currently nothing | 18:46 |
| *** vijendar1 has joined #openstack-containers | 18:46 | |
| Drago | strigazi: Then there is changing the heat templates so that they can be eventually manipulated by the v2 API (adding/removing nodegroups) | 18:46 |
| *** vijendar_ has quit IRC | 18:47 | |
| Drago | So essentially, I think priority should be placed on adding missing information and code to fill them in with values that will eventually have meaning, and the heat template changes | 18:47 |
| *** vijendar has quit IRC | 18:48 | |
| Drago | All of the other data model changes can probably be done in any order. But for simplicity's sake, it might be a good idea to write the specs in a way they assume work from a previous spec has been done | 18:48 |
| Drago | jvgrant and I were thinking data model changes for flattening attributes, then versioning, then nodegroups | 18:49 |
| Drago | I think that's all I wanted to say | 18:50 |
| jvgrant | Drago: did you want me to write up one of those specs while you work on the other? | 18:51 |
| jvgrant | i can do the versioning one with both options | 18:52 |
| strigazi | Would it be a big overehad to write both options ? | 18:52 |
| Drago | jvgrant: Sure. I figure we'll coordinate on it enough that we'll both push patches to all of them | 18:52 |
| Drago | strigazi: For flattening and versioning, I don't think so | 18:52 |
| jvgrant | yeah, just helps us split up getting them started | 18:52 |
| Drago | strigazi: The differences seem pretty constrained | 18:53 |
| jvgrant | ok, i'll get started on the versioning one after lunch | 18:53 |
| Drago | Okay, I'll do the flattening one then | 18:53 |
| strigazi | So you will write for sections? Two for nodegroups and two for versioning? | 18:53 |
| strigazi | So you will write four sections? Two for nodegroups and two for versioning? | 18:53 |
| Drago | strigazi: I'm not sure what you mean. I thought you were talking about the options for attr table or not | 18:54 |
| Drago | and ParentTemplate or not | 18:54 |
| strigazi | Yes | 18:54 |
| strigazi | wait | 18:54 |
| strigazi | Two options for the Data Model, with or without the attr table. And two options for versioning with or without the attr table | 18:56 |
| Drago | strigazi, jvgrant: I kind of think that we should pick one of the options as the one that specs can be based off of. For example, pick the attr table one as the basis for the versioning spec. If the alternative gets accepted, update the spec | 18:56 |
| strigazi | Two options for the Data Model, with or without the attr table. And two options for versioning with or without the Parent table | 18:56 |
| jvgrant | Strigazi: yes | 18:57 |
| strigazi | I can do tomorrow a separate section for versioning without the attr table | 18:57 |
| strigazi | to have it all | 18:57 |
| Drago | So that means that the NodeGroup spec will have four different sections in it? | 18:57 |
| jvgrant | Drago: i think the versioning won't need to care about the attr table decision | 18:57 |
| *** adrian_otto has quit IRC | 18:58 | |
| Drago | jvgrant: You're probably right | 18:58 |
| strigazi | ok, | 18:59 |
| strigazi | Do it like this then: Two options for the Data Model, with or without the attr table. And two options for versioning with or without the Parent table | 18:59 |
| strigazi | I'll see it tomorrow and we can discuss it | 19:00 |
| jvgrant | ok | 19:00 |
| jvgrant | thanks again for staying on late strigazi | 19:00 |
| strigazi | np, Can you do it early (reasonably) | 19:00 |
| jvgrant | will try :) | 19:01 |
| strigazi | jvgrant, You are in the timezone of Austin? | 19:01 |
| Drago | I will try too. Of course, it won't be as hard for me, since jvgrant is two hours behind | 19:01 |
| strigazi | Phoenix? | 19:02 |
| jvgrant | yep | 19:02 |
| strigazi | 9am at phoenix is it ok? | 19:03 |
| jvgrant | yeah | 19:03 |
| Drago | strigazi: Are you creating an event invite? | 19:03 |
| strigazi | In google calendar if you have something better you can do it | 19:04 |
| Drago | strigazi: I can email one out | 19:04 |
| strigazi | better | 19:04 |
| Drago | strigazi: Will google calendar email me? | 19:04 |
| Drago | Okay, I will do it | 19:04 |
| strigazi | less google | 19:04 |
| Drago | jvgrant: Are you GMT-4? | 19:05 |
| Drago | *UTC-4 | 19:05 |
| strigazi | GMT-7 | 19:06 |
| jvgrant | -7 | 19:06 |
| Drago | oh | 19:06 |
| Drago | aha, duh | 19:06 |
| Drago | I'm bad at this | 19:06 |
| jvgrant | until sunday that is :) | 19:06 |
| *** chhavi has quit IRC | 19:07 | |
| strigazi | May I send it, I want to check what happens | 19:07 |
| Drago | strigazi, jvgrant: I sent it | 19:08 |
| strigazi | ok | 19:08 |
| jvgrant | thanks | 19:08 |
| strigazi | the time is correct | 19:08 |
| strigazi | See you tomorrow | 19:08 |
| strigazi | bye | 19:09 |
| *** strigazi is now known as strigazi_AFK | 19:09 | |
| *** dave-mccowan has quit IRC | 19:11 | |
| *** Administrator__ has joined #openstack-containers | 19:11 | |
| *** zhugaoxiao has quit IRC | 19:15 | |
| *** vijendar1 has quit IRC | 19:19 | |
| *** vijenda__ has quit IRC | 19:19 | |
| openstackgerrit | Randall Burt proposed openstack/magnum: [WiP] Add cluster driver encapsulation spec https://review.openstack.org/389835 | 19:19 |
| *** vijendar has joined #openstack-containers | 19:20 | |
| openstackgerrit | Randall Burt proposed openstack/magnum: [WiP] Add cluster driver encapsulation spec https://review.openstack.org/389835 | 19:21 |
| *** vijendar has quit IRC | 19:22 | |
| *** vijendar has joined #openstack-containers | 19:28 | |
| *** anushkrishnamurt has quit IRC | 19:28 | |
| *** vijendar_ has joined #openstack-containers | 19:28 | |
| *** dave-mccowan has joined #openstack-containers | 19:32 | |
| *** chetna has quit IRC | 19:34 | |
| *** rcernin has joined #openstack-containers | 19:41 | |
| *** apuimedo has joined #openstack-containers | 19:43 | |
| *** apuimedo has quit IRC | 19:47 | |
| *** adrian_otto has joined #openstack-containers | 20:00 | |
| *** JoseMello has quit IRC | 20:02 | |
| *** vijendar has quit IRC | 20:03 | |
| *** vijendar_ has quit IRC | 20:03 | |
| *** vijendar has joined #openstack-containers | 20:04 | |
| *** vijendar1 has joined #openstack-containers | 20:08 | |
| *** vijendar has quit IRC | 20:13 | |
| *** vijendar1 has quit IRC | 20:13 | |
| *** vijendar has joined #openstack-containers | 20:19 | |
| *** vijendar1 has joined #openstack-containers | 20:24 | |
| *** askb has joined #openstack-containers | 20:27 | |
| openstackgerrit | Randall Burt proposed openstack/magnum: [WiP] Add cluster driver encapsulation spec https://review.openstack.org/389835 | 20:29 |
| openstackgerrit | Randall Burt proposed openstack/magnum: [WiP] Add cluster driver encapsulation spec https://review.openstack.org/389835 | 20:30 |
| *** vijendar has quit IRC | 20:33 | |
| *** vijendar1 has quit IRC | 20:33 | |
| *** vijendar has joined #openstack-containers | 20:33 | |
| *** vijendar has quit IRC | 20:35 | |
| *** vijendar has joined #openstack-containers | 20:38 | |
| *** vijendar1 has joined #openstack-containers | 20:40 | |
| openstackgerrit | Randall Burt proposed openstack/magnum: [WiP] Add cluster driver encapsulation spec https://review.openstack.org/389835 | 20:43 |
| *** vijendar1 has quit IRC | 20:45 | |
| *** vijendar_ has joined #openstack-containers | 20:45 | |
| *** vijendar has quit IRC | 20:45 | |
| openstackgerrit | Merged openstack/magnum: Move cluster delete method to driver https://review.openstack.org/387748 | 20:46 |
| *** vijendar_ has quit IRC | 20:48 | |
| openstackgerrit | Randall Burt proposed openstack/magnum: [WiP] Add cluster driver encapsulation spec https://review.openstack.org/389835 | 20:52 |
| openstackgerrit | Randall Burt proposed openstack/magnum: Add cluster driver encapsulation spec https://review.openstack.org/389835 | 20:52 |
| *** dfflanders has joined #openstack-containers | 20:54 | |
| *** srwilkers has quit IRC | 20:58 | |
| *** vijendar has joined #openstack-containers | 20:59 | |
| *** vijendar_ has joined #openstack-containers | 20:59 | |
| *** absubram has quit IRC | 21:12 | |
| *** vijendar_ has quit IRC | 21:12 | |
| *** vijendar has quit IRC | 21:13 | |
| *** chetna has joined #openstack-containers | 21:13 | |
| *** vijendar has joined #openstack-containers | 21:14 | |
| *** vijendar1 has joined #openstack-containers | 21:15 | |
| *** chetna has quit IRC | 21:16 | |
| *** chetna has joined #openstack-containers | 21:16 | |
| *** vijendar has quit IRC | 21:26 | |
| *** vijendar1 has quit IRC | 21:28 | |
| *** chris_hultin is now known as chris_hultin|AWA | 21:30 | |
| *** vijendar1 has joined #openstack-containers | 21:30 | |
| *** vijendar_ has joined #openstack-containers | 21:31 | |
| Drago | adrian_otto: http://i.imgur.com/mjDFAed.png | 21:35 |
| *** adrian_otto has quit IRC | 21:36 | |
| randallburt | nice diagram | 21:39 |
| randallburt | Drago: but cloud init doesn't talk directly to heat software config agents. Just does some boostrap configuration wrt the transport for collect-config | 21:40 |
| Drago | randallburt: I semi-blindly redid what's on the Magnum wiki | 21:40 |
| Drago | Let me look | 21:40 |
| randallburt | Drago: after that, the config agents talk with heat via the transport | 21:41 |
| Drago | randallburt: It needs to be updated more, really. It's missing Mesos and technically the Heat agent isn't even there | 21:42 |
| *** dimtruck is now known as zz_dimtruck | 21:44 | |
| randallburt | Drago: no? what's "Heat Config Elements" then? | 21:44 |
| Drago | randallburt: Beats me | 21:45 |
| *** zz_dimtruck is now known as dimtruck | 21:45 | |
| Drago | randallburt: Here's what it looks like now https://wiki.openstack.org/wiki/Magnum#Architecture | 21:46 |
| *** jerrygb has quit IRC | 21:46 | |
| *** vijendar1 has quit IRC | 21:47 | |
| *** vijendar has joined #openstack-containers | 21:47 | |
| randallburt | Drago: yeah, don't quite understand that part then. If you're not using software deployments, then you'd just have cloud-init configure the coe/instance directly | 21:48 |
| randallburt | Drago: and if you are, then the config stuff talks between Heat and the coe | 21:48 |
| *** vijendar_ has quit IRC | 21:49 | |
| *** vijendar1 has joined #openstack-containers | 21:49 | |
| openstackgerrit | Stephen Watson proposed openstack/magnum: [WIP] Adds support for non-ID suffix https://review.openstack.org/389811 | 21:49 |
| Drago | randallburt: Right. I'll update it | 21:52 |
| Drago | randallburt: It's the former for swarm and k8s | 21:52 |
| randallburt | Drago: then no updates without replacing the host :( | 21:53 |
| Drago | randallburt: Well, it IS an atomic host | 21:53 |
| randallburt | Drago: lol, but yeah, they're also easy to update "atomically" but not via cloud-init… | 21:53 |
| Drago | randallburt: True. You're talking about rebasing the host? | 21:54 |
| randallburt | Drago: yep | 21:57 |
| randallburt | Drago: still requires a bounce, but that's better than a full rebuild | 21:57 |
| *** apuimedo has joined #openstack-containers | 22:01 | |
| *** vijendar has quit IRC | 22:04 | |
| *** vijendar has joined #openstack-containers | 22:04 | |
| *** vijendar1 has quit IRC | 22:04 | |
| *** jerrygb has joined #openstack-containers | 22:04 | |
| *** jerrygb has quit IRC | 22:06 | |
| *** vijendar1 has joined #openstack-containers | 22:06 | |
| *** vijendar has quit IRC | 22:14 | |
| *** vijendar1 has quit IRC | 22:14 | |
| openstackgerrit | Merged openstack/magnum: Use function is_valid_mac from oslo.utils https://review.openstack.org/389528 | 22:15 |
| *** vijendar has joined #openstack-containers | 22:16 | |
| *** Drago has quit IRC | 22:17 | |
| *** randallburt has quit IRC | 22:17 | |
| *** vijendar1 has joined #openstack-containers | 22:19 | |
| openstackgerrit | Stephen Watson proposed openstack/magnum: [WIP] Adds support for non-ID suffix https://review.openstack.org/389811 | 22:20 |
| *** vijendar has quit IRC | 22:26 | |
| *** vijendar_ has joined #openstack-containers | 22:26 | |
| *** vijendar1 has quit IRC | 22:27 | |
| openstackgerrit | Jaycen Grant proposed openstack/magnum: [WIP]Spec for adding template versions https://review.openstack.org/392327 | 22:27 |
| *** vijendar has joined #openstack-containers | 22:31 | |
| *** rcernin has quit IRC | 22:31 | |
| *** vijendar has quit IRC | 22:35 | |
| *** vijendar_ has quit IRC | 22:36 | |
| *** rafael__ has quit IRC | 22:42 | |
| *** EricGonc_ has quit IRC | 22:51 | |
| *** Drago5 has joined #openstack-containers | 22:52 | |
| *** EricGonczer_ has joined #openstack-containers | 22:54 | |
| *** sergmelikyan has quit IRC | 22:58 | |
| *** sergmelikyan has joined #openstack-containers | 22:58 | |
| *** sergmelikyan has quit IRC | 23:03 | |
| *** Drago5 is now known as Drago | 23:04 | |
| *** Drago has quit IRC | 23:32 | |
| *** yuanying has joined #openstack-containers | 23:37 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
