[openstack-dev] [tc][packaging][deb] retiring Packaging Deb project

[Allison Randal]

Hi all,

The Debian OpenStack packagers are gathered at the annual Debian
developer event, and discussing the future of OpenStack packaging for
Debian. There's general agreement that we'd like to go ahead and package
Pike, but also agreement that we'd like to move back to the Debian
infrastructure for doing packaging work. There are a variety of reasons,
including that:

- Using the familiar Debian workflows and infrastructure is a better way
to attract experienced Debian developers to the work, and

- The way we set up the Debian packaging workflow on OpenStack Infra was
a temporary compromise, and not really a good fit for OpenStack Infra
(or for Debian).

As a result of the change, we'd like to retire the Packaging Deb
project in OpenStack, and there will be no candidate running for Queens
PTL for the project. There will be some cleanup work to do, around
deb-* repos and other aspects of the Debian packaging workflow we set up
with OpenStack Infra, following the standard retirement procedures:

https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

The OpenStack installation tutorial for Debian will remain in OpenStack,
and we'll update it for Pike.

If you have any concerns about the retirement, please let us know
(especially other distros that use .deb format packages), we'll wait a
bit for feedback before moving ahead with the cleanup.

Thanks,
Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PKG-Openstack-devel] The end of OpenStack packages in Debian?

[Allison Randal]

On 02/24/2017 06:25 AM, Ritesh Raj Sarraf wrote:
> rtslib-fb is a core component for the LIO(-fb) project. We already maintain
> configshell-fb and targetcli-fb under pkg-linux-target group.

Nod, that makes sense. I'd say you should take on maintenance of the
rtslib-fb packages, as long as you're willing to integrate with the
global Debian Python transitions and policy, and to handle the fact that
other projects (like the OpenStack Debian packagers) also use the
module. For OpenStack, we may occasionally need to update the rtslib-fb
packages to specific versions for compatibility with specific OpenStack
releases.

Allison



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Allison Randal]

On 02/21/2017 12:57 PM, Ritesh Raj Sarraf wrote:
> Hello Thomas,
> 
> Sad to see this. But with so much free loading trend, these are bound to 
> happen.
> 
> For the LIO-fb target in Debian, we've been depending on the rtslib-fb 
> package,
> which you've maintained so far. Should we pick it up under the 
> pkg-linux-target
> team ?

Hi Ritesh,

For the sake of consistency, it probably makes more sense to maintain
rtslib-fb within the Debian Python Modules Team. If you'd like to chat
in more detail about which Debian team is the best fit, we can narrow
this thread down to just the PKG OpenStack mailing list.

Thanks,
Allison



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Allison Randal]

On 02/15/2017 07:42 AM, Thomas Goirand wrote:
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).

I'm happy to volunteer for this. TBH, my goal would be to minimize the
delta on these packages to Ubuntu's versions of the packages, so we can
maintain them collaboratively. But, there's certainly no need to drop
the packages from Debian.

> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
> 
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar

These are more "nice to have" packages, not really critical. We can ask
around to see if anyone is using the packaged versions, but if not we
should just drop them from Debian.

> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.

Canonical doesn't have a large team for this work, but I imagine we can
handle it just fine between their team and a few volunteers.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][survey] open source collaboration practices

[Allison Randal]

Hi all,

I’m running a brief (10 question) survey on the collaboration practices
common to companies participating in open source today. I’d greatly
appreciate a moment of your time to share your experience:

https://www.surveymonkey.com/r/os-participation

This survey is part of my academic research, and not related to my
affiliation with any other employers, foundations, or projects. I’m
capturing company names for the purpose of statistical correlation, but
will anonymize these to unidentifiable numbers in the data published
with the research.

Thanks,
Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

[Allison Randal]

