| *** slaweq has joined #openstack-sdks | 00:03 | |
| *** slaweq has quit IRC | 00:08 | |
| *** senrique__ has joined #openstack-sdks | 00:09 | |
| *** slaweq has joined #openstack-sdks | 00:11 | |
| *** mriedem has quit IRC | 00:11 | |
| *** senrique_ has quit IRC | 00:12 | |
| *** jangutter has quit IRC | 00:13 | |
| *** jangutter has joined #openstack-sdks | 00:13 | |
| *** slaweq has quit IRC | 00:16 | |
| *** senrique__ has quit IRC | 00:23 | |
| *** ricolin has joined #openstack-sdks | 00:48 | |
| *** gtema has joined #openstack-sdks | 00:50 | |
| *** enriquetaso has joined #openstack-sdks | 00:54 | |
| *** gtema has quit IRC | 00:56 | |
| *** gtema has joined #openstack-sdks | 00:57 | |
| *** mriedem has joined #openstack-sdks | 01:01 | |
| *** mriedem has joined #openstack-sdks | 01:01 | |
| *** enriquetaso has quit IRC | 01:10 | |
| *** gtema has quit IRC | 01:11 | |
| *** gtema has joined #openstack-sdks | 01:17 | |
| *** gtema has quit IRC | 01:22 | |
| *** gtema has joined #openstack-sdks | 01:25 | |
| *** gtema has quit IRC | 01:33 | |
| *** mriedem has quit IRC | 01:40 | |
| *** gtema has joined #openstack-sdks | 01:42 | |
| *** gtema has quit IRC | 01:54 | |
| *** ricolin_ has joined #openstack-sdks | 02:05 | |
| *** ricolin has quit IRC | 02:07 | |
| *** iokiwi has joined #openstack-sdks | 02:53 | |
| *** Dinesh_Bhor has joined #openstack-sdks | 02:58 | |
| *** gtema has joined #openstack-sdks | 04:45 | |
| *** gtema has quit IRC | 04:49 | |
| *** gtema has joined #openstack-sdks | 05:26 | |
| *** gtema has quit IRC | 05:31 | |
| *** gtema has joined #openstack-sdks | 06:41 | |
| *** gtema has quit IRC | 06:45 | |
| *** gtema has joined #openstack-sdks | 06:54 | |
| *** gtema has quit IRC | 06:59 | |
| *** gkadam has joined #openstack-sdks | 07:13 | |
| *** gkadam has quit IRC | 07:13 | |
| *** gtema has joined #openstack-sdks | 07:26 | |
| *** gtema has quit IRC | 07:54 | |
| *** gtema has joined #openstack-sdks | 07:57 | |
| *** gtema_ has joined #openstack-sdks | 07:58 | |
| *** gtema has quit IRC | 08:01 | |
| *** jpena|off is now known as jpena | 08:01 | |
| *** jpich has joined #openstack-sdks | 08:14 | |
| *** slaweq has joined #openstack-sdks | 08:15 | |
| *** tosky has joined #openstack-sdks | 08:27 | |
| *** slaweq has quit IRC | 08:36 | |
| *** corvus has quit IRC | 08:40 | |
| *** ralonsoh has joined #openstack-sdks | 08:46 | |
| *** tonyb has quit IRC | 08:56 | |
| *** tonyb has joined #openstack-sdks | 08:56 | |
| *** slaweq has joined #openstack-sdks | 08:58 | |
| *** corvus has joined #openstack-sdks | 08:59 | |
| *** goldyfruit_ has quit IRC | 09:29 | |
| *** dtantsur|afk is now known as dtantsur | 09:52 | |
| *** gtema_ has quit IRC | 10:04 | |
| *** gtema has joined #openstack-sdks | 10:05 | |
| *** goldyfruit_ has joined #openstack-sdks | 10:50 | |
| *** dtantsur is now known as dtantsur|brb | 11:09 | |
| *** goldyfruit_ has quit IRC | 11:13 | |
| *** sshnaidm|afk is now known as sshnaidm | 11:32 | |
| *** enriquetaso has joined #openstack-sdks | 11:41 | |
| *** jpena is now known as jpena|lunch | 12:04 | |
| *** mgariepy has joined #openstack-sdks | 12:14 | |
| *** jpich has quit IRC | 12:19 | |
| *** jpich has joined #openstack-sdks | 12:19 | |
| *** sshnaidm has quit IRC | 12:37 | |
| *** sshnaidm has joined #openstack-sdks | 12:38 | |
| *** dtantsur|brb is now known as dtantsur | 12:58 | |
| *** enriquetaso has quit IRC | 13:01 | |
| *** enriquetaso has joined #openstack-sdks | 13:01 | |
| *** enriquetaso has quit IRC | 13:07 | |
| *** jpena|lunch is now known as jpena | 13:15 | |
| *** sshnaidm has quit IRC | 13:18 | |
| *** sshnaidm has joined #openstack-sdks | 13:19 | |
| *** mriedem has joined #openstack-sdks | 13:23 | |
| *** jangutter has quit IRC | 13:51 | |
| *** enriquetaso has joined #openstack-sdks | 13:51 | |
| *** senrique_ has joined #openstack-sdks | 13:54 | |
| *** enriquetaso has quit IRC | 13:56 | |
| *** sshnaidm has quit IRC | 14:04 | |
| *** jangutter has joined #openstack-sdks | 14:05 | |
| *** sshnaidm has joined #openstack-sdks | 14:49 | |
| *** ricolin_ is now known as ricolin | 14:57 | |
| *** lbragstad has joined #openstack-sdks | 15:04 | |
| *** KeithMnemonic has joined #openstack-sdks | 15:07 | |
| *** dtantsur is now known as dtantsur|brb | 15:10 | |
| *** jangutter has quit IRC | 15:15 | |
| *** dave-mccowan has joined #openstack-sdks | 15:33 | |
| *** dtantsur|brb is now known as dtantsur | 15:52 | |
| sshnaidm | hello everyone | 15:59 |
|---|---|---|
| dtantsur | we're about to hijack this slot again \o/ | 15:59 |
| * dtantsur wonders when elmiko starts throwing us out of the door :D | 15:59 | |
| sshnaidm | etherpad is here: https://etherpad.openstack.org/p/openstack-ansible-modules | 16:00 |
| sshnaidm | please add topic for discussions there | 16:00 |
| sshnaidm | dtantsur, can you run the bot please? | 16:00 |
| dtantsur | #startmeeting api-sig | 16:00 |
| openstack | Meeting started Thu Dec 12 16:00:48 2019 UTC and is due to finish in 60 minutes. The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: api-sig)" | 16:00 | |
| openstack | The meeting name has been set to 'api_sig' | 16:00 |
| dtantsur | #chair sshnaidm elmiko | 16:00 |
| openstack | Current chairs: dtantsur elmiko sshnaidm | 16:01 |
| sshnaidm | dtantsur, thanks! | 16:01 |
| sshnaidm | o/ | 16:01 |
| dtantsur | #link https://etherpad.openstack.org/p/openstack-ansible-modules agenda | 16:01 |
| dtantsur | anyone else here? :) | 16:01 |
| gtema | me | 16:01 |
| dtantsur | a nice private party :) | 16:02 |
| gtema | sure | 16:02 |
| gtema | as usual | 16:03 |
| sshnaidm | mnaser, mordred, odyssey4me | 16:03 |
| gtema | last week was weird - too much people :D | 16:03 |
| sshnaidm | just calling people from etherpad :) | 16:03 |
| odyssey4me | o/ | 16:03 |
| sshnaidm | holidays I assume | 16:03 |
| * odyssey4me is in two meetings, but will try to participate | 16:03 | |
| gtema | it's tooooooo early for holidays, who will do the work | 16:03 |
| sshnaidm | so I've sent a mail to legal-discussion: http://lists.openstack.org/pipermail/legal-discuss/2019-December/thread.html | 16:04 |
| sshnaidm | it's the only thread there | 16:04 |
| sshnaidm | got responses that we'd better to keep developing in ansible sig repo under GPL | 16:04 |
| sshnaidm | any other opinions about that? ^ | 16:05 |
| odyssey4me | hmm, is that an OK thing for openstack repositories? | 16:05 |
| mordred | ohai! | 16:05 |
| gtema | well, reading inside I would say there are no answers (mordred doesn't count) | 16:06 |
| sshnaidm | odyssey4me, well, it's not really openstack repository | 16:06 |
| sshnaidm | gtema, yeah, responses were from people of this meeting actually :) | 16:06 |
| mordred | yeah - although while I don't count - the takeaway I've gotten from past encounters is that as along as it's not part of "the software" called openstack, it's ok | 16:07 |
| dtantsur | it seems that we can host GPL code, just not make it official openstack delivarables | 16:07 |
| mordred | yah | 16:07 |
| odyssey4me | is that a problem? | 16:07 |
| sshnaidm | I'd like to know what it blocks for us | 16:07 |
| mordred | nope. should be fine. this is an effort of a sig | 16:07 |
| *** jpena is now known as jpena|off | 16:07 | |
| *** dave-mccowan has quit IRC | 16:07 | |
| mordred | I don't thnk it's blocks anything. ansible is already GPL | 16:08 |
| dtantsur | nothing blocking. just a bit unfortunate that we cannot proudly call these modules official | 16:08 |
| sshnaidm | what is consequences of not having this as deliverable? | 16:08 |
| odyssey4me | we have imports both ways, right - the module imports ansible (GPL) stuff, and also imports openstack (Apache) stuff | 16:08 |
| mordred | so anything that would use these modules must by definition be ok consuming gpl software | 16:08 |
| dtantsur | sshnaidm: no promotion on openstack.org? | 16:08 |
| mordred | I don't think it's a matter of not being able to call these modules official | 16:08 |
| dtantsur | one things that I think is important re licensing: | 16:08 |
| sshnaidm | mordred, this won't change anyway, we don't relicense them | 16:08 |
| mordred | it's that they can't be part of an OpenStack release | 16:08 |
| mordred | which they wouldn't be anyway, since that makes no sense | 16:09 |
| dtantsur | if we write something that looks like logic independent of ansible, we should better put it somewhere else | 16:09 |
| dtantsur | otherwise we won't be able to easily reuse it in other parts of openstack | 16:09 |
| mordred | dtantsur: right. and that's stuff we tend to put in sdk | 16:09 |
| dtantsur | e.g. it will be troublesome to put it to sdk | 16:09 |
| dtantsur | exactly | 16:09 |
| pabelanger | right, this should be the ansible community openstack collection | 16:09 |
| dtantsur | last time I proposed that any logic goes to sdk | 16:09 |
| mordred | (which is one of the reasons we have sdk and are so adamant about butting things in there) | 16:09 |
| mordred | ++ | 16:09 |
| odyssey4me | yep, the thinner the module is as a layer - the better | 16:09 |
| mordred | the modules should be thin glue code between the ansible module structure and logic entities in sdk | 16:09 |
| odyssey4me | *modules | 16:09 |
| mordred | this will be easier to accomplish with the modules in gerrit now | 16:10 |
| dtantsur | #agreed Try to put most of the logic into openstacksdk, keep the ansible modules as thin glue | 16:10 |
| dtantsur | right? | 16:10 |
| sshnaidm | having lite modules with sdk logic is totally fine for me too, but here comes question of compatibility between versions | 16:10 |
| mordred | yah | 16:10 |
| mordred | the sdk supports all versions of openstack | 16:10 |
| *** dave-mccowan has joined #openstack-sdks | 16:10 | |
| mordred | so that direction is fine | 16:10 |
| dtantsur | sshnaidm: any logic code is anyway tied to openstack, not to ansible | 16:10 |
| sshnaidm | dtantsur, right, agree | 16:11 |
| Shrews | yes, there is no reason to not continue that abstraction/separation. also, hi! | 16:11 |
| mordred | the version support matrix is then for different versions of ansible - maybe something changes in newer versions of ansible and we need to update the module interface for that | 16:11 |
| dtantsur | wow, I wild Shrews appears :) | 16:11 |
| dtantsur | * a wild | 16:11 |
| dtantsur | (sigh) | 16:11 |
| Shrews | i'm tame now | 16:11 |
| * mordred hands Shrews a bunny | 16:11 | |
| gtema | atm collection does not define dependency to Ansible (requires version) | 16:11 |
| gtema | so assume this should not happen in near future | 16:12 |
| dtantsur | gundalow: ^^^? | 16:12 |
| mordred | yah. so hopefully we can have our modules support all extant versions of ansible too | 16:12 |
| sshnaidm | I hope won't happen at all | 16:12 |
| mordred | (even if the modules have to have some if logic in them to do so) | 16:12 |
| mordred | but the module interface has been *VERY* stable for the past several years | 16:12 |
| odyssey4me | I guess we're going to have to limit the collection version support for Ansible. Ansible does tend to make pretty heavy changes from time to time. | 16:13 |
| gtema | don't kill me: should we introduce support for microversions in Ansible? | 16:13 |
| mordred | the only main systemic changes have been around things like docstsring formats | 16:13 |
| dtantsur | #agreed Try to support as many versions of ansible as possible with the same code | 16:13 |
| * dtantsur throws a lot of wet cats at gtema | 16:13 | |
| mordred | gtema: no | 16:13 |
| mordred | all microversion support should be in the sdk | 16:13 |
| gtema | it was a joke, but with small sense of truth | 16:13 |
| mordred | heh | 16:13 |
| sshnaidm | so, back to hosting modules - do we completely freeze existing and start new ones? Remember that people will use them from 2.10 from our repo | 16:13 |
| * mordred throws wet cat at gtema | 16:13 | |
| mordred | I *strongly* oppose starting new modules | 16:14 |
| gtema | i mean if someone would like to get info about smth, what is reported only with microversion set | 16:14 |
| dtantsur | mmm? | 16:14 |
| Shrews | why would we *want* new ones? | 16:14 |
| dtantsur | mordred: would you rather prefer a breaking change? | 16:14 |
| sshnaidm | mordred, we'll need to rename them at least | 16:14 |
| dtantsur | Shrews: we need 1) rename some modules, 2) fix auth in some | 16:14 |
| sshnaidm | and people use them in their playbooks | 16:14 |
| pabelanger | one thought I had with collection version, since it is semver. Is have 1.0.0,<2.0.0 support ansible 2.10.0 (stable-2.10), then 2.0.0,<3.0.0 support ansible 2.11.0 (stable-2.11) | 16:14 |
| *** irclogbot_3 has quit IRC | 16:14 | |
| *** irclogbot_1 has quit IRC | 16:14 | |
| pabelanger | etc | 16:14 |
| mordred | I think that's potentially unnecessary and hard | 16:15 |
| mordred | many of these modules have been unchanged from ansible 2.0 | 16:15 |
| dtantsur | it depends on how different 2.11 will be from 2.10 | 16:15 |
| mordred | ansible itself does _not_ change that much as it relates to the module interface | 16:15 |
| sshnaidm | mordred, I think current names and code should be re-thought at least | 16:15 |
| odyssey4me | hmm, ok - is the scope of the collection *just* modules/libraries? | 16:15 |
| dtantsur | I recall auth being mess in ironic modules (maybe all really) | 16:15 |
| openstackgerrit | Andrew Karpow proposed openstack/python-openstackclient master: Use network service for Server AddFixedIP https://review.opendev.org/698749 | 16:15 |
| mordred | odyssey4me: the scope of _this_ collection, yes | 16:16 |
| *** irclogbot_2 has joined #openstack-sdks | 16:16 | |
| gtema | let's talk about collection name | 16:16 |
| dtantsur | what else can we have? | 16:16 |
| mordred | I think this sig can have additional collections published to galaxy that contain roles and stuff | 16:16 |
| odyssey4me | mordred: ok, sounds sensible - we should probbaly document that somewhere | 16:16 |
| *** lbragstad has quit IRC | 16:16 | |
| Shrews | what is the proposed new module naming structure? and why doesn't the current one work? | 16:16 |
| mordred | but this, for now, is about moving the os_ modules from ansible/ansible and into a collection | 16:16 |
| dtantsur | Shrews: at least s/os_ironic/baremetal/ | 16:16 |
| gtema | Shrews: os_ prefix is unnecessary | 16:16 |
| dtantsur | actually, drop os_? | 16:17 |
| mordred | Shrews: 2 potential naming things ... yeah | 16:17 |
| pabelanger | is there no plugins that need to move? | 16:17 |
| pabelanger | dtantsur: plese no | 16:17 |
| pabelanger | that will break playbooks | 16:17 |
| mordred | os_ prefix - and the service-type in the module names for "admin" modules | 16:17 |
| sshnaidm | I'd leave existing with deprecation notice and start from copying and reworking them | 16:17 |
| dtantsur | pabelanger: that's why we're talking about new modules | 16:17 |
| mordred | but - pabelanger makes a good point WRT naming | 16:17 |
| dtantsur | leave os_ironic whatever it is, develop baremetal properly | 16:17 |
| mordred | this is a thing I'd like to really get a real answer on though | 16:17 |
| sshnaidm | pabelanger, yeah, I wouldn't touch them at all | 16:17 |
| * gundalow waves | 16:18 | |
| sshnaidm | mordred, working on old modules doesn't give us any freedom and will most likely break existing playbooks | 16:18 |
| mordred | gundalow mentioned a magical thing that would allow someone to install ansible + a set of collections to get symlinks for the old modules for compat | 16:18 |
| gtema | wrt playbook change, I was still not able to get answer in Ansible | 16:18 |
| mordred | if that exists, and doesn't have support for module-level symlinks, then I think renaming is very mean | 16:18 |
| pabelanger | I would recommend everybody look at https://github.com/ansible-community/collection_migration, that is the tooling being written today to migrate content out of ansible/ansible to collections. So far, that has some large assumptions | 16:18 |
| gtema | so for the moment it is not known, whether it is possible at all | 16:18 |
| mordred | if it doesn't exist - we should rename because everyone is going to be broken anyway | 16:18 |
| mordred | if it does exist AND we can provide a mapping of fully qualified names to old names, then we should rename | 16:19 |
| pabelanger | gtema: which answer? | 16:19 |
| mordred | I think we need an answer on what the omnibus installer looks like before we commit one way or the other to renaming anything | 16:19 |
| sshnaidm | #link https://github.com/ansible-community/collection_migration | 16:19 |
| gtema | exaclty, whether it is possible to leave playbooks unaffected | 16:19 |
| gtema | without introducing FQCN | 16:19 |
| mordred | yah | 16:19 |
| pabelanger | gtema: yes, that is possible | 16:19 |
| gtema | how? | 16:19 |
| pabelanger | collection loader supports relative imports | 16:20 |
| mordred | can you say more words about that? | 16:20 |
| pabelanger | so both cisco.ios.ios_config and ios_config are valid tasks in playbooks using collections | 16:20 |
| sshnaidm | I think gundalow told about this previous time, it works like imports in python | 16:20 |
| mordred | pabelanger: I thought you had to add an import statement to your playbook for that to work | 16:20 |
| gundalow | mordred: there will be a "Ansible Community Distribution" (bikeshed) which will install Ansible + the collections that hold the content that was in Ansible 2.9. | 16:20 |
| pabelanger | if collection is cisco.ios | 16:20 |
| gundalow | sshnaidm: correct | 16:20 |
| gtema | not really, in the 2nd case you introduce import at the beginning of playbook | 16:20 |
| mordred | pabelanger: right - but you have to add a collection reference into the playbook | 16:21 |
| sshnaidm | mordred, when using symlink you shouldn't | 16:21 |
| mordred | hang on | 16:21 |
| pabelanger | mordred: no, not any more | 16:21 |
| mordred | two different things | 16:21 |
| mordred | ok. | 16:21 |
| pabelanger | from playbooks, what I said is fine | 16:21 |
| gundalow | If you are using ACD you may not need to explicitly import anything that ships in ACD, it's done automagically for you | 16:21 |
| pabelanger | for module_utils, you should use fqcn (fully qualify collection name) | 16:21 |
| mordred | gundalow: what's ACD? | 16:21 |
| gundalow | sorry, Ansible Community Distribution | 16:22 |
| mordred | is that what I get when I do "pip install ansible" ? | 16:22 |
| dtantsur | do we expect a lot of people to use it? | 16:22 |
| dtantsur | yeah, same question (dnf install ansible, etc) | 16:22 |
| pabelanger | mordred: magic installer doesn't exist today | 16:22 |
| mordred | ok. I won't be using that | 16:22 |
| gtema | brew install ansible? | 16:22 |
| pabelanger | so, pip install ansible / ansible-galaxy collection install foo | 16:22 |
| gundalow | In an ideal word, yes, `$package_mgr install ansible` will give you ACD | 16:22 |
| dtantsur | and in ours? :) | 16:23 |
| mordred | gundalow: does $package_mgr include pip? (sorry to be pedantic here- just trying to make sure I understand everything) | 16:23 |
| gundalow | dtantsur++ | 16:23 |
| gundalow | mordred: yup including pip | 16:23 |
| mordred | cool | 16:23 |
| mordred | gundalow: so - the magic there is done via symlinks from the botmeta file we discussed the other day right? | 16:23 |
| gtema | I still do not really believe in a perfect world | 16:23 |
| gundalow | Given one of the high level requirements is "don't break people" I'd really hope we can get `pip install ansible` to give you ansible + all the modules | 16:24 |
| mordred | gundalow: do we know if we'll be able to specifiy in that botmeta file mappings on a per-module basis? | 16:24 |
| gtema | when we release first collection we need to insure our func tests from SDK are using really collection | 16:24 |
| gundalow | mordred: yes, BOTMETA supports per file, there are examples, it's just that generally we logically group by directory | 16:24 |
| mordred | gtema: we should probably test both ways | 16:24 |
| mordred | gundalow: cool. | 16:24 |
| mordred | so - let's assume a perfect world for a sec ... | 16:25 |
| pabelanger | gtema: mordred: yes, testing both is safest, that is what ansible network does now | 16:25 |
| * gtema falls asleep | 16:25 | |
| mordred | if the botmeta thing works per file and if it exists and does the symlinks and works for pip nad dnf and friends ... | 16:25 |
| dtantsur | gtema: just half past 5, c'mon! | 16:25 |
| mordred | then it should be safe to rename the modules in the collection | 16:25 |
| sshnaidm | ok, so back to the original question, should we keep old modules fully functional as before for not breaking current users? | 16:25 |
| mordred | because we can do a name mapping in botmeta | 16:25 |
| gtema | sure we need to test both, but exactly here we need to "rely" on assumption it works both ways without modifying playbook | 16:25 |
| mordred | people getting the modules through symlinks will not be affected | 16:25 |
| dtantsur | mordred: assuming our auth changes won't end up breaking? | 16:26 |
| mordred | and people using collection explicitly will use colledction paths | 16:26 |
| dtantsur | (and assuming we won't need other per-module breaking changes) | 16:26 |
| mordred | dtantsur: well - it's sounding like there's less implicit breaking than we thought before | 16:26 |
| gtema | let's do all breaking as new modules | 16:26 |
| gtema | with a fresh design | 16:26 |
| mordred | so maybe we should figure out what we want to do with auth and see if we can figure out a way to do it non-breaking | 16:26 |
| dtantsur | gtema: the question was whether we need new modules | 16:26 |
| gtema | sure we need | 16:26 |
| mordred | gtema: I don't want two different designs - we don't have enough people working on this to support that :) | 16:27 |
| pabelanger | +1 | 16:27 |
| mordred | we *barely* have enough people to keep the ones we have going | 16:27 |
| gtema | we currently do not have possibility to manage tags, and I do not really want to modify each module with tagging mess | 16:27 |
| dtantsur | at the very least we need to think how to support all session AND adapter options | 16:27 |
| dtantsur | I think we don't do it now | 16:27 |
| mordred | yes | 16:27 |
| * Shrews recalls a recent twitter thread on the pitfalls of rewriting s/w from scratch | 16:27 | |
| mordred | well - we assume for complex options you'll use clouds.yaml | 16:27 |
| mordred | dtantsur: and you can pass a full clouds.yaml yaml snippet to the cloud parameter of the module too | 16:28 |
| sshnaidm | there are some modules like ironic_node that should be redesigned at all | 16:28 |
| dtantsur | I'm talking simple: {auth_type: none, endpoint_override: https://bare.metal} | 16:28 |
| mordred | that said- if we NEED to redesign a module and deprecate the old one - we should totally do that | 16:28 |
| mordred | dtantsur: that should work by passing to cloud: | 16:28 |
| dtantsur | mordred: in cloud.yaml - yes (well.. maybe) | 16:28 |
| mordred | no - in the module | 16:28 |
| mordred | you can pass _anything_ to cloud: that you can put in a clouds.yaml cloud entry | 16:29 |
| sshnaidm | mordred, I'm afraid changes in openstack.py may require redesign in most of modules.. | 16:29 |
| dtantsur | I remember I had some problem. I need to check. | 16:29 |
| mordred | sshnaidm: they might - and we might need to do some things | 16:29 |
| mordred | I think what I'm saying is that it sounds like ansible/ansible is providing mechanisms to make this not an inhernet breaking change | 16:30 |
| mordred | so our ground cover for making additional breaking changes is lower | 16:30 |
| mordred | so we should at least TRY to not immediately make breaking changes | 16:30 |
| sshnaidm | mordred, deprecating old modules gives you more freedom to break things, then trying to keep backward compatibility | 16:30 |
| mordred | we might find something that needs to be changed and we can't figure out non-breaking | 16:30 |
| mordred | and we'll just need to figure out how to not screw our users | 16:30 |
| pabelanger | yes, please for users, don't break things out of gate :) | 16:30 |
| mordred | sshnaidm: it does. but right now we're just supposing | 16:30 |
| mordred | we don't have an actual thing that must be done that must be breakingm | 16:30 |
| mordred | I agree - we can deprecate, we can copy/modiify - do lots of things | 16:31 |
| mordred | let's just do those | 16:31 |
| mordred | and not immediately jump to "upstream is breaking everyone anyway so we're safe" | 16:31 |
| gtema | ok for me | 16:31 |
| mordred | in fact ... OOH | 16:31 |
| pabelanger | +100 | 16:31 |
| mordred | no - neverind- I thought I had a new idea | 16:32 |
| mordred | :) | 16:32 |
| sshnaidm | ok, so what are we agreed on currently? :) | 16:32 |
| mordred | that everyone here is awesome :) | 16:32 |
| gtema | not to break immediately | 16:32 |
| odyssey4me | I expect we'll be wanting to deprecate the dynamic inventory, given that the plugin interface is better anyway? | 16:32 |
| sshnaidm | we continue to develop modules with old names and trying not to break current users? | 16:32 |
| sshnaidm | mordred, ^^ ? | 16:32 |
| mordred | odyssey4me: that's already dprecated? people should be using the plugin and not the script already | 16:33 |
| mordred | sshnaidm: I think ansible/ansible has a solution for name mapping | 16:33 |
| gtema | sshnaidm not to break != continue with old names for new things | 16:33 |
| odyssey4me | mordred: one would hope - I guess we could then remove it from ansible/ansible and not put it into the collection | 16:33 |
| mordred | so I think we *can* rename | 16:33 |
| mordred | we just have to put the name mapping into botmeta in ansible/ansible | 16:33 |
| sshnaidm | it's akward to have same modules with different names, either I don't understand something.. | 16:34 |
| mordred | odyssey4me: you raise a good question ... can the inventory _plugin_ go into the collection too? | 16:34 |
| pabelanger | yes | 16:34 |
| mordred | sshnaidm: let me try to explain from scratch with an example | 16:34 |
| sshnaidm | mordred, can you bring an example of rename? | 16:34 |
| mordred | let's take os_server | 16:34 |
| gtema | technically everything can go into collection | 16:34 |
| pabelanger | gtema: yup! | 16:34 |
| *** lbragstad has joined #openstack-sdks | 16:34 | |
| mordred | we put os_server into our collection, let's call it openstack.api for now (we need to bikeshed on that - but roll with it for a sec) | 16:35 |
| mordred | so then the canonical name of the module ios openstack.api.os_server | 16:35 |
| pabelanger | yes | 16:35 |
| mordred | now - in the ansible/ansible repo there is a yaml file, BOTMETA.yml - and in it we put in an entry like: | 16:35 |
| mordred | openstack.api.os_server: os_server | 16:36 |
| mordred | this will cause ansible, when it builds its distros for pip and whatnot to grab the collection and make a symlink from os_server to openstack.api.os_server | 16:36 |
| mordred | so people who aren't paying attention will have no changes happen to that | 16:36 |
| sshnaidm | yeah, but where is the rename? | 16:36 |
| mordred | hang on | 16:36 |
| mordred | since that is the mechanism, there is then nothing stopping us from renaming the module in our collection to openstack.api.server | 16:37 |
| mordred | and making the mpapping be openstack.api.server: os_server | 16:37 |
| mordred | people using fully qualitied are fine | 16:37 |
| mordred | people using omnibus symlinks are fine | 16:37 |
| mordred | everyone is fine | 16:37 |
| pabelanger | so, if I was do to ansible-galaxy collection install openstack.api I could both do openstack.api.os_server: ... and os_server: ... from playbook | 16:37 |
| mordred | and eventually, in the fullness of time, maybe the synlink mapping goes away | 16:37 |
| mordred | pabelanger: yah | 16:38 |
| sshnaidm | mordred, that exactly what I mean, you install os_server and something new like openstack.api.server and it's the same module exactly | 16:38 |
| pabelanger | without botmeta.yml | 16:38 |
| mordred | pabelanger: right - but that keeps us tied to the old names | 16:38 |
| mordred | botmeta lets us rename in teh collection without screwing people | 16:38 |
| pabelanger | yes, agree | 16:38 |
| pabelanger | so, if we did rename in collection | 16:38 |
| mordred | assuming taht support exists and works - but according to gundalow it's pretty essential that it does | 16:38 |
| pabelanger | actually | 16:39 |
| sshnaidm | can we alert people that use os_server that it will be deprecated? | 16:39 |
| sshnaidm | and not people that use openstack.api.server | 16:39 |
| gtema | I guess they will need to adapt with Ansible 2.12 anyway | 16:39 |
| pabelanger | okay, I need to look on our side, I am not sure how ansible-galaxy collection install reads BOTMETA | 16:39 |
| pabelanger | because, today it doesn't | 16:39 |
| sshnaidm | or we'll be stuck forever with the old names :) | 16:39 |
| mordred | pabelanger: it doesn't | 16:40 |
| pabelanger | okay | 16:40 |
| mordred | this have nothing to do with ansible-galaxy | 16:40 |
| mordred | this is something that is a build-time facility for ansible itself | 16:40 |
| pabelanger | okay, standing by | 16:40 |
| mordred | so when they buikld the wheel for ansible - the build script will grab the collections, suck them in and make symlinks | 16:40 |
| mordred | AIUI | 16:40 |
| pabelanger | right, however people can do ansible-galaxy collection install out side of meta ansible package | 16:41 |
| mordred | sure | 16:41 |
| sshnaidm | I suggest we'll continue in ML about renaming, we're past half meeting | 16:41 |
| pabelanger | in that install case, renames would break playbooks today | 16:41 |
| mordred | ok. let's take this as an action | 16:41 |
| gtema | let's make for safety own links inside of collection | 16:41 |
| sshnaidm | #action sshnaidm to write ML to discuss renaming | 16:41 |
| mordred | I'll cirlce up with gundalow and get to the point where I *completely* understand what the intent is | 16:41 |
| sshnaidm | we have now openstack namespace hosted by mordred | 16:42 |
| mordred | and then write up a summary for us as it relates to us, yeah? | 16:42 |
| sshnaidm | do we want to put all modules in one collection? | 16:42 |
| pabelanger | +1 | 16:42 |
| mordred | yes | 16:42 |
| pabelanger | yes | 16:42 |
| gtema | yes | 16:42 |
| sshnaidm | what would it be? openstack.cloud ? | 16:42 |
| dtantsur | bikeshedding \o/ finally! | 16:42 |
| gtema | weird | 16:42 |
| sshnaidm | and then openstack.cloud.os_server etc | 16:42 |
| mordred | that's a good option. when we did the .well-known support we picked openstack.api | 16:43 |
| dtantsur | I don't dislike openstack.cloud | 16:43 |
| sshnaidm | openstack.api.os_server..? | 16:43 |
| gtema | pabelanger: what is the name for networking? | 16:43 |
| sshnaidm | openstack.ansible ? | 16:43 |
| sshnaidm | I have a lot of ideas :D | 16:43 |
| mordred | I like both cloud and api - I do not like ansible :) | 16:44 |
| dtantsur | same | 16:44 |
| sshnaidm | api sounds weird for me | 16:44 |
| mordred | but - let's make a quick distinction on something | 16:44 |
| pabelanger | gtema: we don't have a meta collection, so we have things like cisco.ios / cisco.iosxr / junpernetwork.junos | 16:44 |
| gtema | ah, ok | 16:44 |
| pabelanger | I am trying to see what aws and google did | 16:44 |
| pabelanger | they might be cloud.google and cloud.aws | 16:44 |
| mordred | no _ I think it's google.cloud | 16:44 |
| sshnaidm | aha | 16:44 |
| mordred | (other way - they have namespaces?) | 16:45 |
| pabelanger | yes, google.cloud | 16:45 |
| pabelanger | https://github.com/ansible-collections/ansible_collections_google/blob/master/galaxy.yml | 16:45 |
| mordred | so let's just do openstackcloud | 16:45 |
| mordred | so let's just do openstack.cloud | 16:45 |
| mordred | yeah? | 16:45 |
| sshnaidm | +1 | 16:45 |
| gtema | ok for me | 16:45 |
| pabelanger | WFM | 16:45 |
| mordred | no need to be different | 16:45 |
| mordred | so - earlier the question was "do we put all of the modules in one collection" | 16:45 |
| gtema | yes | 16:45 |
| mordred | I think the answer is "yes" - as long as we're talking about modules that interact with teh openstack api | 16:46 |
| sshnaidm | #agreed to have one collection as openstack.cloud | 16:46 |
| sshnaidm | ok? ^ | 16:46 |
| mordred | if there is, say, an openstack-ansible or tripleo module that does things like manipulates nova databases or somethingm | 16:46 |
| mordred | then I think that can go into a different collection | 16:46 |
| mordred | yes? | 16:46 |
| pabelanger | +1 | 16:46 |
| gtema | yes | 16:46 |
| dtantsur | ++ | 16:46 |
| sshnaidm | cool | 16:46 |
| sshnaidm | admins to namespace | 16:46 |
| mordred | (in fact, I would expect us to be able to have collections for tripleo/openstack-ansible roles and plugins and stuff) | 16:46 |
| gtema | yes | 16:47 |
| sshnaidm | do we need admins? should it be a zuul? | 16:47 |
| mordred | for the namespace - currently it's tied in to auth things in such a way that it's likelky easiest if it's just infra/zuul who are admins and we just publish through jobs | 16:47 |
| sshnaidm | zuul needs to post updated code to collection afaiu | 16:47 |
| mordred | we'll need to figure that out long term - but it's complicated at the moment, so that would be my suggestion for now :) | 16:48 |
| mordred | yah | 16:48 |
| odyssey4me | As an aside - and excuse my ignorance - but is it possible to unit test modules at all, or are we stuck with only functional tests? | 16:48 |
| mordred | we can write a publication job for that - or reallky just steal the ones pabelanger has already written | 16:48 |
| sshnaidm | mordred, are there admins for specific collections? | 16:48 |
| sshnaidm | pabelanger, gundalow ^^ | 16:48 |
| mordred | odyssey4me: you can totally unit test modules | 16:48 |
| pabelanger | yes, I have a job for that in zuul | 16:48 |
| pabelanger | unit tests is via ansible-test | 16:48 |
| mordred | yeah. it's pretty col | 16:48 |
| mordred | cool | 16:48 |
| odyssey4me | mordred: hooray! I'll have to look into that | 16:48 |
| Shrews | the current openstacksdk tests should likely move to the new project | 16:48 |
| sshnaidm | odyssey4me, yeah, there are examples in ansible repo | 16:49 |
| mordred | sshnaidm: no - to my knowledge it's a namepsace level | 16:49 |
| Shrews | s/tests/module tests/ | 16:49 |
| mordred | Shrews: ++ | 16:49 |
| pabelanger | however, I would love to build some sort of stestr ansible-playbook things, to work with any playbook | 16:49 |
| odyssey4me | thanks - good to know that I have some homework to do :) | 16:49 |
| sshnaidm | I've already have a patch to migrate the job to this repo | 16:49 |
| sshnaidm | ok, let's move on | 16:49 |
| sshnaidm | versioning and branching | 16:49 |
| sshnaidm | we want to keep modules up to date, right? | 16:50 |
| sshnaidm | not as they were in ansible rpeo | 16:50 |
| gtema | no, what for | 16:50 |
| gtema | :D | 16:50 |
| mordred | I don't understand the question? | 16:50 |
| sshnaidm | will we have manual releases as some openstack repos do? or it will be continuous delivery | 16:51 |
| mordred | ah - that's a _great_ question | 16:51 |
| sshnaidm | and should we be tied to openstack releases? | 16:51 |
| mordred | no | 16:51 |
| mordred | that is a for sure no | 16:51 |
| odyssey4me | no tie to openstack releases IMO, and CD would be great IMO | 16:51 |
| mordred | but for the other - I think the intent is for collections to be versioned with semver right? | 16:51 |
| gtema | it's more likely to tie somehow to SDK version | 16:51 |
| Shrews | yeah, ansible users do not want to wait for an openstack release to get a bug fix/feature | 16:52 |
| mordred | yeah - a version of the collection will have a minimum sdk version | 16:52 |
| mordred | but neither of those need to be tied to an openstack release | 16:52 |
| pabelanger | and depend on ansible engine (stdlib / minimal) | 16:52 |
| mordred | so - maybe we start with "tag releases as needed?" | 16:52 |
| elmiko | dtantsur: no worries, i actually missed the start here =( | 16:52 |
| sshnaidm | we won't have branches like ussuri, train, etc, right? | 16:52 |
| pabelanger | mordred: I'd love to see us upload pre-release versions to galaxy | 16:52 |
| dtantsur | elmiko: :) | 16:52 |
| mordred | that's been working pretty will for sdk | 16:52 |
| pabelanger | then tag when want to support it | 16:52 |
| mordred | pabelanger: I mean - I don't know why we'd... can you give me an example of what we'd do with that use case? | 16:53 |
| pabelanger | as, collections are artifacts, not git repos now | 16:53 |
| pabelanger | you need to build the collection, to install | 16:53 |
| sshnaidm | mordred, I'd prefer CD, but with good CI tests for it :) | 16:53 |
| elmiko | dtantsur: fwiw, i say keep using this slot as long as it is useful and productive for the group =) | 16:53 |
| dtantsur | elmiko: cool! I would expect some more times before we settle down on everything | 16:53 |
| mordred | yeah. but like - we don't publish pre-releases of sdk to pypi - we just release all the time - so I want to make sure I understand when we'd maybe need to diverge from that? | 16:54 |
| sshnaidm | mordred, all the time - how often? | 16:54 |
| Shrews | when requested :) | 16:54 |
| mordred | (also - I have no problem supporting uploading pre-releases - that's a great idea - I just want to understand when we'd choose to use that support) | 16:54 |
| mordred | yeah- we can cut 3 sdk releases in a week if we need to | 16:54 |
| sshnaidm | it's almost CD :) | 16:54 |
| mordred | :) | 16:55 |
| gtema | we can do daily, aren't we? | 16:55 |
| sshnaidm | what is the advantage? | 16:55 |
| sshnaidm | then why not every patch | 16:55 |
| mordred | because we have to tag to make a release | 16:55 |
| pabelanger | for me, if I want to use the latest master version of openstack.api, that has to come from galaxy now, not git. Otherwise, there needs to be some process to first build the colleciton to install | 16:55 |
| mordred | and that goes through openstack-release | 16:55 |
| elmiko | dtantsur: yeah, it's all good. the sig office hour is slow, so i think the multiplexing is fine ;) | 16:55 |
| odyssey4me | we could just do a release release whenever there's a change which doesn't match an exception list (docs, tests, etc) - we could then somehow automate whether the increment is major, minor of patch | 16:55 |
| sshnaidm | mordred, I'm just curios if it has some advantages over CD | 16:55 |
| mordred | pabelanger: sure ... I guess what I'm sayuing is - why woudln't we just cut a real release? | 16:55 |
| Shrews | sshnaidm: we have to submit a separate review to release a new version. not quite CD | 16:56 |
| pabelanger | mordred: Yup, that works too. A pre-release just avoids the need for asking | 16:56 |
| mordred | yeah. and some people don't want actual constant upgrades | 16:56 |
| sshnaidm | Shrews, it seems like more maintenance | 16:56 |
| mordred | so we try to just use judgement | 16:56 |
| mordred | it's not a burden on us sdk side | 16:56 |
| pabelanger | odyssey4me: https://github.com/ansible-network/releases/blob/master/ansible_releases/cmd/generate_ansible_collection.py, how we do it today for network | 16:57 |
| mordred | it's been really easy to work with | 16:57 |
| Shrews | sshnaidm: it is the openstack process we've agreed to as an openstack project | 16:57 |
| mordred | I mostly think we shouldn't overcomplicate this until we need to | 16:57 |
| Shrews | ++ | 16:57 |
| gtema | +1 | 16:57 |
| sshnaidm | and not overcomplicating is..? | 16:57 |
| sshnaidm | manual releasing? | 16:58 |
| mordred | we can cut releases whenever - that can be 20 times a week or no releases for 20 weeks - and we can just use our human judgement for a while until we can identify a flaw in that | 16:58 |
| mordred | so we all have a common basis of understanding of the problem we're trying to solve | 16:58 |
| mordred | we can also, similar to openstack, produce master artifacts probably | 16:58 |
| sshnaidm | I'm not against releases, just trying to get the point where it helps | 16:58 |
| mordred | for people who do want to consume CD | 16:58 |
| pabelanger | yes, building the collection isn't difficult | 16:59 |
| mordred | sshnaidm: I'm not sure it helps or hurts - it's just that to actually release semver versioned artifacts on every commit would involve inventing a bunch of new automation and I don't know that effort on that is worth it | 16:59 |
| sshnaidm | ok, so anybody objects to manual releases and want CD only? | 17:00 |
| sshnaidm | #agreed on having manual releases as much as we need | 17:00 |
| gtema | not me | 17:00 |
| dtantsur | sounds good | 17:00 |
| sshnaidm | well, we're out of time | 17:00 |
| dtantsur | yay, thanks all! | 17:00 |
| mordred | woot! | 17:00 |
| pabelanger | mordred: I can share what we are doing in network, atleast as a discussion point. But is also a step towards buildset-galaxy too, not sure if there is interest in that right now | 17:00 |
| sshnaidm | #endmeeting | 17:01 |
| *** openstack changes topic to "Bug tracker for SDK and OSC is now at https://storyboard.openstack.org" | 17:01 | |
| openstack | Meeting ended Thu Dec 12 17:01:07 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.html | 17:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.txt | 17:01 |
| mordred | pabelanger: I want buildset-galaxy the instant we can have it | 17:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-12-16.00.log.html | 17:01 |
| mordred | :) | 17:01 |
| gtema | dtantsur, can I sleep now? | 17:01 |
| dtantsur | gtema: I shall permit that | 17:02 |
| sshnaidm | mordred, I think I'll get my CI job patch on top of yours with modules | 17:02 |
| gtema | thks | 17:02 |
| sshnaidm | mordred, to have it ready for running basic tests for them | 17:02 |
| pabelanger | sshnaidm: how do you plan to run unit tests? | 17:03 |
| sshnaidm | pabelanger, we don't have these afaik | 17:03 |
| sshnaidm | pabelanger, with tox? | 17:03 |
| pabelanger | sshnaidm: this is unit tests? | 17:03 |
| sshnaidm | pabelanger, we have a job that runs functional tests and was running on ansible patches before | 17:04 |
| sshnaidm | pabelanger, I convert it to run on sig repo now | 17:04 |
| pabelanger | yah, that is devstack right? | 17:04 |
| sshnaidm | pabelanger, yep | 17:04 |
| sshnaidm | pabelanger, I didn't see unittests, lemme check in ansible repo.. | 17:05 |
| pabelanger | k, so should be able to just build collection and install, and ansible dev find it | 17:05 |
| pabelanger | using ansible-galaxy | 17:05 |
| Shrews | there were no unit tests, only functional tests | 17:05 |
| Shrews | i wouldn't even know how to unit test an ansible module | 17:05 |
| pabelanger | yah, it is a little messy IMO | 17:06 |
| sshnaidm | yeah, no unit tests | 17:07 |
| sshnaidm | there is a guide in ansible docs | 17:07 |
| Shrews | and the current functional tests are woefully inadequate and hopefully will be improved uon | 17:07 |
| Shrews | upon | 17:07 |
| sshnaidm | https://docs.ansible.com/ansible/latest/dev_guide/testing_units_modules.html | 17:07 |
| sshnaidm | didn't try it yet | 17:07 |
| Shrews | yeah, i know it's possible, i've never had interest to learn how though | 17:08 |
| gtema | mordred: what can you say about https://review.opendev.org/#/c/650374/15/openstackclient/image/v2/image.py@127 | 17:08 |
| pabelanger | no, I wouldn't use ansible-test for unit tests. I would much rather do something like stestr for it | 17:08 |
| pabelanger | ansible-test is very opionioned in that case | 17:08 |
| *** efried is now known as efried_afk | 17:08 | |
| sshnaidm | pabelanger, is it usable for something? | 17:09 |
| sshnaidm | ansible-test I mean | 17:09 |
| sshnaidm | it has a lot of sanity checks I saw | 17:09 |
| pabelanger | we use it for integration testing, in network | 17:09 |
| pabelanger | it works, but is also slow in some cases | 17:09 |
| sshnaidm | pabelanger, can you drop a link please? | 17:09 |
| pabelanger | but not for unit tests for sanity | 17:09 |
| sshnaidm | I'm curios if we can use molecule for tests | 17:10 |
| mordred | Shrews, sshnaidm, pabelanger: perhaps once we're structured a bit more like this: https://review.opendev.org/#/c/698044/ it'll be easier to write "normal" unit tests? | 17:10 |
| pabelanger | molecule uses pytest | 17:10 |
| mordred | or maybe it won't be - who know | 17:11 |
| mordred | knows | 17:11 |
| pabelanger | sshnaidm: https://dashboard.zuul.ansible.com/t/ansible/build/6060fe2d015a4b718f1ab81f59a97a4f is a integration test for network and collections | 17:11 |
| pabelanger | https://github.com/ansible-network/ansible_collections.arista.eos/pull/50 | 17:11 |
| pabelanger | basically, we have a parent job for build-ansible-collection, which creates the artifacts and passed is back into swift (soon galaxy) | 17:12 |
| pabelanger | then ansible-test jobs, fetch collections and ansible-galaxy collection install it | 17:12 |
| pabelanger | to then run ansible-test | 17:12 |
| sshnaidm | mordred, yeah, need to try.. | 17:12 |
| mordred | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/test-upload-logs-swift/library/test_zuul_swift_upload.py | 17:13 |
| pabelanger | I'm not sure I'd try to use molecule... personally, I haven't see much work on ansible side to update it for collections | 17:13 |
| mordred | that's how we unittest modules in zuul-jobs | 17:13 |
| mordred | pabelanger: yah - also molecule seems a bit focused on being able to make test envs for you and stuff- I don't know that it's a great fit here | 17:14 |
| pabelanger | mordred: yah, it would be great to some how loop that into a test runner, for both zuul and local | 17:14 |
| mordred | pabelanger: I think we can do that pretty easily | 17:14 |
| pabelanger | +1 | 17:14 |
| mordred | if you run stestr in zuul-jobs it'll run those unit tests | 17:14 |
| pabelanger | oh, today? | 17:14 |
| pabelanger | nice | 17:14 |
| pabelanger | that is what I want to do for network | 17:14 |
| mordred | yeah | 17:15 |
| mordred | it'll need to be slightly adapter - but it should be mostly cargo-cultable | 17:15 |
| pabelanger | then, even add support for ansible-playbook and inventory file, like we did with zuul functional testing | 17:15 |
| mordred | tests/test_discovery.py is what drives finding the tests to run | 17:15 |
| mordred | ++ | 17:15 |
| pabelanger | ack | 17:16 |
| *** sshnaidm has quit IRC | 17:18 | |
| *** jpena|off is now known as jpena | 17:27 | |
| *** gtema has quit IRC | 17:27 | |
| *** KeithMnemonic has quit IRC | 17:36 | |
| *** dtantsur is now known as dtantsur|afk | 17:37 | |
| *** jpich has quit IRC | 17:37 | |
| *** lbragstad has quit IRC | 17:52 | |
| *** ralonsoh has quit IRC | 18:24 | |
| *** ricolin has quit IRC | 18:24 | |
| *** jpena is now known as jpena|off | 18:36 | |
| *** gmann is now known as gmann_afk | 18:53 | |
| *** mgariepy has quit IRC | 19:08 | |
| *** sshnaidm has joined #openstack-sdks | 19:09 | |
| *** tosky has quit IRC | 19:21 | |
| *** efried_afk is now known as efried | 19:38 | |
| *** KeithMnemonic has joined #openstack-sdks | 20:09 | |
| *** gmann_afk is now known as gmann | 22:29 | |
| *** mriedem is now known as mriedem_away | 23:01 | |
| *** dmellado has quit IRC | 23:09 | |
| *** mriedem_away has quit IRC | 23:10 | |
| *** mriedem has joined #openstack-sdks | 23:11 | |
| *** irclogbot_2 has quit IRC | 23:11 | |
| *** sshnaidm is now known as sshnaidm|off | 23:11 | |
| *** dmellado has joined #openstack-sdks | 23:11 | |
| *** irclogbot_0 has joined #openstack-sdks | 23:12 | |
| *** slaweq has quit IRC | 23:30 | |
| *** slaweq has joined #openstack-sdks | 23:34 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!