=== Guest44232 is now known as zz_Guest44232
[07:51] <jamespage> gnuoy, based on your +1 of my wily python bootstrap fix yesterday, are you ok for me to land the same change across all of the charms with appropriate unit/lint/amulet +1's?
[07:51] <jamespage> I could give you all of the MP's but there are quite a few
[07:51] <gnuoy> jamespage,RS +1 for the rest
[07:51] <jamespage> gnuoy, ta
[07:51]  * jamespage goes todo some landing
=== natefinch-afk is now known as natefeinch
=== natefeinch is now known as natefinch
[14:04] <jamespage> thedac, coreycb, ddellav, gnuoy: working through action upgrade landings pm today
[14:05] <coreycb> jamespage, ah great thanks
[14:06] <coreycb> jamespage, wolsen's been reviewing too. note that we can't call register_configs() in the action, we need to import CONFIGS instead so some of the mp's need updates.
[14:07] <jamespage> coreycb, so like - https://code.launchpad.net/~thedac/charms/trusty/swift-storage/action-managed-upgrade/+merge/272046
[14:07] <jamespage> that's ok right?
[14:07] <coreycb> jamespage, yep that one's good
[14:15] <jamespage> coreycb, ok - I still see some ones need updating
[14:28] <thedac> jamespage: swift-storage is good. The rest of mine still need fixing. I got stuck yesterday on nova cc. I can't quite figure out what I need to mock to allow importing of the openstack_upgrade. I may skip this one and get the others ready.
[14:29] <jamespage> thedac, ack - and where did you guys get to last week on service status stuff?
[14:29] <jamespage> (just catching up)
[14:30] <thedac> The CH bits are landed. And I demonstrated to our team but no further. Action upgrades was the priority
[14:38] <thedac> openstack-dashboard should be good now
[14:41] <thedac> and neutron-gateway should have started with those. :) Now back to the grind with nova cc
[16:10] <thedac> jamespage: nova-cloud-controller done. I finally looked at the git_install example which layed out exactly what I needed. :p
[17:19] <cholcombe> anyone know if you can deny juju storage from detaching a disk?
[17:20] <rick_h_> cholcombe: hmm, does storage support blocks?
[17:21] <cholcombe> i have no idea
[17:21] <cholcombe> i'm thinking when a disk is being detached i might want to prevent it until i know it's safe
[17:22] <cholcombe> rick_h_, if i'm down to 2 out of 3 disks in my replica set and another disk is being detached i want to stop that
[17:22] <cholcombe> rick_h_, that reminds me i need to create another task for myself
[17:22] <rick_h_> cholcombe: if you could it would be a block https://jujucharms.com/docs/1.24/juju-block
[17:23] <rick_h_> cholcombe: I just noticed I don't have the PPA and 1.25 on this machine thuogh so not able to test that list out
[17:23] <cholcombe> i'm running 1.24.x
[17:23] <rick_h_> cholcombe: if not, might be worth a juju email thread.
[17:23] <rick_h_> alexisb: ^
[17:24] <rick_h_> cholcombe: yea, storage is a feature flag in 1.24 though right?
[17:24] <cholcombe> rick_h_, thanks.  If we can block that will prevent possible disasters
[17:24] <cholcombe> rick_h_, i believe so
[17:25] <rick_h_> cholcombe: yea, not seeing it in the list and it's not part of the general config block-able stuff https://jujucharms.com/docs/1.24/config-general#alphabetical-list-of-general-configuration-values
[17:25] <alexisb> cholcombe, there were many improvements to storage in 1.25
[17:25] <alexisb> cholcombe, I can send you a list
[17:26] <alexisb> and your best expert on this is axw
[17:26] <rick_h_> cholcombe: alexisb I think the question is does storage support or plan on supporting blocks on it
[17:26] <cholcombe> alexisb, ok yeah i was chatting with him last night.  he's on aussy time
[17:26] <cholcombe> alexisb, i'll see if i can catch him later today
[17:26] <rick_h_> cholcombe: if you chat with him let me know what you find out
[17:27] <cholcombe> rick_h_, will do :)
[17:27] <cholcombe> rick_h_, this will necessitate functions to tell whether it's safe to remove a disk.  That's tricky with ceph
[17:27] <rick_h_> cholcombe: well what would happen is yo'd block it and if someone tried to do something that killed it it would stop and say no
[17:28] <rick_h_> cholcombe: and you'd have to manually remove the block to continue
[17:28] <cholcombe> right
[17:28] <cholcombe> rick_h_, it's best effort right?  people can still just yank the disk
[17:28] <rick_h_> cholcombe: yes, this is all only within juju
[17:28] <firl> Any openstack charmers on?
=== scuttlemonkey is now known as scuttle|afk
[17:29] <marcoceppi> firl: there are dozens of us! I'm not one, but I'm dangerous enough to answer questions. Best to just ask
[17:29] <firl> haha thanks marcoceppi
[17:29] <firl> I specifically want to branch / know the best way of getting mellanox support into the trusty/juno stack for neutron,nova, and ceph
=== scuttle|afk is now known as scuttlemonkey
[17:33] <marcoceppi> firl: well first off, all the core openstack charms are the same codebase, so the charms in trusty, vivid, precise, wily, etc are the same and that same code base models strategies for Icehouse -> Liberty
[17:34] <firl> it’s all in bazaar too?
[17:34] <marcoceppi> firl: the development workflow is modeled here: https://wiki.ubuntu.com/ServerTeam/OpenStackCharms
[17:35] <marcoceppi> firl: it's all in bzr atm, but they are moving to include the charms in git, not sure the process of that beisner coreycb jamespage ^?
[17:36] <firl> thanks marcoceppi for the link, I don’t know the best way to integrate the mellanox side. I figured I would just make it a boolean config value with sane defaults to start
[17:37] <coreycb> firl, marcoceppi: james is working on moving the charms to git but I don't think we're there yet.  so I'd use bzr for now.
[17:37] <firl> kk
[17:38] <coreycb> firl, jamespage or gnuoy would be best to ask about mellanox but you might need to hit them up earlier tomorrow since they're probably EOD now
[17:38] <firl> gotcha
[18:29] <marcoceppi> bcsaller cory_fu I've got some questions about the charm gen/layers stuff around best practices
[18:29] <cory_fu> Sure
[18:29] <bcsaller> go for it
[18:29] <bcsaller> I am sure there are some things we can do to make it easier
[18:30] <marcoceppi> bcsaller cory_fu so this is my first stab https://github.com/marcoceppi/mysql-charm-layer
[18:31] <marcoceppi> one thing I tried to do was create a helpers directory in the reactive dir to house my charm specific code that I didn't want cluttering my mysql.py file in reactive
[18:31] <marcoceppi> but that didn't work for imports, so I put it in lib/helpers, though I can see this as being potentially a problem/conflict
[18:32] <marcoceppi> so I was curious if there was a pattern already for where to house this code, the idea being that they're generic MySQL helpers (install_mysql, create_database) that other layers could utilize via importing
[18:32] <marcoceppi> there are almost things that were once in charmhelpers.contrib.mysql actually
[18:33] <cory_fu> I think lib makes sense, then.  Maybe lib/helpers/__init__.py could be created in base, if that's a common namespace, though you could also have used mysql_helpers
[18:34] <marcoceppi> I despise underscores in general, so I just used a directory to namespace, but to your point I could creaet mysql_helpers.py in lib?
[18:34] <bcsaller> marcoceppi:  off the top of my head there are a few ways this could play out. One, we talked about namespaces for newer charm helpers, so they can be different repos but still packaged and pushed to pip. I that case you might add a pip import trigger to your layer in /lib for example
[18:34] <bcsaller> marcoceppi: you can see the base layer does this to include its deps
[18:35] <bcsaller> I wouldn't mind if CH made its own namespace and other packages added to that
[18:35] <marcoceppi> bcsaller: I did see that, these aren't actually in the contrib library, and while somewhat generic they are verioned/released with the layer which is why I opted to have it as an included dep
[18:35] <bcsaller> ahh ok
[18:35] <marcoceppi> embeded*
[18:36] <cory_fu> marcoceppi, bcsaller: We could certainly have a lib/charms/ namespace directory in base so that layers could easily add packages to that namespace without creating a separate, external library
[18:36] <bcsaller> cory_fu: or allow layers a helper that could help adjust the python path, but that might be too much
[18:36] <marcoceppi> cory_fu: so I could just have lib/charms/mysql ? alongside reactive?
[18:36] <cory_fu> Right
[18:36] <marcoceppi> that sounds interesting
[18:37] <cory_fu> Actually, with how the libs are pulled in from pypi, I don't think we'd even need to change the basic layer
[18:38] <cory_fu> I think it would probably just work if you created those folders in your mysql layer
[18:38] <bcsaller> yeah, it should
[18:38]  * marcoceppi tries that
[18:39] <cory_fu> marcoceppi: So, just change lib/helpers to lib/charms and drop lib/helpers/__init__.py
[18:40] <marcoceppi> cory_fu: I mean, it worked
[18:40] <marcoceppi> let me change the import calls and deploy
[18:42] <marcoceppi> I love charm inspect
[18:42] <bcsaller> cool
[18:43] <cory_fu> I would love it more if we could get it to work with paging (e.g., less) ;)
[18:43] <cory_fu> Even if the paging was built-in
[18:43] <marcoceppi> bcsaller cory_fu yeah, that worked great, upgrade charm ran cleanly so new imports worked etc
[18:43] <marcoceppi> not sure if we want to document that as a best practice or not?
[18:43] <bcsaller> cory_fu: I could patch that I think, blessings does tty detection (which less fails) but you can disable that
[18:44] <cory_fu> bcsaller: Maybe a "--force-color" option that disables the auto-detect?
[18:44] <bcsaller> yeah, I can look into that
[18:44] <cory_fu> marcoceppi: I think that seems like a good practice, yeah
[18:44] <marcoceppi> cory_fu bcsaller I also noticed there are some patches in 1.6 branch for compose not released, should those be another patch release?
[18:45] <marcoceppi> or do youy have more you wish to land first?
[18:45] <bcsaller> marcoceppi: there will have to be, one is an important bug fix, but we still might want to wait for the bikeshed on naming to resolve
[18:46] <bcsaller> marcoceppi: I have a branch with the current naming in it, but I will also try to make inspect page better, we'll call it minor papercuts
[18:48] <cory_fu> bcsaller: Is the bike-shedding not already resolved from on-high?  ;)
[18:48] <cory_fu> bcsaller: And at any rate, just make aliases
[18:49] <marcoceppi> yes, aliases with "deprecation" notice? and then never deprecate
[18:49] <bcsaller> they are just aliases in setup.py now
[18:49] <marcoceppi> you never truly finish bikshedding
[18:50] <bcsaller> https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality but I do agree names can be important
[19:42] <wolverineav> hey, this is openstack keystone related query - for HA, it mentions this: "VIP is only required if you plan on multi-unit clustering (requires relating with hacluster charm). The VIP becomes a highly-available API endpoint."
[19:42] <wolverineav> i don't know what is the hacluster charm in this context. is it 'haproxy'?
[19:44] <rick_h_> wolverineav: https://jujucharms.com/hacluster/
[19:45] <wolverineav> ah, thanks rick_h
[19:45] <rick_h_> wolverineav: np, good luck!
[19:46] <wolverineav> somehow when you search 'hacluster' in charmstore, this one is not in the top 10
[19:48] <rick_h_> wolverineav: ah, it's not fully gone through the review process so it's demoted.
[19:48] <rick_h_> wolverineav: I'll look into that. thanks for the heads up
[19:49] <wolverineav> rick_h_: that explains it :)
=== natefinch is now known as natefinch-afk
=== zz_Guest44232 is now known as CyberJacob
=== CyberJacob is now known as zz_CyberJacob