On 04/11/2016 02:51 PM, Fox, Kevin M wrote:
> Yeah, I think there are two places where it may make sense.
> 
> 1. Ironic's nova plugin is a lowst common denominator for treating a
> physical host like a vm. Ironic's api is much more rich, but sometimes
> all you need is the lowest common denominator and don't want to rewrite
> a bunch of code. In this case, it may make sense to have a nova plugin
> that talks to magnum to launch a heavy weight container to make the use
> case easy.
> 
> 2. Basic abstraction of Orchestration systems. Most (all?) docker
> orchestration systems work with a yaml file. What's in it differs, but
> shipping it from point A to point B using an authenticated channel can
> probably be nicely abstracted. I think this would be a big usability
> gain as well. Things like the applications catalog could much more
> easily hook into it then. The catalog would provide the yaml, and a tag
> to know which orchestrator type it is, and just pass that info along to
> magnum.

The typical conundrum here is making "the easy things easy, and the hard
things possible". It doesn't have to be a choice between a) providing a
rich API with access to all the features of each individual compute
paradigm, and b) providing a simple API that allows users to request a
compute resource of any type that's available in the public/private
cloud they're interacting with. OpenStack can have both.

The simple lowest common denominator interface would be very limited
(both by necessity and by design), but easy to understand and get
started on, making some smart assumptions on common usage patterns. The
richer APIs are there for users who need more power and flexibility, and
are ready to go beyond the easy on-ramp.

Again, nothing new here, it seems to be the direction we're already
heading. I'm just articulating why.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

[Allison Randal]

> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas  wrote:
>> Reading unofficial notes [1], i found one topic very interesting:
>> One Platform – How do we truly support containers and bare metal under
>> a common API with VMs? (Ironic, Nova, adjacent communities e.g.
>> Kubernetes, Apache Mesos etc)
>>
>> Anyone present at the meeting, please expand on those few notes on
>> etherpad? And how if any this feedback is getting back to the
>> projects?

It was really two separate conversations that got conflated in the
summary. One conversation was just being supportive of bare metal, VMs,
and containers within the OpenStack umbrella. The other conversation
started with Monty talking about his work on shade, and how it wouldn't
exist if more APIs were focused on the way users consume the APIs, and
less an expression of the implementation details of each project.
OpenStackClient was mentioned as a unified CLI for OpenStack focused
more on the way users consume the CLI. (OpenStackSDK wasn't mentioned,
but falls in the same general category of work.)

i.e. There wasn't anything new in the conversation, it was more a matter
of the developers/TC members on the board sharing information about work
that's already happening.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Allison Randal]

On 02/22/2016 10:31 AM, Monty Taylor wrote:
> On 02/22/2016 07:24 AM, Russell Bryant wrote:
>> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote:
>>
>> Hi everyone,
>>
>> TL;DR: Let's split the events, starting after Barcelona.
>>
>>
>> This proposal sounds fantastic.  Thank you very much to those that help
>> put it together.
> 
> Totally agree. I think it's an excellent way to address the concerns and
> balance all of the diverse needs we have.

+1

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[Allison Randal]

On 06/15/2015 01:43 PM, Paul Belanger wrote:
 While I agree those points are valid, and going to be helpful, moving
 under OpenStack (even Stackforge) does also offer the chance to get more
 test integration upstream (not saying this was the original scope).
 However, this could also be achieved by 3rd party integration too.

Nod, 3rd party integration is worth exploring.

 I'm still driving forward with some -infra specific packaging for Debian
 / Fedora ATM (zuul packaging). Mostly because of -infra needs for
 packages. Not saying that is a reason to reconsider, but there is the
 need for -infra to consume packages from upstream.

I suspect that, at least initially, the needs of -infra specific
packaging will be quite different than the needs of general-purpose
packaging in Debian/Fedora distros. Trying to tightly couple the two
will just bog you down in trying to solve far too many problems for far
too many people. But, I also suspect that -infra packaging will be quite
minimal and intended for the services to be configured by puppet, so
there's a very good chance that if you sprint ahead and just do it, your
style of packaging will end up feeding back into future packaging in the
distros.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[Allison Randal]

