Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2016-11-06

| Channels | #salt index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 alexlist joined #salt
00:16 myraft joined #salt
00:17 myraft joined #salt
00:21 subsignal joined #salt
00:21 NeoXiD joined #salt
00:23 NeoXiD Hi! Recently migrated over to Salt and now I'm looking for a solution where a minion checks if a file exists, if not, the master should run a command (HTTP POST), store the result (a token) in a variable, pass it back to the minion and the minion continues to do stuff with that token. Is that kind of approach possible? Salt Mine seems wrong (long term data), returnes see overcomplicated (external),
00:23 NeoXiD orchestration runner itself works, but doesn't seem to offer any kind of variable handling (passing data between minions/master), so I'm clueless. Thanks in advance for any kind of input.
00:24 edrocks joined #salt
00:25 Klas joined #salt
00:28 hasues joined #salt
00:29 Pulp joined #salt
00:29 hasues left #salt
00:31 fas3r I'm trying to use : ipaddr_start and ipadd_end to setup a new interface. The state is executed properly, the file /etc/sysconfig/network-scripts/eth1-range0 is well created. However the 2 variable IPADD_START= and IPADD_END= are not present in the file.
00:37 hemebond NeoXiD: Just use a script on the master that uses the LocalClient
00:39 hemebond fas3r: You will need to paste your state somewhere. Sounds like your state is wrong. Probably your Jinja.
00:39 hemebond But we have no idea how you're doing it.
00:40 fas3r hemebond: yes, I was preparing it : http://pastebin.com/eLdNTx4U
00:40 fas3r I store the info in the pillar directly. Also it works for my other regular states.
00:43 NeoXiD hemebond: was only using states with jinja-renderer and highstate/orchestrator so far, wasn't sure if that's best practice (being used to ansible's "delegate_to"). So it's all fine if I write my own runner in python, doing the stuff that the orchestrate runner does + additional execution logic?
00:43 myraft joined #salt
00:44 jas02 joined #salt
00:49 hemebond NeoXiD: Sure. I use a custom runner to do AWS provisioning.
00:51 mikecmpbll joined #salt
00:51 hemebond fas3r: Can you get those pillar values from the command line?
00:52 fas3r yes
00:52 fas3r I also tried by setting values directly
00:52 fas3r ( instead of {{ salt......}} )
00:53 hemebond Using the latest version of Salt? 2016.3.3 or 2016.3.4?
00:54 fas3r 2016.3.3
00:54 fas3r latest from yum
00:54 fas3r hum
00:55 fas3r let me upgrade it
00:55 fas3r it's upgrading.
01:01 fas3r hemebond: http://pastebin.com/6WDvKTPk
01:01 fas3r same thing after upgrade.
01:05 mpanetta joined #salt
01:08 hemebond What OS?
01:08 fas3r centos 7
01:11 devtea joined #salt
01:13 fas3r hemebond: in worst case I will just do a file.append
01:13 hemebond I can't see anything obviously wrong in the code so far; though I'm not familiar with it. I also don't have a Centos/Redhat machine to test with.
01:15 fas3r np
01:22 Guest70405 left #salt
01:22 hemebond fas3r: What version of Redhat does Centos match? 7?
01:23 fas3r CentOS Linux release 7.2.1511 (Core)
01:23 hemebond https://github.com/saltstack/salt/blob/v2016.3.4/salt/templates/rh_ip/rh7_eth.jinja
01:25 hemebond template = JINJA.get_template('rh{0}_eth.jinja'.format(rh_major))
01:25 hemebond So it grabs a template that matches the major version of the OS.
01:25 hemebond But I don't see ipaddr_start and ipaddr_end in that template.
01:25 hemebond I do see those variables in rh6_eth.jinja
01:26 fas3r hemebond: it's from the doc : https://docs.saltstack.com/en/latest/ref/states/all/salt.states.network.html#configuration-of-network-interfaces
01:27 hemebond Yip, I see it in the module. And previous Redhat version it probably would have worked.
01:27 hemebond I'm not sure this template works.
01:27 fas3r the one that you ssend me is the same that the one that I have
01:27 fas3r just did a diff.
01:27 hemebond Yip. So might be a bug.
01:28 hemebond Try adding in lines to output those variables.
01:28 fas3r do you think I can add them manually ?
01:28 hemebond Just edit the Salt source manually on the minion.
01:29 UForgotten ok so in theory using requires on states should make them run in a predictable order, right?  For whatever reason it looks like its still running them out of order.
01:32 Nahual joined #salt
01:32 UForgotten http://pastebin.com/A3W4UGgd - it should run service-factory-code then service-factory-install, then service-factory-start, then service-factory-check - but its running check before start. I thought order didn't matter as much as the requires since it could run them in any order?
01:34 fas3r hemebond: it's working, does it mean that I have to change it on all my new minions ?
01:38 hemebond fas3r: Raise a bug https://github.com/saltstack/salt/issues and yeah, it means you'll have to patch the code for all your minions that you want to do this on.
01:38 NeoXiD https://gist.github.com/NeoXiD/02d275a7434b2336d510272a519dd270 <-- Any way to get the output of all minions properly printed? Tried already passing in the array or a 'for _, result in results.items(): ...', both don't work.
01:38 hemebond Probably easier to just write the file manually.
01:38 hemebond Until it's fixed.
01:39 fas3r yes
01:39 netcho joined #salt
01:39 fas3r anyway it's not doing what I was expected :D
01:39 hemebond Yeah, an annoying bug that.
01:40 hemebond UForgotten: Your requires are wrong.
01:40 hemebond The format is "- module: state-id"
01:40 hemebond You've got "- state_id: module"
01:41 felskrone joined #salt
01:43 UForgotten hemebond: then why isnt it complaining about it?  Didnt work that way.
01:43 hemebond Pass
01:47 jas02 joined #salt
01:50 UForgotten hemebond: its still not observing the order with stateid:module in requires
01:50 hemebond UForgotten: Correct, that's the wrong order.
01:50 hemebond I said you need module: state-id
01:51 UForgotten whatever.
01:51 UForgotten I reversed it
01:51 UForgotten and its still broke
01:51 UForgotten :)
01:51 hemebond Paste your new state.
01:53 UForgotten http://pastebin.com/gU91FPu3
01:53 hemebond Oh, your require is still wrong
01:53 hemebond It has to be under cmd.run
01:54 hemebond Requires aren't state-wide, they belong to a particular module.function reference within a state.
01:54 hemebond https://docs.saltstack.com/en/latest/ref/states/requisites.html#require
01:55 UForgotten thats the docs/example I used. totally not intuitive at all.
01:56 hemebond Any ideas how it can be clearer?
01:56 UForgotten yes, state id :)
01:56 hemebond Like https://docs.saltstack.com/en/latest/ref/states/requisites.html#state-target-matching ?
01:57 hemebond I just learned you can target the name parameter or the state ID. Interesting.
01:58 UForgotten yes, it doesnt appear to work as advertised, or I'm missing something.
01:58 UForgotten its backwards from what would make sense anyway
01:58 hemebond What do you mean?
01:58 UForgotten I name a state. I should be able to just reference that, whatever module it's calling should not matter.
01:58 hemebond Your current state will work if you indent the require block and put - before the require
01:59 hemebond But state IDs can have several module calls under it.
01:59 hemebond *them.
01:59 devtea joined #salt
02:03 UForgotten Understood. but its still not making sense nor working.
02:03 hemebond Paste what you have now.
02:03 UForgotten it would make perfect sense if it was require my_state_name: module
02:04 hemebond Maybe. Might just be your preference there.
02:04 UForgotten going to try a few more things first.
02:05 UForgotten the order it shows them in the salt call is the order it ran them, right? its running them in the order they appear in the state file
02:05 vegasq joined #salt
02:05 hemebond Yes, by default it uses the order in the file.
02:05 UForgotten which I could easily re-order there. but its kind of just the principle that I should be able to order them by requires
02:05 hemebond You can override it using requisites.
02:06 hemebond I use requisites a lot.
02:16 UForgotten See this is what I was getting before Invalid requisite type 'cmd.run' in state 'service-factory-check', in SLS 'saltycontainer'. Requisite types must not contain dots, did you mean 'cmd'
02:16 hemebond You mean "cmd"
02:16 UForgotten but you said to use cmd.run :)
02:16 hemebond No, I said use module
02:16 UForgotten adn I had cmd before
02:16 hemebond The module is cmd
02:17 hemebond You had "stateid: module"
02:17 hemebond You need "module: stateid"
02:17 hemebond e.g., git: service-factory-code
02:18 UForgotten yeah. I had tried that before but it didn't work --  the real issue was the indent.
02:18 UForgotten thought the require would go on the state itself but it had to go on the module
02:18 hemebond I've got to head out for a bit. Good luck ????
02:18 NeoXiD Does it matter if I use 'salt.output.display_output' or '__jid_event__.fire_event({ ... }, "progress")' in a custom runner?
02:18 UForgotten I think I might have actually got it - thanks.
02:21 devtea joined #salt
02:23 stooj joined #salt
02:25 netcho joined #salt
02:26 edrocks joined #salt
02:31 UForgotten does anyone have a wrapper script of some sort that they run states from to ensure they complete? the standard salt client even with a timeout can be rather impatient and give up on the async jobs :)
02:39 Shirkdog joined #salt
02:46 vegasq_ joined #salt
03:03 preludedrew joined #salt
03:04 mavhq joined #salt
03:13 bastiand1 joined #salt
03:44 hemebond Haven't really had a problem myself with timeouts.
03:44 hemebond What would the wrapper do?
03:45 hemebond Poll the jobs queue until the async job has finished?
03:49 UForgotten that's one way
03:50 UForgotten I thought I read somwhere that you can write something that uses the api that starts a poller for a job and can do it that way
03:50 hemebond Yeah, you could write something that used LocalClient to watch jobs for you.
03:50 UForgotten use case is, would use salt to do a deploy that runs a state or set of states, need to verify that all states passed.
03:51 hemebond Well, if a state fails, then ... dependent states would fail. Or you could fail hard and stop all processing.
03:52 UForgotten right. have seen that done.  Just haven't seen something that will make sure a long running job finishes.
03:52 hemebond What would that mean?
03:53 hemebond That sounds like something you want outside of Salt.
03:53 mavhq joined #salt
03:53 lompik joined #salt
03:53 UForgotten its just as you said, something to poll the job queue and make sure all the jobs finished successfully
03:54 hemebond Well that was more about not having to manually run the command yourself to check the job.
03:54 hemebond So you can use async but still get the result as soon as it comes in.
03:55 hemebond Not really monitoring.
03:55 UForgotten hmm. might even be ok to output as json and have something check the json, but that's only good if the client doesn't drop :)
03:56 hemebond Yeah, if you have really long-running tasks then just up the timeout.
03:56 hemebond It'll still show the result as soon as it comes in.
03:57 UForgotten ll
04:11 onlyanegg joined #salt
04:12 PerilousApricot joined #salt
04:15 DEger joined #salt
04:26 netcho joined #salt
04:32 armguy joined #salt
04:49 jas02 joined #salt
04:50 informant joined #salt
05:06 mpanetta joined #salt
05:14 sarlalian joined #salt
05:17 PerilousApricot joined #salt
05:25 abonilla joined #salt
05:28 edrocks joined #salt
05:35 mavhq joined #salt
05:46 DEger_ joined #salt
05:51 jas02 joined #salt
06:02 ivanjaros joined #salt
06:14 subsignal joined #salt
06:17 akhter joined #salt
06:18 netcho joined #salt
06:19 perfectsine joined #salt
06:49 subsignal joined #salt
06:51 jas02 joined #salt
06:52 jas02_ joined #salt
07:04 jfelchner joined #salt
07:08 onlyanegg joined #salt
07:25 subsignal joined #salt
07:30 edrocks joined #salt
07:51 jas02 joined #salt
07:58 ivanjaros joined #salt
07:59 ivanjaros3916 joined #salt
08:00 subsignal joined #salt
08:14 Ni3mm4nd joined #salt
08:25 sgo_ joined #salt
08:30 jas02 joined #salt
08:30 jas02_ joined #salt
08:35 subsignal joined #salt
08:48 abonilla joined #salt
08:54 _KaszpiR_ joined #salt
08:55 Renich joined #salt
09:11 subsignal joined #salt
09:15 sh123124213 joined #salt
09:17 TyrfingMjolnir joined #salt
09:20 bocaneri joined #salt
09:31 jas02 joined #salt
09:32 Trauma joined #salt
09:42 onlyanegg joined #salt
09:46 subsignal joined #salt
09:48 zulutango joined #salt
09:49 sgo_ joined #salt
09:53 Ni3mm4nd joined #salt
09:54 jas02 joined #salt
09:57 keimlink joined #salt
10:02 Ni3mm4nd joined #salt
10:04 mavhq joined #salt
10:05 bastiandg joined #salt
10:06 cyborg-one joined #salt
10:09 darvon joined #salt
10:18 catpig joined #salt
10:20 Ni3mm4nd joined #salt
10:22 subsignal joined #salt
10:33 akhter joined #salt
10:34 DEger joined #salt
10:37 keimlink joined #salt
10:38 Ni3mm4nd joined #salt
10:42 onlyanegg joined #salt
10:44 Trauma joined #salt
10:48 Ni3mm4nd joined #salt
10:55 jas02 joined #salt
10:57 Ni3mm4nd joined #salt
10:58 subsignal joined #salt
11:10 haam3r joined #salt
11:15 Ni3mm4nd joined #salt
11:28 netcho joined #salt
11:33 Ni3mm4nd joined #salt
11:34 subsignal joined #salt
11:38 mikecmpbll joined #salt
11:43 Ni3mm4nd joined #salt
11:49 catpigger joined #salt
11:51 sebastian-w joined #salt
11:55 Trauma joined #salt
12:01 Ni3mm4nd joined #salt
12:09 subsignal joined #salt
12:20 jas02 joined #salt
12:34 edrocks joined #salt
12:35 jas02 joined #salt
12:37 Ni3mm4nd joined #salt
12:41 abednarik joined #salt
12:43 onlyanegg joined #salt
12:45 subsignal joined #salt
12:51 ebawnix joined #salt
12:51 ebawnix left #salt
12:55 Ni3mm4nd joined #salt
12:56 jeddi joined #salt
12:58 aidin joined #salt
13:04 s_kunk joined #salt
13:09 cyborg-one joined #salt
13:11 mavhq joined #salt
13:13 Ni3mm4nd joined #salt
13:19 abonilla joined #salt
13:21 subsignal joined #salt
13:26 s_kunk joined #salt
13:32 Ni3mm4nd joined #salt
13:33 amontalban joined #salt
13:33 amontalban joined #salt
13:34 DEger joined #salt
13:35 jas02 joined #salt
13:38 Ni3mm4nd joined #salt
13:47 ProT-0-TypE joined #salt
13:57 subsignal joined #salt
14:09 av_ joined #salt
14:12 vegasq joined #salt
14:23 amcorreia joined #salt
14:25 netcho joined #salt
14:32 subsignal joined #salt
14:36 edrocks joined #salt
14:36 jas02 joined #salt
14:41 Nightcinder joined #salt
14:42 samodid joined #salt
14:42 AirOnSkin joined #salt
14:44 onlyanegg joined #salt
14:45 subsignal joined #salt
14:47 scoates joined #salt
14:54 GnuLxUsr joined #salt
15:01 jas02 joined #salt
15:13 perfectsine joined #salt
15:21 jas02_ joined #salt
15:24 justanotheruser joined #salt
15:28 hax404 joined #salt
15:38 ivanjaros joined #salt
15:38 scoates joined #salt
15:38 vegasq joined #salt
15:44 eeeprom joined #salt
15:44 evilrob joined #salt
15:56 scoates joined #salt
16:00 onlyanegg joined #salt
16:03 hax404 joined #salt
16:08 amcorreia joined #salt
16:09 sh123124213 joined #salt
16:13 vegasq_ joined #salt
16:13 Ni3mm4nd_ joined #salt
16:15 Brijesh1 joined #salt
16:15 Brijesh1 joined #salt
16:17 nunatak joined #salt
16:22 armyriad joined #salt
16:26 aidin joined #salt
16:35 onlyanegg joined #salt
16:37 Brijesh1 left #salt
16:40 NeoXiD Is there are more efficient way than calling 'salt.utils.minions.get_minion_data' for all minions, followed by executing 'LocalClient.cmd(minion_id, <cmd>, <args>)' for each minion?
16:40 NeoXiD I know that I can use "*" as the minion_id in LocalClient.cmd (globbing), but then I'm unable to use the fqdn-grain in the arguments
16:41 smcquay joined #salt
16:42 yidhra joined #salt
16:49 Trauma joined #salt
17:04 mavhq joined #salt
17:13 felskrone joined #salt
17:17 jas02 joined #salt
17:23 jas02 joined #salt
17:35 onlyanegg joined #salt
17:36 DEger joined #salt
17:37 jfelchner joined #salt
17:38 edrocks joined #salt
17:49 onlyanegg joined #salt
17:53 nNbbnTDqLtQzJnpR joined #salt
17:53 nNbbnTDqLtQzJnpR https://www.youtube.com/watch?v=3EsJLNGVJ7E & https://wikileaks.org/podesta-emails/emailid/15893, http://www.reuters.com/article/us-usa-election-foundation-idUSKBN12Z2SL & https://wikileaks.org/podesta-emails/emailid/3774 (ctrl+f qatar) - please don't let these be buried
17:53 nNbbnTDqLtQzJnpR left #salt
18:08 ProT-0-TypE joined #salt
18:37 jas02 joined #salt
18:46 PerilousApricot joined #salt
18:54 Lionel_Debroux_ joined #salt
19:01 fas3r can I call " salt-cloud -p "my_profile" "name_instance" from a state ?
19:08 yidhra joined #salt
19:10 jas02 joined #salt
19:12 mpanetta joined #salt
19:17 nunatak left #salt
19:28 jfelchner_ joined #salt
19:40 subsignal joined #salt
19:40 edrocks joined #salt
19:43 jas02 joined #salt
19:47 hemebond fas3r: There are cloud modules that you can probably call from a state using module.run
20:09 subsignal joined #salt
20:10 jas02_ joined #salt
20:37 DEger_ joined #salt
20:43 jfelchner joined #salt
20:46 RandyT joined #salt
20:47 fas3r is it possible to use watch or require on a "network.managed" state ?
20:49 hemebond Sure.
20:49 hemebond You can watch and require any state.
20:49 hemebond All watching means is if that state makes a change then the watching state will also be run/applied.
20:50 fas3r so if I did : conf_eth1:   network.managed: .....      in the second state I can do :   -watch :     conf_eth1 ?
20:50 hemebond network: conf_eth1
20:50 hemebond yes
20:50 fas3r ok
20:50 fas3r thanks
20:53 felskrone joined #salt
20:58 amontalban joined #salt
20:58 amontalban joined #salt
21:00 RandyT joined #salt
21:08 RandyT joined #salt
21:13 jas02 joined #salt
21:17 RandyT joined #salt
21:17 whytewolf fas3r: to your earlyer question there is a cloud.profile state https://docs.saltstack.com/en/carbon/ref/states/all/salt.states.cloud.html
21:18 fas3r I meant map, not profile.
21:18 fas3r sorry
21:19 whytewolf ahh a map you need a runner for
21:19 whytewolf https://docs.saltstack.com/en/carbon/ref/runners/all/salt.runners.cloud.html#salt.runners.cloud.map_run
21:19 whytewolf since that is purly master side
21:20 whytewolf there is no exacution module or state that does maps
21:20 fas3r whytewolf: It's ok.
21:20 cyborg-one joined #salt
21:20 fas3r I also notice that virtual_interface_create / detach are not working.
21:22 fracklen joined #salt
21:23 onovy joined #salt
21:23 _W_ joined #salt
21:23 whytewolf also. as for watching another state. the issue is watch might not be the best choice. watch is for adding addition behavour based on if another state runs. network.managed does not have a mod_watch function for added behavour. onchanges might be the better choice as it only exacutes if the state changes
21:24 abednarik joined #salt
21:26 whytewolf virtual_interface_create? as in cloud.virtual_interface_create ?
21:27 fas3r whytewolf: salt.modules.cloud.virtual_interface_create
21:28 fas3r yes
21:28 whytewolf what cloud driver are you using?
21:28 fas3r nova
21:29 whytewolf humm, that should work with nova.
21:29 whytewolf if you were using openstack it defintly wouldn't work
21:30 whytewolf the openstack driver doesn't have the action needed for it
21:30 whytewolf does cloud.virtual_interface_list work? and what does -l debug tell you when you try?
21:32 robbintt joined #salt
21:33 fas3r whytewolf: http://pastebin.com/9T26P8ML
21:37 whytewolf so nova is returning not found? could be no virtual interfaces on that instance. or it couldn't find the instance.
21:38 whytewolf and of coarse. my own cloud doens't support virtual-interfaces
21:38 fas3r no there is 4 network on it
21:38 fas3r the other module works
21:38 whytewolf virtual-interfaces is different then networks
21:39 whytewolf are you using neutron in your cloud?
21:40 whytewolf or nova-network
21:40 fas3r well I just would like to do the same as servers.interface_attach when using nova python libs directly :)
21:40 fas3r my provider is set to use nova driver
21:41 whytewolf ... in your cloud not in salt
21:42 whytewolf the issue is the nova openstack driver is very rackspace orentend. if your cloud is not built like rackspace then issues can come up. hopefully some of gtmanfred's changes are going to be changeing that.
21:42 whytewolf the other problem is the openstack driver is old.
21:43 whytewolf and doesn't support some of these salt features
21:43 fas3r that's why I wrote my own module for that, I added in /usr/lib/python2.7/site-packages/salt/modules/cloud.py of my salt-master
21:44 fas3r I mean function
21:44 whytewolf ... are you targettting your master with the cloud commands?
21:45 fas3r yes
21:45 fas3r you mean that I should add the info of the provider in the /etc/salt/cloud of each minion ?
21:46 whytewolf no.
21:46 fas3r :)
21:46 fas3r ok
21:46 fas3r when I run the salt-cloud command it's from my salt-master, so I thought that if I want to do the same with cloud.create I should target my salt-master.
21:47 whytewolf salt-cloud can live a lot of places.
21:47 whytewolf doens't have to live on the master
21:47 fas3r yes
21:47 fas3r you just need to give the provider info
21:47 whytewolf yes.
21:47 fas3r but for know I would prefer to keep everything on the master.
21:48 whytewolf anyway that isn't important the reason i asked if you were targetting the master is because you said you changed a file in an odd spot
21:48 whytewolf changeing this file on the master /usr/lib/python2.7/site-packages/salt/modules/cloud.py
21:49 fas3r yes, I added an function in it that I can call it from salt.  I can do salt 'my_master'  cloud.mynewfunction
21:49 whytewolf you could just put that file in a _modules directory in the root of your file_roots and then sync it
21:49 fas3r my target would be to do it from the states actually directly.
21:50 whytewolf custom modules override built in modules
21:51 whytewolf you didn't need to change the file with in salt
21:51 whytewolf but we are getting off track
21:51 fas3r :)
21:51 fas3r yep.
21:52 fracklen_ joined #salt
21:52 fas3r basically I just want to be able to add network interface to my instances.
21:52 whytewolf okay. and what is your version of openstack and what network subsystem in openstack are you using?
21:52 fas3r as I dont want to deploy the provider info on the minion, I can not do it during the highstate
21:53 fracklen_ joined #salt
21:53 whytewolf who said anything about putting provider info on your minion?
21:53 fas3r whytewolf: I'm not sure how to get the info, it's OVH.
21:53 whytewolf or using highstate
21:54 fas3r well the module virtual_interface_attach is not working anyway :D
21:54 whytewolf OVH? that is a cloud provider i have not heard about. one second researching
21:55 whytewolf virtual_interface_attach is dependent on nova-network
21:55 fas3r you mean novapython lib ?
21:55 whytewolf no i mean the project called nova-network that preceded neutron as the built in openstack network driver
21:55 fas3r ok
21:56 Edgan joined #salt
21:56 fas3r because I use novaclient in python and I dont have issue to add interfaces.
21:57 whytewolf sigh
21:57 whytewolf novaclient has MANY functions that deal with network.
21:57 whytewolf many of them are old and outdated
21:57 whytewolf some are in nova 1_1
21:59 whytewolf you said interface_attach does work for you?
21:59 fas3r yes
21:59 fas3r I was thinkg that maybe I can just put that instead of virtual_interface_network ... somewhere :D
21:59 fas3r at least as a tfix
22:03 whytewolf well. it is possable. but it isn't fun...
22:03 whytewolf right now. the function is calling virtual_interface.create [which is NOT what you need. you need a real interface not a virtual interface, which is a big difference between nova-network and neutron]
22:04 whytewolf there are several places you would need to change things.
22:04 fas3r that's why I dev my own functions
22:04 fas3r it's parsing the provider info in /srv/salt/cloud.providers.d/
22:04 whytewolf i was talking about coode wise.
22:04 fas3r then just use servers.interface_attach with the proper info.
22:05 whytewolf salt/utils/openstack/nova.py
22:05 fas3r it was easier for me to code it than looking where to do the modification ..
22:05 PerilousApricot joined #salt
22:05 whytewolf salt/cloud/clouds/nova.py
22:06 fas3r I openened it :)
22:09 jas02 joined #salt
22:12 fas3r whytewolf: "AttributeError: 'SaltNova' object has no attribute 'interface_list'"
22:13 whytewolf saltnova is nova the novaclient
22:13 whytewolf err not
22:14 whytewolf saltnova is salt/utils/openstack/nova.py
22:14 whytewolf like i said couple of places
22:14 sh123124213 joined #salt
22:14 fas3r yes, I change "return conn.virtual_interface_list(name) to return conn.interface_list(name)"
22:15 fas3r should I just do a sed for everything having virtual_interface_create :) ?
22:15 fas3r or list, to check
22:16 whytewolf how about actually checking that conn is what you are expecting it to be first
22:18 whytewolf conn = saltnova
22:19 whytewolf which is NOT the novaclient python it is the saltutils nova driverd
22:19 whytewolf which i pointed at earlyer
22:25 fas3r whytewolf: thanks you very much
22:25 fas3r corrected it
22:25 fas3r it's working now.
22:25 fas3r just need to work on the output..
22:33 fas3r whytewolf: thanks you very much
22:33 whytewolf :)
22:47 fracklen joined #salt
22:49 fracklen joined #salt
23:13 mpanetta joined #salt
23:14 jas02 joined #salt
23:17 amcorreia joined #salt
23:32 Trauma joined #salt
23:45 scoates joined #salt
23:53 jeddi joined #salt
23:53 sh123124213 joined #salt
23:54 DEger joined #salt
23:56 cyteen joined #salt
23:59 ninjada joined #salt

| Channels | #salt index | Today | | Search | Google Search | Plain-Text | summary