OpenStack uses paste.openstack.org all the time, and I've heard issues with how long content is stored there.
On Wed, Aug 27, 2014 at 12:45 PM, Aleksandra Fedorova < afedor...@mirantis.com> wrote: > > I can not find the policy about how long data is stored there, but I doubt > that pastebin service can be used as a longterm storage. If we don't want > to lose logs and scripts data, the use of paste.o.o links for bug reports > should be forbidden. > > Launchpad attachments are much more reliable even though less comfortable > to use. > On Aug 27, 2014 8:49 AM, "Mike Scherbakov" <mscherba...@mirantis.com> > wrote: > >> +1 on updating bug descriptions (not comments) about probability of >> failure, and using paste.openstack.org more often. >> >> >> On Wed, Aug 27, 2014 at 3:41 AM, Dmitry Borodaenko < >> dborodae...@mirantis.com> wrote: >> >>> On Tue, Aug 26, 2014 at 12:11 AM, Mike Scherbakov >>> <mscherba...@mirantis.com> wrote: >>> > "confusing versioning in OpenStack patching" - if we didn't change >>> puppet >>> > manifests and Fuel/OpenStack reference architecture in next Fuel >>> versions, >>> > then it would be as simple as patching from 5.0 to 5.1. But it >>> appeared to >>> > be more complicated system than you would initially think of, so in >>> general >>> > 5.0.2 may not be equal to 5.1, that's where all things come up. If we >>> had >>> > OpenStack upgrades, then we could just say 5.0 -> 6.0 - easy. >>> >>> We may have had technical reasons to make this decision, but it still >>> is confusing and negatively impacts UX. I agree that having an >>> incomplete feature early is better than not having it at all until >>> much later, as long as we don't stop working on it until it's complete >>> and these small but annoying deficiencies are addressed. Our >>> experience with technical debt so far is not very reassuring. >>> >>> > "issues with containers" - we have same issues with everything. Let's >>> take >>> > Galera, for example. It's just issues. We can question maturity of >>> tools we >>> > use, and here I'd agree - we spent too much fixing issues around >>> Docker. At >>> > the same time, if we were about taking our own journey with LXC, we >>> would >>> > likely spend even more time inventing our own bicycle. >>> >>> You're assuming that it was just Docker as a piece of software that is >>> the primary cause of all our troubles with Fuel upgrades. Docker is >>> only a small part of the a much large and much more intrusive design >>> decision to use containers for upgrading Fuel (and also the design >>> decision to use a different mechanism based on Puppet for patching >>> OpenStack). I think we should question high-level design decisions >>> like these more often, even after they are implemented. >>> >>> > Also, I'd like to ask everyone to provide >>> > such information in every bug you report if possible (or if get this >>> info >>> > later, put comments): in many bug reports it is unclear to understand >>> how >>> > severe issue is. >>> >>> I think we should start updating bug description more often, so that >>> you can find a summary of current state of the bug and of all relevant >>> information from the description, without having to scroll through >>> dozens of comments. We should also use paste.openstack.org more >>> heavily and avoid pasting more than 1-2 lines of logs into bug >>> description and comments, also to make it easier to find important >>> bits in bugs history. >>> >> >> >> >> -- >> Mike Scherbakov >> #mihgen >> >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : fuel-dev@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp >> >> -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp