kevinbenton | jroll: ok, we should plan to meetup then. Maybe I’ll send an email to the Ironic dev list to see who else is interested so we can try to schedule something | 00:01 |
---|---|---|
devananda | kevinbenton: do you have an idea what that integration would look like? what are you hoping to achieve (and what's reasonable todayy)? | 00:01 |
devananda | kevinbenton: i know there are some folks in HP as well who are interested (not sure if they're attending) | 00:01 |
jroll | kevinbenton: yeah, agreed. we've been looking at what we want to do with neutron but it's not ready yet | 00:02 |
kevinbenton | devananda: so the workflow is that when an admit adds a physical server to the network, he/she would create a neutron physical port with two identifiers (the MAC and the attachment ID) | 00:02 |
kevinbenton | devananda: the attachment ID is something the network backend understands eg. “Switch1:Port8” | 00:03 |
kevinbenton | then the physical port is assigned to whichever tenant has control of the server | 00:03 |
morgabra | kevinbenton: devananda: fwiw, I've been working on a plugin for this | 00:03 |
morgabra | I had planned on it being kind of a stopgap for us, but I should have been better about making it open | 00:04 |
kevinbenton | that tenant can then assign it to various neutron networks | 00:04 |
morgabra | kevinbenton: https://gist.github.com/morgabra/ccef48de278583ef3ad7 | 00:04 |
*** dwalleck has quit IRC | 00:04 | |
devananda | so, folks, one thing to point out... | 00:04 |
jroll | morgabra: bad paste? -H 'Content-Type: applicatiobec-81f8-4e26-94d8-274391706a41" :P | 00:04 |
devananda | ironic does not associate hw nodes to tenants | 00:05 |
morgabra | jroll: fixed | 00:05 |
jroll | cool | 00:05 |
kevinbenton | devananda: ah, so there isn’t a concept of a tenant owning baremetal servers? | 00:05 |
devananda | kevinbenton: nope | 00:05 |
jroll | it's all in nova, right? | 00:05 |
devananda | kevinbenton: ironic's API is *not* meant to be exposed to end users. full stop. | 00:05 |
devananda | it is an admin only API right now | 00:05 |
devananda | user talks to Nova to request an instance | 00:06 |
devananda | nova uses the ironic driver to talk to ironic-api, then ironic provisions the hw, and lets nova know when it's done and ready for the user | 00:06 |
devananda | neutron sets up the networking | 00:07 |
jroll | so, what if the neutron calls happened in the virt driver where we know about things like tenants? (disclaimer: I know almost nothing about neutron) | 00:07 |
devananda | ironic knows the MACs, passes them out to Nova, which passes them off to neutron during virt.driver.spawn() | 00:07 |
devananda | jroll: they do | 00:07 |
jroll | aha. | 00:07 |
jroll | ok | 00:07 |
devananda | so | 00:07 |
devananda | a network and an IP range are associated to a tenant | 00:07 |
devananda | neutron assigns an IP from taht tenant to the nova Instance | 00:07 |
devananda | normal workflow was neutron would also generate a MAC, but in this case, it requests the MAC from nova (which gets it from ironic) | 00:08 |
devananda | what we need, security wise, is for the hw node and its ports to be isolated | 00:08 |
devananda | from other tenants | 00:08 |
devananda | and from the control network | 00:08 |
devananda | when an instance is provisioned on it | 00:08 |
devananda | -- and have it moved back when taht instance is deleted, etc | 00:08 |
devananda | kevinbenton: does that fit with your thinking? | 00:08 |
kevinbenton | devananda: yeah, that latter part would be handled | 00:08 |
kevinbenton | devananda: the workflow is slightly different though | 00:09 |
kevinbenton | devananda: let me think about it for a second | 00:09 |
devananda | one add'l component -- ironic passes the dhcp extra options to neutron | 00:09 |
devananda | to direct the dhcp boot request to an appropriate tftp server | 00:09 |
jroll | devananda: right, so, the isolation is exactly what morgabra is working on right now :) | 00:10 |
devananda | great | 00:11 |
devananda | morgabra: what are the requirements for that isolation? | 00:11 |
devananda | ie, does it work with only swicthes from XX vendor? | 00:11 |
morgabra | well, it's pretty severely hardware dependent | 00:11 |
*** eguz has quit IRC | 00:11 | |
kevinbenton | devananda: how does this workflow work at all right now? how can an instance be correctly placed on the VLAN corresponding to the neutron network? | 00:11 |
devananda | kevinbenton: flat network | 00:12 |
jroll | morgabra: but that's pluggable, yeah? | 00:12 |
devananda | kevinbenton: is the only network model that works today | 00:12 |
devananda | kevinbenton: we *want* it to work with VLANs | 00:12 |
devananda | kevinbenton: and afaik, cloud-init can pass the necessary vlan metadata in to the instance -- but we lack the integration with hardware to move the node between vlan's | 00:13 |
morgabra | jroll: yes, but it's yet another driver abstraction on top of a plugin. I'm fairly convinced my implementation is wrong for the rest of neutron proper but I wanted something to work immediately for us | 00:13 |
jroll | heh, yeah | 00:13 |
devananda | morgabra: an openflow / ovs implementation will be required for testing, fwiw | 00:13 |
kevinbenton | devananda: i don’t think you would want cloud-init to pass vlan info into the instance, would you? | 00:14 |
devananda | kevinbenton: why not? | 00:14 |
kevinbenton | devananda: this should be all transparently handled by the network | 00:14 |
devananda | kevinbenton: the instance has to come up on teh tenant's network | 00:14 |
devananda | there's no agent | 00:14 |
devananda | oh | 00:14 |
kevinbenton | devananda: because if you don’t trust the tenant, they could change their vlan tagging | 00:14 |
devananda | right right | 00:15 |
morgabra | the switch won't respect that | 00:15 |
morgabra | or shouldn't | 00:15 |
devananda | you'd have the switch force all traffic on that port to that vlan | 00:15 |
devananda | yes | 00:15 |
kevinbenton | devananda: yeah, since the switch requires configuration, it should just be untagged traffic and ignore everything else | 00:15 |
devananda | kevinbenton: yes | 00:16 |
devananda | i hate to run right now, but i need to ... | 00:17 |
devananda | please continue w/o me, and def follow up on the ML :) | 00:17 |
kevinbenton | kevinbenton: so we might just need to adjust our extension a bit. is it safe to assume then that ironic will pass in that switch port identifier information in the port-create request? | 00:17 |
kevinbenton | devananda: ^^ | 00:17 |
kevinbenton | morgabra: ^^. that’s the approach you are using, right? | 00:18 |
morgabra | kevinbenton: yes, but I'm pretty sure this is the first that devananda and co has heard of it, I've been off on my own for a bit | 00:19 |
*** matsuhashi has joined #openstack-ironic | 00:19 | |
kevinbenton | morgabra: ok, i will think about our extension and see how we can handle ironic and non-ironic attachments to the network and then I will send an email to the list to see if we can start converging on an approach | 00:20 |
*** zdiN0bot has quit IRC | 00:27 | |
*** dwalleck has joined #openstack-ironic | 00:27 | |
*** radsy has joined #openstack-ironic | 00:31 | |
*** radsy has joined #openstack-ironic | 00:31 | |
*** dwalleck_ has joined #openstack-ironic | 00:36 | |
*** zdiN0bot has joined #openstack-ironic | 00:38 | |
*** dwalleck has quit IRC | 00:40 | |
*** zdiN0bot1 has joined #openstack-ironic | 00:42 | |
*** zdiN0bot has quit IRC | 00:42 | |
*** zdiN0bot1 has quit IRC | 00:53 | |
*** datajerk has joined #openstack-ironic | 00:54 | |
*** dwalleck_ has quit IRC | 01:01 | |
*** newell has quit IRC | 01:01 | |
*** datajerk has quit IRC | 01:22 | |
*** radsy has quit IRC | 01:33 | |
*** nosnos has joined #openstack-ironic | 01:36 | |
*** rwsu has quit IRC | 01:47 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/88722 | 01:48 |
*** hemna_ has joined #openstack-ironic | 02:11 | |
*** rameshg87 has joined #openstack-ironic | 02:47 | |
*** coolsvap|afk is now known as coolsvap | 02:48 | |
*** eghobo has joined #openstack-ironic | 02:53 | |
*** harlowja is now known as harlowja_away | 02:58 | |
*** harlowja_away is now known as harlowja | 03:16 | |
*** matsuhashi has quit IRC | 03:20 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 03:25 |
*** nosnos has quit IRC | 03:32 | |
*** dkehn_ has joined #openstack-ironic | 04:21 | |
*** dkehnx has quit IRC | 04:25 | |
*** matsuhashi has joined #openstack-ironic | 04:28 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 04:30 |
*** nosnos has joined #openstack-ironic | 04:37 | |
*** matsuhas_ has joined #openstack-ironic | 05:02 | |
*** matsuhashi has quit IRC | 05:05 | |
*** dwalleck has joined #openstack-ironic | 05:06 | |
*** dwalleck has quit IRC | 05:11 | |
*** vkozhukalov has joined #openstack-ironic | 05:15 | |
*** harlowja is now known as harlowja_away | 05:41 | |
*** uberj has quit IRC | 05:50 | |
*** uberj has joined #openstack-ironic | 05:52 | |
*** uberj has quit IRC | 05:53 | |
*** uberj_ has joined #openstack-ironic | 05:54 | |
*** matsuhas_ has quit IRC | 06:02 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/88508 | 06:07 |
*** Mikhail_D_ltp has joined #openstack-ironic | 06:08 | |
*** matsuhashi has joined #openstack-ironic | 06:10 | |
*** ifarkas has joined #openstack-ironic | 06:10 | |
*** early has quit IRC | 06:14 | |
*** viktors has joined #openstack-ironic | 06:16 | |
*** vkozhukalov has quit IRC | 06:17 | |
*** early has joined #openstack-ironic | 06:17 | |
*** raies has joined #openstack-ironic | 06:27 | |
raies | hi, | 06:27 |
raies | can someone tell me the prossible values for node provision state ?? | 06:28 |
raies | also please point it in ironic code | 06:28 |
*** max_lobur has joined #openstack-ironic | 06:40 | |
rameshg87 | hello raies: | 06:41 |
raies | rameshg87: hi | 06:41 |
rameshg87 | are you looking for this: https://github.com/openstack/ironic/blob/master/ironic/common/states.py#L50-L60 ? | 06:41 |
raies | rameshg87: Yes I checked it but I am not well confirmed of it | 06:43 |
*** Manishanker has joined #openstack-ironic | 06:43 | |
rameshg87 | raies: are you looking for something specific that deals with these node states ? | 06:43 |
raies | No no, I just want to know which possible provision state are there. | 06:44 |
raies | And if I set provision state to particular state as of above using API request, then which filed of node show will give info that it is set successful | 06:45 |
*** Mikhail_D_ltp has quit IRC | 06:50 | |
raies | actually when I set provision state to active using API, then I get "target_provision_state" of node show command - "deploy complete" and field "provision_stat" is None | 06:50 |
raies | rameshg87: ^^ is it correct behavior can you explain?? | 06:51 |
*** yfujioka has joined #openstack-ironic | 06:51 | |
rameshg87 | raies: how did you set the provision state ? did you use nodes/$NODE/states/provision from the API ? | 06:56 |
raies | yes | 06:56 |
*** hemna_ has quit IRC | 06:56 | |
rameshg87 | if you make a call to this api, then this is the expected behaviour | 06:56 |
rameshg87 | raies: the api call that you make ends up here: https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L222-L224 | 06:57 |
*** viktors has quit IRC | 06:58 | |
rameshg87 | it calls do_node_deploy() on the conductor which sets the target state to "deploy complete", and current state to "deploying". its done here on the conductor: https://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L350-L353 | 06:58 |
raies | rameshg87: got it. but one more issue - "node.target_provision_state = states.DEPLOYDONE" mean deploy complete | 07:00 |
raies | but node.provision_state = states.DEPLOYING | 07:00 |
raies | what it indicates ?? | 07:00 |
raies | rameshg87: ok got it :) | 07:01 |
raies | thanks for this great healp | 07:01 |
rameshg87 | raies: it just indicates that the node would ideally next goto node.target_provision_state | 07:01 |
rameshg87 | raies: anyways you already got it :-) | 07:01 |
raies | rameshg87: One more thing I want to ask, in which order provisioning could be called ?? | 07:02 |
raies | mean if I called active first | 07:02 |
raies | then if I call next deploying then it will give error | 07:02 |
raies | did you get my question ? | 07:03 |
rameshg87 | raies: you cannot ask nodes/$NODE/states/provision API to set the node to any intermediate states. you can only set it to either "active" or "deleted" | 07:04 |
rameshg87 | raies: any other state, the API will simply reject: https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L205-L211 | 07:05 |
rameshg87 | raies: you can do two basic operations by using these two states - either "do a deploy" or "do a teardown" | 07:05 |
raies | rameshg87: I didn't get your last suggestion | 07:06 |
raies | 'do a deploy' and 'do a teardown' I didn't get it | 07:07 |
rameshg87 | raies: when we send target: "active" with nodes/$NODE/states/provision API call, we are asking ironic to "do a deploy" on the baremetal node | 07:07 |
rameshg87 | raies: similarly, when we send target: "deleted" with nodes/$NODE/states/provision API call, we are asking ironic to "do a teardown" on the already provisioning baremetal node | 07:08 |
raies | ok got it thanks for your great help :) | 07:08 |
rameshg87 | raies: :-) | 07:08 |
raies | rameshg87: One more thing it is very silly but I want to confirm it anyway | 07:09 |
rameshg87 | raies: sure .. | 07:09 |
raies | rameshg87: what does provisioning state of a node actually mean ?? | 07:10 |
rameshg87 | raies: it's the current state of the node w.r.t to deploy operation. it is used both internally and externally to know the current status of a registered baremetal node | 07:11 |
rameshg87 | raies: when we register a new node, the node is not provisioned by ironic, so the provision state is None | 07:11 |
rameshg87 | raies: when we want ironic to deploy (or when nova wants ironic to deploy), we ask ironic to do so by changing the provision state | 07:12 |
*** viktors has joined #openstack-ironic | 07:13 | |
rameshg87 | raies: on the process, ironic conductor sets the current state to deploying, and calls the deploy() method of the driver which is associated with the node | 07:13 |
raies | rameshg87: when a node is get registered using node-create we cannot use that directly. When we deploy a baremetal node using nova then these APIs get called. Am I right ?? | 07:13 |
rameshg87 | raies: yes | 07:13 |
raies | after deployment we can use the node well right | 07:14 |
raies | ?? | 07:14 |
rameshg87 | raies: the deploy() method of the driver takes it through various stages of deployment and sets the state of the node accordingly. finally when the deployment is complete, the driver will set the node state as active | 07:14 |
rameshg87 | raies: yes, after deployment, the end user can use the node | 07:14 |
raies | rameshg87: thanks for your great help u cleared all my illusions | 07:15 |
rameshg87 | raies: :-) | 07:15 |
raies | are u going to Atlanta ?? | 07:15 |
*** eghobo has quit IRC | 07:15 | |
rameshg87 | raies: nope.. :-( . are you going ? | 07:25 |
*** yuriyz|2 has quit IRC | 07:26 | |
*** yuriyz has joined #openstack-ironic | 07:26 | |
*** ndipanov has joined #openstack-ironic | 07:42 | |
*** vkozhukalov has joined #openstack-ironic | 07:46 | |
Mikhail_D_wk | Good morning Ironic :) | 07:47 |
rameshg87 | good morning Mikhail_D_wk: | 07:54 |
*** romcheg has joined #openstack-ironic | 07:55 | |
vkozhukalov | morning guys | 07:55 |
*** ndipanov has quit IRC | 07:56 | |
*** romcheg1 has quit IRC | 07:58 | |
*** romcheg1 has joined #openstack-ironic | 07:58 | |
*** derekh has joined #openstack-ironic | 08:03 | |
dtantsur | Morning Ironic | 08:04 |
openstackgerrit | Ramakrishnan G proposed a change to openstack/ironic: Add IloDriver and its utils https://review.openstack.org/89500 | 08:05 |
Mikhail_D_wk | dtantsur: morning :) | 08:06 |
dtantsur | Mikhail_D_wk, hi :) Have you been to IRC meeting? Something interesting except for design sessions? I completely forgot about it due to holiday :) | 08:08 |
Mikhail_D_wk | dtantsur: Nope :( I forgot too... :) | 08:09 |
*** ndipanov has joined #openstack-ironic | 08:09 | |
dtantsur | Did you have holiday yesterday as well? :) (I am not sure where you're located) | 08:11 |
*** jistr has joined #openstack-ironic | 08:12 | |
*** romcheg has quit IRC | 08:14 | |
*** martyntaylor has joined #openstack-ironic | 08:14 | |
raies | rameshg87: yes I am going | 08:16 |
rameshg87 | raies: great :-) | 08:17 |
*** mrda is now known as mrda_away | 08:17 | |
*** lucasagomes has joined #openstack-ironic | 08:19 | |
*** yfujioka has quit IRC | 08:25 | |
*** romcheg1 has quit IRC | 08:46 | |
raies | rameshg87: hi | 08:51 |
raies | can we clear provisioning state of node ?? | 08:51 |
raies | i.e if it is set to active ----> again None can be achieved ?? | 08:52 |
rameshg87 | raies: once you have the node state as "active", you need to tear down the node. send target: "deleted" to nodes/$NODE/states/provision API | 08:54 |
raies | ok i.e this flow of action is possible None--->active---->deleted----->None ?? | 08:56 |
*** romcheg has joined #openstack-ironic | 08:58 | |
raies | but what I see with action that if node provision is set to active then deleted APi gets failed | 09:00 |
raies | ^^ as per https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L225-L227 | 09:00 |
raies | rameshg87: If I have a baremetal node registered, and I want to test whether both provisions (activ, deleted) get sets successfully or not then with a single node what could be the call flow ?? | 09:03 |
rameshg87 | raies: the following flow should work | 09:05 |
rameshg87 | 1. register the node | 09:05 |
raies | rameshg87: As per me - 1. create baremetal node associated with chassis 2. set provision state active (ends with deploy complete) 3. set deleted (This case is getting failed) 4. | 09:05 |
raies | ok please continue :) | 09:05 |
rameshg87 | raies: the #3 in the above flow should work | 09:05 |
rameshg87 | raies: i was about to say the same thing | 09:06 |
rameshg87 | :-) | 09:06 |
rameshg87 | raies: once the state of the node is "active", we should be able to call provision with target: "deleted" | 09:06 |
raies | rameshg87: I created node, set active which sets target_provision_state "deploy complete" | 09:08 |
rameshg87 | raies: okay | 09:08 |
rameshg87 | then ? | 09:08 |
raies | rameshg87: I checked node show I didn't find "active" keyword anywhere | 09:08 |
rameshg87 | the deploy takes some time to complete. after the deploy is complete, your target_provision_state will be None and provision_state will be active | 09:08 |
rameshg87 | the deploy will take some time to complete .. | 09:09 |
raies | ohh | 09:09 |
raies | it is the matter | 09:09 |
raies | ok can you please tell me the timeout ?? | 09:09 |
rameshg87 | deploy_callback_timeout is set to 1800 seconds by default in /etc/ironic/ironic.conf | 09:10 |
Mikhail_D_wk | dtantsur: Yeah!!! We had holiday yesterday :) (I'm in Ukraine in Kharkiv) | 09:11 |
raies | rameshg87: actually I am writing tests in tempest for baremetal APIs | 09:12 |
raies | ther ein configuration we need to write timeouts | 09:12 |
rameshg87 | raies: okay | 09:12 |
raies | rameshg87: as per /etc/ironic/ironic.conf a node will take 30 minuts to get active ?? | 09:14 |
raies | omg it is too high to have it in conf of tempest | 09:14 |
rameshg87 | no, it won't 30 minutes to get active | 09:15 |
rameshg87 | the pxe deploy operation configures the pxe environment and asks power cycles the node | 09:16 |
rameshg87 | after the node boots, the node informs ironic conductor, and the conductor starts writing the image to the disk | 09:16 |
rameshg87 | the deploy_callback_timeout is the timeout for the node after the power cycle to contact the ironic conductor | 09:16 |
rameshg87 | if the node doesn't contact within that time, the deploy operation should fail | 09:17 |
raies | ok | 09:17 |
raies | during deploy, is it required to take node in power state on ?? | 09:18 |
raies | rameshg87: I am using devstack development environment. I followed steps as I told above (1. Create node 2. Provision state set active (deploy completed), 3. show node (after an hour) target_provision_state is still "deploy compted" and provision state is still None) | 09:24 |
raies | I don't know whether m I going right or wrong | 09:25 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Add ManagementInterface https://review.openstack.org/86063 | 09:25 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMITool to use the new ManagementInterface https://review.openstack.org/86092 | 09:25 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: SeaMicro to use the new ManagementInterface https://review.openstack.org/86328 | 09:25 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMINative to use the new ManagementInterface https://review.openstack.org/86588 | 09:26 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: IPMINative set_boot_device persistent https://review.openstack.org/85742 | 09:26 |
*** foexle has joined #openstack-ironic | 09:28 | |
openstackgerrit | A change was merged to openstack/ironic: Implement list_instance_uuids() in Nova driver https://review.openstack.org/88684 | 09:41 |
openstackgerrit | A change was merged to openstack/ironic: Modify the get console API https://review.openstack.org/87760 | 09:41 |
*** dshulyak has joined #openstack-ironic | 09:42 | |
*** andreykurilin has quit IRC | 09:49 | |
raies | rameshg87: for APi verification will this level verification do or not ?? | 09:55 |
raies | i.e when I set provision state to "active" | 09:56 |
raies | how can I validate that provision state is set as invoked | 09:57 |
raies | I am using devstack environment | 09:57 |
raies | rameshg87: what steps I followed, I explained you. It has been more than an hour but still provison state is None | 09:58 |
*** dkehn__ has joined #openstack-ironic | 10:07 | |
*** dkehn_ has quit IRC | 10:10 | |
dtantsur | Guys, maybe you now: is it possible to run several conductor processes on the same machine and thus share the master image directory? | 10:12 |
dtantsur | I am trying to understand why we had file-based locking for master image directory in PXE module | 10:13 |
dtantsur | my intention is to just replace it with lockutils | 10:13 |
dtantsur | lucasagomes, hi, maybe you know ^^^ ? | 10:16 |
lucasagomes | dtantsur, hmm not off the top of my head, I know it's possible to run more than one conductor (for testing the hash ring for example) | 10:30 |
lucasagomes | idk if it's something that should be done in production tho | 10:30 |
lucasagomes | now having the file-based lock, I think it's used to prevent that case, to not allow the dir to be used by diff processes at the same time | 10:31 |
dtantsur | lucasagomes, but there are a lot of places already, where process-based lock is used, so I am a bit confused | 10:32 |
lucasagomes | right | 10:32 |
lucasagomes | you're running the processes with the same user? | 10:32 |
dtantsur | lucasagomes, I am not, I am thinking about possible race conditions in caching code :) | 10:33 |
dtantsur | there are some already, and it seems like I introduced even more | 10:33 |
dtantsur | and now trying to fix things at once :) | 10:34 |
dtantsur | it is re https://review.openstack.org/#/c/85387 | 10:34 |
lucasagomes | heh, right... | 10:36 |
lucasagomes | one thing is I don't tihnk we will ever want to run >1 conductor on the same node in production | 10:36 |
dtantsur | lucasagomes, that's a relief :) ok, I will stick to convenient lockutils for now and see what people are going to say | 10:37 |
lucasagomes | dtantsur, ack... | 10:37 |
*** coolsvap is now known as coolsvap|afk | 10:40 | |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Document ClusteredComputeManager https://review.openstack.org/89533 | 11:00 |
*** derekh has quit IRC | 11:01 | |
*** rameshg87 has left #openstack-ironic | 11:21 | |
*** lucasagomes is now known as lucas-hungry | 11:22 | |
*** killer_prince has quit IRC | 11:57 | |
openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Unified object model https://review.openstack.org/85065 | 12:01 |
openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Get rid object model `dict` methods part 3 https://review.openstack.org/64108 | 12:01 |
openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Get rid object model `dict` methods part 1 https://review.openstack.org/60025 | 12:01 |
openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Get rid object model `dict` methods part 2 https://review.openstack.org/62331 | 12:01 |
openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Get rid object model `dict` methods part 5 https://review.openstack.org/64278 | 12:01 |
openstackgerrit | Vladimir Kozhukalov proposed a change to openstack/ironic-python-agent: Added list and report disk utils https://review.openstack.org/88602 | 12:02 |
*** jdob has joined #openstack-ironic | 12:06 | |
*** datajerk has joined #openstack-ironic | 12:07 | |
*** jdob has quit IRC | 12:09 | |
*** jdob has joined #openstack-ironic | 12:09 | |
*** Manishanker has quit IRC | 12:15 | |
*** andreykurilin has joined #openstack-ironic | 12:15 | |
*** lucas-hungry is now known as lucasagomes | 12:20 | |
*** datajerk has quit IRC | 12:25 | |
NobodyCam | good morning Ironic | 12:28 |
Mikhail_D_wk | NobodyCam: g'morning :) | 12:32 |
NobodyCam | morning Mikhail_D_wk :) | 12:33 |
*** Mikhail_D_wk has left #openstack-ironic | 12:38 | |
*** Mikhail_D_wk has joined #openstack-ironic | 12:40 | |
*** derekh has joined #openstack-ironic | 12:41 | |
*** matsuhashi has quit IRC | 12:43 | |
*** matsuhashi has joined #openstack-ironic | 12:43 | |
lucasagomes | morning NobodyCam Mikhail_D_wk | 12:44 |
Mikhail_D_wk | lucasagomes: morning :) | 12:45 |
NobodyCam | morning lucasagomes :) | 12:45 |
NobodyCam | have a good weekend? | 12:45 |
romcheg | Hi NobodyCam, lucasagomes and everyone else! | 12:47 |
Mikhail_D_wk | lucasagomes: I left comment in https://review.openstack.org/#/c/60025/ | 12:47 |
*** datajerk has joined #openstack-ironic | 12:47 | |
NobodyCam | hey hey romcheg :) | 12:47 |
*** datajerk has quit IRC | 12:47 | |
openstackgerrit | Mikhail Durnosvistov proposed a change to openstack/ironic: Old value 'updated_at' field returned after update https://review.openstack.org/75430 | 12:47 |
*** matsuhashi has quit IRC | 12:48 | |
NobodyCam | your back back in the news over here :-p ... Hope everyone is safe and well :) | 12:48 |
*** blamar has quit IRC | 12:48 | |
*** nosnos has quit IRC | 12:48 | |
lucasagomes | Mikhail_D_wk, thanks will see | 12:48 |
*** blamar has joined #openstack-ironic | 12:49 | |
*** rloo has joined #openstack-ironic | 12:50 | |
*** nosnos has joined #openstack-ironic | 12:51 | |
*** nosnos has quit IRC | 12:52 | |
*** jbjohnso has joined #openstack-ironic | 12:53 | |
*** viktors has quit IRC | 12:54 | |
*** viktors has joined #openstack-ironic | 12:56 | |
*** dkehn__ is now known as dkehnx | 12:57 | |
NobodyCam | wow 2 X 2 X 40G fiber network connections for 160G of network bandwidth per server... | 12:57 |
*** killer_prince has joined #openstack-ironic | 12:58 | |
NobodyCam | brb | 13:00 |
*** sseago has quit IRC | 13:04 | |
*** max_lobur has quit IRC | 13:14 | |
*** max_lobur has joined #openstack-ironic | 13:15 | |
*** mdickson has quit IRC | 13:16 | |
*** matty_dubs|gone is now known as matty_dubs | 13:23 | |
*** linggao has joined #openstack-ironic | 13:24 | |
jroll | morning ironic :) | 13:26 |
NobodyCam | morning jroll :) | 13:26 |
NobodyCam | lucasagomes: question... was this not by design? https://bugs.launchpad.net/python-ironicclient/+bug/1310446 | 13:29 |
*** mdickson has joined #openstack-ironic | 13:29 | |
lucasagomes | NobodyCam, hey, it was | 13:30 |
lucasagomes | NobodyCam, we added it to the libs (so that nova can start the deployment) but not the cli | 13:30 |
NobodyCam | the the need for bp approval | 13:30 |
NobodyCam | yep | 13:30 |
NobodyCam | s/the the/thus the/ | 13:31 |
lucasagomes | right | 13:31 |
*** jgrimm has joined #openstack-ironic | 13:32 | |
NobodyCam | commented | 13:33 |
NobodyCam | :-p | 13:33 |
lucasagomes | :D | 13:33 |
lucasagomes | cheers | 13:33 |
*** datajerk has joined #openstack-ironic | 13:35 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 13:42 |
openstackgerrit | Jarrod Johnson proposed a change to stackforge/pyghmi: Fix mass thread initialization of sessions https://review.openstack.org/89573 | 13:50 |
NobodyCam | ok heres a question I am seeing may come up. | 13:52 |
NobodyCam | can we deploy a image with out hdd... by that I mean say the user wishes to deploy only a ram disk | 13:53 |
*** ndipanov has quit IRC | 13:53 | |
*** ndipanov has joined #openstack-ironic | 13:55 | |
*** datajerk has quit IRC | 13:55 | |
lucasagomes | NobodyCam, network volume? | 14:00 |
lucasagomes | when we support that we could than deploy a node without a local hd | 14:00 |
NobodyCam | lucasagomes: nope.. system with 3TB of RAM | 14:00 |
lucasagomes | we will be able then* | 14:00 |
NobodyCam | the ramdisk is the user image | 14:01 |
lucasagomes | right | 14:01 |
lucasagomes | well, I don't know the use cases for that... but right now we can't | 14:01 |
lucasagomes | because the provision_state will be set to active | 14:02 |
lucasagomes | after the pass_deploy_info | 14:02 |
lucasagomes | but doesn't sounds hard to implement it | 14:02 |
NobodyCam | lucasagomes: yea.. its for big data. in memory DB, auto scalling | 14:03 |
dtantsur | re blueprints: there was an idea to consider Glance checksum when caching master images (or using one from cache). Do you think I need to create a blueprint before starting? | 14:03 |
dtantsur | I just have no idea what change is large enough to have a blueprint | 14:04 |
linggao | ping matty_dubs | 14:04 |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Implement more robust caching for master images https://review.openstack.org/85387 | 14:04 |
NobodyCam | dtantsur: if you have a question if its a big enough change for BP then it prob is :) | 14:04 |
lucasagomes | NobodyCam, i see :D | 14:05 |
dtantsur | NobodyCam, it's not large, but it seems it can be controversial | 14:05 |
NobodyCam | dtantsur: then I would do a BP for it | 14:05 |
dtantsur | thanks | 14:05 |
NobodyCam | eheheh :) | 14:06 |
jroll | NobodyCam: send me that 3TB system and I'll figure it out :P | 14:06 |
NobodyCam | jroll: I want to do a burn in with ... oh say a unreal server :-p | 14:07 |
jroll | :D | 14:07 |
lucasagomes | heh thats a crap load of ram :P | 14:08 |
NobodyCam | 96 dimm slots filled with 32 gb dimms :) | 14:09 |
*** rwsu has joined #openstack-ironic | 14:09 | |
jroll | NobodyCam: these are pretty cool http://www.innodisk.com/intel/SATADOM_all.html | 14:09 |
jroll | just get a little one for the boot disk and good to go | 14:10 |
*** datajerk has joined #openstack-ironic | 14:10 | |
linggao | ping devananda | 14:10 |
NobodyCam | humm... | 14:10 |
NobodyCam | linggao: prob a liitle bit b4 he's online | 14:10 |
linggao | morning NobodyCam. | 14:11 |
NobodyCam | jroll: those are cool :) | 14:11 |
NobodyCam | morning linggao :) | 14:11 |
matty_dubs | jroll: What do those cost? | 14:11 |
matty_dubs | Normal people money, or 3TB RAM money? | 14:12 |
jroll | matty_dubs: I have no idea, but I don't see why they'd be too expensive | 14:12 |
jroll | afaik it's just like the flash memory in your phone or whatever plus a sata connector | 14:12 |
matty_dubs | The SLC bit made me nervous | 14:12 |
jroll | random amazon search says < $100 | 14:12 |
NobodyCam | ya I can pick like 20 gb ssd for $30 or less now a days | 14:12 |
matty_dubs | I've been toying with building a ZFS box at home and keep reading that you should put the ZIL on an SLC drive | 14:13 |
jroll | oh yeah, slc is a bit more expensive | 14:13 |
linggao | ping matty_dubs | 14:15 |
matty_dubs | linggao: pong | 14:15 |
linggao | matty_dubs, for the console patch https://review.openstack.org/#/c/64100/, I think I need to do some restructure. | 14:15 |
matty_dubs | How so? | 14:16 |
linggao | I want to pull the functions that related to shellinabox in a separate file like console_util.py because ipminative and many other drivers will use the same functions. | 14:16 |
matty_dubs | Hmm, that seems fairly reasonable. | 14:17 |
matty_dubs | linggao: I was actually poking at the ssh drivers for something unrelated, and thinking we could plug in console support there, too. | 14:18 |
matty_dubs | linggao: Not in this patch, though :) | 14:18 |
linggao | And the 3 configuration settings 'terminal_cert_dir', 'terminal_pid_dir', 'terminal' are not really for ipmi. They should be under [console] section and be shared by different drivers. | 14:18 |
matty_dubs | But I like the idea of making it a bit more extensible. | 14:18 |
matty_dubs | Ah, +1 to that | 14:18 |
linggao | matty_dubs, yes so I'd like to get this patch landed and then make the changes to pull the common functions out. | 14:19 |
matty_dubs | linggao: Oh, so you want to merge 64100 soon and _then_ refactor? | 14:19 |
matty_dubs | I'm fine with either, FWIW. | 14:19 |
linggao | great. I'll work on a patch that depends on this one. | 14:20 |
linggao | matty_dubs, thanks. | 14:21 |
matty_dubs | linggao: Really, we just need more reviewers. I already gave a +1, but I'm the only one :'( | 14:22 |
linggao | matty_dubs, let's see if we can bribe someone, like lucasagomes or NobodyCam? | 14:25 |
NobodyCam | huh | 14:25 |
NobodyCam | hehehe | 14:25 |
matty_dubs | Ooh, good idea | 14:26 |
openstackgerrit | linggao proposed a change to openstack/ironic: Support serial console access https://review.openstack.org/64100 | 14:27 |
*** newell has joined #openstack-ironic | 14:28 | |
linggao | plase ignore this set. I need to do pep8 | 14:28 |
*** datajerk has quit IRC | 14:28 | |
lucasagomes | linggao, will take a look (need to finish one thing before) | 14:29 |
linggao | thanks, lucasagomes. I need to check in another set for it to incoporate the new console api change. | 14:30 |
*** sseago has joined #openstack-ironic | 14:32 | |
*** datajerk has joined #openstack-ironic | 14:33 | |
*** sseago has quit IRC | 14:41 | |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 14:50 |
*** sseago has joined #openstack-ironic | 14:55 | |
*** datajerk has quit IRC | 14:57 | |
*** dwalleck has joined #openstack-ironic | 14:59 | |
matty_dubs | linggao: What changed in this one? Does this include the above change, or was it a rebase? (Diffing it against the previous patch shows about 16k lines changed, seemingly due to changes on master.) | 14:59 |
NobodyCam | matty_dubs: sounds like rebase to me | 14:59 |
matty_dubs | I guess my question is more accurately, "Was it just a rebase, or are there code changes too?" | 15:00 |
linggao | matty_dubs, please ignore this one. I am working on a rebase and make changes in the get_console to return a dict instead of a string. The API changes in 87760. | 15:01 |
matty_dubs | Ah, will do. Thanks. | 15:01 |
*** derekh has quit IRC | 15:02 | |
*** datajerk has joined #openstack-ironic | 15:10 | |
NobodyCam | bbt..brb | 15:13 |
*** hemna_ has joined #openstack-ironic | 15:13 | |
*** hemna_ has quit IRC | 15:14 | |
*** hemna_ has joined #openstack-ironic | 15:18 | |
*** datajerk has quit IRC | 15:20 | |
*** ndipanov has quit IRC | 15:24 | |
*** hemna_ has quit IRC | 15:25 | |
dwalleck | jroll: ping? | 15:29 |
openstackgerrit | linggao proposed a change to openstack/ironic: Support serial console access https://review.openstack.org/64100 | 15:29 |
*** datajerk has joined #openstack-ironic | 15:36 | |
*** ndipanov has joined #openstack-ironic | 15:37 | |
NobodyCam | did we come up with a way to do rack aware provisioning? | 15:42 |
jroll | dwalleck: waiting for the bus, will get back to you from the office :) | 15:44 |
*** yuriyz has quit IRC | 15:45 | |
*** datajerk has quit IRC | 15:45 | |
*** hemna_ has joined #openstack-ironic | 15:45 | |
*** jistr has quit IRC | 15:48 | |
*** jistr has joined #openstack-ironic | 15:50 | |
*** eghobo has joined #openstack-ironic | 15:51 | |
*** viktors is now known as viktors_away | 15:52 | |
*** vkozhukalov has quit IRC | 15:52 | |
*** derekh has joined #openstack-ironic | 15:53 | |
*** mdickson has quit IRC | 16:00 | |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Port to oslo.messaging https://review.openstack.org/88307 | 16:03 |
*** mdickson has joined #openstack-ironic | 16:03 | |
openstackgerrit | Dmitry Tantsur proposed a change to openstack/ironic: Implement more robust caching for master images https://review.openstack.org/85387 | 16:04 |
openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Port to oslo.messaging https://review.openstack.org/88307 | 16:06 |
lucasagomes | devananda, https://blueprints.launchpad.net/ironic/+spec/promote-set-boot-device as asked for the set_boot_device work | 16:07 |
dtantsur | ifarkas, hope I managed to create a proper blueprint for all these cache-related things https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching | 16:07 |
dtantsur | lucasagomes, we need MOAR blueprints :D | 16:11 |
lucasagomes | hah | 16:11 |
*** matty_dubs is now known as matty_dubs|lunch | 16:11 | |
*** jistr has quit IRC | 16:12 | |
ifarkas | dtantsur, wow, do we need a blueprint for that? | 16:12 |
ifarkas | but yeah, makes sense | 16:12 |
dtantsur | ifarkas, as I understand, trend now is to have blueprint for major changes. ours proved to be a major one | 16:12 |
*** zdiN0bot has joined #openstack-ironic | 16:13 | |
dtantsur | and guys, we need a blueprint for having more blueprints :) | 16:13 |
*** lucasagomes is now known as lucas-afk | 16:13 | |
*** datajerk has joined #openstack-ironic | 16:16 | |
dtantsur | now seriously, what is the process of approving blueprints? | 16:16 |
openstackgerrit | linggao proposed a change to openstack/python-ironicclient: node-get-console incorporate the changes in API https://review.openstack.org/87769 | 16:17 |
NobodyCam | dtantsur: as of right now... put up blueprint and then have people go look at it.. | 16:17 |
NobodyCam | thou that will be changing soon | 16:17 |
dtantsur | yeah, I've heard about Nova procedure, I just wondering what to do right now :) | 16:18 |
*** datajerk has quit IRC | 16:18 | |
dtantsur | NobodyCam, because in my situation a started to work on a bug (proper caching? peace of cake, what can go wrong?) and then realized that this is a major rework actually, so I created a blueprint for this and future changes | 16:19 |
dtantsur | probably not exactly the right thing to do (tm), but... | 16:19 |
NobodyCam | :) thats the way it goes sometimes | 16:20 |
*** uberj_ is now known as uberj | 16:25 | |
dtantsur | btw, NobodyCam, could you actually have a look? https://blueprints.launchpad.net/ironic/+spec/pxe-master-images-caching | 16:26 |
* dtantsur be back in ~hour | 16:26 | |
*** jgrimm has quit IRC | 16:26 | |
jroll | dwalleck: here now, got a few? | 16:26 |
NobodyCam | dtantsur: sure.. but am about to jump on a conf call so ok if I look after that :) | 16:26 |
dtantsur | sure | 16:27 |
NobodyCam | :) | 16:27 |
devananda | mornin, all | 16:28 |
NobodyCam | good morning devananda :) | 16:29 |
BadCub | Morning Devananda | 16:29 |
jroll | heya devananda :) | 16:30 |
NobodyCam | dtantsur: what are the impacts of this change.. Ie will api's need changing? | 16:30 |
NobodyCam | with the doc require changes | 16:30 |
NobodyCam | s/doc/docs/ | 16:30 |
NobodyCam | hehe on hold.. :-p | 16:30 |
dwalleck | jroll: Was my turn to bail out, hit the food trucks | 16:38 |
*** shakamunyi has joined #openstack-ironic | 16:39 | |
jroll | heh, no worries. good now? | 16:39 |
dwalleck | yup! | 16:40 |
jroll | cool | 16:40 |
jroll | so I'm thinking about agent + tempest | 16:40 |
jroll | idk how much you've looked at it | 16:40 |
jroll | but should it be pretty similar to the existing tempest things? | 16:40 |
devananda | BadCub: !! hi there :) | 16:40 |
*** ndipanov is now known as ndipanov_gone | 16:41 | |
dwalleck | Ahh, that's what you mean. I'm aware of the agent, haven't messed with it much | 16:41 |
jroll | dwalleck: or are we going to have to go from scratch | 16:41 |
jroll | ok | 16:41 |
dwalleck | Well, sort of. Tempest mostly interacts with APIs | 16:41 |
jroll | where can I find the existing tests btw? | 16:41 |
dwalleck | Tempest is at: github.com/openstack/tempest CloudCafe at github.com/stackforge/cloudroast | 16:42 |
jroll | as far as the agent, it's somewhat similar to the existing pxe driver | 16:42 |
jroll | see https://wiki.openstack.org/wiki/Ironic-python-agent | 16:42 |
jroll | and the diagrams linked from there | 16:42 |
jroll | ok | 16:42 |
dwalleck | Haven't tried it, but I think it's doable. How are things communicating with the agent? sockets? | 16:43 |
jroll | http, yeah | 16:43 |
jroll | so | 16:43 |
dwalleck | Oh! The agent does expose a rest API! | 16:43 |
jroll | when the agent starts up, it registers with a node in ironic through the api | 16:43 |
jroll | then ironic sends commands to the agent through the agent's rest api | 16:44 |
jroll | and yes :) | 16:44 |
jroll | that API is only ever touched by ironic | 16:44 |
*** zdiN0bot has quit IRC | 16:44 | |
jroll | it seems to me that tempest focuses on integration testing, so we would only want tempest to poke the ironic API, right? | 16:44 |
jroll | or would we also want to write standalone agent tests? | 16:45 |
dwalleck | The Tempest folks really only like people poking at the API and validating side effects. For example, I sort of hit the Nova agent when I change a password via the public API. It catches it as an integration piece | 16:46 |
dwalleck | It's possible we want both | 16:46 |
dwalleck | Tempest was originally integration only, but if you look at it now it's a bit of both | 16:47 |
dwalleck | As long as it's a deployed, functional thing, testing via Tempest should be fair game | 16:47 |
jroll | ok, right on | 16:48 |
jroll | seems like this is where actually spinning up a node is tested? https://github.com/openstack/tempest/blob/master/tempest/scenario/test_baremetal_basic_ops.py | 16:48 |
openstackgerrit | A change was merged to openstack/ironic: cleanup docstring for drivers.utils.get_node_mac_addresses https://review.openstack.org/88395 | 16:49 |
jroll | so we would just need another class for the agent_ssh driver I think | 16:49 |
jroll | shouldn't be too bad | 16:49 |
jroll | devananda: wdyt? tldr: agent testing - make another test scenario in tempest for the agent_ssh driver, and maybe even have tempest tests for the agent APIs | 16:50 |
dwalleck | So if I spin up an server right now, its already getting the ironic agent? | 16:50 |
dwalleck | I wasn't sure we were that far yet | 16:51 |
jroll | dwalleck: would you be able to work on that? | 16:51 |
dwalleck | jroll: Absolutely | 16:51 |
jroll | dwalleck: are you talking internally or? | 16:51 |
*** packet has joined #openstack-ironic | 16:51 | |
*** derekh has quit IRC | 16:51 | |
jroll | how the agent works overall is it's in a ramdisk that we pxe boot | 16:51 |
jroll | and if you're talking about our test environment, yes, we have agents running there | 16:52 |
jroll | now, deploys aren't fully functional | 16:52 |
jroll | but we're almost there, just some bugs to work out (which might just be environmental things) | 16:53 |
dwalleck | Yeah, having something working will help speed things up :) I can futz around if I need to. I think I'm making a bad translation though. When I think of agents, I think of the Nova agent, which is a process that lives inside each VM. That's not the case with Ironic agent? | 16:53 |
jroll | ah, nonono | 16:54 |
jroll | the agent will only run on unprovisioned servers | 16:54 |
jroll | it provisions an instance and we pass off to user | 16:54 |
dwalleck | Oh! | 16:54 |
dwalleck | That makes total sense | 16:54 |
jroll | then when user is done, it does decom work and then waits for a provision command again | 16:54 |
jroll | cool | 16:55 |
dwalleck | Cool! So is there one agent per chassis or something like that? | 16:55 |
jroll | by ironic terms, per node | 16:55 |
jroll | but a node is usually a chassis | 16:55 |
jroll | so yeah | 16:55 |
dwalleck | Okay, now I'm on the wagon | 16:55 |
jroll | \o/ | 16:56 |
jroll | the diagrams on that wiki page should have slightly more detail than that | 16:56 |
*** martyntaylor has left #openstack-ironic | 16:56 | |
dwalleck | Okay. Let me read through this so I have more intelligent questions to ask | 16:57 |
*** romcheg1 has joined #openstack-ironic | 16:57 | |
jroll | sure thing | 16:57 |
dwalleck | But my general feeling is that this shouldn't be too hard (jinx). Where these tests live might be the only thing up for debate | 16:58 |
*** zdiN0bot has joined #openstack-ironic | 16:58 | |
jroll | I'm just trying to get a general plan thought out atm | 16:58 |
jroll | heh | 16:58 |
jroll | as far as tempest vs cloudcafe or something else? | 16:58 |
dwalleck | Well, Tempest only likes testing public APIs. This might be considered an internal API | 16:58 |
dwalleck | But I'll roll the dice and see what they think. | 16:59 |
jroll | mmm | 16:59 |
jroll | well | 16:59 |
jroll | we currently have tempest tests for the pxe driver of ironic | 16:59 |
jroll | so ironic + agent driver are fair game | 16:59 |
dwalleck | Sounds reasonable | 17:00 |
jroll | I would prefer to have agent API tests, but if it's not allowed then /shrug | 17:00 |
JoshNang | most of the agent APIs should get hit by ironic tests though | 17:01 |
*** datajerk has joined #openstack-ironic | 17:01 | |
jroll | yeah, exactly | 17:01 |
jroll | but we could exercise more cases than ironic would, I think | 17:01 |
openstackgerrit | Devananda van der Veen proposed a change to openstack/ironic: Remove 'fake' driver from default enabled drivers https://review.openstack.org/88711 | 17:02 |
jroll | dwalleck: also, what's the deal with cloudroast? is the goal to replace tempest? | 17:02 |
*** matty_dubs|lunch is now known as matty_dubs | 17:02 | |
dwalleck | jroll: Not really. Tempest (as proven this morning in a lively discussion) is focused on API testing only. CloudRoast is more of a hoalistic view | 17:03 |
openstackgerrit | A change was merged to stackforge/pyghmi: Fix mass thread initialization of sessions https://review.openstack.org/89573 | 17:04 |
jroll | mmm | 17:04 |
dwalleck | The major different is that Tempest is something I wrote when I first started testing APIs. CloudCafe is what I wrote after I learned my lessons :-) | 17:04 |
dwalleck | So for example, today I put up the idea that Tempest should know the configured hypervisor/driver and skip based on what actions are implemented for that driver. That was shot down because they don't want Tempest to know anything about the environment | 17:05 |
dwalleck | In CloudCafe we're not only knowledgeable about the hypervisors, but go further in depth testing behaviors that occur because of that hypervisor | 17:06 |
*** eghobo has quit IRC | 17:07 | |
*** eghobo has joined #openstack-ironic | 17:07 | |
devananda | dwalleck: you know that, to get tempest to test ironic (via nova) there's a regex filter on the tests, right? | 17:08 |
jroll | dwalleck: I see | 17:08 |
devananda | dwalleck: we're essentially doing ^^ but at a layer above tempest ... | 17:08 |
jroll | devananda: did you catch this btw? | 17:08 |
jroll | 09:50:43 jroll | devananda: wdyt? tldr: agent testing - make another test scenario in tempest for the agent_ssh driver, and maybe even have tempest tests for the agent APIs | 17:08 |
devananda | jroll: hmm. well... | 17:09 |
jroll | :) | 17:09 |
devananda | jroll: we have two sets of tempest tests for ironic today, and i dont think we need more (though separate tests for the agent API might make sense... i'll come back to that) | 17:10 |
devananda | * API c/r/u/d tests w/ fake driver | 17:10 |
devananda | where tempest talks directly to ironic | 17:10 |
devananda | * integration test | 17:10 |
devananda | where devstack configures nova to use ironic, then tempest talks to nova | 17:11 |
devananda | jroll: as we add drivers that require testing, i think they should fit into that second category transparently | 17:11 |
devananda | whether we configure devstack to enroll the hw with driver A or B, it shouldn't matter to tempest | 17:12 |
devananda | because it shouldn't matter to the user of nova | 17:12 |
devananda | if it does, we've broken the abstraction | 17:12 |
jroll | devananda: sure | 17:12 |
jroll | so, would a better way be to have integration tests provision n nodes, each with different drivers? | 17:13 |
devananda | possibly | 17:14 |
jroll | that's kind of what I had in mind | 17:14 |
jroll | then I saw https://github.com/openstack/tempest/blob/master/tempest/scenario/test_baremetal_basic_ops.py#L52 | 17:14 |
jroll | and thought maybe we should just add another class like that | 17:14 |
*** zdiN0bot has quit IRC | 17:14 | |
*** zdiN0bot has joined #openstack-ironic | 17:14 | |
*** datajerk has quit IRC | 17:15 | |
devananda | adam_g: thoughts ^ ? | 17:15 |
devananda | jroll: I think that's the same thing | 17:16 |
jroll | ah | 17:16 |
jroll | yeah, so that was my plan | 17:16 |
devananda | jroll: well, "it shouldn't matter to tempest" may be a bit misleading | 17:16 |
jroll | and then maybe some agent API testing if we can talk tempest folks into testing internal apis | 17:16 |
devananda | jroll: tempest is validating that certain things happened, which are, in this case, specific to the ironic driver in question | 17:17 |
jroll | right | 17:17 |
devananda | dwalleck's comments seem to indicate that is not in keeping with what folks want tempest to do... i'm not sure | 17:17 |
jroll | right | 17:17 |
devananda | though this information is exposed in Ironic's API, so tempest is able to validate it there, without having to reach "underneath" ironic to check | 17:18 |
jroll | either way, we're going to have tests for the API, it's just a matter of where they live and if things are mocked :) | 17:18 |
jroll | yeah | 17:18 |
devananda | also, some of that needs to move to instance_info (not driver_info) | 17:18 |
*** harlowja_away is now known as harlowja | 17:18 | |
devananda | and will be the same for the pxe and agent drivers | 17:18 |
dwalleck | devananda: Yeah, they were not very amused by my proposal to give Tempest even the knowledge of what driver Nova is using | 17:18 |
devananda | eg, deploy_ramdisk, root_gb, etc | 17:18 |
jroll | yep | 17:18 |
devananda | dwalleck: heh. well, they've allowed that in for ironic | 17:19 |
devananda | dwalleck: see the link jroll posted | 17:19 |
devananda | it's verifying specific results in Ironic's API as a result of Nova using the Ironi driver here: https://github.com/openstack/tempest/blob/master/tempest/scenario/test_baremetal_basic_ops.py#L83 | 17:20 |
dwalleck | devananda: Actually, that's very true | 17:20 |
dwalleck | That would never work with another driver | 17:20 |
devananda | jroll: once we move as much as we can from driver_info to instance_info, and the agent driver uses the same DHCP integration with Neutron, I think these tests will look identical | 17:21 |
devananda | dwalleck: right | 17:21 |
jroll | devananda: I hope so :) | 17:22 |
dwalleck | But you do have to have the Ironic service enabled for those tests to run, which goes back to just declaring your nova driver. Docker and LXC folks are in the same boat | 17:22 |
devananda | dwalleck: right | 17:22 |
devananda | dwalleck: but there are a lot of tests which we also have to *disable* when using the ironic driver | 17:23 |
*** Mikhail_D_ltp has joined #openstack-ironic | 17:24 | |
*** Mikhail_D_ltp has quit IRC | 17:24 | |
dwalleck | right. That's why I proposed a higher level of abstraction as it would make the effort much, much easier. The general feeling was that any nova driver should support most or some agreed on subset of the API, so I withdrew to fight another day :) | 17:25 |
devananda | dwalleck: yea. i've had that discussion with clarkb a few times, and i think there's a session in atlanta o nit | 17:25 |
devananda | tldr; there are some things which ironic doesn't (and essentially cant) implement that other virt drivers do | 17:26 |
devananda | does that mean ironic can never be a supported driver for nova? | 17:26 |
dwalleck | devananda: That's the point I was starting to make | 17:27 |
dwalleck | KVM doesn't support change password, so is it out of Nova too? :) | 17:27 |
devananda | heh | 17:28 |
*** vkozhukalov has joined #openstack-ironic | 17:30 | |
*** jgrimm has joined #openstack-ironic | 17:32 | |
adam_g | jroll, devananda my original idea was to extend the current tempest scenario test beyond *PXESSH, and have tests skip based on what drivers are reported by ironic | 17:32 |
devananda | adam_g: ah. so then, when used for third-party tests, it might run only the tests for that specific (eg, seamicro) driver? | 17:33 |
adam_g | if we want to test other drivers or the agent, we'd need to have devstack be able to deploy it with some driver flag (it ucrrently only support pxe_ssh hard coded) | 17:33 |
dtantsur | NobodyCam, sorry, was out for language lesson :) Should I updated a blueprint with information on impact (none expected on API, not quite sure about docs)? | 17:34 |
devananda | adam_g: if at some point we have multiple drivers being tested upstream, think it's reasonable for devstack to create multiple nodes, one (or mroe) with each driver? | 17:35 |
adam_g | devananda, ideally yeah, we need to figure out a good way of targetting / discovering specific driver. say we have an ironic deployment that deploys / reports different drivers, can we boot a nova instance and target a specific driver ahead of time? | 17:35 |
devananda | adam_g: or would we want separate devstack runs, one for each driver? | 17:35 |
adam_g | devananda, i would think different runs for each driver. and devstack deployment deploys an ironic endpoint that lists only one supported driver, so tempest knows what to test | 17:36 |
*** epim has joined #openstack-ironic | 17:37 | |
NobodyCam | dtantsur: those are things that will be in the new BP template / format I put it out there more for thought. it is not required at this point but will be soon so I am trying to get folks to thing about it | 17:37 |
devananda | adam_g: nova allows targeting a specific host:node when booting an instance | 17:37 |
dtantsur | ack, thanks | 17:37 |
jroll | devananda: does it? comstud had to hack that in for me the other day :P | 17:38 |
devananda | adam_g: separate devstack run for each driver would require separate jenkins / devstack-gate job for each ironic driver, which seems like a waste of resources if we can avoid that | 17:39 |
devananda | adam_g: whereas it makes more sense for third-party tests, where they may only want one driver | 17:39 |
devananda | adam_g: though it should be easy now to have devstack configure ironic with only one driver, based on an ENV var | 17:40 |
adam_g | devananda, so... a seamicro test would query nodes for one enlisted /w that driver, skip if it doesnt find it, and run the scenario with a host:node constraint? | 17:40 |
adam_g | ..if it does | 17:40 |
devananda | well, as soon as https://review.openstack.org/#/c/86958/ lands, it will need one more patch | 17:40 |
devananda | adam_g: possibly | 17:41 |
devananda | i'm thinking of two different test environments | 17:41 |
devananda | 1) upstream, where we can test reference drivers // drivers taht are not hardware-specific (eg, pxe_ssh, agent_ssh) | 17:41 |
devananda | 2) third-party ci, where specific hardware is required (eg, seamicro, ilo) | 17:41 |
adam_g | whatever the test environment, you should ideally be able to point-and-shoot /w tempest and have it figure out what to run/skip | 17:41 |
devananda | actually, that's going to be more complicated than i thought at first | 17:43 |
devananda | but i think we need to | 17:44 |
NobodyCam | Shrews: I think #1 is dangerious | 17:44 |
devananda | jroll: this is sort of a follow on to yesterdays' conversation. if we can run pxe_* and agent_* in the same environment, we should be able to test both in the same devstack/tempest environment ,too | 17:44 |
jroll | indeed | 17:45 |
devananda | jroll: if we can't run them in the same env (eg, because they have different DHCP requirements) then we've broken the architecture | 17:45 |
devananda | so it seems that having devstack deploy both and tempest test both in parallel would actually be good | 17:45 |
devananda | maybe a high bar, but a good one | 17:45 |
jroll | yep, +1 | 17:45 |
devananda | and we should then impose the same requirement on thrid-party drivers | 17:46 |
devananda | eg, run both pxe_ipmi and seamicro_ipmi in the same test env | 17:46 |
devananda | adam_g: so i think we actually need tempest to run tests against two drivers in parallel to ensure that no driver breaks the architectural assumption that multiple drivers _can_ coexist | 17:46 |
adam_g | with the agent, are there ironic API calls we can make while the nova provisioning flow is happening that the test can verify all things are happening correctly? as we do with the current pxe_ssh scenario test? | 17:47 |
Shrews | NobodyCam: #1 is not my first choice either | 17:47 |
*** martyntaylor has joined #openstack-ironic | 17:47 | |
jroll | adam_g: yes. goal is to make it work similarly to the pxe driver, e.g. you'll be able to see target_provisioning_state set correctly etc | 17:47 |
NobodyCam | maybe if mantiance mode as also true | 17:47 |
NobodyCam | but still scarry | 17:48 |
Shrews | yeah | 17:48 |
adam_g | devananda, running them in parallel may be a challenge, at least in the near term. we explicitly turn of concurrent tests. but having a single tempest run hit both tests serially would probably be doable. | 17:48 |
devananda | adam_g: serial is fine | 17:48 |
rloo | Mikhail_D_wk: are you around? | 17:52 |
NobodyCam | morning rloo :) | 17:52 |
Shrews | devananda: fyi, my initial -1 vote on 87346 was b/c logging wasn't working. It does after a rebase so I changed my vote. | 17:52 |
rloo | morning NobodyCam! | 17:52 |
NobodyCam | :) | 17:52 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 17:53 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Drivers determine acceptable power states https://review.openstack.org/86744 | 17:55 |
*** jbjohnso has quit IRC | 17:58 | |
comstud | devananda: ya, i couldn't/can't find any way to target a specific host or node. There happens to be internal use of it, but it's not accessable via scheduler hints | 17:59 |
comstud | from what i could find | 17:59 |
Shrews | SpamapS: rebuild is not really a "state", but triggers a state change on the instance. To trigger a deploy, we set the target state to "active", but since the instance is already active, the api complains. :/ | 17:59 |
devananda | comstud: nova boot --availability-zone zone:host:node | 17:59 |
*** packet has quit IRC | 18:00 | |
comstud | ah right, with AZS | 18:00 |
comstud | but without AZs, there's no way | 18:00 |
devananda | yea. the old --force_host got replaced b ythat | 18:00 |
adam_g | devananda, isn't that an admin-only capability? | 18:00 |
comstud | unless maybe 'default' works | 18:00 |
devananda | well, there should be a default AZ | 18:00 |
devananda | adam_g: yes | 18:00 |
comstud | so maybe default:host:node works | 18:01 |
devananda | adam_g: well, by default, yes. but i think you can change that with nova policy | 18:01 |
adam_g | devananda, so WRT tempest we run everything as the non-admin user | 18:01 |
devananda | adam_g: set up one nova flavor per node? | 18:02 |
devananda | hmm, nvm. | 18:02 |
devananda | it might work but is a pretty bad hack | 18:02 |
adam_g | devananda, that was my original idea. baremetal_pxe, baremetal_seamicro? | 18:02 |
adam_g | flavor per driver | 18:02 |
devananda | we could add a scheduler filter that matched on that, perhaps | 18:02 |
devananda | but not the way i'd recommend operators to deploy it, and not something users should see | 18:03 |
adam_g | right | 18:03 |
*** jbjohnso has joined #openstack-ironic | 18:03 | |
devananda | i would rather just change the nova policy for --availability-zone | 18:04 |
jroll | there also may be a need for a driver to use multiple flavors | 18:04 |
devananda | initial guess: "compute:create:forced_host": "is_admin:True", | 18:04 |
*** BLZbubba_ has quit IRC | 18:05 | |
devananda | we just need to change that | 18:05 |
*** rameshg87 has joined #openstack-ironic | 18:05 | |
devananda | jroll: IMO the flavor should match the type of hardware being provisioned, not the specific driver doing the provisioning | 18:05 |
jroll | exactly. | 18:05 |
jroll | I didn't word that very well :P | 18:06 |
devananda | if I ask for a node with 8 cores and 32GB RAM, it shouldn't matter whether it's HP or AMD hardware | 18:06 |
devananda | :) | 18:06 |
jroll | as an HP employee I would think you *would* have an opinion on that :P | 18:06 |
* jroll stops derailing | 18:06 | |
adam_g | ha | 18:07 |
devananda | jroll: with my HP hat on, yes. with my PTL hat on, no :p | 18:08 |
NobodyCam | hummm.. speaking of deraining... should we register our port? http://www.iana.org/form/ports-services | 18:08 |
jroll | :) | 18:08 |
devananda | NobodyCam: ahh. yes ... | 18:08 |
devananda | NobodyCam: thanks for reminding me | 18:09 |
NobodyCam | :-p | 18:09 |
SpamapS | Shrews: I don't really understand what that means. It sounds like implementation details. | 18:14 |
devananda | NobodyCam: interesting... looks like several openstack services are not registered | 18:14 |
NobodyCam | yep I saw that | 18:15 |
*** eguz has joined #openstack-ironic | 18:15 | |
*** eghobo has quit IRC | 18:19 | |
matty_dubs | boris-42: devananda: Say, any pointers on where to get started for taking a look at perf-testing Ironic? I've got a couple boxes with 128GB RAM and 10Gb Ethernet to play with^W^Wuse for testing | 18:24 |
NobodyCam | lan party at matty_dubs house :-p | 18:26 |
*** krtaylor has quit IRC | 18:26 | |
matty_dubs | lol | 18:26 |
*** martyntaylor has left #openstack-ironic | 18:26 | |
*** hemna__ has joined #openstack-ironic | 18:26 | |
NobodyCam | matty_dubs: I would love to know if we are faster then nova BM | 18:26 |
* NobodyCam thinks not.. but | 18:27 | |
jroll | didn't lifeless determine that we are recently? | 18:27 |
lifeless | Ironic is linearly faster today | 18:27 |
jroll | (faster than BM) | 18:27 |
NobodyCam | w00t :) and mornign lifeless :) | 18:28 |
matty_dubs | ooh | 18:28 |
lifeless | https://review.openstack.org/#/c/87938/ will close the gap a bit | 18:28 |
lifeless | but there are things Ironic overlaps better beyond that ovherad | 18:28 |
lifeless | 'overhead' | 18:28 |
lifeless | matty_dubs: perf testing or scale testing | 18:29 |
lifeless | matty_dubs: time-to-deliver 1 node isn't interesting. Hundreds or thousands would be interesting | 18:29 |
lifeless | time-to-finished was 22minutes for 40 machines w/Ironic, 120 or so for nova-bm | 18:29 |
matty_dubs | lifeless: I have a small number of moderately-powerful machines, so more perf than scale. Though I could test scale with VMs, I suppose | 18:29 |
jroll | oh, that was 40 machines? nice. | 18:29 |
lifeless | jroll: yup, amortised 30 seconds/machine with Ironic, 3m with nova-bm | 18:30 |
* jroll has a secret goal of beating that record | 18:30 | |
matty_dubs | Oh, wow | 18:30 |
matty_dubs | I assume that's with parallel provisioning? | 18:30 |
lifeless | no | 18:30 |
matty_dubs | ! | 18:30 |
*** datajerk has joined #openstack-ironic | 18:30 | |
jroll | :o | 18:30 |
NobodyCam | nice :) | 18:30 |
jroll | seriously? | 18:30 |
jroll | that's impressive | 18:31 |
lifeless | well, whatever Ironic's default is. I think 2 dd's in parallel. Probably would be slightly faster if tuned to one at a time. | 18:31 |
jroll | that's time to get into reboot, yes? not including the actual boot? | 18:31 |
lifeless | the next big jump needs the multicast stuff implemented | 18:31 |
jroll | and these 40 were real machines, not VMs? | 18:31 |
lifeless | jroll: thats time to ACTIVE, HP Proliants. | 18:31 |
devananda | lifeless: that's with 40 "nova boot" in parallel, but the actual dd's are serialized, right? | 18:31 |
lifeless | jroll: 10Gbps network. | 18:31 |
jroll | dayum | 18:32 |
matty_dubs | That's pretty slick. Most machines I've seen can't _boot_ in 30sec | 18:32 |
lifeless | devananda: the driver for the test was 'devtest_overcloud.sh' with OVERCLOUD_COMPUTE_SCALE=40 | 18:32 |
matty_dubs | Much less get provisioned | 18:32 |
lifeless | matty_dubs: thats why I said 'amortised' | 18:32 |
devananda | matty_dubs: that's not the per-machine time-to-boot | 18:32 |
lifeless | matty_dubs: the time to first machine was 10m, and then they tick over in rapid fire sequence | 18:32 |
lifeless | 10m-or-so - I didn't time it precisely. | 18:33 |
devananda | right, so 2 POST cycles | 18:33 |
matty_dubs | Ha! Okay, yeah, that makes sense. I was doing nonsense math. | 18:33 |
*** dwalleck has quit IRC | 18:33 | |
matty_dubs | I'm with you now | 18:33 |
lifeless | | NovaCompute8 | 7e28aa0f-dd34-4672-918c-fc8945dd8ac9 | state changed | CREATE_IN_PROGRESS | 2014-04-15T08:01:21Z | | 18:33 |
devananda | jroll: you guys are trying to optimize the linear time-to-boot one machine though, right? | 18:33 |
lifeless | ... | 18:34 |
lifeless | | NovaCompute8 | 46bac141-ca08-4b67-b32e-c813d75a33d2 | state changed | CREATE_COMPLETE | 2014-04-15T08:08:33Z | | 18:34 |
lifeless | 7 minutes for the one POST cycle + partitioning + dd + initiate the second POST | 18:34 |
devananda | 7:12... nice | 18:34 |
devananda | yep | 18:34 |
lifeless | so <=14m to be in userspace | 18:34 |
jroll | devananda: that's the main number I want to look at, but I also am looking at whole-rack times | 18:34 |
lifeless | multicast should let us get the rack down from 22m to 14m. | 18:35 |
lifeless | https://etherpad.openstack.org/p/glance-multicast-image-transfer | 18:35 |
lifeless | libpgm is looking pretty good, I just need more timeslices on it | 18:35 |
devananda | lifeless: is there going to be a perf-related session in tripleo track? | 18:35 |
lifeless | devananda: probably not | 18:35 |
lifeless | devananda: not enough sessions | 18:36 |
devananda | lifeless: heh, right. and you have 2 more than we do :) | 18:36 |
lifeless | jroll: so Ironic is very close to 'optimal' today for single machine cases. | 18:37 |
lifeless | jroll: to make it faster I believe we'd need to write some custom C code and instead of dding, do a smart used-blocks-only copy from the qcow2 - probably preprocessing it to avoid high compute costs while still guaranteeing linear IO | 18:38 |
jroll | lifeless: or remove one POST cycle :) | 18:38 |
lifeless | jroll: this is something I think should be done as a successor to multicast, so we can obsolete the dd backend in the fullness of time | 18:38 |
lifeless | jroll: we did that, it wasn't reliable. | 18:38 |
devananda | fwiw, i'm not aware of any OOB mechanism which removes a POST cycle | 18:38 |
devananda | lifeless: he's referrign to pre-running an agent on all the hosts | 18:38 |
jroll | ^ | 18:39 |
devananda | not kexec (i hope) | 18:39 |
jroll | well, that's also a thing, but a bit more questionable | 18:39 |
jroll | :) | 18:39 |
devananda | jroll: you did mention kexec in your session proposal. fwiw, that's not an option because of poor support from PCI vendors | 18:39 |
lifeless | oh, ok, but that doesn't remove a POST cycle for reusing / reimaging, only for greenfields | 18:39 |
jroll | devananda: maybe as a config option or something. just a thought for now. | 18:40 |
devananda | it assumes excess capacity where the agent could sit idle (and, arguably, wasting power) | 18:40 |
jroll | lifeless: we don't really plan on fast turnover for a reimage or whatever. we'll do the decom when its released and have the agent wait for a deploy. | 18:41 |
lifeless | jroll: yeah, deploy-kexec in diskimage-builder will get you a nova-bm kexec deploy ramdisk, if you want to work on it. | 18:41 |
jroll | hmm, ok | 18:41 |
lifeless | jroll: reimage == nova rebuild --preserve-ephemeral btw. So same user, user data preserved. Time matters there. | 18:41 |
*** hemna__ has quit IRC | 18:42 | |
jroll | lifeless: right, I know. that's not a high priority for us right now. or at least for speed. | 18:42 |
lifeless | jroll: ack | 18:43 |
*** dwalleck has joined #openstack-ironic | 18:43 | |
*** openstackgerrit has quit IRC | 18:49 | |
*** openstackgerrit has joined #openstack-ironic | 18:49 | |
*** jistr has joined #openstack-ironic | 19:01 | |
*** derekh has joined #openstack-ironic | 19:03 | |
*** foexle has quit IRC | 19:05 | |
*** krtaylor has joined #openstack-ironic | 19:07 | |
*** GheAway is now known as GheRivero | 19:07 | |
*** datajerk has quit IRC | 19:11 | |
devananda | adam_g: I tossed some notes up here https://wiki.openstack.org/wiki/Ironic/Testing | 19:14 |
devananda | jroll: also applies to testing the agent | 19:15 |
devananda | please comment/edit as appropriate | 19:15 |
*** zdiN0bot has quit IRC | 19:16 | |
jroll | cool | 19:16 |
jroll | dwalleck: ^ | 19:16 |
dwalleck | jroll: Thanks! I'll check that out | 19:17 |
*** shakamunyi has quit IRC | 19:33 | |
*** shakamunyi has joined #openstack-ironic | 19:36 | |
*** hewbrocca has quit IRC | 19:39 | |
devananda | NobodyCam: answer to your IANA question -- keystone is the only one registered because it is the discovery mechanism for all the rest. thus the individual service ports don't matter | 19:47 |
linggao | ping matty_dubs | 19:48 |
matty_dubs | linggao: pong | 19:50 |
linggao | matty_dubs, now I think about the rearraging the functions for the console patch, I should use the current patch. what do you think? | 19:51 |
NobodyCam | ahh ok | 19:52 |
linggao | It makes send to make it right since the console has never been landed. | 19:52 |
matty_dubs | linggao: Yes, it does make sense now. The only risk is that it'll take even longer to get the patch merged. | 19:52 |
matty_dubs | But I guess we're not in a huge rush. | 19:52 |
NobodyCam | but with out registering our port could not "new service x" come along an snach it from us? | 19:53 |
linggao | matty_dubs, I'll get it in tomorrow. I'll put both your and my names as co-auther to be fair. | 19:53 |
matty_dubs | linggao: OK, I didn't mean to rush you. I just meant that if I were in your shoes I'd want the thing merged soon since it's >20 revisions. ;) I'm all for getting it right, though. | 19:54 |
matty_dubs | I've only contributed a handful of lines to the patch; not sure what the standard is for Co-authored by | 19:55 |
linggao | matty_dubs, I found out there need to be more doc changes in the code while doing the rearrangement. That's why I think it's better to to do it in the new file at one shot. :-) | 19:56 |
linggao | matty_dubs, you also helped testing it and contributing ideas. | 19:57 |
matty_dubs | Sure, that makes sense | 20:00 |
matty_dubs | I should really test this stuff on other hardware, too -- I realized that the box I'm testing on is IBM/Lenovo, and I presume yours is the same. | 20:00 |
matty_dubs | IPMI should be the same, but it wouldn't hurt for me to test this on a Dell box or something | 20:01 |
linggao | matty_dubs, yes, I tested on IBM/Lenovo too, "great minds think alike" haha. | 20:02 |
matty_dubs | :-D | 20:02 |
jroll | I haven't looked at this yet, are you using SOL? | 20:02 |
jroll | linggao: ^ | 20:02 |
*** derekh has quit IRC | 20:03 | |
matty_dubs | Yeah, it's IPMI SoL | 20:03 |
matty_dubs | Err, not to speak for linggao ;) | 20:03 |
linggao | jroll, yes, ipmitool sol activate with shellinabox | 20:03 |
jroll | cool | 20:03 |
openstackgerrit | Josh Gachnang proposed a change to openstack/ironic: Adding a reference driver for the agent https://review.openstack.org/84795 | 20:11 |
jroll | this driver_info -> instance_info patch might get massive... :/ | 20:13 |
*** dwalleck has quit IRC | 20:14 | |
devananda | jroll: it's gonna have to touch the pxe driver, nova.virt.ironic, devstack, and tempest | 20:15 |
jroll | I know :/ | 20:15 |
*** ifarkas has quit IRC | 20:19 | |
*** jistr has quit IRC | 20:20 | |
rloo | devananda: if you have a few minutes, this was rebased, needs approval again: https://review.openstack.org/#/c/78651/ | 20:20 |
*** vkozhukalov has quit IRC | 20:33 | |
NobodyCam | brb | 20:41 |
*** rch has joined #openstack-ironic | 20:44 | |
*** zdiN0bot has joined #openstack-ironic | 20:47 | |
*** romcheg2 has joined #openstack-ironic | 20:48 | |
*** romcheg1 has quit IRC | 20:50 | |
*** romcheg2 has quit IRC | 20:56 | |
*** epim has quit IRC | 21:00 | |
*** matty_dubs is now known as matty_dubs|gone | 21:03 | |
*** jdob has quit IRC | 21:04 | |
*** linggao has quit IRC | 21:10 | |
openstackgerrit | A change was merged to openstack/ironic: Add worker threads limit to _check_deploy_timeouts task https://review.openstack.org/78651 | 21:12 |
*** mdickson has quit IRC | 21:14 | |
jroll | devananda: hmm. looking at https://bugs.launchpad.net/ironic/+bug/1308680 | 21:15 |
jroll | devananda: rpc_thread_pool_size comes from ironic/openstack/common/rpc | 21:15 |
jroll | is there a way we can change the default in ironic code somehow? | 21:15 |
*** dwalleck has joined #openstack-ironic | 21:15 | |
devananda | jroll: the oslo.messaging patch from lucas-afk adds an option to change the worker pool separately | 21:18 |
devananda | ooh. i see what you mean | 21:18 |
jroll | yeah. | 21:18 |
devananda | we want to rpc thread pool to be very small | 21:18 |
devananda | taht option gets imported into our config file | 21:18 |
devananda | but with the default from oslo | 21:18 |
devananda | hmmm | 21:18 |
jroll | right | 21:19 |
devananda | lemme look once this meeting is over | 21:19 |
lucas-afk | :) | 21:19 |
jroll | ok, just curious if you knew something offhand | 21:19 |
jroll | I'll poke oslo and see if this has come up before | 21:19 |
devananda | nope | 21:19 |
devananda | we do things in the unit tests | 21:19 |
devananda | to override conf defaults | 21:19 |
lucas-afk | btw devananda jroll afternoon... devananda can you take a look at https://blueprints.launchpad.net/ironic/+spec/promote-set-boot-device ? (requested on the adding the management interface patch series) | 21:19 |
lucas-afk | no hurry as well, finish the meeting before | 21:20 |
devananda | k k | 21:20 |
jroll | good evening lucas :) | 21:20 |
*** jbjohnso has quit IRC | 21:22 | |
*** romcheg1 has joined #openstack-ironic | 21:24 | |
JoshNang | temptest is giving me a lot of 'no valid host, no conductor supports driver fake' errors. http://logs.openstack.org/95/84795/34/check/check-tempest-dsvm-ironic/c71655d/console.html | 21:27 |
JoshNang | has anyone else been getting that? | 21:28 |
adam_g | JoshNang, conductor isn't starting, probably due to something in your patch? http://logs.openstack.org/95/84795/34/check/check-tempest-dsvm-ironic/c71655d/logs/screen-ir-cond.txt.gz | 21:30 |
JoshNang | hmm. that's not good :) | 21:30 |
JoshNang | thanks adam_g ! | 21:30 |
adam_g | np! | 21:31 |
*** max_lobur has quit IRC | 21:40 | |
*** gpizza has joined #openstack-ironic | 21:46 | |
*** romcheg1 has quit IRC | 21:50 | |
devananda | lucas-afk: ok, mostly done. so, about https://blueprints.launchpad.net/ironic/+spec/promote-set-boot-device | 21:58 |
devananda | lucas-afk: two things come to mind imemdiately | 21:59 |
devananda | * we should just make it work with the ssh power driver, or we can't call it a "core interface" | 21:59 |
devananda | * we need to test it with tempest, in the gate | 21:59 |
NobodyCam | ugg munging xml :-p | 21:59 |
NobodyCam | http://stackoverflow.com/questions/19011159/how-to-set-boot-order-on-kvm-libvirt-virsh | 22:00 |
devananda | lucas-afk: so i'd like to see a plan for testing set boot device with VMs, even if it's not implemented prior to landing the management interface | 22:01 |
NobodyCam | vbox and vmware should be able to make the change via command line | 22:03 |
lucas-afk | devananda, right, I can put some work on getting the ssh driver to have a a set_boot_device | 22:04 |
lucas-afk | devananda, thanks for the review, I will take a look at it tomorrow then | 22:04 |
devananda | just posted comments to BP as well | 22:04 |
devananda | and updated direction to approved | 22:05 |
lucas-afk | devananda, ack, /me added it to my todo list | 22:05 |
lucas-afk | NobodyCam, thanks for the link :D | 22:05 |
NobodyCam | lucas-afk: http://download3.vmware.com/sample_code/Perl/VMBootOrder.html <- vmware | 22:05 |
openstackgerrit | Jim Rollenhagen proposed a change to openstack/ironic: Set a sane default for rpc_thread_pool_size https://review.openstack.org/89704 | 22:07 |
NobodyCam | lucas-afk: VBoxManage modifyvm <uuid|name> [--boot<1-4> none|floppy|dvd|disk|net>] <- vbox command to change boot order | 22:07 |
lucas-afk | NobodyCam, ah wow, thanks for that! | 22:08 |
jroll | devananda: haven't tested that bug along with lucas' patch, but there's the other half of your proposed fix | 22:08 |
lucas-afk | NobodyCam, idk how I will test vmware tho | 22:08 |
jroll | lucas-afk: does your oslo-messaging patch work or is it WIP? | 22:08 |
NobodyCam | ask who ever added the patch to test it :-p | 22:09 |
lucas-afk | jroll, it works | 22:09 |
jroll | cool | 22:09 |
*** datajerk has joined #openstack-ironic | 22:09 | |
jroll | thanks | 22:09 |
lucas-afk | NobodyCam, lol ack | 22:09 |
NobodyCam | :) | 22:09 |
lucas-afk | jroll, np :) | 22:09 |
jroll | lucas-afk, NobodyCam, JoshNang has vmware on his laptop, and I'm happy to try to throw him under that bus ;) | 22:10 |
devananda | jroll: i'm going to test both patches together and see what i get | 22:10 |
*** sseago has quit IRC | 22:10 | |
JoshNang | :D | 22:10 |
jroll | devananda: cool | 22:10 |
NobodyCam | lol Ty jroll :) | 22:10 |
lucas-afk | devananda, ^ about the oslo.messaging... I left some comments inline, the eventlet one I talked to markmc, basically prepare() returns a new context which not alterns the self.client | 22:10 |
NobodyCam | (and TY too JoshNang) lol | 22:10 |
JoshNang | np haha | 22:11 |
lucas-afk | jroll, JoshNang ah, nice... I will try to put something up tomorrow | 22:11 |
lucas-afk | thanks | 22:11 |
jroll | devananda: also quick thing I noticed, this isn't reflected in the sample config, is that expected or can I fix that real quick? https://github.com/openstack/ironic/blob/master/ironic/common/config.py#L25 | 22:11 |
devananda | jroll: oh. i see. would you mind rebasing on lucas' patch? | 22:11 |
devananda | you've got a TODO in there | 22:11 |
jroll | heh, sure thing | 22:11 |
devananda | thanks :) | 22:11 |
jroll | yeah | 22:11 |
jroll | well | 22:11 |
jroll | that's not lucas' patch in the todo | 22:11 |
jroll | that's in oslo-incubator https://review.openstack.org/#/c/89702/ | 22:11 |
devananda | oh! hah | 22:12 |
jroll | I can still rebase if you'd like | 22:12 |
devananda | jroll: nvm | 22:12 |
jroll | ok | 22:12 |
*** derekh has joined #openstack-ironic | 22:13 | |
devananda | jroll: well, your change is for the oslo-incubator code base, not the oslo.messaging library | 22:13 |
jroll | devananda: right | 22:13 |
jroll | oh | 22:13 |
jroll | ohhhhh | 22:13 |
devananda | lucas' patch rips taht out | 22:13 |
jroll | right | 22:14 |
jroll | will fix | 22:14 |
devananda | :) | 22:14 |
jroll | thanks for that | 22:14 |
* devananda tests lucas' patch in isolation | 22:14 | |
lucas-afk | jroll, you might want to fix that in the oslo.messaging | 22:14 |
lucas-afk | https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/transport.py#L56 | 22:14 |
jroll | right | 22:14 |
lucas-afk | jroll, yeah my patch removes the whole openstack/common/rpc/ stuff | 22:14 |
jroll | lucas-afk: actually it might need to be here: https://github.com/openstack/oslo.messaging/blob/19053b6e652d54444af44cff2c7db640b5b5b207/oslo/messaging/_executors/impl_eventlet.py | 22:15 |
jroll | that's the config that needs to change | 22:15 |
NobodyCam | ok calling it a day | 22:15 |
jroll | otherwise I could do something like: cfg.set_defaults(_eventlet_opts, rpc_thread_pool_size=4) | 22:15 |
NobodyCam | have a good night | 22:16 |
lucas-afk | jroll, right | 22:16 |
lucas-afk | NobodyCam, have a good night! | 22:16 |
jroll | but I'd rather not be reaching into _executors either :/ | 22:16 |
NobodyCam | :) | 22:16 |
jroll | night NobodyCam | 22:16 |
devananda | g'nght, NobodyCam ! | 22:16 |
NobodyCam | night lucas-afk jroll devananda and all others :) | 22:17 |
devananda | hmm, i haven't looked at the oslo libs enough yet to know the answer | 22:17 |
devananda | how do we change the CONF default at run time before instantiating the class whose __init__ registers it? | 22:17 |
jroll | oh, ouch | 22:18 |
devananda | dhellmann: ping | 22:18 |
jroll | hrm | 22:18 |
lucas-afk | yeah dunno as well | 22:18 |
* devananda drops an email to the list | 22:19 | |
jroll | so there's this https://github.com/openstack/oslo.messaging/search?q=rpc_thread_pool_size&ref=cmdform | 22:19 |
jroll | I'm curious how zmq implementation uses that | 22:19 |
jroll | assuming zmq doesn't use impl_eventlet somewhere | 22:19 |
jroll | oh heh https://github.com/openstack/oslo.messaging/blob/06ab616d8ffb73fa1607878c52edbcbd3b54b91e/oslo/messaging/_drivers/impl_zmq.py#L889 | 22:20 |
*** epim has joined #openstack-ironic | 22:20 | |
*** epim has quit IRC | 22:20 | |
lucas-afk | heh | 22:20 |
devananda | jroll: it probably doeshttps://github.com/openstack/oslo.messaging/blob/06ab616d8ffb73fa1607878c52edbcbd3b54b91e/oslo/messaging/_drivers/impl_zmq.py#L34 | 22:20 |
lucas-afk | the /search is pretty cool, I didn't know it existed | 22:21 |
jroll | yeah I just linked to where they register it, deva | 22:21 |
devananda | yea, i pasted while switching windows, heh | 22:21 |
devananda | didn't see your msg before i hit enter | 22:21 |
jroll | heh | 22:21 |
*** sseago has joined #openstack-ironic | 22:22 | |
* jroll crosses fingers | 22:28 | |
devananda | i have an email drafted, and might have spotted a solution in the mean time | 22:29 |
* devananda tests before hitting send | 22:29 | |
jroll | ooo I'm curious to see this | 22:29 |
devananda | nope, doesn't seem to work | 22:49 |
*** newell has quit IRC | 22:50 | |
*** epim has joined #openstack-ironic | 22:50 | |
*** zdiN0bot has quit IRC | 22:52 | |
devananda | email sent | 22:54 |
*** lucas-afk has quit IRC | 22:57 | |
*** zdiN0bot has joined #openstack-ironic | 23:14 | |
*** datajerk has quit IRC | 23:34 | |
*** eguz has quit IRC | 23:36 | |
*** yfujioka has joined #openstack-ironic | 23:36 | |
*** eghobo has joined #openstack-ironic | 23:36 | |
*** jgrimm has quit IRC | 23:36 | |
*** krtaylor has quit IRC | 23:43 | |
*** dwalleck has quit IRC | 23:50 | |
jroll | thanks for looking into that, devananda | 23:52 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!