| *** davideagnello has joined #openstack-cue | 00:06 | |
| *** davideagnello has quit IRC | 00:11 | |
| *** openstackgerrit has quit IRC | 13:00 | |
| *** miqui has joined #openstack-cue | 13:01 | |
| *** openstackgerrit has joined #openstack-cue | 13:03 | |
| *** sputnik13 has joined #openstack-cue | 16:40 | |
| *** sputnik13 has quit IRC | 17:08 | |
| *** danielallegood has joined #openstack-cue | 17:10 | |
| *** davideagnello has joined #openstack-cue | 17:18 | |
| *** harlowja_away is now known as harlowja | 17:37 | |
| *** abitha has joined #openstack-cue | 18:03 | |
| *** sputnik13 has joined #openstack-cue | 18:19 | |
| *** abitha has quit IRC | 18:20 | |
| *** abitha has joined #openstack-cue | 18:26 | |
| *** SlickNik has quit IRC | 18:31 | |
| *** SlickNik has joined #openstack-cue | 18:32 | |
| openstackgerrit | Abitha Palaniappan proposed stackforge/cue: Change network_id argument to list type https://review.openstack.org/169065 | 18:33 |
|---|---|---|
| openstackgerrit | Abitha Palaniappan proposed stackforge/cue: Change network_id argument to list type https://review.openstack.org/169065 | 18:54 |
| openstackgerrit | Abitha Palaniappan proposed stackforge/cue: Unit test wsme objects https://review.openstack.org/172253 | 19:24 |
| *** abitha has quit IRC | 19:25 | |
| openstackgerrit | Merged stackforge/python-cueclient: Expose endpoints in cluster list command https://review.openstack.org/169536 | 19:35 |
| *** abitha has joined #openstack-cue | 20:21 | |
| openstackgerrit | Steve Leon proposed stackforge/cue: Refactoring fixtures https://review.openstack.org/171439 | 20:34 |
| openstackgerrit | Steve Leon proposed stackforge/cue: Refactoring fixtures https://review.openstack.org/171439 | 20:36 |
| *** miqui has quit IRC | 21:38 | |
| openstackgerrit | Daniel Allegood proposed stackforge/cue: Adding Database Migration test class https://review.openstack.org/171802 | 22:15 |
| openstackgerrit | Daniel Allegood proposed stackforge/cue: Adding Database Migration test class https://review.openstack.org/171802 | 22:24 |
| sputnik13 | https://review.openstack.org/#/c/169065/8/cue/api/controllers/v1/cluster.py | 22:33 |
| sputnik13 | ^ esmute does this mean we need to use "uuid" for network IDs and "port" for port IDs? | 22:34 |
| sputnik13 | and they all fall under "networks"? | 22:34 |
| esmute | that is how it is in nova | 22:34 |
| sputnik13 | that's horrible | 22:35 |
| esmute | and trove (although trove forward the nic content to nova directly) | 22:35 |
| sputnik13 | yeah, that's horrible | 22:35 |
| esmute | sputnik13: Here is the nova python code where it creates the request | 22:35 |
| esmute | https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/servers.py#L505 | 22:35 |
| esmute | so the nova api expects the nic content to be in this form | 22:36 |
| sputnik13 | yeah, sorry that's horrible, we shouldn't follow this | 22:37 |
| sputnik13 | it's ambiguous | 22:37 |
| sputnik13 | that just looks like a legacy/historical artifact rather than an intentional design to me | 22:38 |
| esmute | yeah.. let me see how the api handles it | 22:38 |
| sputnik13 | like they had networks, and then they tacked on everything else | 22:38 |
| sputnik13 | because if you look at it from the perspective of a list of network uuids, it makes sense | 22:39 |
| sputnik13 | but then to interleave port-ids as "ports" and "ips" etc | 22:39 |
| esmute | but if we do this, then eventually, we can not store network infromation within cue and let nova handle it | 22:39 |
| sputnik13 | I don't see why that is | 22:39 |
| esmute | and not have to change the api | 22:39 |
| sputnik13 | we don't have to map 1-1 between our identifiers and the ones nova uses at API level | 22:40 |
| sputnik13 | because to begin with we're not creating the nova API calls, we're using python-novaclient for that | 22:40 |
| sputnik13 | and python-novaclient's API interface for booting a VM takse net_id and port_id iirc | 22:41 |
| esmute | yeah.. that is a good point | 22:42 |
| sputnik13 | I agree with using a list of name/value pairs where the name is the type of "nic" and the id is the id for that "nic" because that maps well with what nova wants overall | 22:42 |
| esmute | im ok with using net_id and port_id | 22:42 |
| esmute | etc | 22:42 |
| sputnik13 | but the particular naming, I think it makes more sense to use what python-novaclient API expects, because it looks better desgiend | 22:43 |
| sputnik13 | s/desgiend/designed | 22:43 |
| esmute | in this case, we can just leave it as nic as the main index and use net-id and port-id etc as the key/value | 22:44 |
| davideagnello | makes sense to use net_id and port_id | 22:44 |
| esmute | abitha: Do you agree with this ^? | 22:44 |
| abitha | in our api , if I change the 'network_id' to 'networks' it needs to be changed in objects, database, and taskflow for the current setup. So should i change it | 22:44 |
| abitha | yes net-id and port-id sounds good. | 22:45 |
| esmute | looks like nic": [{"net-id": "123"}] is the way to go | 22:45 |
| davideagnello | like Abitha mentioned, changing the name will require changes through the various layers to the DB including models, and db version | 22:50 |
| davideagnello | does nic even make sense. someone looking at the acronym, you would think of Network Interface Card | 22:51 |
| davideagnello | network_interface is more intuitive | 22:51 |
| sputnik13 | well... a network isn't a network_interface eitehr | 22:52 |
| sputnik13 | there's no clean approach unless you separate network and port | 22:52 |
| sputnik13 | but that's overkill... nic, network, they're both less than ideal, so it seems like either would be just as good/bad as the other | 22:53 |
| esmute | sorry.. it is not nic.. it is nics | 22:53 |
| sputnik13 | I think it would be good if the cueclient actually took network-id's and port-id's as separate parameters, network-id for now, port-id later if/when we support it | 22:54 |
| abitha | so whats the final verdict? | 22:54 |
| sputnik13 | it's not very user friendly to have them type in --nics network-id=ID1,port_id=ID2 etc | 22:54 |
| davideagnello | we already have network_id | 22:55 |
| sputnik13 | oh yeah | 22:55 |
| davideagnello | why don't we add port_id as an optional field | 22:55 |
| sputnik13 | but the change we're really talking about is the REST API | 22:55 |
| esmute | davideagnello: how would you specify for multiple networks? | 22:55 |
| sputnik13 | we don't need to add port_id at all right now | 22:55 |
| davideagnello | they can both be lists | 22:55 |
| sputnik13 | esmute: I think that's a moot point right now since we don't support multiple networks | 22:55 |
| davideagnello | sputnik13: nope, we don't need it right now | 22:56 |
| esmute | to keep it consistent with nova, trove, neutron etc.... "nics": [{"net-id": "123"}] is what they use | 22:56 |
| sputnik13 | it could be a comma separated list or just multiple instances of the option | 22:56 |
| sputnik13 | esmute: are you talking about REST API or command line? | 22:56 |
| esmute | sputnik13: correct but when we do support it, we wont want to be changing the api | 22:56 |
| esmute | rest API | 22:56 |
| sputnik13 | ok, I was talking about command line, I'm confusing us, sorry | 22:56 |
| esmute | i was refering to the curl request that goes to the API... the network info is passed as "nics": [{"net-id": "123"}] in nova and trove | 22:57 |
| esmute | yeah.. in command line, it would be --nic net-id=123 --nic net-id=456 | 22:58 |
| openstackgerrit | Daniel Allegood proposed stackforge/cue: Adding Database Migration test class https://review.openstack.org/171802 | 23:18 |
| sputnik13 | this change seems like a slippery slope, we should table it for the time being and do an end to end design after the quality stuff... | 23:21 |
| sputnik13 | vipul are you ok with that? | 23:21 |
| vipul | sputnik13: you mean table the patch entirely? | 23:23 |
| vipul | or do you mean let's got with renaming uuid -> net-id | 23:23 |
| sputnik13 | actually, I think the renaming part | 23:24 |
| sputnik13 | leave it as a list of just network-ids | 23:24 |
| vipul | so we wouldn't support supplying ports as an option.. at least in v1? | 23:25 |
| vipul | just trying to make sure we understand the implications.. if we leave it as-is then we break API | 23:26 |
| vipul | if we have to change it.. | 23:26 |
| sputnik13 | at least put that off until after we're done with the quality efforts, not saying we release v1 without | 23:26 |
| vipul | actually i'm fine with supporting network-ids only.. which would mean Cue always creates the port | 23:26 |
| vipul | Yep +1 the important thing right now is to get multiple nics to attach | 23:27 |
| sputnik13 | I would lean that way as well, but I think we could leave it as an open issue if anyone feels strongly about it... if we support port_id then there needs to be more changes than just the API change | 23:27 |
| vipul | because without this.. any deployment is useless | 23:28 |
| sputnik13 | well, remember this doesn't preclude multiple NICs on the VM (our management and user's network) | 23:28 |
| sputnik13 | this patch is for multiple user networks | 23:28 |
| sputnik13 | so, supporting just network_id list for now, and if/when we add support for ports revisit the requisite API and backend changes? | 23:29 |
| vipul | yea i'm cool with that | 23:30 |
| vipul | let's get multi-nic working.. and revisit the api later | 23:30 |
| vipul | put in a bug or something to track it | 23:30 |
| sputnik13 | vipul: k | 23:39 |
| openstackgerrit | Merged stackforge/cue: Refactoring fixtures https://review.openstack.org/171439 | 23:44 |
| openstackgerrit | Abitha Palaniappan proposed stackforge/cue: Change network_id argument to list type https://review.openstack.org/169065 | 23:51 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!