No, I'd suggest that Drydock fail (and clean up resources used by failed builds immediately) instead of deadlocking.

So you'd suggest that we encourage Drydock users to configure limits in excess of available resources ("not wear a seatbelt") to improve error behavior when they configure a deadlock ("fall in the ocean")? If so, wouldn't it be better to simply remove the limits entirely ("uninstall seatbelts from cars") so that they can't accidentally configure a limit with bad behavior?

If you drive without a seatbelt, it will be easier to escape from your vehicle when it becomes submerged in the ocean.

I've reproduced the first issue with the lease breaking but not being released. Here's what I did:

If you drive without a seatbelt, it will be easier to escape from your vehicle when it becomes submerged in the ocean.

I believe there's another deadlock issue here as well though, say 10 builds start with the following plan:

For example, suppose we have perfect resource reclamation and reuse algorithms which always instantly destroy a resource the moment it is no longer in use.

The recommended solution for T9875 is to set a limit lower than "available disk space / size of largest repository", which reduces it to this deadlock issue.

T9875 is different to this. This discusses leases being deadlocked, whereas T9875 is there not being enough storage space on the host to hold copies of all working copies + build artifacts at once.

Broadly, two issues here:

I didn't tag it properly, but D14812 resolved this.

This does not describe a bug with the upstream. We do not have the resources to investigate or fix problems which begin with "apply <large amount of custom code>". See also T5447.

That is, I changed the configuration to fix things on this install; the new task details describe fixing the root issue.

This was a configuration issue which permitted configuring a currently-invalid mixture of "Space" and "View Policy" visibility.

@epriestley I sure hope there's a badge for whoever creates T10000...

Verified! You guys rock!

This should be fixed in HEAD. Let us know if you're still seeing issues or we missed anything.

Even if it's not an everyone has a blog case, again, I can't imagine it's a common use case to regularly be switching blogs to post on. Again, this is just a convenience function (a "New Post" button that creates a new post for the last-posted-to-blog). Not required, just a nice to have.

Ah ok, I don't think we've considered the "everyone has a blog" case. It might get hairy.

Oh cool - that's a useful shortcut. But imagine that the primary use case is this sort of note taking where everyone has their personal blog, I anticipate that 95% of the time, people will be writing blog posts on the same blog they last wrote on. For the 15 people on our team, 100% of us only write on one blog which is our personal blog.

The + is a link to create new posts, may not be 100% obvious.

The only feedback I have is that since the "New Blog" button was added top Right (instead of, for example, "New Post" which would default to, say, the last blog that you posted to), I inadvertently created a new Blog when I meant to write a post.

Sounds like you're using it as we do, though.

Well we're about to unbeta Phame if you have any use cases we're not thinking of.

As an aside, if you guys ever want insight from heavy Phab users, let me and Nico know! We're so deeply integrated now...we even automate the creation of Phab tasks via Salesforce to manage our entire Client Services team's work flow to onboard new clients. :)

Awesome :) yes, I don't see any of us caring about the slugs. In fact I remember it being a bit of a nuisance to do this because we'd have 15 people all with the slug of, for example, 12/10/2016, so we'd all have to make them unique. :)

ah, true

Since slugs no longer need to be unique, I'm just going to simplify this whole process and generate them automatically from titles.

We don't have external references to Phame, only internal references within Phame itself. So no need to have the old urls work in that regard. It's just that clicking the links in the phame UI itself is an important piece we'll need to work.

Also, is the fact that the URL scheme changed an issue (i.e., do you have a lot of links to the old URLs in external systems)? We weren't aware anyone was really using Phame seriously, but I can write a little extension you could use to keep the old redirects working for a while if that's also causing you pain.

(the reason this issue is exacerbated for us is because the titles of all our posts are dates, which many folks use /'s for, so we have a ton of posts with this issue)

Yeah it's a critical part of our workflow :) back at Google there's this concept of "weekly snippets" that the whole company used to use and our engineering team here at Doctor.com models after that. It's really useful to get visibility into work. :)

We could also just bring that patch upstream, but I think allowing "/" in slugs is probably a decision we'd regret in the long term.

As a workaround, you can apply this patch locally, which should make things work for now:

I am stoked someone uses Phame though!

(maybe we can hack the route?)

I don't know how involved a migration script would be, @epriestley?

You can use the URL /phame/post/edit/775/

@chad Hi Chad, so how can we remove it if we can't edit the post? Is there a workaround to edit the post? Or some manual database change we can make? We have literally hundreds of blog posts as we use this feature internally to track weekly work (hence the urgency as now our entire company has lost visibility into each other's work), so it would be a nightmare to do manually...

You'll need to edit your title phame_title to fix the 404 for now (I don't think it's worth providing a retroactive fix). We should have always been removing / from Phame Title as it would have always 404'd with Live View.

It looks like it counts the total working copies. I thought the limit is for every single repo: when I set the the limit to be 5, I expect that every single repo can have 5 copies at most. This is not scalable: when more and more repos get created, we have to adjust the limit.

Also why can't a new lease get another resource when previous lease holds a resource? I set the limit of the working copy to be 5, so there should be enough resources available to be used.

w00t w00t, I got something out of this bug report after all!

I inducted you into Community so you should have sweeping editorial powers once again.

I don't have a shell alias, but I do have a wrapper script around arc. Doh! I totally forgot about that. Sorry for the false alarm.

I can't reproduce this:

In T9986#149260, @chad wrote:

Afterwards I clicked on Create Task and it worked, it did not give me any other error.

Where, specifically. "Create Task" is a permission-locked form on this install.

Afterwards I clicked on Create Task and it worked, it did not give me any other error.

Not sure what you mean. Afterwards I clicked on Create Task and it worked, it did not give me any other error.

This is correct, only Community members can directly create tasks.

I had the same issue, it seems related to T9908.

This does not appear to describe a bug in Phabricator. See Contributing Bug Reports.

In T9986#149208, @joshuaspence wrote:

Can you provide steps on how to reproduce this bug, it's not clear from your report. See Contributing Bug Reports.

Can you provide steps on how to reproduce this bug, it's not clear from your report. See Contributing Bug Reports.

That's expected, you disabled the form for creating other forms.

@epriestley I hit this again. These are some stats from SSHing into the machine:

After some digging I found the problem.

Did a new test install. I could reproduce it.

Can you show me what you see at this path (replacing the domain with your domain)?

Can you show me exactly what version you're running, by navigating to Config → Versions?

D14783 fixes the second exception.

What version of Phabricator are you running?

After an exception

Just an update:

Broadly, if you're using arc land --hold <feature> to preview changes, there are three ways to proceed:

I'm not open to reverting to the old behavior. The new behavior solves a large number of problems for many users, discussed in T9657.