| === benonsoftware is now known as bdunn | ||
| === bdunn is now known as benonsoftware | ||
| === benonsoftware is now known as MerryChristmas | ||
| === MerryChristmas is now known as benonsoftware | ||
| lazypower | rick_h_, ping | 14:52 |
|---|---|---|
| lazypower | urulama, or if you have a moment, ping | 14:52 |
| rick_h_ | lazypower: what's up? | 14:52 |
| rick_h_ | lazypower: standup starts in 8 but got a sec until that call starts | 14:53 |
| urulama | lazypower: pong | 14:53 |
| lazypower | https://bugs.launchpad.net/charms/+bug/1459555 - this is a CPP submission, their charms have landed but they depend on /next branches of the openstack charms | 14:53 |
| mup | Bug #1459555: PLUMgrid charms bundle review required <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1459555> | 14:53 |
| lazypower | we dont typically promote this, but this also directly reflects their presence at ODS Tokyo, they've been fatigued already by being asked to rewrite their charm suite once, and this has been a 7 month process - is there anything we can do to accomodate them in this extraneous circumstance? | 14:54 |
| rick_h_ | lazypower: I'm not following. What's the actual issue that's blocking? | 14:54 |
| lazypower | rick_h_, that its pointing to non /TRUNK branches of charms | 14:55 |
| lazypower | (not theirs, the openstack components) | 14:55 |
| rick_h_ | lazypower: so in looking 1: they're fixing, 2: they're fixing, 3: ... | 14:55 |
| rick_h_ | lazypower: oh, the bundle uses non-trunk versions so they're not in the store? | 14:55 |
| rick_h_ | lazypower: so a couple of paths: 1) they vendor the next charms into their namespace as /trunk and use those for the bundle | 14:56 |
| lazypower | right, the plumgrid charms are. they did everything required to land those. There were modifications to openstack itself to support them, and those ar ein /NEXT until end of next month when the OS charms promulgate | 14:56 |
| rick_h_ | lazypower: 2) they go the local deploy route and use deployer | 14:56 |
| rick_h_ | lazypower: we can't pull in non-trunk charms. It requires code/changes to charmstore and means every dev branch would be ingested killing the store | 14:56 |
| rick_h_ | lazypower: so we have to find some path that pulls the charms they need into the store through a normal path. | 14:57 |
| lazypower | ok, so the preferred method would be to "fork" those openstack charms into the plumgrid-team namespace, update the bundle w/ those paths, and we can then push those | 14:57 |
| lazypower | once the /next branches land, they nuke those charms and update the bundle to point at ~recommended charms? | 14:57 |
| rick_h_ | lazypower: yes, vendor them for now until the OS ones move up and then update the bundle to point to the approved ones. Else go local deploy | 14:57 |
| rick_h_ | lazypower: which if they're doing demo stuff at ODS they should probably do anyway | 14:58 |
| rick_h_ | lazypower: in case of charmstore lag/network connectivity issues | 14:58 |
| rick_h_ | lazypower: and if they want folks to use it at ODS, the OS charms will be updated by then correct? | 14:58 |
| lazypower | i dont know if the OS charm release will be before ODS Tokyo | 14:58 |
| rick_h_ | lazypower: yea, I mean you're kind of asking us to get dev charms into teh store for folks to see/use before they think they're ready for folks to see/use? | 14:59 |
| lazypower | Oh I wasn't asking if you could rewrite the charm store - i just kno we dont do this and was asking for a recommended path forward for them so a) they get a nice concise handout for consumers @ their booth b) we dont further fatigue them with our process | 15:01 |
| lazypower | so it was more for a work around for the month they will be in limbo while /next branches land | 15:01 |
| rick_h_ | lazypower: understood, yea the vendoring would be the best thing I can suggest, but they should make clear these are non-final/ready OS branches folks really shouldn't use | 15:01 |
| lazypower | Ack, thanks for the clarification rick_h_ | 15:02 |
| rick_h_ | lazypower: one good note is that with bundles landing in core we're working on a path that would allow local bundles to include a local copy of charms as well | 15:02 |
| rick_h_ | lazypower: so we'll be closer to something nicer for a dev/one off case like this...in a few months :/ | 15:02 |
| lazypower | ack - its not a terrible story where we are right now, its just unfortunate that their timing always seems to coincide with bad news | 15:04 |
| rick_h_ | lazypower: agreed, wish I had something better. | 15:04 |
| lazypower | rick_h_, this was a pretty specific issue - but i was just re-clued into this being a thing - https://jujucharms.com/u/openstack-charmers-next/ so we may be able to circumnavigate any issues with these branches :) | 15:25 |
| rick_h_ | lazypower: ah ok | 15:27 |
| rick_h_ | lazypower: even better | 15:27 |
| rick_h_ | lazypower: along those lines it falls a bit into https://docs.google.com/document/d/19ndRpWSojtv6kyokeppnRE0MFEMFqd69XeAXp72jBdo/edit if you've got time to read/feedback | 15:29 |
| rick_h_ | lazypower: e.g. the development channel | 15:30 |
| lazypower | will do :) | 15:30 |
| rick_h_ | lazypower: please let me konw when you poke at thata bundle. It's a known issue we've not been able to get past atm. If that doesn't work then maybe there's another bug I'm not seeing. | 19:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!