This bug was fixed in the package maas - 1.5+bzr2252-0ubuntu1
---
maas (1.5+bzr2252-0ubuntu1) trusty; urgency=medium
* New upstream release
- Add support to install Third Party Drivers. In order for this to be
used the user will have to go to the Settings page to enable th
** Branch linked: lp:ubuntu/trusty-proposed/maas
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1305839
Title:
FFe: Support for Third Party Driver Installation
To manage notifications
If you land code for this feature without tests then *please* file a bug
(tagged tech-debt) and let us on the MAAS team know so that we can
either write the tests or help you write the tests. If you don't file a
bug, chances are it's going to get forgotten about.
I've already filed bug 1307906 for
It has to do with automating the installation of MAAS environments,
which includes automating the installation of MAAS itself. In particular
this is important to our Openstack cloud-installer and for bootstrapping
'other' environments.
--
You received this bug notification because you are a membe
To Robbie's point - yes, it makes no sense to make the install break
mysteriously when we can get it to work, any more so on a server or a
phone. It does make sense to flag in the UI when we have used drivers
outside of the normal Ubuntu kernel set. We're not installing
proprietary applications, I
> So I was informed that prompting for non-free during installation would
> break unmanned installs of MAAS, which causes problems for our cloud
> install plans.
I'm trying to sort out what this means. Do we actually care that the
maas *controller* be installable with zero intervention? Why is t
For context, here's the branch I'm working on. It handles the insecure
key retrieval problem. I plan on handling the udeb problem by inserting
the keyring into the preseed, retrieving Release/Release.gpg for the
repo, using the keyring to verify the Release file, then using the sha
sums to verify t
Looks like ash can support hexadecimal escaped strings - so that's a way
forward for me.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1305839
Title:
FFe: Support for Third Party Driv
On 04/14/2014 08:45 AM, Adam Conrad wrote:
> The whole point of having the key is to give you a trusty path to the
> (u)debs, surely?
Yes - we need it for the udebs, and for setting up the repository in the
installed system. I'm still trying to work out the details on how to
verify the udebs given
Would it be a better approach to simply display a notice in the MAAS Web UI
and maybe when we do the initial MAAS setup, notifying the user that this
setting is enabled by default?
On Mon, Apr 14, 2014 at 9:24 AM, Robbie Williamson <
robbie.william...@canonical.com> wrote:
> I'm in favor of the
So I was informed that prompting for non-free during installation would
break unmanned installs of MAAS, which causes problems for our cloud
install plans. I'm all for supporting our commitment to non-free, but
at the end of the day, we're also committed to ensuring our users have a
great experien
> I've posted a branch now that inserts the key directly into the yaml instead
> of retrieving it via http.
> Still working on a way to securely retrieve the udeb. The repo has a sha1 on
> the udeb; just need to
> work out how to validate the repo's sha1 now.
The whole point of having the key is
Some responses to Dave's comments:
* Yes, it was done quickly and isn't perfect. It's a minimum useful set
of functionality to address a real use case and that improvements can be
added iteratively with the benefit of getting feedback from users in the
meanwhile.
* fastpath can be added without
I'm in favor of the approach suggested in comment #12, whereby we prompt
the user during the first install of MAAS, as to whether they want to
allow the install of non-free drivers for such cases where there are no
free ones available, e.g. . Once they answer, we point
out that the setting can be
I'm not sure our approach on phones should be held up as a benchmark
here, it was a pragmatic solution to rapid iteration on devices that
weren't built for Ubuntu. It's also code that we "control" (from the
point of view of us shipping it in the archive, us being able to audit
and fix it, etc).
E
Hi,
I think everyone is largely aligned with the freedom aspects of this.
This is certainly not a concern for myself at least.
What is concerning to me, is that this feature feels rushed and somewhat
unfinished. I just had a quick look at the code that landed for this
feature:
There is no suppo
The key difference in my mind is recoverability. In the server case, the
install is by nature largely automated, and often will fail altogether
if you don't for example have the ability to configure your hard drives.
Perhaps an analogy for the desktop would be to ask the question - what
if a popul
So, it's been noted that this is slightly different from the
desktop/ubiquity case only in that the ubiquity case presents the user
up-front with the "do you want non-free stuff?" toggle on an installer
page, while maas is putting it in a settings page.
So, for starters, I think the settings page
(To be clear to people following along, I'm fine with Mark's assessment
and explicit ACK of the FFe, and we'll happily accept the feature being
uploaded under his conditions of being heavily tested, etc, the above
quibbling is only about if the feature is on or off in a default setup)
--
You rece
Right, so the key here (on the software freedom front), as it was with
ubiquity when we discussed it, is that the option needs to be off by
default. If a sysadmin turns it on (and I don't doubt that many will),
that's entirely fine, but they need to be the ones explicitly making the
call.
If we m
Also, thank you Adam for pointing out that we need to do the same sort
of ubiquity- and jockey-like calling out of the issues associated with
binary blobs on servers that we do on the PC. I'll get the MAAS folks to
make that very clear on the node page as a way of socialising the
benefits of open d
Thanks all for the comments and discussion.
Responding to some key points:
* building confidence in code changes both for this FFE and subsequent
SRUs is important, the archive and RM teams have a mandate to seek
comfort on that front before ack'ing an upload under either
circumstances
* in ot
On Friday 11 Apr 2014 12:26:59 Adam Conrad wrote:
> Can you test the crap out of the new codepaths here, especially in any
> way that they interact with existing functionality (ie: the web UI,
> etc)? If you guys are satisfied that this won't make anything any more
> broken than it already is, I m
Adam,
This was tested yesterday both manually by us and was also tested at a
customer site with successful results. We will give him another round of
testing. Sorry if I've been causing too much of a headache for you! I hope
you understand that me pushing this is due comes from high up. Thanks.
On
Can you test the crap out of the new codepaths here, especially in any
way that they interact with existing functionality (ie: the web UI,
etc)? If you guys are satisfied that this won't make anything any more
broken than it already is, I might be inclined to be a Very Nice Person,
and let you sli
Hi Adam,
Sorry for the misunderstanding but to me the answer to my question ("Yeah,
I think that would satisfy me.") as to whether this was enough to get the
FFe approved sounds like an unofficial ACK.
So the question is now... Will this be ACK'd or NACK'd?
On Apr 11, 2014 8:16 AM, "Adam Conrad"
I wouldn't say I "unofficially approved the FFe", that's twisting my
words and the content of our conversations. I gave you the reasons why
I would flat out reject the upload (FFe or not), and even petition to
have it removed from the archive if the "install non-free software by
default" feature s
There's no regression potential per se because this doesn't affect the
current Maas operation as this will only be in effect if the user enables
the capability. Other than that this has been QA'd and testes on the field.
On Apr 11, 2014 4:50 AM, "Dave Walker" wrote:
> I really struggle to support
Hi Dave,
It is a certification requirement hence needs to be on the ISO. We had
discussed this with Adam and he had been reviewing the code and gave us
pointer to address. He unofficially approved the FFe before final freeze.
On Apr 11, 2014 4:50 AM, "Dave Walker" wrote:
> I really struggle to s
I really struggle to support this change. It is a clearly impactful
change. FFe raised on the day of Final Freeze. Feels rushed. There is
no commentary on the regression potential, or the testing done.
Not to mention that RC1 was happily released with a broken MAAS
installer, that took 2 weeks
30 matches
Mail list logo
