Update patch set 8
Patch Set 8: (7 comments) Patch-set: 8 Label: Verified=0
This commit is contained in:
Gerrit User 7185
Gerrit Code Review
parent
12d326e531
commit
1df6179626
|
|
@ -0,0 +1,147 @@
|
|||
{
|
||||
"comments": [
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_727ef3e3",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 18,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e Let\u0027s call it isogen mainly because its been the name consistently\n \u003e throughout the design discussions, and not because it really\n \u003e matters,\n\nFixed",
|
||||
"range": {
|
||||
"startLine": 18,
|
||||
"startChar": 24,
|
||||
"endLine": 18,
|
||||
"endChar": 30
|
||||
},
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_52697722",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 19,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e typo\n\nFixed",
|
||||
"range": {
|
||||
"startLine": 19,
|
||||
"startChar": 43,
|
||||
"endLine": 19,
|
||||
"endChar": 50
|
||||
},
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_b261cb3b",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 42,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e I would add that we expect to bootstrap remotely when possible,\n \u003e without the need for physical access or operator manual\n \u003e intervention.\n\nAdded",
|
||||
"range": {
|
||||
"startLine": 41,
|
||||
"startChar": 0,
|
||||
"endLine": 42,
|
||||
"endChar": 28
|
||||
},
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_d266c751",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 61,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e We should escribe that these commands need to be able to :\n \u003e - Utilize the airshipctl config to identify the location of YAML\n \u003e documents that describe the intention for the site\n \u003e - Identify the YAML files that describe the details required for\n \u003e the HOST for which the iso is been generated.\n \u003e - Be able to extract from the appropriate YAML(s) the information\n \u003e for the host, such as IP, Name, MAC, etc.\n \u003e - Be able to gather the information from teh YAML and generate the\n \u003e appropriate cloud-config.yaml file .\n \u003e This includes the ability to be prescriptive with which information\n \u003e is included in the cloud-config file.\n \u003e Specifically we expect to have the ability to \"know\" how t generate\n \u003e i.e. a redfish URL to this host. , or the appropriate k8s endpoint\n \u003e with teh appropriate credentials (certs) to interact with the\n \u003e cluster in this host once teh iso is deployed.\n \u003e \n \u003e Keep in mind that some of these expectations above should be\n \u003e functions in the airshipctl document pkg/module that airshipctl\n \u003e boostrap isogen should leverage. In essence, what I am saying here\n \u003e is we need to make sure we have the place holder for those\n \u003e expectations to be fulfilled.\n\nRestructured sections. Added more details and steps for isogen command",
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_925ccf7d",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 100,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e If there is any other information that needs to be passed to the\n \u003e ISO, besides the cloud-config.yaml, perhaps we need a config file\n \u003e that can be the input passing mechanism. Obviously, this is only\n \u003e needed if we have many arguments . I prefer that than docker run\n \u003e ... isogencontainer \u003claundry list of arguments\u003e\n\nIMO cloud-config.yaml should be only input for container generator. I\u0027d not overload interface.",
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_f24ae3aa",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 105,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e Do we need some YAML output that updates existing YAML? Or we think\n \u003e that is implicitly known during the input for the generation and\n \u003e therefore there is no need to generate output with data for the\n \u003e next steps...\n \u003e \n \u003e If we do clearly the definition of the format of this potential\n \u003e output would need to be part of the interface definition for the\n \u003e iso generating containers.\n\nAdded YAML-formated output and its schema",
|
||||
"range": {
|
||||
"startLine": 104,
|
||||
"startChar": 2,
|
||||
"endLine": 105,
|
||||
"endChar": 26
|
||||
},
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
},
|
||||
{
|
||||
"key": {
|
||||
"uuid": "7faddb67_32dabbe8",
|
||||
"filename": "specs/approved/airshictl_bootstrap_image.rst",
|
||||
"patchSetId": 8
|
||||
},
|
||||
"lineNbr": 135,
|
||||
"author": {
|
||||
"id": 7185
|
||||
},
|
||||
"writtenOn": "2019-08-19T10:18:36Z",
|
||||
"side": 1,
|
||||
"message": "\u003e Not sure I understand what this means?\n \u003e What is the purpose of this.\n\nTried to rephrase. The idea is that we need to put preconfigured certs for kubeadm to spin up K8s cluster\n\nAs an alternative we can generate them on the fly each time node boots up from ISO and share them via HTTP using K8s pod started on ephemeral cluster (or via ssh). This is not really secure but certs will be re-generated after every reboot of ephemeral k8s and not going to live longer than cluster itself",
|
||||
"revId": "52280370556a3b0472e422f2f17a6ac88d15e3bb",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
|
||||
"unresolved": false
|
||||
}
|
||||
]
|
||||
}
|
||||
Loading…
Reference in New Issue