On 06/15/2015 11:48 AM, Thomas Goirand wrote:
 On 06/15/2015 04:55 PM, James Page wrote:
 The problem of managing delta and allowing a good level of
 distribution independence is still going to continue to exist and will
 be more difficult to manage due to the tighter coupling of development
 process and teams than we have today.

 On this basis, we're -1 on taking this proposal forward.

 That said, we do appreciate that the Ubuntu packaging for OpenStack is
 not as accessible as it might be using Bazaar as a VCS. In order to
 provide a more familiar experience to developers and operators looking
 to contribute to the wider Openstack ecosystem we will be moving our
 OpenStack packaging branches over to the new Git support in Launchpad
 in the next few weeks.
[...]
 During our discussions at the Summit, you seemed to be enthusiastic
 about pushing our packaging to Stackforge. Then others told me to push
 it to the /openstack namespace to make it more big tent-ish, which
 made me very excited about the idea.
 
 So far, I've been very happy of the reboot of our collaboration, and
 felt like it was just awesome new atmosphere. So I have to admit I'm a
 bit disappointed to read the above, even though I do understand the
 reasoning.

James is right. This discussion thread put a lot of faith in the
possibility that moving packaging efforts under the OpenStack umbrella
would magically solve our key blocking issues. (I'm guilty of it as much
as anyone else.) But really, we the collaborators are the ones who have
to solve those blocking issues, and we'll have to do it together, no
matter what banner we do it under.

 Anyway, does this mean that you don't want to push packaging to
 /stackforge either, which was the idea we shared at the summit?
 
 I'm a bit lost on what I should do now, as what was exciting was
 enabling operation people to contribute. I'll think about it and see
 what to do next.

It doesn't really matter where the repos are located, we can still
collaborate. Just moving Ubuntu's openstack repos to git and the Debian
Python Modules Team repos to git will be a massive step forward.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[Allison Randal]

On 06/03/2015 03:31 PM, Haïkel wrote:
 2015-06-03 23:41 GMT+02:00 Allison Randal alli...@lohutok.net:
 
 I have to disagree on that point, integration with underlying OS and low-level
 services is important. If that integration doesn't exists, it's
 off-loaded to the
 operators. So downstream packages bring more value than pip deployment,
 as it will pull dependencies (not just things from PyPI), working combination
 with underlying OS components etc.
 
 Packages could be used in a variety of different configurations, even ones we
 didn't expect. Any sensitive scenario that we can't support is likely
 to be a packaging
 bug for me.
 
 In some cases, it makes sense for fine-tuning, but generally, you just want to
 get things work and tweak your configuration.

Oh, yeah, I'm making an implicit distinction here that should be
explicit. There are two different types of dependencies for an OpenStack
service:

- system dependencies that have to be installed on the same machine as
the service, like a Python library used within the Nova code

- service dependencies like a database, message queue, or other
OpenStack service, which might be running on the same machine or might
be running on a completely different machine

System dependencies should be installed by the distro packaging, and
you're right, distro packaging has an advantage over pip for installing
non-Python system dependencies. (Though, typically with pip you're using
it over the top of some other system config management tool, so the
disadvantage is easy enough to iron out.)

Service dependencies is where the problems lie, because neither pip nor
distro packaging were designed as orchestration tools.

 Both pip and distro packaging should be consumable by any set of config
 management/orchestration tools, which means just install the software
 with minimal configuration.
 
 +1
 As a matter of fact, I prefer that packages to be as agnostic as
 possible about the
 deployment and let that work to the orchestration tool.

I'm a big fan of using the right tool for the job.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[Allison Randal]

