Monday, 2014-06-23

*** matsuhashi has joined #openstack-ironic00:31
*** mitz has quit IRC01:11
*** mitz has joined #openstack-ironic01:25
*** mitz has quit IRC01:28
*** mitz has joined #openstack-ironic01:28
*** theDavidAiken has joined #openstack-ironic01:37
*** nosnos has joined #openstack-ironic01:39
*** mitz has quit IRC01:57
*** mitz has joined #openstack-ironic02:01
*** theDavidAiken has quit IRC02:21
*** annegentle_ has quit IRC02:25
*** annegentle has joined #openstack-ironic02:35
*** mitz has quit IRC02:48
*** mitz has joined #openstack-ironic02:50
*** mitz has quit IRC02:52
*** mitz has joined #openstack-ironic02:54
*** Haomeng has joined #openstack-ironic03:32
*** Nisha has joined #openstack-ironic03:35
*** Penick has joined #openstack-ironic03:37
*** matsuhashi has quit IRC03:39
*** Nisha has quit IRC03:40
*** sseago has quit IRC03:47
*** nosnos has quit IRC03:54
*** Penick has quit IRC04:01
*** sseago has joined #openstack-ironic04:01
*** Poornima has joined #openstack-ironic04:05
*** eghobo has joined #openstack-ironic04:17
*** saripurigopi has joined #openstack-ironic04:25
*** pradipta_away is now known as pradipta04:32
*** matsuhashi has joined #openstack-ironic04:39
*** nosnos has joined #openstack-ironic04:41
*** rakesh_hs4 has joined #openstack-ironic04:45
*** nosnos has quit IRC04:46
*** nosnos has joined #openstack-ironic04:47
*** vinbs has joined #openstack-ironic04:47
*** nikunj2512 has joined #openstack-ironic04:55
*** bmahalakshmi has joined #openstack-ironic05:07
*** Poornima|mtg has joined #openstack-ironic05:13
*** Poornima has quit IRC05:16
*** coolsvap|afk has joined #openstack-ironic05:17
*** coolsvap|afk is now known as coolsvap05:18
*** ajc_ has joined #openstack-ironic05:29
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ironic-python-agent: Updated from global requirements  https://review.openstack.org/8872205:30
*** coolsvap is now known as coolsvap|afk05:33
*** nosnos has quit IRC05:35
*** radsy has quit IRC05:36
*** nosnos has joined #openstack-ironic05:37
*** lazy_prince has joined #openstack-ironic05:40
*** coolsvap|afk is now known as coolsvap05:41
*** s-moriya has joined #openstack-ironic05:45
*** s-moriya has quit IRC05:47
*** Nisha has joined #openstack-ironic05:47
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ironic: Imported Translations from Transifex  https://review.openstack.org/9606306:01
*** coolsvap is now known as coolsvap|afk06:03
*** matsuhashi has quit IRC06:05
*** matsuhashi has joined #openstack-ironic06:06
GheRiveromorning Ironic06:09
*** matsuhashi has quit IRC06:11
saripurigopiCan someone share ironic juno github link?06:13
*** coolsvap|afk is now known as coolsvap06:13
*** matsuhashi has joined #openstack-ironic06:13
Haomengmorning GheRivero, saripurigopi06:17
Haomengsaripurigopi: current is juno branch I think - https://github.com/openstack/ironic06:17
*** matsuhashi has quit IRC06:19
*** matsuhashi has joined #openstack-ironic06:19
saripurigopi@Haomeng, I'm looking for driver specific vendor_passthru implementation, the defect says its fixed in juno version.06:22
*** coolsvap is now known as coolsvap|afk06:23
saripurigopiIt is present in the latest code, Thanks @Haomeng.06:26
*** sysexit has joined #openstack-ironic06:26
*** openstackstatus has quit IRC06:27
Haomengsaripurigopi: welcome:)06:31
*** vinbs has quit IRC06:35
*** Mikhail_D_ltp has joined #openstack-ironic06:36
*** vinbs has joined #openstack-ironic06:36
*** vinbs has joined #openstack-ironic06:36
*** eghobo has quit IRC06:37
*** matsuhashi has quit IRC06:55
*** matsuhashi has joined #openstack-ironic06:56
*** viktors|afk is now known as viktors06:59
*** rameshg87 has joined #openstack-ironic07:04
*** Mikhail_D_ltp has quit IRC07:11
*** romcheg has joined #openstack-ironic07:17
*** coolsvap|afk is now known as coolsvap07:17
*** ifarkas has joined #openstack-ironic07:31
*** coolsvap is now known as coolsvap|afk07:41
*** saripurigopi has quit IRC07:42
*** vinbs has quit IRC07:44
*** coolsvap|afk is now known as coolsvap07:54
dtantsur|afkmorning Ironic07:55
mrdahi dtantsur|afk07:55
*** dtantsur|afk is now known as dtantsur07:55
dtantsurmrda, hi :)07:55
romchegMorning dtantsur mrda and everyone else!07:56
mrdahi romcheg07:56
dtantsurmorning, romcheg07:58
*** jcoufal has joined #openstack-ironic08:00
*** Mikhail_D_ltp has joined #openstack-ironic08:04
*** foexle has joined #openstack-ironic08:07
*** Mikhail_D_ltp has quit IRC08:08
*** Mikhail_D_ltp has joined #openstack-ironic08:10
*** jcoufal has quit IRC08:11
romchegHave to move the migration stuff to Nova08:11
Mikhail_D_ltpMorning all!08:11
romchegGah, another dependency hell :)08:11
mrdaHi Mikhail_D_ltp08:12
mrdaand with that, good night all!08:12
*** mrda is now known as mrda-away08:12
Mikhail_D_ltpmrda-away: g'night :)08:12
*** jcoufal has joined #openstack-ironic08:13
*** vinbs has joined #openstack-ironic08:23
dtantsurmorning, Mikhail_D_ltp08:24
*** lucasagomes has joined #openstack-ironic08:28
*** Mikhail_D_ltp has left #openstack-ironic08:38
*** martyntaylor has joined #openstack-ironic08:41
*** Poornima|mtg has quit IRC08:45
*** romcheg has quit IRC08:55
*** romcheg has joined #openstack-ironic08:55
*** athomas has joined #openstack-ironic08:58
*** Mikhail_D_ltp has joined #openstack-ironic08:59
*** romcheg1 has joined #openstack-ironic09:03
*** romcheg has quit IRC09:05
*** mkerrin has quit IRC09:15
*** romcheg1 is now known as romcheg09:16
*** mkerrin has joined #openstack-ironic09:18
*** max_lobur has joined #openstack-ironic09:19
dtantsurFolks, what is our current policy on changes introduced before we have a spec procedure? I'm feeling like requesting spec for https://review.openstack.org/#/c/86744/09:25
dtantsurAs people keep arriving with different ideas on how to implement the particular feature09:25
rameshg87dtantsur, since it involved changes the base.py, yes i think it might make sense to have a spec for this09:28
rameshg87dtantsur, but i thought that was almost signed-off change :-)09:28
dtantsurthat's why I'm in doubts09:28
romcheg++ for spec!09:29
dtantsurok, I will block a patch and review spec asap, once it arrives09:29
rameshg87dtantsur, yeah ++ from me too :-)09:29
romchegdtantsur: agree!09:29
openstackgerritDmitry Tantsur proposed a change to openstack/ironic: Add some real-world testing on DiskPartitioner  https://review.openstack.org/9462009:37
openstackgerritImre Farkas proposed a change to openstack/ironic-specs: DRAC power driver  https://review.openstack.org/9935209:43
*** Poornima has joined #openstack-ironic09:43
rameshg87dtantsur, romcheg i have a question09:44
romchegrameshg87: ask then :)09:44
rameshg87there was a previous commit from lucas which changed all the parameters from driver_info to instance_info recently: https://review.openstack.org/#/c/94855/1409:45
dtantsurnot all but most, yes09:45
romchegs/all/some/09:45
romchegs/some/most/ :)09:45
rameshg87having moved to instance_info, the parameter names have been changed to generic ones, and can be used by other deploy drivers09:45
rameshg87i think we can move to a common location.09:46
dtantsurwhat exactly do you suggest to move?09:46
rameshg87this method: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L119-L16409:47
romchegrameshg87: it depends on a driver I believe09:47
rameshg87romcheg, most of the fields are passed by nova to ironic, and won't most drivers atleast need a look at those fields ?09:48
rameshg87romcheg, except for CONF.pxe.default_ephemeral_format, i don't see anything 'pxe'-specific there :-)09:49
*** pelix has joined #openstack-ironic09:49
dtantsurMaybe (except for deploy_key). This worse trying to write a spec, I guess :)09:50
romchegrameshg87: We cannot say some other drivers won't need putting something different there. I'm not as familiar with different hardware as NobodyCam is so I'd ask his opinion09:51
rameshg87romcheg, i was thinking if we can move the most common things (which are all already in that method) to a common place09:52
romchegdtantsur: Do we need a spec for a refactoring? In general it should not change the behaviour of the code in the end09:52
rameshg87romcheg, dtantsur, yeah that was my question. can we file a bug and suggest a change like this in a patch ?09:53
dtantsurromcheg, I don't know. These kinds of refactoring often go to far...09:53
romchegrameshg87: It makes sense if we move the common properties to a common place (by common I mean that we guarantee that those properties are required for all observable drivers)09:53
*** Nisha has quit IRC09:53
romchegrameshg87: and then we add methods like _populate_instance_info(…) to the drivers and so drivers add their own stuff09:54
dtantsurrameshg87, romcheg: my request for spec was to at least specify: 1. what we mean by "common properties", 2. which properties we expect to be common09:54
romchegdtantsur: Agree, if we define those common properties, we can factor them out to some common place.09:55
rameshg87dtantsur, romcheg, okay. thanks :-)09:56
rameshg87dtantsur, romcheg, i would pursue writing a spec for this ..09:56
romchegrameshg87, dtantsur: If most of the instance_info is common, that factoring it out makes sense. Otherwise it'll only add more complexity09:56
romchegAnyway, NobodyCam, devananda, we need your opinion on ^^09:57
rameshg87romcheg, i feel it is. if those deploy drivers are not going to honour them, they may ignore them09:57
*** vinbs has quit IRC09:57
*** vinbs has joined #openstack-ironic09:58
foexleheyho guys, i'm trying to write a manual install doc for ironic on different hosts (comp, controller, net) and i've some questions is here anyone they  can help ?10:06
foexlefirst question: i installed conductor and api on controller host, confgure nova config for ironic and now on the compute node the network. Is that correct or should the conductor running on the comp host ?10:09
romchegfoexle: Do you mean Ironic Conductor?10:11
foexleromcheg: yep :)10:12
dtantsurfoexle, as devananda explained last week, Conductor is completely independent and can be run everywhere10:13
romchegSo Nova does not interract with Ironic Conductor. It only queries Ironic over the API10:13
dtantsurfoexle, it may be even better to run it on a separate machine, as it's quite privileged10:13
romchegfoexle: Does it answer your question?10:13
foexledtantsur: yes i know, romcheg answer solved my question. so conductor doesn't need to commuicate directly with libvirt10:17
foexlenova-comute will communicate ? .... exactly the ironic compute driver10:18
dtantsurright, conductor does not communicate with libvirt. ironic driver does all interaction with nova internals, conductor is accessed via HTTP API10:18
foexledtantsur: thanks :), i'm installing and configuring step by step with help of devstack10:20
*** amitpp has joined #openstack-ironic10:32
dtantsurFolks, we're having our docs builds marked as "UNSTABLE". What does it mean?10:35
romchegdtantsur: Usually that means some problems with the node10:35
romchegdtantsur: Better ask in #openstack-infra10:36
dtantsurack thnx10:36
*** amitpp has quit IRC10:42
*** amitpp has joined #openstack-ironic10:42
*** petertoft has joined #openstack-ironic10:43
*** pradipta is now known as pradipta_away10:45
*** amitpp has quit IRC10:47
*** amitpp has joined #openstack-ironic10:47
dtantsurhttps://bugs.launchpad.net/openstack-ci/+bug/133319710:56
dtantsurtl;dr docs server ran out of disk space10:57
romchegJust as I said — a problem with the node11:01
*** pradipta_away is now known as pradipta11:04
lucasagomes:(11:07
*** romcheg1 has joined #openstack-ironic11:09
*** romcheg has quit IRC11:10
*** coolsvap is now known as coolsvap|afk11:11
dtantsurFolks, anyone to approve https://review.openstack.org/#/c/94371/ ? 2x +2, 3x +1 already11:12
dtantsuralso, <ruhe> you can use "recheck bug 1333197" to restart jenkins jobs11:13
yuriyzgood day dtantsur, I will look11:14
dtantsuryuriyz, hi, thanks!11:14
*** romcheg has joined #openstack-ironic11:14
*** romcheg1 has quit IRC11:15
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Do not delete pxe_deploy_{kernel, ramdisk} on tear down  https://review.openstack.org/10186411:31
openstackgerritRamakrishnan G proposed a change to openstack/ironic-specs: iLO Power Driver for Ironic  https://review.openstack.org/9745511:33
*** rameshg87 has left #openstack-ironic11:36
*** rameshg87 has joined #openstack-ironic11:36
*** rameshg87 has left #openstack-ironic11:36
foexlequestion again  :( .... ironic node-create => -i ssh_address and other ssh options which ip should i use here ? Do i need to take a free ipaddress of my neutron subnet ? or the ip of the compute host ?!11:37
*** lucasagomes is now known as lucas-hungry11:38
*** pradipta is now known as pradipta_away11:46
dtantsurfoexle, that's if you use virtual environment and PXE power driver11:48
dtantsurfoexle, than it's IP address of virtualization host, where your VM's will run11:48
dtantsuryuriyz, changes you commented on were introduced after previous reviews :) I don't care, I can just as well delete them, as I anyway have to rebase11:49
foexledtantsur: ah ok what should i use if i dont user venv ? and which driver ?11:49
dtantsurfoexle, probably one of IPMI drivers11:49
foexleahhh i see and as IP address the IPMI ip with login creds right ?11:50
yuriyzdtantsur, ok11:50
dtantsurI guess we don't have docs on IPMI, do we?12:02
dtantsuradded to https://bugs.launchpad.net/ironic/+bug/132358912:03
*** vinbs has quit IRC12:08
openstackgerritDmitry Tantsur proposed a change to openstack/ironic: PXE to pass hints to ImageCache on how much space to reclaim  https://review.openstack.org/9437112:09
dtantsuryuriyz, lucas-hungry, romcheg rebased ^^^ could you reconsider?12:10
yuriyzok12:10
foexledtantsur: thx i'll try to boot with IPMI and will inform you .... I'll try to make a github repo with my doc i've done some steps which is missing in your doc12:19
dtantsurfoexle, cool! If you do, please link it to bug report https://bugs.launchpad.net/ironic/+bug/132358912:20
*** matsuhashi has quit IRC12:23
*** jdob has joined #openstack-ironic12:23
*** matsuhashi has joined #openstack-ironic12:23
*** matsuhashi has quit IRC12:28
*** matsuhashi has joined #openstack-ironic12:28
foexledtantsur: of course :)12:31
*** Poornima has quit IRC12:33
*** bmahalakshmi has quit IRC12:35
*** matsuhashi has quit IRC12:35
*** matsuhashi has joined #openstack-ironic12:35
viktorsdtantsur: around?12:38
dtantsurviktors, yep12:38
dtantsurhi12:38
*** matsuhas_ has joined #openstack-ironic12:38
viktorsdtantsur: hi!12:38
viktorsI have a question about bug https://launchpad.net/bugs/127755512:39
dtantsursure12:39
*** matsuhashi has quit IRC12:39
*** ajc_ has quit IRC12:40
viktorsdtantsur: why do you suppose to map all db exception to  IronicDBError class instead of raise something like NodeAlreadyExist?12:41
dtantsurviktors, the idea (inherited from Josh actually) is to raise specific exception, when we have it. When we don't - raise generic exception, that hides SQL details12:42
*** lucas-hungry is now known as lucasagomes12:43
dtantsurany comments and suggestions are welcome :)12:43
viktorswell, I'm just confused a bit with this change, but anyway, it's just IMO - I'm not from core team  :)12:44
dtantsurviktors, it's a difficult topic, any feedback is highly appreciated12:45
viktorsdtantsur: AFAIK, such approach is preferable in OS - https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/api.py#L38812:45
dtantsurviktors, sure, my point is what to do, when we don't expect a particular exception12:46
viktorsdtantsur: well, anyway it's should be a some kind of server error12:47
viktorsso there is no big sense to cut SQL tracebach there12:47
viktors*traceback12:47
dtantsurviktors, I guess the point is to never show SQL details in e.g. node-show output12:48
viktorsdtantsur: yes, but it's not commercial product, so we can allow it for debug12:50
viktorsat least12:50
dtantsurviktors, IIRC, if debug = True, everything is left as it is12:51
*** amitpp has quit IRC12:52
viktorsdtantsur: you mean, if we will use  patch https://review.openstack.org/#/c/73121 &12:54
viktors?12:54
viktorsseems to be, that we loose thaceback in this case (or maybe I miss something?)12:55
dtantsurviktors, at least it used to be there... now I don't see the code, but I can reintroduce it12:55
dtantsurviktors, we're loosing Python traceback (it still gets logged), and I expected we leave SQL error in case of debug=True, but it seems no longer the case and I will check it12:56
*** linggao has joined #openstack-ironic12:57
viktorsdtantsur: ok, just to be sure, that we don't loose debug information (like traceback) in this case12:58
viktorsdtantsur: in a few worlds - my point is - we set code 409 only for DBDuplicateEntry, so IMO, there is a sense to catch there exceptions in db-api methods. Another exception can provide usefull debud information.12:58
viktors*debug12:59
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Do not delete pxe_deploy_{kernel, ramdisk} on tear down  https://review.openstack.org/10186412:59
dtantsurviktors, you mean, catch DBDuplicateEntry in db-api methods explicitly?13:00
viktorsdtantsur: yes, see an example here - https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/api.py#L38813:01
*** coolsvap|afk is now known as coolsvap13:01
dtantsurviktors, provided that this exception only happens on save and create - yes, makes sense13:02
viktorsdtantsur: agreed13:02
*** rloo has joined #openstack-ironic13:03
*** matsuhas_ has quit IRC13:03
dtantsurviktors, cool, thanks! So I'll update a patch with 2 fixes we spotted: don't hide SQL error with debug=True and catch  DBDuplicateEntry explicitly13:03
*** matsuhashi has joined #openstack-ironic13:03
*** dtantsur is now known as dtantsur|lunch13:06
viktorsdtantsur|lunch: : ok, I will also add a comment to discussion in launchpad13:06
*** rloo has quit IRC13:07
*** rloo has joined #openstack-ironic13:07
*** matsuhashi has quit IRC13:08
*** matsuhashi has joined #openstack-ironic13:08
*** rloo has quit IRC13:08
*** rloo has joined #openstack-ironic13:09
*** matsuhashi has quit IRC13:13
*** rloo has quit IRC13:14
*** matsuhashi has joined #openstack-ironic13:14
*** rloo has joined #openstack-ironic13:14
*** rloo has quit IRC13:17
*** rloo has joined #openstack-ironic13:17
*** rloo has quit IRC13:17
*** rloo has joined #openstack-ironic13:17
*** matsuhashi has quit IRC13:18
*** rloo has quit IRC13:18
*** rloo has joined #openstack-ironic13:21
*** rloo_ has joined #openstack-ironic13:21
*** rloo has quit IRC13:24
NobodyCamgood morning13:26
NobodyCambrb mak'n coffee13:27
*** dtantsur|lunch is now known as dtantsur13:27
*** matty_dubs has joined #openstack-ironic13:28
dtantsurNobodyCam, morning!13:28
matty_dubsMornin' NobodyCam, dtantsur!13:28
dtantsurmatty_dubs, \o/13:29
dtantsurhow were your pto?13:29
*** nosnos has quit IRC13:29
matty_dubsdtantsur: Great! Nice and relaxing. But, soooooo much email this morning.13:30
lucasagomesmorning all13:30
dtantsurlucasagomes, morning :)13:31
jrollmorning y'all13:31
dtantsurmatty_dubs, oh yeah, I got back from PTO last monday I was shocked. Next week I'm going on 2-weeks PTO and it's going to be much worse :)13:31
dtantsurjroll, morning!13:31
romchegMorning NobodyCam jroll matty_dubs!13:31
jrolldtantsur: hey, about https://review.openstack.org/#/c/86744/13:32
jrollI have mixed feelings about needing a spec for this13:32
jrollthere's two ways to look at this change:13:32
jroll1) removing hard-coded assumptions: IMO doesn't need a spec13:33
jroll2) supporting long-running deploy ramdisks: definitely needs a spec, but the spec would be along the lines of supporting that, not a simple spec to factor the hard-coded logic out13:33
NobodyCammorning dtantsur lucasagomes romcheg matty_dubs and jroll13:36
jrollhey NobodyCam13:36
dtantsurjroll, I also have mixed feeling actually, but it's changing our interfaces, so there should be a spec. I would not require it, though, was it not for the last comment, which asked to change the implementation substantially13:36
dtantsurjroll, now we have either to ignore the comment and approve (possible, not good) or change the way it's implemented (than we need a spec, so that we don't argue forever)13:37
dtantsurwhat do you think?13:37
jrolldtantsur: I'm not sure I understand the point of that comment :/13:38
jroll2. The function can't be reused. For example, if some other operations, say 'firmware update' or something wanted to check power state, this method can't be reused.13:38
jrollthis isn't true13:38
jroll(1) is about it being odd to be on the base class, and I'm not sure that's a valid comment13:39
jrollvalid comment to block the work on, I should say13:39
jrollrameshg8-: ^ around?13:39
dtantsurjroll, I understood it like: we may want every interface to have a list of operations and possible states for them13:39
rloo_dtantsur: hi! wrt https://review.openstack.org/#/c/100571/3//COMMIT_MSG, 'docn' is short for documentation. 'docs' isn't quite right cuz it is only one section that is updated (not more than one doc).13:39
NobodyCammorning rloo_ :)13:40
dtantsurjroll, and than it may make sense to have a generic function13:40
rloo_dtantsur: hi. sorry, i'll just reply to the patch. no need to ping you here about it ;)13:40
rloo_NobodyCam: morning!13:40
dtantsurrloo_, morning :) thanks you for explanation, as you probably know my English leaves a lot to be desired :)13:40
jrolldtantsur: if a driver needs to check power state for 'firmware update', it would add 'firmware update' to `valid_states` dict defined in that driver13:40
dtantsurjroll, to me (1) is not valid: interface can have default implementations (e.g. in modern programming languages)13:41
rloo_dtantsur: no worries! Your English is quite good considering it isn't your first language.13:41
dtantsurrloo_ :)13:41
openstackgerritA change was merged to openstack/ironic: PXE to pass hints to ImageCache on how much space to reclaim  https://review.openstack.org/9437113:41
jrolldtantsur: if a new method 'firmware update' is added to the base class or conductor or whatever, defaults will be added to the `valid_states` dict, drivers can implement as needed13:41
dtantsurjroll, but "firmware update" won't be in deploy interface, it's likely to be in management interface13:41
*** rloo_ has quit IRC13:41
jrollhrm13:42
*** rloo has joined #openstack-ironic13:42
jrollfwiw, I'm still not sure how I feel about the fact that we have Power/Management/Deploy interfaces, but that might just be me13:42
jrolle.g. the ManagementInterface for agent_ipmitool will need to speak both to the agent and to IPMI13:43
dtantsurjroll, heh... the separation may be a bit artificial from the very beginning13:44
dtantsurjroll, does writing a spec for this change seriously slow down your work?13:45
jrolldtantsur: if I say yes, will you change your mind? :)13:45
*** blamar has joined #openstack-ironic13:45
jrolldtantsur: I'm coming from a project perspective on this, I don't mind writing a spec13:46
jrolldtantsur: my plan is eventually to write a spec about long-running deploy ramdisks, and this patch would be part of that patch series13:46
jroll(if it's not landed before I get to that, of course)13:46
dtantsurjroll, I could :) But I definitely prefer a spec for everything that changes interfaces13:47
dtantsuralso, I don't how the others feel, but I prefer many small specs rather than one huge13:47
*** rloo has quit IRC13:48
jroll+113:48
*** rloo has joined #openstack-ironic13:48
jrollalthough, sometimes I'd rather have 1 large spec per feature, rather than many small specs to build one feature13:49
jrolldtantsur: in the bottom section here, 'depends on 84795', we will need specs for all of those https://etherpad.openstack.org/p/ipa-todos13:50
jrolldtantsur: so you can expect specs for each of those13:50
dtantsurjroll, I understand the feeling. But it's obviously easier to review small ones13:50
dtantsurjroll, I am ready, you won't scare me :)13:51
*** rloo has quit IRC13:51
* dtantsur thinks we should speed up with approving specs actually13:51
jrolldtantsur: heh, getting there :)13:52
jrolland +1 on speeding up13:52
* jroll pokes russell_h to do a bunch of spec review13:52
dtantsurjroll, I'll talk to devananda today, but I guess we need at least one more low-level things guru (like IPMI etc)13:53
dtantsur... in specs-core team13:53
*** rloo has joined #openstack-ironic13:54
*** rloo has quit IRC13:54
*** rloo has joined #openstack-ironic13:54
jrolldtantsur: indeed13:54
jrolldtantsur: for ipmi specifically, I'd nominate jbjohnso (though he's not here as much as he used to be, it seems)13:55
*** rloo has quit IRC13:55
*** rloo has joined #openstack-ironic13:55
dtantsurok, we can discuss on the meeting13:55
jrolldtantsur: also, JayF comes from an ops background and is pretty good with low-level systems stuff, e.g. kernels, disk partitioning, etc13:55
jrollJayF has been our go-to guy for debugging linux incompatibilities on our opencompute gear13:56
*** rloo has quit IRC13:56
jrolls/incompatibilities/random issues/13:56
*** rloo has joined #openstack-ironic13:56
*** rloo has quit IRC13:57
*** rloo has joined #openstack-ironic13:58
*** rloo has quit IRC14:00
*** rloo has joined #openstack-ironic14:01
*** rloo has quit IRC14:02
openstackgerritDavid Shrewsbury proposed a change to openstack/ironic-specs: Make the REST API fully asynchronous  https://review.openstack.org/9492314:02
*** rloo has joined #openstack-ironic14:02
lucasagomesjroll, ping re agent POSTing things back to the Ironic API. I see that the agent when it starts it will POST the hardware information to the drivers/.../vendor_passthru/lookup URI14:03
lucasagomesjroll, how the authentication works?14:04
*** rloo has quit IRC14:04
*** rloo has joined #openstack-ironic14:04
lucasagomesjroll, there's a token in the tftp directly that the agent will get in order to authenticate when talking to the ironic API?14:04
jrolllucasagomes: we've been debating how that will work. maybe client cert checking. there's nothing today, except securing the heck out of the provisioning network14:04
lucasagomesjroll, right14:05
lucasagomesjroll, but how u guys are doing today? no auth?14:05
jrollcorrect, just a very secure network14:05
ShrewsAll:  94923 is my attempt to pick up some of that work from devananda and coalesce some ideas that were discussed in an etherpad. Please be gentle and be aware that I *very likely* have some misunderstandings that will need correcting.  :)14:05
lucasagomesjroll, ok gotcha, thanks14:05
jrolllucasagomes: we expect to have auth soon14:05
jrolllucasagomes: I'm not sure if I like the token thing, because any node that can dhcp can get a token, yes?14:06
lucasagomesjroll, yea that would be good... just checking because I was thinking about how to do that, but don't want to reivent the wheel in case u guys already had something ready for it14:06
lucasagomesjroll, yeah the token is flawed14:06
lucasagomesjroll, we need something better for sure14:07
jrolllucasagomes: yeah, client cert checks are the idea right now... however there exists zero python to do such a thing afaik :/14:07
jrolllucasagomes: a couple guys working on barbican/cryptography.io even told us "just use nginx"14:07
lucasagomesjroll, you guys have any etherpad/wiki/... about how would that work?14:07
jrollno, we've just been tossing around ideas at lunch etc14:08
lucasagomesright, yeah :(14:08
lucasagomesjroll, no problemo14:08
jrollsecurity is hard (tm)14:08
lucasagomes+114:09
dtantsurShrews, sure, will have a look :)14:11
Shrewsdtantsur: you may want to wait and let devananda have a pass at it first  :)14:12
NobodyCameveryone looked at todays agenda, are we all up to date?14:13
*** rloo has quit IRC14:13
* dtantsur is looking14:13
NobodyCam:-p14:13
*** rloo has joined #openstack-ironic14:14
*** lazy_prince has quit IRC14:15
*** rloo has quit IRC14:15
jrollNobodyCam: btw, I have to leave the meeting about 10 minutes early... if the meeting is moving slow please keep me in mind :)14:15
NobodyCamjroll: ack.. we'll try and get you up to bat early14:16
*** rloo has joined #openstack-ironic14:16
jrollthanks :)14:16
* jroll owes NobodyCam a bagel for that one :P14:17
NobodyCam:-p14:17
*** rloo has quit IRC14:17
*** rloo has joined #openstack-ironic14:17
*** rloo has joined #openstack-ironic14:18
*** rloo has quit IRC14:18
*** rloo has joined #openstack-ironic14:19
*** rloo_ has joined #openstack-ironic14:20
*** rloo__ has joined #openstack-ironic14:21
*** rloo__ has quit IRC14:22
*** rloo__ has joined #openstack-ironic14:23
*** rloo has quit IRC14:24
*** rloo_ has quit IRC14:24
*** pcrews has joined #openstack-ironic14:25
*** rloo has joined #openstack-ironic14:31
*** rloo__ has quit IRC14:31
*** rakesh_hs4 has quit IRC14:37
*** rloo has quit IRC14:38
*** rloo has joined #openstack-ironic14:39
*** rloo has joined #openstack-ironic14:40
*** rloo has quit IRC14:40
*** rloo has joined #openstack-ironic14:41
*** rloo has quit IRC14:41
*** rloo has joined #openstack-ironic14:42
*** rloo has quit IRC14:43
*** rloo has joined #openstack-ironic14:45
*** rloo_ has joined #openstack-ironic14:46
NobodyCamany one know if neutron supports dhcp option #42 .. would setting that work for https://bugs.launchpad.net/ironic/+bug/133186214:47
*** rloo_ has quit IRC14:48
*** rloo_ has joined #openstack-ironic14:48
*** rloo has quit IRC14:49
ShrewsNobodyCam: hrm, that's interesting. alas, i have no answer for you14:50
*** rloo has joined #openstack-ironic14:50
*** rloo has quit IRC14:51
NobodyCam42 is the ultimate answer ... :-p14:51
lucasagomesNobodyCam, +114:52
lucasagomeshah14:52
*** rloo has joined #openstack-ironic14:52
*** rloo has quit IRC14:53
*** rloo has joined #openstack-ironic14:53
*** rloo_ has quit IRC14:53
*** rloo has quit IRC14:55
*** rwsu has joined #openstack-ironic14:55
*** rloo has joined #openstack-ironic14:56
*** rloo has quit IRC15:01
*** rloo has joined #openstack-ironic15:01
*** rloo has quit IRC15:02
*** rloo has joined #openstack-ironic15:03
*** rloo has quit IRC15:04
*** rloo has joined #openstack-ironic15:04
*** rloo has quit IRC15:04
*** rloo has joined #openstack-ironic15:05
*** rloo has quit IRC15:06
*** mdorman has joined #openstack-ironic15:07
*** rloo has joined #openstack-ironic15:08
*** rloo has quit IRC15:08
*** rloo has joined #openstack-ironic15:09
*** rloo has quit IRC15:11
petertoftAny takers for https://bugs.launchpad.net/ironic/+bug/1321787? This is breaking most of our virtual runs using TripleO, and hence is a critical issue for us. I have folks on my team looking at it, but additional expertise would be welcome.15:14
NobodyCampetertoft: have you looked at https://github.com/paramiko/paramiko/issues/17315:17
*** rloo_ has joined #openstack-ironic15:18
*** rloo has joined #openstack-ironic15:18
*** rloo has quit IRC15:19
*** rloo has joined #openstack-ironic15:19
*** rloo__ has joined #openstack-ironic15:20
*** rloo_ has quit IRC15:21
*** rloo__ has quit IRC15:21
*** rloo_ has joined #openstack-ironic15:21
petertoftNobodyCam: Thanks. My folks have indicated that there are underlying Paramiko/Eventlet issues, but I guess I'm concerned that this is going to fall into the gaps.15:23
*** rloo has quit IRC15:24
Shrewsinteresting comment at the end of https://bugs.launchpad.net/sahara/+bug/1212341  What version of paramiko are you using, petertoft?15:24
Shrewsoh, we already require a version higher than that. nevermind15:25
openstackgerritDan Prince proposed a change to openstack/ironic: Port iBoot PDU driver from Nova  https://review.openstack.org/5097715:25
petertoftHeh, I've no idea (whatever upstream is using), but I'll pass this along. Thanks Shrews.15:26
Shrewspetertoft: i don't think it's relevant, actually15:26
petertoftYeh, saw that. Thanks anyway15:26
*** rloo_ has quit IRC15:26
*** nikunj2512 has quit IRC15:28
*** romcheg1 has joined #openstack-ironic15:30
lifelessmrda-away: were you going to land https://review.openstack.org/#/c/97693/ ?15:31
devanandamorning, all15:31
*** romcheg has quit IRC15:32
lucasagomesdevananda, morning15:33
NobodyCamgood morning devananda15:34
lucasagomesdevananda, can you scroll back a bit and see the conversation I had with jroll about authentication and ramdisk15:34
*** rloo has joined #openstack-ironic15:34
lucasagomesdevananda, have you put any thoughts about the right way to solve that problem?15:34
devanandafoexle: "ssh*" driver is meant for test environments which do not have real hardware with remote power capabilities (eg, no IPMI)15:35
devanandafoexle: if you are testing with real hardware, you should probably use the pxe_ipmitool driver for now15:35
*** jcoufal has quit IRC15:35
dtantsurmorning, devananda!15:37
* devananda is catching up ons crollback15:37
*** romcheg has joined #openstack-ironic15:38
lifelessmrda-away: ah, nvm I see.15:38
*** romcheg1 has quit IRC15:40
jrollmornin devananda15:43
devanandalucasagomes: hi! caught up now - i think you're asking about securely auth'ing the first POST from the ramdisk (whether IPA or PXE ramdisk, doedsn't matter)15:44
devanandalucasagomes: yes?15:44
lucasagomesdevananda, correct15:44
devanandalucasagomes: while using standard IPMI, I'm not aware of any solution yet, though jbjohnso may know some tricks using the SOL console to inject data15:45
lifelessmrda-away: but I prefer your patch I think. Commented on NobodyCam's15:45
devanandalucasagomes: if using a driver which extends OOB channel, eg iLO or SeaMicro, then it is much simpler15:45
NobodyCammorning lifeless ... On a conf call atm ... will look over the comments in a little bit15:47
lucasagomesdevananda, wait, I think we are a bit out of sync... because it's between the ramdisk and our API15:47
devanandalucasagomes: create a small ISO9660 image, containing a cert or priv key unique to that machine, and a copy of the server's pub key, load that via the BMC, then DHCP BOOT a ramdisk which uses those to communicate back to ironic15:47
*** rloo_ has joined #openstack-ironic15:47
lucasagomesdevananda, like when we POST the iqn for the ISCSI disk to the vendor_passtrhu/pass_deploy_info URI15:47
devanandaright15:47
lucasagomesdevananda, or for future work, to the discovery ramdisk to talk back to the Ironic api and register itself on it15:48
lucasagomesindependent from the driver15:48
romchegGood morning devananda!15:49
devanandalucasagomes: yep yep. well, not independent from the driver15:49
devanandalucasagomes: because any crypto capabilities of the hardware will be known by the driver -- they won't be generic15:49
*** martyntaylor has quit IRC15:50
lucasagomesdevananda, right15:50
lucasagomesdevananda, cause I was thinking about how to eliminate that admin token on the tftp directory that we use right now15:51
devanandalucasagomes: load the token directly via the BMC15:51
*** eghobo has joined #openstack-ironic15:51
devanandalet me see if this is described in the ilo spec ...15:51
devanandait should be15:51
lucasagomesright15:51
lucasagomesdevananda, ok so I'm out of the track hehe, I was reading about Keystone Trust15:52
*** rameshg87 has joined #openstack-ironic15:52
lucasagomeslike having a user for the deployment with scoped permissions15:52
devanandalucasagomes: keystone should probably be used as the source of trust. or barbican. or something.15:52
devanandalucasagomes: but the delivery of those keys to the node needs to be dnoe by the driver's management interface via the OOB virtual-media channel15:52
*** eghobo has quit IRC15:53
devanandalucasagomes: that is the most trusted channel in deployment environments15:53
lucasagomesdevananda, I c15:53
devanandawhich is somewhat ironic, because IPMI is actually rather insecure15:53
lucasagomesinteresting I will take a look at the iLo spec15:53
lucasagomeslol15:53
lucasagomesyeah15:53
*** Nisha has joined #openstack-ironic15:54
Nishadtantsur: Hi15:54
devanandalucasagomes: https://review.openstack.org/#/c/97744/2/specs/ironic-ilo-virtualmedia-driver.rst15:55
devanandadescribed there15:55
*** rloo_ has quit IRC15:56
rameshg87devananda, lucasagomes, looks like i joined at the right time.  i was just thinking i would remind someone about having a look at the ilo deploy spec :-)15:56
devanandarameshg87: o/15:56
lucasagomes:D15:56
lucasagomesrameshg87, devananda thanks15:56
*** eghobo has joined #openstack-ironic15:58
devanandarameshg87: in deploy(), is the deploy_iso shared? or is it unique to each node?15:59
dtantsurNisha, hi15:59
rameshg87devananda, the deploy_iso is shared.15:59
Nishadtantsur: I have seen your comments for https://review.openstack.org/#/c/100951/716:00
NobodyCambrb16:00
devanandarameshg87: ok, small problem in the spec, leaving a comment16:00
NishaWhy do you think it shall be split into two?16:01
*** viktors is now known as viktors|afk16:01
Nishadtantsur: : Why do you think it shall be split into two?16:01
devanandarameshg87: actually, question -- why does this driver need both deploy kernel/ramdisk AND deploy_iso ?16:01
rameshg87devananda, we don't ask the user to build the deploy_iso. for the first deployment, ironic conductor builds deploy kernel/ramdisk and then uploads the glance.16:02
devanandarameshg87: how?16:02
dtantsurNisha, it's proposed change part is nearly 200 lines and looks like covering several use cases. It would be very good for reviewers, if you manage to split it.16:03
rameshg87devananda, it uses mkisofs utility to create an isolinux based iso image. the user just provides the deploy kernel/ramdisk for the image (as glance arguments).16:04
dtantsurNisha, when reviewing a spec, we have to read it several times and understand as a whole, which is hard for a large spec.16:04
devanandarameshg87: if the deploy iso is shared across many nodes, I think the operator should be required to create it16:04
dtantsurNisha, not sure, but maybe you can handle --create_ports and --discover separately...16:04
Nishadtantsur: , but its a general proposal and we are implementing through iLO driver16:05
Nishadtantsur: i didnt get , how do we handle them seperately16:05
Nishadtantsur: manually doing all these tasks are already there16:05
Nishadtantsur: the proposal is to automate them16:05
dtantsurNisha, ah, yeah, general proposal should be separate, because it's something that affects the whole Ironic, may require reviews from people from other subteams etc16:05
devanandarameshg87: ironic does not, today, build images and upload them to glance, change nova or glance image properties, and so on. This seems like a change in scope, not just adding a new driver16:05
rameshg87devananda, we were just thinking of avoiding an extra step for the operator. (to obtain parity with what is required for other drivers)16:06
devanandarameshg87: I had thought the iLO driver was going to stash objects in swift for a short time (eg, during a deploy) then delete them16:06
*** martyntaylor has joined #openstack-ironic16:06
dtantsurNisha, your introduction reads as a general means of handling this situation, but than you follow with ILO-specific part16:06
rameshg87devananda, do you feel the iso should be created by the operator himself ?16:06
devanandarameshg87: requiring the operator to build an ISO image, which is used by all nodes in their environment that use the iLO driver, seems fine to me16:06
rameshg87devananda, okay16:07
Nishadtantsur: , the egneric stuff needs to be implemented by any driver16:07
jrollNisha, dtantsur, I agree that any driver-specific things should not be in that spec16:07
*** eguz has joined #openstack-ironic16:07
devanandarameshg87: it should be documented. eg, "if using the iLO driver, do $this and configure $that"16:07
devanandarameshg87: but that seems fine to me16:07
dtantsurNisha, IPA folks will want to review the generic part, as it may be closely related to their work, but they barely want to get deep into iLO details: they have their own16:07
*** petertoft1 has joined #openstack-ironic16:08
jrollNisha, dtantsur, that spec should define the api and scope for discovery, not any implementations16:08
dtantsur+116:08
rameshg87devananda, the ilo driver will upload the floppy images to swift with auto-expiring feature16:08
Nishadtantsur: jroll , but ilo stuff is how it is implemented in ilo driver. rest is generic16:08
devanandarameshg87: for passing tokens to the node -- yes, that's fine :)16:08
devanandarameshg87: the IPA driver is doing something very similar16:08
rameshg87devananda, the floppy image will have the parameters for the deploy and the token16:08
*** romcheg has quit IRC16:09
dtantsurNisha, yes, and I don't see any compelling reason for them to be mixed. Or otherwise also add sections for _all_ drivers (which you surely don;t want to do :)16:09
jrollNisha: indeed, and that should be a separate spec (if it should even be a spec at all)16:09
Nishajroll, dtantsur last week when the spec was reviewed by devananda, devananda proposed to add the details how the changes will be implemented in the spec16:09
rameshg87devananda, if we mandate operator himself to build isos, then the operator will need to build the deploy iso (shared across nodes) and boot iso(one per image)16:09
dtantsurNisha, quoting devananda: So, if this is a specific feature of the iLO driver, please update the title and introductory paragraph to indicate that. On the other hand, if it's a generic feature (which I think is your intent) then it should discuss how other drivers will implement the same feature.16:10
Nishajroll: dtantsur , i added implementation specific details only in latest patch16:10
*** romcheg has joined #openstack-ironic16:10
*** petertoft has quit IRC16:10
rameshg87devananda, we were just thinking of simplifying this step for the operator. do you feel it's okay to leave the operator to do so ?16:10
jrollNisha: I'd bet good money he meant how will the changes be implemented at the generic level :)16:10
jrollor what dtantsur said :p16:11
dtantsurNisha, as 1st is not the case and you barely want to do the second, I suggest one more option: have 1 spec talking about this feature in general and the second only for iLO-specific things16:11
*** eghobo has quit IRC16:11
devanandarameshg87: I believe the operator should build the shared image (whether that is deploy kernel & ramdisk for PXE driver, or deploy iso for ILO driver)16:11
devanandarameshg87: and the operator should set the appropriate nova and/or glance metadata16:12
rameshg87devananda, what about boot kernel/ramdisk ?16:12
rameshg87devananda, we would need a boot_iso from boot kernel/ramdisk, and then use that to boot up the node16:12
*** Mikhail_D_ltp has quit IRC16:12
devanandarameshg87: same for boot kernel/ramdisk -- this is also a common object which requires setting glance metadata.16:12
*** matty_dubs is now known as matty_dubs|lunch16:12
rameshg87devananda, yes16:13
rameshg87devananda, okay16:13
jrolldtantsur: so a more meta question, shpuld we require specs for "implement some existing generic feature in $driver"? /cc devananda16:13
devanandajroll: yes16:13
rameshg87devananda, one more thing to catch attention is how the node is booted up.16:13
jrollok :)16:13
Nishadtantsur: jroll , quoting IRC chat comments from deva on 19th June: "<devananda> wanyen: so i'm thinking of the REST API -- and the CLI as an extension of that. how does "--discover" look to the REST API ?"16:13
rameshg87devananda, after deployment, we need to attach the boot_iso everytime to boot up the node16:14
jrollNisha: yes, that has nothing to do with ilo16:14
rameshg87devananda, when the power driver of ilo recieves a request to reboot a deployed node, it would first attach the boot iso to the ilo and then boot the node.16:14
* jroll still does not quite understand why we don't write boot partitions and boot from disk :/16:15
rameshg87devananda, the boot iso will be attached as virtual media in such a way that it gets removed after that boot16:15
rameshg87devananda, i would like to know your thoughts on that16:15
rameshg87devananda, we felt it had an advantage that the baremetal node can never come up without being managed by ironic conductor16:16
devanandarameshg87: that will need to be optional, eventually16:17
devanandarameshg87: some operators want to enable boot-from-local-disk while otheres do not16:17
rameshg87devananda, this is only for fs-images16:17
Nishadtantsur: jroll it may not be possible to paste complete chat from that day chat, but initially spec just said that /v1/nodes/post and /v1/nodes/patch , then devananda asked to update the spec how they will be modified16:17
rameshg87devananda, if the user deploy a disk image, it can boot up from the node16:17
*** ellenh has joined #openstack-ironic16:17
devanandajroll: we should. and we should not. i have the start of a spec for that. want to take it over? I'd love that feature :)16:17
jrolldevananda: I was waiting for you to finish it :p16:18
dtantsurNisha, I don't understand your point at all, sorry. I don't know why you're talking about some API's, while what we ask you is to split generic and non-generic parts16:18
rameshg87devananda, we wanted to put forward the solution this way.  if the operator wants that "bm nodes never come up without conductor's knowledge, then use fs images"16:19
devanandarameshg87: that's fine16:19
dtantsurdevananda, could you provide your opinion on this spec discussion?16:20
rameshg87devananda, thanks16:20
devanandadtantsur: link? sorry, too many thinsg already open ...16:20
dtantsurdevananda, https://review.openstack.org/#/c/100951/7 I insist we split it into generic spec and iLO-specific one, jroll seems to agree16:20
rameshg87devananda, just one more thing, please have a look at ilo power driver when you get time: https://review.openstack.org/#/c/97455/ (already got one +2)16:21
lucasagomeslifeless, the problem with mrda-away patch is that it sets the power_state w/o validating the credentials16:21
lucasagomeslifeless, so if the credentials are not correct, and the power_state != None, after awhile the node is put in maintenance mode16:22
* NobodyCam is back16:22
rameshg87lucasagomes, i would request you also to take a look at ilo power driver since you reviewed code a while back https://review.openstack.org/#/c/97455/16:22
lucasagomeslifeless, I think that's not desirable ^ and we would need to work that out. NobodyCam's patch at least doesn't have that problem16:23
rameshg87lucasagomes, this is spec btw16:23
lucasagomesrameshg87, sure will do... interesting that other virtual media spec16:23
devanandarameshg87: have you considered how a node will be restarted without doing a full deploy?16:23
rameshg87devananda, i guess i didn't get the question16:25
devanandarameshg87: oh, never mind. it's further towards the end of the spec16:25
rameshg87devananda, okay :-)16:26
dtantsurlearning czech time, brb16:28
Nishadevananda: Do you think the spec to be splitted into two? I have just proposed that the feature be implemented by ilo driver its not specific to ilo driver16:32
Nishahttps://review.openstack.org/#/c/100951/716:32
lucasagomesdevananda, https://review.openstack.org/#/c/96136/ was rebased on trunk already, so you might want to remove the -1 (if that's the only reason for the -1)16:32
devanandaNisha: yes, this needs two specs. one describing the new REST and RPC and driver APIs, what the control flow looks like, etc. and another for iLO's implementation.16:34
Nishadtantsur: devananda jroll : Thanks will split it and post another patch16:34
devanandaNisha: it looks like this is adding several features, not one16:34
Nishameans?16:35
jrollNisha: thabk you!16:35
Nishadevananda: could you explain further more on your comment16:35
*** amitpp has joined #openstack-ironic16:36
Nishajroll: no probs16:37
*** martyntaylor has left #openstack-ironic16:37
Nishadevananda: apart from node properties discovery and automatic port create at node-create/node-update do you see any other feature is included here?16:39
devanandaNisha: I'm not yet convinced that --create-ports should be part of this. seems like a separate feature.16:39
devanandaNisha: also, you did not add what I asked for last time16:39
devanandaNisha: which is a description of this work item:  REST API node-create and node-update changes.16:39
*** eghobo has joined #openstack-ironic16:40
devanandaNisha: line 284 says "REST APIs .. need to be modified to have a new option" but doesn't show /how/ they will be modified16:40
Nishadevananda:I think you mean when node-create and node-update is patched ?16:40
devanandaNisha: yes16:41
*** lazy_prince2 has joined #openstack-ironic16:41
devanandaNisha: what REST API changes will be made to POST and PATCH such that the ironic-api service knows that --discover or --create-ports were specified on the CLI?16:42
*** eguz has quit IRC16:42
devanandaNisha: this is not explained in your spec16:42
Nishadevananda: please see line 296 onwards, it proposes the algo followed in node-create (this is when its not patched). I will add the description/details for patched approach.16:43
devanandaNisha: this is not what i'm asking for16:43
devanandaNisha: if I were to send a raw HTTP query string to ironic-api to initiate discovery, what would that HTTP query look like?16:44
devanandaNisha: what is the new parameter which triggers discovery?16:44
Nishadevananda: i think u mean the path ?16:45
devanandaNisha: path or resource or parameter -- yes16:45
Nishadevananda: do u mean this way: "PUT /v1/nodes/68228b2d-fc97-4fc3-b31f-e1616777af8d/management HTTP/1.1" 200 6316:45
devanandaNisha: so, that is the URL for that node's management resource. a PUT to that URL must have some body, and that body is a structured JSON document16:46
devanandaNisha: your proposal to modify "POST /v1/nodes" does not specify how you intend to change the POST body16:47
devanandaor if you intend to introduce a new resource URL, or what you intend to do16:47
Nishadevananda: triggering discovery is based on the argument passed to --discover option, that will be in CLI. CLI will decide whether to invoke the REST API or not for hw discovery16:47
lucasagomesNisha, I think that what devananda is saying is that... all that the CLI does is send HTTP requests to the API... so you will need a flag in the REST API to tell Ironic to do the discovery for u16:48
lucasagomese.g16:48
lucasagomesPOST /nodes/?discover=true16:49
lucasagomessomething like that16:49
devanandayes :)16:49
devanandathough I was trying not to suggest a specific implementation16:49
Nishalucasagomes: devananda Ok i got the point but I intended to do automatic hw discovery while doing node-create, and add the option --discover only for node-update if user wants to rediscover properties at node-update16:51
devanandaNisha: so the same question would apply to "node-update --discover"16:51
Nishadevananda: lucasagomes in that case node-create will not have any option of "--discover", it will rather do automatically16:51
devanandaNisha: also, it sounds like you are suggesting that node-create will ALWAYS do automatic hw discovery16:52
lucasagomesNisha, right, so there will be like a config option that Ironic will look at to know if it should discover things automatically or not16:52
Nishadevananda: Yes, i will update for node-update16:52
* lucasagomes I need to read the spec... 16:52
Nishadevananda: lucasagomes Yes the proposal is that16:53
Nishadevananda: for node-create16:53
*** klindgren has quit IRC16:53
devanandaNisha: which is not stated clearly in your specification16:53
lucasagomesack16:53
lucasagomesit kinda looks like something that could be put on the ManagementInterface for the update part16:53
lucasagomeslike a trigger that would return 202 and do the job on the background to find out the physical characterists of that node16:54
* lucasagomes might be going to far16:54
Nisha lucasagomes Yes the proposal is under ManagementInterface16:54
lucasagomeshah ok I will read the spec16:54
lucasagomessorry16:54
* lucasagomes RTFS :)16:54
rameshg87JoshNang, are you there ?16:54
Nishadevananda: Ok i will update the spec with that :)16:55
JoshNangrameshg87: i am, but i have to run in about 3 mins16:55
JoshNangbut i'll be back in an hour. what's up?16:55
rameshg87JoshNang, just had a couple of question regarding direct url. in short, it is not working for me :-(16:55
*** lucasagomes is now known as lucas-afk16:55
rameshg87JoshNang, i would like to use the same code in ilo deploy, i am trying to make it work for me as well.16:56
rameshg87JoshNang, but due to some reason it is not working :-(16:57
JoshNangrameshg87: i saw that. we've had some issues with direct url in our deployment and wound up going with config settings to override the host part16:57
rameshg87JoshNang, ah okay. i have a problem similar to that16:57
JoshNangi have tested it and it works, but we had some security concerns with the username and password possibly getting exposed16:57
JoshNang(works in at least one config. apparently not all)16:57
rameshg87JoshNang, giving only the secret key doesn't generate url which can be retrieved over http for me. i am on devstack16:58
JoshNangrameshg87: is it possible to private gist me the config file (with passwords etc removed?) for glance?16:58
rameshg87JoshNang, which config file do you need ? ironic.conf ?16:58
*** lazy_prince has joined #openstack-ironic16:58
JoshNangglance.conf (or is glance-api.conf?). but i gotta run. i'll be back in an hour16:58
JoshNangironic.conmf wouldn't hurt either16:59
*** Mikhail_D_ltp has joined #openstack-ironic16:59
rameshg87JoshNang, np. i will ping you back. i should be around when you are back16:59
rameshg87JoshNang, please ping me if possible when you are back and you are free.16:59
Nishadevananda: DO you still think create-ports be another feature for this spec?17:00
devanandaNisha: possibly...17:00
devanandai am going to post comments soon17:00
Nishadevananda: but we want to create ports at the time hw discovery17:01
*** lazy_prince has quit IRC17:03
*** killer_prince has joined #openstack-ironic17:07
*** Penick has joined #openstack-ironic17:07
*** killer_prince is now known as lazy_prince17:07
*** lazy_prince has quit IRC17:08
*** harlowja_away is now known as harlowja17:08
devanandaNisha: dtantsur: many comments posted on https://review.openstack.org/#/c/100951/17:10
*** wanyen has joined #openstack-ironic17:13
Nishadevananda: Thanks for the review17:14
*** romcheg has quit IRC17:15
rameshg87devananda, request some time for this review as well, https://review.openstack.org/#/c/97455/ . a simple review compared to deploy one btw .. :-)17:16
*** romcheg has joined #openstack-ironic17:16
*** klindgren has joined #openstack-ironic17:16
devanandarameshg87: almost done with deploy driver review, fwiw17:17
*** hemna_ is now known as hemna17:17
*** killer_prince has joined #openstack-ironic17:17
*** eghobo has quit IRC17:17
rameshg87devananda, thanks :-)17:18
*** amitpp has quit IRC17:19
NobodyCambrb17:19
*** amitpp has joined #openstack-ironic17:19
*** eghobo has joined #openstack-ironic17:24
*** romcheg has quit IRC17:31
*** killer_prince has quit IRC17:34
*** sam__ has joined #openstack-ironic17:36
*** killer_prince has joined #openstack-ironic17:37
*** Penick has quit IRC17:37
*** Penick has joined #openstack-ironic17:41
*** killer_prince has quit IRC17:43
rameshg87devananda, just had one question on your comment. rest all 11 comments are fine with me.17:45
rameshg87devananda, regarding "That said, I think there is a cleaner solution for the boot_iso. Build it and cache it locally on the conductor."17:46
*** killer_prince has joined #openstack-ironic17:46
*** pelix has quit IRC17:46
rameshg87devananda, we would need the boot iso to be in glance to be able to attach as the virtual media. we generate the temp-url for the glance image and then attach it as virtual media cdrom17:47
*** ellenh has quit IRC17:47
devanandarameshg87: ooh. gotcha17:47
rameshg87devananda, if we cache it locally on the conductor alone, we won't be able to attach it as virtual media (unless we run a web server on the ironic conductor node which we preferably wanted to avoid)17:48
devanandarameshg87: ok. please disregard that comment then.17:48
rameshg87devananda, then we might need the operator to build the boot iso from boot kernel and boot ramdisk as well (just like they build deploy iso from deploy kernel and deploy ramdisk)17:48
*** ellenh has joined #openstack-ironic17:48
devanandarameshg87: yep17:49
devanandarameshg87: have you proposed to diskimage-builder that it create iso images?17:49
rameshg87devananda, no i haven't.17:49
devanandarameshg87: that seems like the natural solution to me. It already has this utility: https://github.com/openstack/diskimage-builder/blob/master/bin/disk-image-get-kernel17:50
rameshg87devananda, it just need to be a small shell script iso-image-create which can create iso images given a kernel/ramdisk pair17:50
devanandarameshg87: exactly17:50
devanandarameshg87: and for tripleo, it would be easy to add a flag whcih says, "when using the iLO driver, call disk-image-make-iso instead" -- or smoething like that17:50
rameshg87devananda, okay. i would do that. do we need a design spec or just a launch bug is sufficient ? just asking because the shell script would be small17:51
devanandalifeless: how does ^ sound to you?17:51
*** jdob has quit IRC17:51
*** jdob has joined #openstack-ironic17:51
*** lazy_prince2 has quit IRC17:52
lifelessdevananda: not sure how far back I need to read17:54
lifelessrameshg87: why is it a temp url ?17:54
devanandalifeless: tldr; instead of disk-image-get-kernel, have another utility which wraps it up in an ISO image17:54
lifelessdisk-image-get-kernel is deprecated in favour of spitting out the files at build time17:54
devanandalifeless: so that things like iLO can mount dib output over virtual media17:54
lifelessspitting out an iso seems like a reasonable variation on the ramdisk thing17:55
devanandaneed a spec for that? or just a patch to add it?17:55
rameshg87lifeless, instead of asking operators run a webserver, we have them in swift and generate a tmp url which can be accessed over http/htps17:55
lifelessrameshg87: you answered a different question17:56
lifelessrameshg87: I asked why a temp url17:57
lifelessrameshg87: not why the use of swift17:57
*** martyntaylor has joined #openstack-ironic17:57
rameshg87lifeless, the tempurl generated will be attached as virtual media on the ilo17:57
lifelessagain, different question17:58
devanandalifeless: i think your question may be to something out of context17:58
lifelesswhy a temp url.17:58
lifelesswhy a /temp/ url17:58
devanandalifeless: the tempurl is only for the instance-specific token17:58
devanandawhich is only needed during deploy17:58
devanandalifeless: and has nothing to do with DIB :)17:58
lifelessI understood it to be for the virtual media ISO17:58
devanandano17:58
devanandataht should be in glance17:58
*** matty_dubs|lunch is now known as matty_dubs17:58
devanandalifeless: you didn't read back far enough ;)17:59
rameshg87lifeless, ah was the question "why the url is temp ?"17:59
lifelessdevananda: "05:47 < rameshg87> devananda, we would need the boot iso to be in glance to be able to attach as the virtual17:59
lifeless                   media. we generate the temp-url for the glance image and then attach it as virtual media17:59
lifeless                   cdrom17:59
lifeless"17:59
lifelessrameshg87: yes!17:59
*** petertoft1 has quit IRC17:59
rameshg87lifeless, the url needs to be accessible for only for a few mins for the proliant server to boot18:00
*** harlowja has quit IRC18:00
devanandalifeless: ah. I mis-parsed that. thanks!18:00
devanandarameshg87: the boot ISO will be shared by any node booting that glance image. it should be in glance.18:00
rameshg87devananda, yes, the boot iso will be shared.18:00
lifelessrameshg87: but why not just get the permanent url, why a temp one? Seems like pointless overhead18:01
rameshg87lifeless, we are using a feature of swift which generates http urls valid only for a certain amount of time18:01
lifelessrameshg87: do we need to use that feature?18:02
rameshg87lifeless, yes18:02
lifelessrameshg87: I have to pop into a meeting, sorry18:03
rameshg87lifeless, i request if you take a look at this spec when you get time: https://review.openstack.org/#/c/97744/2/specs/ironic-ilo-virtualmedia-driver.rst18:04
devanandajroll: you may want to review https://review.openstack.org/#/c/97736/2/specs/juno/deploy-ironic-bm.rst -- it seems like it is duplicating some IPA functionality18:04
devanandajroll: or perhaps implementing a very small subset in ways that could be better shared? I dunno...18:06
devanandarameshg87: regarding using the iLO virtual media channel to load a secure token, please think about how this can be used by other drivers besides iLO18:07
devanandarameshg87: i dont see any coverage for this in your specs yet, and I believe it is important18:07
rameshg87devananda, sure. i will explore more in this.18:08
devanandarameshg87: the APIs should be distinct engouh so that other drivers can use OOB virtual-media channels to load secure keys with other deploy drivers, eg IPA18:08
rameshg87devananda, isn't that a future refactor that you are meaning ?18:09
rameshg87devananda, currently the loading of keys is part of ilo deploy driver itself18:10
rameshg87devananda, i mean in the current proposed spec18:10
devanandarameshg87: right. but what if I want to use the iLO power and iLO management interfaces with the IPA deploy interface?18:10
rameshg87devananda, yes, i see your point. first, the ilo code should be easy enough to be modified and made to work with ipa deploy interface18:11
jrolldevananda: sounds like IPA implemented in bash :|18:12
rameshg87devananda, did i get it right ?18:12
jrolldevananda: This type of change is already proposed in the IPA, but IPA will not be using diskimage-builder to build the images.18:12
jrolldevananda: uhhhhhh18:12
jrolllifeless: one benefit of temp urls that rameshg87 may be betting on, is that they are unauthenticated (so you don't have to give iLO any creds)18:13
devanandajroll: comments just posted on there, fwiw18:13
jrollyeah, doing the same now18:13
*** jcoufal has joined #openstack-ironic18:14
devanandarameshg87: correct. you don't need to implement that, but I would appreciate if the proposal describes how that functionality (loading keys via virtual media) could be used with other drivers.18:15
rameshg87devananda, okay. i will do that.18:16
*** killer_prince has quit IRC18:17
*** romcheg has joined #openstack-ironic18:17
rameshg87jroll, we knew that ipa has a similar proposed functionality, but then the diskimage-builder changes were small enough if we can make it. we wanted to integrate with ipa as well, when it is ready.18:17
jrollrameshg87: I don't see what the difference is, really18:18
jrollrameshg87: other than using bash instead of python, no REST API, etc18:18
*** killer_prince has joined #openstack-ironic18:18
rameshg87jroll, the current proposed diskimage-builder element is just a parity of what ironic conductor is doing18:18
jrollrameshg87: IPA *is* ready. we have it running in production. patches just aren't great and so haven't landed18:19
*** killer_prince has quit IRC18:19
jrollrameshg87: I see. I still don't see the point. :/18:19
*** killer_prince has joined #openstack-ironic18:19
jrollrameshg87: all it takes to run IPA today is to apply some in-flight patches to ironic18:19
*** athomas has quit IRC18:20
rameshg87jroll, will it get merged to ironic soon ?18:20
jrollrameshg87: ask cores :P more seriously, though, we're refactoring the patches to make them more easily landable, and my goal is to land deploy/tear_down functionality by J218:21
*** romcheg has quit IRC18:21
rameshg87devananda, jroll, do you feel it's better for the ilo driver to use ipa instead of the new proposed element in dib ?18:27
jrollrameshg87: the ilo driver should be able to use the pxe deploy driver *and* the agent driver18:28
NobodyCambrb18:28
rameshg87jroll, the difference that we are trying to bring in is to be able to avoid pxe18:28
jrollrameshg87: that said, yes, I think there's no reason to make the new proposed element, especially if the goal is only to use it with the iLO driver.18:29
jrollrameshg87: to avoid PXE booting or the PXE driver?18:29
rameshg87jroll, to avoid pxe booting18:29
jrollum18:29
jrollhow do you plan to avoid pxe booting with either driver? mount the deploy ramdisk as virtual media?18:30
jrollI don't see why that's a problem with either driver18:30
rameshg87jroll, create a bootable iso with kernel/ramdisk and then attach it as virtual media and then boot up the machine18:30
rameshg87jroll, i assume we can boot up the ipa kernel/ramdisk as well ...18:31
jrollrameshg87: right, ok. I don't see why you need a new DIB to do that18:31
jrollindeed18:31
*** romcheg has joined #openstack-ironic18:32
*** max_lobur has quit IRC18:33
JoshNangrameshg87: back if you still have questions18:33
rameshg87JoshNang, i was into another discussion, will get back in a few mins ...18:34
devanandarameshg87: I think you should add a new ability to DIB to create the ISO images, but I dont think you need a separate element for the iLO driver18:34
JoshNangnp18:34
rameshg87devananda, so just use ilo driver to boot up the ipa ?18:34
rameshg87devananda, instead of dib build deploy kernel/ramdisk ?18:35
rameshg87devananda, we had that in the plan, but we didn't know if ipa was ready yet for that18:35
jrollrameshg87: what does IPA need to do to be ready for that?18:35
devanandarameshg87: i think that is going to be easier than duplicating all those features yourself in a bash script18:35
jroll^18:35
*** eghobo has quit IRC18:35
devanandaactually18:36
*** killer_prince has quit IRC18:36
devanandajroll: just to be devil's advocate for a moment18:36
jrolloh god18:37
jroll:)18:37
*** Penick has quit IRC18:37
*** bandicot has joined #openstack-ironic18:37
devanandaIFF the only thing this ramdisk needs to do is: fetch image from $URL, partition disk based on $PARAMS, write image to disk, POST to $URL using $TOKEN18:38
devanandait would be quite a lot smaller and simpler than IPA18:38
*** harlowja has joined #openstack-ironic18:38
*** harlowja has quit IRC18:38
jrollsure, I have no problem with a ramdisk that does that18:38
*** eghobo has joined #openstack-ironic18:38
*** killer_prince has joined #openstack-ironic18:38
devanandathere's no interaction or flow control18:39
*** harlowja has joined #openstack-ironic18:39
*** harlowja has quit IRC18:39
jrollbut in that case, this spec should be titled: "add option for s/iscsi/curl/ in pxe driver"18:39
*** Penick has joined #openstack-ironic18:39
jrollright?18:39
devanandayep18:39
devananda"enable current ramdisk to fetch image from $URL"18:39
jrollyeah, I have no problem with a ramdisk like this, for use with the pxe driver18:39
devanandaor something18:39
jrollbut I have many problems with the current version of the spec18:39
devananda*nod*18:40
rameshg87jroll, why only pxe driver ? :-)18:40
* devananda steps away to prep for the meeting in ~20m18:40
jrollrameshg87: what other driver would use this?18:40
devanandarameshg87: the same image could be used with iLO or PXE -- that is only the delivery mechanism.18:40
Shrewsdevstack is being a major PITA today with the latest ironic  :(18:41
* Shrews sets RECLONE=true18:41
jrollrameshg87: (maybe I missed the fact that there will be an iLO deploy driver, I thought iLO was only a management/power interface)18:41
jrollJoshNang: maybe I missed something, but in the agent tests, 'driver': 'fake_pxe', etc, should be 'fake_agent', no?18:42
rameshg87jroll, yes, with ilo and pxe18:42
JoshNangjroll: yes18:42
jrollrameshg87: is ilo going to have a deploy interface as well?18:43
rameshg87jroll, yes it is.18:43
jrollok18:43
rameshg87jroll, instead of using pxe for booting up the machine, ilo will use virtual media to boot up the node18:43
jrollright18:43
rameshg87jroll, 1 - we try to avoid pxe boot for customers who don't prefer pxe, 2 - it uses oob channel to get the token to the bm node18:44
jrollrameshg87: sounds good, then, but this spec should be to improve the existing ironic DIB element, not for a new one (I think)18:44
rameshg87jroll, yeah, i mentioned that in the alternative as well.18:45
*** eghobo has quit IRC18:45
jrollright, I think it's a totally valid alternative :)18:45
*** eghobo has joined #openstack-ironic18:45
* jroll walks away until meeting time18:45
rameshg87jroll, the existing element deploy-ironic can be modified to do download the image and write it instead of exposing the disk over iscsi18:46
rameshg87jroll, just to confirm if we are on the same page :-)18:46
jrollrameshg87: yes :)18:46
rameshg87jroll, point taken. please add that as comment if you wish.18:47
rameshg87devananda, does adding the functionality proposed in new element into the existing element deploy-ironic makes sense to you as well ?18:48
rameshg87devananda, did i make a confusing statement ? i mean does adding that functionality into existing element make sense to you ?18:48
devanandarameshg87: adding it to existing element in a way that is compatible with the current PXE driver -- yes. I think that would be ideal18:49
rameshg87devananda, that would mean the element deploy-ironic would support 2 modes of installation - 1. expose current disk over iscsi and ask conductor to complete installation18:50
rameshg872. download the image by temp url and do deployment on its own18:50
rameshg87devananda, we would be able to invoke the required functionality by passing required arguments.18:51
*** harlowja has joined #openstack-ironic18:51
*** harlowja has quit IRC18:51
rameshg87devananda, pxe driver will continue to use the iscsi mode of installation (unless someone feels it needs to be changed)18:52
rameshg87devananda, ilo driver will start using the mode tempurl #2 mechanism of installation18:52
rameshg87devananda, does that make sense ?18:52
*** harlowja has joined #openstack-ironic18:52
*** harlowja has quit IRC18:52
devanandarameshg87: sounds good so far18:53
*** harlowja has joined #openstack-ironic18:53
*** hello has joined #openstack-ironic18:53
rameshg87devananda, thanks..i would revise the spec based on our chat and then initiate review again.18:53
devanandarameshg87: thanks!18:53
*** dwalleck has joined #openstack-ironic18:54
*** sysexit has quit IRC18:55
*** Abhishe__ has joined #openstack-ironic18:56
*** Abhishe__ has joined #openstack-ironic18:56
*** mrda-away is now known as mrda18:56
mrdaMorning Ironic!18:57
*** lucas-afk is now known as lucasagomes18:57
dtantsurmorning, mrda! :)18:57
NobodyCamDKMS is unstable in opensuse :-p18:58
NobodyCammorning mrda18:58
dtantsurnearly meeting time!18:59
mrdaNobodyCam and dtantsur: hi18:59
romchegMorning again mrda :)19:00
devanandameeting time!19:00
devanandamorning, mrda19:00
mrdaromcheg and devananda: o/19:01
*** ellenh has quit IRC19:02
*** Abhishe__ is now known as achanda19:06
*** wanyen has quit IRC19:06
*** devananda has quit IRC19:10
*** coolsvap is now known as coolsvap|afk19:16
*** hello has quit IRC19:16
*** devananda has joined #openstack-ironic19:18
*** devananda is now known as devananda_19:18
*** devananda_ is now known as devananda19:18
*** Nisha has quit IRC19:20
*** achanda has quit IRC19:22
*** rameshg87 has left #openstack-ironic19:27
*** amitpp has quit IRC19:28
*** devanand1 has joined #openstack-ironic19:28
*** killer_prince has quit IRC19:30
*** killer_prince has joined #openstack-ironic19:32
*** achanda has joined #openstack-ironic19:36
*** killer_prince has quit IRC19:37
*** killer_prince has joined #openstack-ironic19:41
*** sysexit has joined #openstack-ironic19:46
openstackgerritMathieu Gagné proposed a change to openstack/ironic: Add genconfig tox job for sample config file generation  https://review.openstack.org/10161419:49
*** foexle has quit IRC19:56
NobodyCamahh back homw ... great meeting everyone20:01
lucasagomesrloo, yes, if we do it, it's mb for everything20:01
NobodyCamesp the tea reports TY all20:01
*** devananda has quit IRC20:01
*** yuriyz has quit IRC20:01
*** devanand1 is now known as devananda20:01
lucasagomesrloo, and the driver would convert it for us, root 1GB in nova == 1024 MB in Ironic20:01
NobodyCams/tea/team/20:01
matty_dubsBut #2 would allow <1GB partitions too, wouldn't it?20:01
* devananda is back on his irc proxy now20:02
lucasagomesmatty_dubs, yes20:02
ShrewsNobodyCam: i prefer tea reports. much more tasty20:02
NobodyCammatty_dubs: we would have to do math then20:02
ifarkasdevananda, re: ceilometer integration. thanks for the link. I guess it's not a requirement for graduation, is that correct?20:02
dtantsurmatty_dubs, yeah, and some surprises like 1.999999999999 GiB :)20:02
lucasagomesmatty_dubs, by using floats, but ppl may argue that floats are not good to represent partition sizes20:02
devanandamatty_dubs: the concern with #2 is taht it allows sizes like ^20:02
rloolucasagomes, did you get a chance to discuss with lifeless ?20:02
dtantsuror what was this funny number?20:02
matty_dubsI'm not sure I fully understand the controversy, but I don't see refusing to accept things less than full GBs as a feature.20:02
romchegdevananda: So in Grenade test it should be possible to build images, upload them to glance and generate a csv20:02
NobodyCamlucasagomes: 3.14.....20:02
lucasagomesrloo, wanted to do it in the meeting, I left some questions in the review as well I think20:02
lucasagomesrloo, but no dice20:02
devanandaifarkas: for metering and billing -- that should be handled by nova already, AIUI20:03
lucasagomesbrazil match just started!20:03
devanandaifarkas: for monitoring, ceilometer team did not agree wether they want to handle all the fan speed and temperature stats20:03
romcheglucasagomes: Oh, I will cheer for Brazil :)20:04
lucasagomesromcheg, :D cheers20:04
devanandaifarkas: I do believe that Ironic should support a pluggable way to emit notifications for hardware sensor data and events. and ceilometer would be one such receiver20:04
matty_dubsThat discussion seemed to bring up a fundamental disagreement within the ceilometer community, really20:04
devanandamatty_dubs: yep20:04
lucasagomesok so should I send it to the mailist? or we can vote on the unit sizes thing?20:04
romchegIt's a trend in Ukraine this season to cheer anyone but Russia. I haven't chosen my favourite team yet :)20:04
rloolucasagomes, so, why even change it? to be consistent with units?20:05
lucasagomesromcheg, hah brazil man :P20:05
NobodyCamromcheg: lol I'll bet20:05
lucasagomestho we are not doing well in this cup20:05
NobodyCambrb20:05
lucasagomesrloo, for the sake of consistency20:05
lucasagomesrloo, but I asked that too, do we want to have consistency or just leave it?20:05
ifarkasdevananda, yeah, it seems to be the right thing. is there a mailing list discussion, or there wasn't any between the two projects?20:05
devanandaifarkas: there hasn't been one since the summit20:06
*** dwalleck has quit IRC20:06
lucasagomesI'm almost leaving it because I think I already implemented all the 3 options I gave there at some point in time :)20:06
romchegWe need to set time limits for each topic for the meeting20:06
rloolucasagomes, it seems to me that this is something that can be done at a later date?20:06
devanandalucasagomes: ugh! :(20:06
lucasagomesrloo, yea20:06
lucasagomesrloo, but if we are doing it's better now since it's affect the driver20:06
rloolucasagomes, because it doesn't seem clear which way to go.20:06
lucasagomesrloo, so as sooner the better20:06
ifarkasdevananda, ok, thanks20:06
romchegBecause we usually spend half of the meeting for one topic and then there's no time for the rest of the stuff20:06
devanandalucasagomes: it's like metric vs. imperial units!20:07
rloolucasagomes, i think the 'right' way to do it is to support whatever X way in the future, but also support existing way for some period of time.20:07
lucasagomesdevananda, hah yeah!!!!!!20:07
rloooh, devananda has a grand idea. support both. but metric is clearly better ;)20:08
lucasagomesrloo, :P20:08
devanandaromcheg: i am working on that. sometimes it's hard to tell how long a topic needs20:08
lucasagomesrloo, right, hmm ok... I don't want to complicate things... it just that it kinda annoys me to see root_gb ephe_gb and swap_MB!20:08
lucasagomeslol20:08
romchegdevananda: That could be changed by a topic lead20:08
devanandaromcheg: if topics are urgent or require everyone, i generally try to bring them up early on20:08
Shrewslucasagomes: i vote making the units configurable!!!  :)20:09
devanandaromcheg: also, i lost 'net for the first ~20 minutes today ... which definitely slowed me down20:09
* Shrews hides from lucasagomes20:09
lucasagomesShrews, hah hah oh god lol20:09
romchegWhat are imperial units for partition sizes? :)20:10
rloolucasagomes: Shrews vote basically means support root_gb, root_mb, ephemeral_gb, ephemeral_mb, swap_mb and swap_gb. I don't see why not.20:10
* devananda wants to measure everything in medival japanese units of Shaku and Koku20:10
* rloo wonders if we should believe that devananda knows what he's talking about. He probably does though.20:10
lucasagomesrloo, unit configurable for me includes: B, KB, KiB, MB, MiB, GB, GiB...20:10
matty_dubsSpeaking of the metric system... http://en.wikipedia.org/wiki/Metrication#Chronology_and_status_of_conversion_by_country -- the US, Liberia, and Burma/Myanmar are effectively the only countries that have not adopted them.20:10
matty_dubs^ today's semi-off-topic trivia20:10
lifelessrloo: discuss what wwith me?20:10
rloolucasagomes, ah, you're right. I think we should stick with 'i' only ;)20:11
devanandakoku = unit of rice20:11
devanandashaku = roughly the length of an arm20:11
*** achanda has quit IRC20:11
lucasagomesdevananda, lol20:11
dtantsurit's a wonderful idea to measure partitions on rice and arms!20:11
romcheg++ for koku and shaku :D20:11
lucasagomescool, 15 arms for the root partition20:11
*** max_lobur has joined #openstack-ironic20:11
rloolifeless, using GB vs MB for root/ephemeral/swap.20:12
devanandaoh, actually, shaku is derived as roughly the distance between two nodes on a bamboo pole20:12
romchegGuys, aren't you in a coffe shop in Amsterdam right now? :)20:12
matty_dubsLOL romcheg20:12
lifelessrloo: I would be fine with all-in-MB; seems wasteful, but 1000% better than floats.20:12
dtantsurromcheg :D20:12
matty_dubsSo, I think I missed the background -- but is there any downside, other than it being change, to using MB everywhere? (Or allowing fractional GB?)20:13
lucasagomeslifeless, aye!20:13
rloolifeless, and the reason against floats is cuz it won't always translate from eg GB to units of MB.20:13
mrdaso a better measure for network latency? devananda20:13
lifelessrloo: aye20:13
lucasagomesok so MB then!?20:14
lifelessrloo: also because its just the wrong tool for the job20:14
rloomatty_dubs, so the downside to using MB is that the user may think in GB (or more accurately GiB).20:14
dtantsurrloo, user may also think in shaku! And even worse - in koku!20:14
rloolifeless, yeah, you're probably right. I was willing to go with floats cuz I didn't think that 5 MB should be converted to 1 GB.20:14
romchegmrda: Arm/Season for network20:14
*** achanda has joined #openstack-ironic20:14
lucasagomesdtantsur, hah20:15
lucasagomesso do we have a consensus here?20:15
rlooso to be honest, I am now thinking that we should support GiB and MiB and let the user choose to be consistent or not. Our examples etc could use MiB if you like. Of course, we don't use 'MiB' now in anything.20:15
matty_dubsrloo: Oh, hrm. You're probably right. But when I go to install a Linux distro, I'm usually asked to put in data in GB -- but with floats allowed.20:15
matty_dubsCould we just do MiB in the code, and *1024 in the UI as an option?20:16
matty_dubsOr, take the units? --size 4000M or --size 8G?20:16
lucasagomesmatty_dubs, sure, tuskar can do that20:16
rlooone day, someone might want TiB...20:16
mrdamatty_dubs: I like this.20:16
matty_dubsWell, until someone does --size 20 expecting 20MB/GB and gets 20 bytes ;)20:17
lucasagomesGOAL!!! brazil 1x020:17
dtantsurlucasagomes, lol20:18
devanandamrda: traditional japanese hours were based on the length of the day. which naturally vary by season and latitude. that would make fascinating network latency measurements :)20:18
dtantsurok folks, I like this Monday evening with you in this channel, but I have to go :)20:19
dtantsurg'night everyone20:19
devanandadtantsur: g'night!20:19
lucasagomesdtantsur, night!20:19
NobodyCamnight dtantsur20:19
lucasagomesyeah I'm going as well (want to watch the match)20:19
*** dtantsur is now known as dtantsur|afk20:19
NobodyCamnight lucasagomes20:19
rloonight lucasagomes, dtantsur|afk20:20
*** lucasagomes is now known as lucas-dinner20:20
matty_dubsSee ya, lucas-dinner and dtantsur|afk !20:20
lucas-dinnernight everyone!20:20
mrdadevananda: the measurements of a network wouldn't be any less correct using that system though :)20:20
romchegHave to go as well20:20
romchegG'night everyone20:21
matty_dubsOh, I aksed this in the meeting but we didn't have time -- do we all plan to attend the meeting all day Wednesday? Or are people leaving mid-day?20:21
devanandamatty_dubs: the midcycle?20:21
matty_dubsdevananda: Yes. Oops, context helps.20:21
*** Manishanker has joined #openstack-ironic20:22
devanandamatty_dubs: I tend to think 2 days is too little for int'l travel, so I'd encourage folks to stay for all of wed. But that's just my 2c :)20:22
matty_dubsThat's what I was thinking, too, but every time I think that, half the people leave the AM of the last day. ;)20:22
devanandamatty_dubs: folks dont want to travel on weekends :)20:23
matty_dubsOh, that's a good point20:23
devanandaso mon-fri often becomes mon-thu with fri being a travel day for int'l flights20:23
mrdamatty_dubs: I've got a 6:20pm flight leaving PDX, so I'll be leaving around 4pm I guess20:23
devanandamrda: are you arriving sunday?20:23
mrdaI'll be in Saturday night20:23
devanandamrda: awesome. let's do things on sunday20:24
*** bandicot has quit IRC20:24
mrdadevananda: sounds great!  Would like to hang out a bit and make the most of the trip20:24
* devananda points at the "if you're arriving early" bit20:24
devanandahttps://etherpad.openstack.org/p/juno-ironic-sprint20:24
mrdapyconau in BNE is on Friday, so any people at nova/ironic midcycle need to scoot back on Wed night to make it20:25
devanandaahh20:25
mrdaas in, don't go home, get off a 15 hour flight and go straight to conference and be two hours late20:25
lifelessdevananda: review 97736 seems like it should be an ironic spec20:26
* mrda thinks this is a crazy schedule20:26
devanandalifeless: we discussed with rameshg8- earlier. i need to update my comments20:27
devanandalifeless: posted20:28
devanandalifeless: ultimately, it's a change in DIB which will be leveraged by Ironic. There is a spec alraedy in Ironic to match (ilo deploy driver)20:30
devanandalifeless: I'm fine with it if you dont want a spec in DIB for that. we can fold it into the existing ironic spec20:30
*** ifarkas has quit IRC20:30
*** max_lobur1 has joined #openstack-ironic20:31
*** max_lobur has quit IRC20:31
*** martyntaylor has quit IRC20:36
*** ellenh has joined #openstack-ironic20:36
*** Haomeng has quit IRC20:40
matty_dubsOh, anyone know if there's any sort of shuttle, or if we'll need a car rental between the hotel and office each day?20:46
matty_dubs(Or if they're within walking distance?)20:46
mrdamatty_dubs: if you're staying at Larkspur Landing or whatever, I think it's too long a walk20:47
mrda...but if we're all in the designated hotel, I'm sure there'll be a spare seat in a car or something20:47
matty_dubsmrda: Yeah, I just Google Maps'ed it. Looks like about 3 miles20:48
matty_dubsOr whatever that is in non-imperial units ;)20:48
mrdaI don't mind walking that, especially in July in the USA, but some might not like it20:48
*** jcoufal has quit IRC20:49
matty_dubsUnless it rains :-\20:49
matty_dubsI think it'll book a car. It'll probably look bad if the people Red Hat sends all have to bum rides from other people. ;)20:50
*** sam__ has quit IRC20:50
mrdaWe should all start talking in shaku.20:50
mrdaWest Coast USA is in a drought, right? Or is this just CA?20:51
matty_dubsmrda: I haven't been keeping up, honestly. When I was in CA just before the last meetup, they were in the midst of the worst drought in about 125 years. My flight was delayed 6 hours due to torrential downpours in Los Angeles.20:52
matty_dubsIt seems like no major airlines fly into Hillsboro Airport? It seems kind of silly that the hotel and the office are separated by an airport, but not the one I'm flying into.20:54
mrdamatty_dubs: lol20:54
*** max_lobur1 has quit IRC20:54
JoshNangmrda: looks like its mostly CA affected by the worst parts of the drought http://droughtmonitor.unl.edu/20:54
mrdaI think Hillsboro airport is there for Intel private jets20:55
*** jdob has quit IRC20:55
matty_dubsOoh. Maybe I can hitch a ride on one of those!20:56
*** Manishanker has quit IRC20:56
devanandai need to run out soon and am way behind on things -- anyone want to rebase https://review.openstack.org/#/c/92819/ ?21:03
*** Haomeng has joined #openstack-ironic21:04
mrdadevananda: sure21:04
devanandamrda: thanks!21:04
*** linggao has quit IRC21:04
*** matty_dubs is now known as matty_dubs|gone21:04
jrolldevananda, mrda, my goal is to get to portland sunday afternoon and be able to hang out21:18
mrdajroll: cool!21:19
*** mdorman_ has joined #openstack-ironic21:23
*** mdorman_ has quit IRC21:25
*** mdorman_ has joined #openstack-ironic21:26
*** mdorman has quit IRC21:27
*** mdorman_ is now known as mdorman21:27
*** chen has joined #openstack-ironic21:29
openstackgerritMichael Davies proposed a change to openstack/ironic: Mock pyghmi lib in unit tests if not present  https://review.openstack.org/9281921:30
*** Mikhail_D_ltp has quit IRC21:33
*** chen has quit IRC21:38
*** yu_ has joined #openstack-ironic21:53
* devananda reviews more specs21:56
NobodyCambrb21:59
*** achanda has quit IRC22:03
devanandaheading out in a bit for an appt...22:06
NobodyCam:)22:08
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver (DO NOT MERGE)  https://review.openstack.org/10102022:23
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Adding swift temp url support  https://review.openstack.org/8139122:27
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Factor out TFTPImageCache  https://review.openstack.org/10073422:29
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Factor out deploy info from PXE driver  https://review.openstack.org/10073522:29
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Add methods to ipmitool driver  https://review.openstack.org/10036422:29
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver (DO NOT MERGE)  https://review.openstack.org/10102022:29
jrollwheeeeeeee22:30
*** sysexit has quit IRC22:33
*** achanda has joined #openstack-ironic22:45
*** romcheg has quit IRC22:47
*** kylers has joined #openstack-ironic23:26
*** mdorman has quit IRC23:27
lifelessdevananda: I've no objection to the spec there, but I think it needs Ironic consensus before +A23:30
* NobodyCam steps afk23:52

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!