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
** 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
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
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. HP example here. Once they answer, we point
out that the
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'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 to
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
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
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
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
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
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
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
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
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
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).
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
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 davewal...@ubuntu.com wrote:
I
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 davewal...@ubuntu.com wrote:
I really
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
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
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
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 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
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
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
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
(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
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
30 matches
Mail list logo