On 06/03/2015 01:30 PM, Sean Dague wrote:
 
 So wouldn't that be more of an arguement to move as much of the
 installation logic back into the python packages as possible.
 
 So that pip install nova was a thing that you could do, and get
 reasonable results, and then the packaging teams would work around
 bundling that and handling dependencies sanely for their platforms.
 
 The closer we can get logic about what a service should look like on
 disk back into that service itself, the less work duplicated by any of
 the installers, and the more common OpenStack envs would be. The fact
 that every installer / package needs to copy in a bunch of etc files
 (because the python packages don't do it) has always seemed rather odd
 to me.

TBH, I don't think pip or distro packaging are ever going to be the
right answer for fully configuring an OpenStack cloud. Because, there is
no one true cloud, there are a variety of different configurations and
combinations depending on whether you're in a dev/test scenario, running
a private cloud, a public cloud, how many machines you're deploying to,
what services you want to run on which machines, what your underlying
network looks like, etc, etc...

Having pip or distro packaging that's very opinionated about configuring
a large set of related services is worse than useless when it's fighting
against the configuration you need. It's on the order of installing the
nginx package and finding that apt has set up a Wordpress instance and
database you didn't want or need. Operator's nightmare.

Both pip and distro packaging should be consumable by any set of config
management/orchestration tools, which means just install the software
with minimal configuration.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[Allison Randal]

On 06/03/2015 07:22 AM, Thomas Goirand wrote:
 
 However, talking with James Page (from Canonical, head of their server
 team which does the OpenStack packaging), we believe it's best if we had
 2 different distinct teams: one for Fedora/SuSe/everything-rpm, and one
 for Debian based distribution.
 
 We could try to work as a single entity (RPM + deb teams), but rpm+yum
 and dpkg+apt are 2 distinct worlds which have very few common
 attributes. So even if it may socially be nice, it's not the right
 technical decision.

Taking a step back, even though the tooling and packaging formats are
different, it is a massive benefit to OpenStack and to operators if the
end result of installing OpenStack packages on any distro is as similar
as possible. To that end, this should be one unified packaging team
focused on delivering a usable OpenStack through the distros.

Allison

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] developer survey on contribution policies

[Allison Randal]

Hi all,

I'm gathering input on developer perspectives about CLAs and other
contribution policies. While you're clicking through voting for PTLs,
I'd appreciate it if you could take an extra 5 minutes and click through
the developer survey too:

http://survey.lohutok.net/

I'm aiming for a broad and diverse representation of developer
communities, so feel free to pass this along to anyone you think might
be interested.

Thanks,
Allison

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] developer survey on contribution policies

[Allison Randal]

On 09/28/2014 11:30 AM, Tim Bell wrote:
 Can you give some more details on the survey with respect to 
 OpenStack ? I have both a developer contribution policy survey and a 
 project contribution policy survey.
 
 It would also be good to have more background as to the interest in 
 obtaining the survey results and what you intend to do with them 
 since this is not clear from your post.

It's a topic I've been interested in for over a decade, as I've worked
on various different open source projects, in various different roles.
People sometimes talk about what most projects do or what most
developers want, but I've never seen any data to back up those
statements. It can be difficult to have a genuine conversation around a
large unknown center.

The idea for this particular survey started in the last face-to-face
meeting of the OpenStack Foundation board, on the topic of CLAs. I
promised several people, but especially Josh McKenty, that I'd gather
more concrete statistics on developer opinions about contribution
policies, and on project usage patterns for CLAs and other contribution
agreements (how common they are, how they're applied, etc).

The survey isn't just for OpenStack developers, it's for all FLOSS
developers. I'll make a blog post noting general trends across the
entire FLOSS community. But, I'll also put together a very condensed
informational slide of the results for the OpenStack Foundation board
meeting in Paris.

Allison

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

[Allison Randal]

On 09/23/2014 02:18 AM, Thierry Carrez wrote:
 The main goal of incubation, as we did it in the past cycles, is a
 learning period where the new project aligns enough with the existing
 ones so that it integrates with them (Horizon shows Sahara dashboard)
 and won't break them around release time (stability, co-gate, respect of
 release deadlines).
 
 If we have a strict set of projects in layer #1, I don't see the point
 of keeping incubation. We wouldn't add new projects to layer #1 (only
 project splits which do not really require incubations), and additions
 to the big tent are considered on social alignment only (are you
 vaguely about cloud and do you follow the OpenStack way). If there is
 nothing to graduate to, there is no need for incubation.

