Guano

Jump to bottom
Joe Kaiser edited this page Jan 25, 2018 · 3 revisions

Guano

Shit we're thinking about.

This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.

Idea: Replace the frontend's install wizard with a web-app

Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.

Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.

We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.

Con: This webapp would probably be written in JS -- this reduces code reuse.

Contra-con: There really isn't a ton of code needed to be reused here.

Idea: Replace tfptd with the fbtftp library

Motivation: We have had users in the past bottlenecked by access to the TFTP server.

Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.

Con: Greg suffers from 80s nostalgia.

Contra-con: He needs to get over it.

Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.

Idea: Online interactive doc search

Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.

Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?

Con: Where to host? Is live documentation useful?

Contra-con:

Idea: stack report system

This has been done. Use "stack report system"

It probably needs more stuff to report.

Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.

Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.

Con: O.J. Simpson (now ex)

Contra-con: Oliver North (also ex)

Idea: Add callbacks to the message queue

Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.

Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.

Con:

Contra-con:

Idea: Stacki FedUp as a Service (FUaaS)

Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.

Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.

Con: I don't know anything about Bonjour, but there are Apache licensed versions.

Contra-con:

Idea: Run a cart on a backend node after the node has been installed.

Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.

Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.

Con: This is insane. Rerun the install.

Contra-con:

Idea: stack add/remove monkeypatch

Motivation: Testing and delivering features and bugfixes is annoying.

Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.

Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?

Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.

Idea:

Motivation:

Detail:

Con:

Contra-con:

Checkout our Google Group or our Slack Team for any support or other questions.

Want to contribute to this Wiki? Fork it and send a pull request.

Stacki Documentation

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Guano
Jump to bottom

Joe Kaiser edited this page Jan 25, 2018
·
3 revisions
Guano
Shit we're thinking about.
This page serves as a collection for ideas that may (and in some cases should?!) never, ever be implemented in Stacki, or as an add-on to Stacki, but are interesting enough that they should be written down and kept somewhere. Certainly, nothing written here should be read as a commitment, or even a plan.
Idea: Replace the frontend's install wizard with a web-app
Motivation: Removing WxPython would have a large impact on the build size and build time of the Stacki pallet. It would also decrease the number of dependencies in the installer. Finally, the wizard's code needs an overhaul.
Detail: Rather than embedding a full web browser (or a doing it half-way via something like Electron), the installer would start a server-side JS server and announce via console connectivity information. We could even do the frontend in Covalent.
We could also just use the built-in Python http.server.SimpleHTTPRequestHandler for the web server. We can render the web form using a WebkitGtk in a fullscreen window.
Con: This webapp would probably be written in JS -- this reduces code reuse.
Contra-con: There really isn't a ton of code needed to be reused here.
Idea: Replace tfptd with the fbtftp library
Motivation: We have had users in the past bottlenecked by access to the TFTP server.
Detail: fbtftp was built to be scalable, and is actually a python library allowing for potentially a CGI-like response to tftp requests.
Con: Greg suffers from 80s nostalgia.
Contra-con: He needs to get over it.
Status: Done. In stacki 5.0 as foundation-fbtftp. Installed on CentOS and not enabled. Not currently installed on SLES.
Idea: Online interactive doc search
Motivation: The number of stack commands is growing over time, and users discovering stack commands is now a common issue.
Detail: A webapp could be created (and hosted... somewhere...?) that performed live full text search on all stacki commands and docstrings, updating as the field is populated. For example searching 'dns' would return stack add network, stack set host address, stack set network dns and sync dns because the first to have a 'dns' parameter, and the second two have 'dns' in the command name. Could there be some console/curses/etc trickery that allows a CLI version of this?
Con: Where to host? Is live documentation useful?
Contra-con:
Idea: stack report system
This has been done. Use "stack report system"
It probably needs more stuff to report.
Motivation: Most stacki troubleshooting starts with the same half-dozen questions 'stack list pallet, stack list host boot, etc'. In some cases these are pasted in forums without any attempt at maintaining formatting, or worse are screenshots.
Detail: We could create a single report command that performed a series of these commands (along with some others, like the output of df, etc), already formatted in some way. This would not invalidate the need for further questions, and collecting the whole database is infeasible anyway.
Con: O.J. Simpson (now ex)
Contra-con: Oliver North (also ex)
Idea: Add callbacks to the message queue
Motivation: Currently doing things like monitoring the state of the installing nodes requires polling, either via CLI or REST API.
Detail: We could add an optional callback URL to the message queue. Something along of the lines of providing a REST endpoint (and optional data?) that the frontend would POST to once it received the message.
Con:
Contra-con:
Idea: Stacki FedUp as a Service (FUaaS)
Motivation: For some, setting up a Stacki frontend for the first time is a large hurdle. We could have instructions/extra functionality for setting up a master Stacki Frontend. Internal to Teradata, this would be very useful.
Detail: Stacki FedUp, to an extent allows for this. However, PXE-booting the actual frontend may not be plausible. This tool could allow for making that accessible over a LAN and capable of creating an attrfile and palletfile, as well as ensuring the pallets are accessible. The node-to-be-provisioned would need to boot off of some media (to work around the DHCP issues) and then be pointed to (or know how to contact via another service/protocol such as Bonjour/mDNS?) the FedUp server.
Con: I don't know anything about Bonjour, but there are Apache licensed versions.
Contra-con:
Idea: Run a cart on a backend node after the node has been installed.
Motivation: If you're of the mind-set that makes worst-case scenario inferences from implied questions, then some guy on the list asked for this.
Detail: You install a machine. You add a cart. Now you want to put the stuff in the cart on the backend node. You're too lazy to reinstall. Do "stack run host cart backend-0-0" and the cart runs.
Con: This is insane. Rerun the install.
Contra-con:
Idea: stack add/remove monkeypatch
Motivation: Testing and delivering features and bugfixes is annoying.
Detail: Add a new set of stack commands. The premise is to allow you to manage patches to the stack commandline. stack add monkeypatch $SHA would allow you to add functionality from the patch, stack remove monkeypatch $SHA would revert the patch. stack list monkeypatch would show you patches on the system. Perhaps stack create monkeypatch could identify changes to the existing system and prepare a diff suitable for consuming in git apply. I don't think this would be usable outside of the stack CLI.
Con: This is complicated and potentially dangerous to implement. How do you handle merge conflicts?
Contra-con: Git could do the heavy lifting here. We could prevent adding conflicting patches.
Idea:
Motivation:
Detail:
Con:
Contra-con:
Checkout our Google Group or our Slack Team for any support or other questions.
Want to contribute to this Wiki? Fork it and send a pull request.
Stacki Documentation
Clone this wiki locally