There's no need for incubation, as such, but it's worth taking the time
to think about the technical and social functions that incubation and
integration served (sometimes ineffectively, or only as side-effects),
and what will replace them. You've identified a few there:

- learning period for new projects
- alignment with existing projects
- stability (in which gating served as a weak crutch, and the real
answer will likely lie in more extensive cross-project communication,
also carefully filtered to avoid information overload)
- respect of release deadlines (which doesn't necessarily mean releasing
all at the same time, just being cognizant of network-effects of
releases, and the cadence of other projects in an up-or-down dependency
relationship with yours)

 In Monty's proposal, ATC status would be linked to contributions to the
 big tent. Projects apply to become part of it, subject themselves to the
 oversight of the Technical Committee, and get the right to elect TC
 members in return.

And, a few more here:

- transitioning from island to part of the big tent
- accepting oversight of TC
- accepting responsibility to participate in TC election

Allison

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] a small experiment with Ansible in TripleO

[Allison Randal]

On 08/04/2014 08:19 AM, Clint Byrum wrote:
 I've been fiddling on github. This repo is unfortunately named the same
 but is not the same ancestry as yours. Anyway, the branch 'fiddling' has
 a working Heat inventory plugin which should give you a hostvar of
 'heat_metadata' per host in the given stack.

Cool, Monty and I have that merged now. And, I've got a working Ansible
module for nova rebuild:

https://github.com/allisonrandal/tripleo-ansible/blob/master/library/cloud/nova_rebuild

 Note that in the root there is a 'heat-ansible-inventory.conf' that is
 an example config (works w/ devstack) to query a heat stack and turn it
 into an ansible inventory. That uses oslo.config so all of the usual
 patterns for loading configs in openstack should apply.

This is really elegant, I'll follow suit in the example playbook for
rebuild.

Allison

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] a small experiment with Ansible in TripleO

[Allison Randal]

A few of us have been independently experimenting with Ansible as a
backend for TripleO, and have just decided to try experimenting
together. I've chatted with Robert, and he says that TripleO was always
intended to have pluggable backends (CM layer), and just never had
anyone interested in working on them. (I see it now, even in the early
docs and talks, I guess I just couldn't see the forest for the trees.)
So, the work is in line with the overall goals of the TripleO project.

We're starting with a tiny scope, focused only on updating a running
TripleO deployment, so our first work is in:

- Create an Ansible Dynamic Inventory plugin to extract metadata from Heat
- Improve/extend the Ansible nova_compute Cloud Module (or create a new
one), for Nova rebuild
- Develop a minimal handoff from Heat to Ansible, particularly focused
on the interactions between os-collect-config and Ansible

We're merging our work in this repo, until we figure out where it should
live:

https://github.com/allisonrandal/tripleo-ansible

We've set ourselves one week as the first sanity-check to see whether
this idea is going anywhere, and we may scrap it all at that point. But,
it seems best to be totally transparent about the idea from the start,
so no-one is surprised later.

Cheers,
Allison

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] a small experiment with Ansible in TripleO

[Allison Randal]

On 08/01/2014 12:06 PM, Galbraith, Patrick wrote:
 I have been working on Ansible nova_compute, a new “nova_facts”
 module as well as the nova dynamic inventory plugin, so please do
 feel free to collaborate with me on this.

Great, are you on #tripleo? I'm 'wendar', and I'm working on this bit.

Allison

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev